DirectWindow is for the window’s direct access to the hardware, so if there’s a DirectScreen, or DirectDisplay to go along with that, is that OK, or would it be overkill?
There is DirectView too.
What do you want to do?
I want to port wayland. It seems simple enough, as there’s already a haiku-drm port and the mesa driver. So if I can port wayland then could it be used to as a base to start a wayland-based app_server?
We already have app_server, why would we want wayland?
2 Likes
Why not? Being open-source is all about choice, right? Exercising ideas, that sort of thing. It doesn’t need to be one or the other. Besides it seems like it would be a cool thing to see.
Haiku isn’t all about choice, it’s about a coherent well putt together system.
Now we already have a perfectly working application server, where is the benefit in ripping some protocol from linux and trying to force it into haikus servers? as far as i can tell the app_server already works better than wayland, and wayland doesn’t seem suited to operate as an application server we can use without changing a lot of stuff for basically no benefit.
5 Likes
Wayland is a display protocol. It allows you to define your display settings for different aspects of your system using xml. The app_server would still be the app_server, but like k/qt-wayland it would be acting as the implementation of the wayland protocol.
XML is a prescriptive part of wayland, it isn’t the wire protocol, the application server already has it’s own protocol which is working now, and /doesnt/ follow the wayland model at all, we don’t use compositing and the majority of texts and ui controls is drawn by app_server directly, compared to X11/wayland where nowadays almost nothing is drawn by them. One of the advantages of haikus app_server+input_server is the low input latency it produces, atleast in my (biased) anecdotal evidence that doesn’t seem to be the case for any wayland implementation i know off.
Again, where is the benefit?
“we don’t use compositing and the majority of texts and ui controls is drawn by app_server directly, compared to X11/wayland where nowadays almost nothing is drawn by them”
I know: a reply to a previous question about compositing told me that the app_server is using software rendering in memory and not hardware rendering
“One of the advantages of haikus app_server+input_server is the low input latency it produces, atleast in my (biased) anecdotal evidence that doesn’t seem to be the case for any wayland implementation i know off.”
Actually kwayland/qtwayland are supposed to be low-latency, but again that opinion is probably biased based upon the respective platforms. E17 is definitly supposed to be low-latency, but I’ve not used it for a long-time.
“Again, where is the benefit?”
Well I could say hardware-rendering/compositing, lots of glossy 3D effects, but it all depends on what you want from the system you’re using. What’s the harm, in trying it a different way?
none of those things require wayland, or even any other application protocol.
as for e17, enlightement had one of the worst input latencies i’ve ever seen on linux, so much so that it was the main factor keeping me from ever using it.
I don’t see what good the question you stated poses, I don’t see any benefit, but i see lots of disadvantages, you can of course work on this if you want, but it is really doubtfull that app_server will ever switch to wayland, especially because it is so different in design.
1 Like
It was the Tizen folks who worked on e17, so the input latencies, according to them, is really good.
But just for the sake of… Could you list your disadvantages? Would that be OK?
You could spend your knowledge on other needed fields for the Haiku Community instead.
What about a port of Snes9x a Nintendo Super NES emulator
or BSnes for 64bit?
The libretro port is just too slow on slower PCs
Lots of people would benifit!
Isn’t there a port of that mace emulator? that’s got all of the carteridge games from the snes, psone, atari and commodore?
BDirectWindow and similar are obsolete, don’t use it. If you want to make your own GUI server instead of built-in app_server, you need to use Haiku video driver API called “accelerant” or implement/port your own drivers. See SlimDemo from BeOS sample code to know how to use video card directly without app_server.
How are you expecting to run Wayland server in Haiku? In a Haiku window? Rootless windows? In fullscreen replacing Haiku native app_server? In last case do you plan to support Haiku GUI applications and if yes, how?
No, only early attempts. Nothing is working now.
Haiku Mesa port is currently support only LLVM-based software rendering, no hardware-accelerated drivers.
i actually don’t know how to answer! To begin with I was thinking along the lines of kwayland/qtwayland (client->compositor->server) type thing, but as everyones saying that would be pointless, I don’t feel much motivation.
New Things and other peope thinging in other ways are never bad. Without it we never get qt and all the qt apps for haiku.
If you think it make sense, if it is possible to do and you can include it into the system, why not?
But yes it would make more sense so join haiku dev team to make haiku better.
I do think it’s doable, and I think that it would benifit Haiku. But that’s just me, the other replies here are saying that it’s pointless, so I should focus my efforts elsewhere. By the way, would there actually be a use for a native framework like libretro, openemu, or others for playing games. I’m asking because I think building a native kit for that would allow you to do more?
In Linux, there are two display servers, x and Wayland. The developers of apps have to make sure that their software works fine with the both of them and the users have to think of the display server when choosing a distro. Back in the day, I didn’t know what a display server is before trying a Linux distro and as the end user of the desktop operating system, I shouldn’t have to know or care.
In Haiku, you have this one display server that all software is designed to use, and it is designed to work perfectly with all Haiku usoftware. This is Steve Jobs’philosophy of having one perfected option instead of a paradox of choices
That is not to say that Linux is objectively bad, but one of the biggest reasons to use Haiku instead of Linux in the way that it favors sane standards instead of a jungle of software that are not always inter-compatible. If we started porting unnecessary system components just for the sake of, like in Linux, having choices, Haiku would become “Linux but not really,” and we don’t want that now, do we?
You can try porting Wayland to Haiku, but if you ask me your efforts would be better invested in improving the native server or improving the OpenGL support or something like that.
1 Like
I agree that improving the native server and OpenGL for hardware-acceleration, would probably be a better investment, but if you guys don’t think that then the efforts still wasted
There is RetroArch /Libretro which is far too slow in emulating:
RetroArch BSnes:
RetroArch SNes9x:
And the original Snes9x (32bit):
This is on Intel Atom 1,6GHz Haiku 32bit
It would be a challenge to get new native fast port for 32 and 64bit!
Could be your Quest
RetroArch is too big and slow and works only on fast Computers