Not sure why… it just runs on top of KMS/DRM right but ties all the features together, but maybe that would really be a job better done by app_server for reasons of design choices that they have made in wayland. I think the question to ask is… which allows the least changes to app_server, and provides the most benefits with the least work. If implemented directly on KMS/DRM then I think there is some work app_server needs to do to ensure tear free functionality that wayland guarantees.
Something to consider is that the developers and environment that birthed BeOS were not anything like Haiku… they may have had many of the same mindsets but vastly different constraints. Today Haiku is constrained by design considerations far more than hardware considerations that constrained BeOS. A Principle that Jim Keller has mentioned is that you should seriously consider a redesign every few years or be left in the dust… clearly that is a principle best applied to projects with lots of money, but after 25 years have passed it probably applies here too.
All hardware-dependent work in app_server is done with accelerant add-on that is dynamically loadable module. DRM specific accelerant can be packaged in DRM package, no changes are needed for app_server itself.
Of course I only expressed my personal opinion. As for the path of least resistance, well, it happens that I find the Linux code messy and hard to follow. So I prefer to write the drivers myself. Feel free to prove me wrong by managing to port the Linux drivers (or run the whole Haiku userland on top of the Linux kernel or whatever, at this point).
The thing is, I’m as annoyed as you by hearing talk and talk about how just using the Linux driver would be faster and simpler, yet no one actually wants to work on it. So, until then, I’ll be maintaining and improving the existing driver, and keeping it up to our standards of code readability and cleanliness. For me there is less resistance this way, and I’m learning things about graphics card along the way.
Ports can be used to interact between app_server accelerant and client with OpenGL context. Client can also load accelerant in client mode, this is already used by BWindowScreen.
DRM driver from BSD may be simpler to port. I looked at Linux and BSD DRM kernel modules and BSD one is less messy and easier to port. I tried but not managed to compile it yet, fixing missing/conflicting/incompatible headers is needed.
You have previously emphasized how switching to Wayland will magically solve all the problems we have with graphics architecture, how app_server is designed in a way that will prevent accelerated graphics, how the BView drawing APIs are un-accelerateable due to their design, etc. etc. etc. etc., and I have previously demonstrated that all of these misconceptions are just plain false.
The only thing holding Haiku up is the same thing that has always been holding Haiku up: We are volunteers and we do this in our spare time. That’s it.
Current accelerant API already has ability to distinguish host/client mode. Host (app_server) initalize accelerant with B_INIT_ACCELERANT, client (BWindowScreen etc.) initalize accelerant with with B_CLONE_ACCELERANT. So port trick is not needed. Only major change needed to be made is adding display id.
How about not responding with a cop out… thanks. Just don’t reply at all if you aren’t going to add anything beneficial you made this into an argument rather than a discussion. I didn’t say anything would “magically” be solved at all, porting the app_server to render to DRM/KMS or Wayland is a valid path… but its asinine to think the current graphics architecture on Haiku should be retained it’s literally at least 20-25 years old doesn’t support any of the wanted features, and every other operating system on the planet that does desktop graphics has been through 2-3 complete graphics system rewrites since then. You may as well adopt a modern graphics architecture by just directly porting it, instead of porting it peacemeal into an old system which will likely require years of work.
No. It won’t require years of work, we have been over this before; and now, and independent programmer (X512) has come along and agrees that it can be added to the current system without much work. We disagree slightly on the best method, but not on whether the methods themselves will work or not.
Again, Wayland is about application-to-server communication and related protocols, i.e. the equivalent of libbe-to-app_server in Haiku. It has not a whole lot to do with KMS-DRM itself, if anything, really.
“Any of the wanted features”, really? What wanted features do we not have besides 3D acceleration? Compositing app_server? That also won’t take “years” (looncraz had it working, and the code still exists somewhere) if we decide it is actually beneficial.
Linux has indeed had multiple rewrites or major overhauls over the past 20-25 years. So what? X11 dates from the 1980s, and apps written against the X11 protocol then will probably still work now. Haiku’s app_server protocol dates from the mid 2000s, and also took some unorthodox design choices that absolutely hold up today. Wayland is, IMHO, a somewhat bad design in general, and especially bad for us in particular, for a long list of reasons I’ve enumerated before.
Age itself don’t make architecture worse, if it was properly designed no rewrites are needed. Hardware acceleration, multiple screens, remote desktop, multiple user sessions, tearing and flickering free rendering, fast screen video capture can be implemented with current architecture without major rewrites. Can you list your wanted features that need graphics system rewrite?
You again completely missed the point… why invest the work in updating Haiku’s architecture to support all these things, it definitely does not support, when you can adopt what already exists and reduce maintenance burden at the same time. The further you deviate from existing implementations the longer it it will take to update it in the future.
@waddlesplash I didn’t say anything about rewriting app_server… I said ditch the current graphics driver architecture if you are going to continue to reply do bother to understand what I clearly said.
Lets be very clear graphics acceleration barely even existed from BeOS’s perspective and was a roughed in API… certainly not finished so it’s pretty much irrelevant to running any relevant BeOS software as nothing actually uses that outside of a few vintage drivers, that Linux has support for that hardware anyway.
What do you mean by “all these things” and what you want to adopt? If Wayland, it definitely not needed, it is not complete, major Linux distributions don’t use it as primary display server. Support DRM directly is simpler than introducing Wayland. Note than Wayland is not just about graphics, it also handle input in a way incompatible with Haiku.
You listed about half of them yourself and some of them are quite large features… lets also not forget pulkomandy and how Haiku’s current drivers can’t even render graphics on anything newer than I think sandy bridge. Vega doesn’t really work in anything but fallback mode and Navi certainly doesn’t.
Tear free rendering is like at least 50% of the impetuous behind the Xorg developers developing wayland… to begin with.
I mean the KMS/DRM/DRI infrastructure from Linux … port it all as is with minimal changes. Have App server just render directly to that… instead of to an old BeOS style driver as a DRM/KMS client. What I’m saying is if we are going to port drivers… lets port them and use them as is, otherwise you are just throwing layers in there that really don’t’ even need to be there for any reason. And you’re going to have add new features to those layers to even fully support the underlying driver! The only BeOS style drivers you’d need to keep would be the one’s Linux doesn’t have a KMS driver for… and that is indeed quite little hardware.
Now you are just moving the goalposts; earlier you said that it could not be done, now you are just talking about “investing the work”.
You also keep talking about “the architecture”, as if it is “the architecture” that does not support these things, rather than there just not being code to handle them…
You talked about using Wayland. How is that not rewriting (or replacing) app_server?
It did not really exist at all, the Accelerants API has basic 2D acceleration hooks (optional, and we don’t use them anyway), it didn’t have anything for 3D acceleration at all. The NVIDIA acceleration system based on UtahGLX had an accelerant, but the 3D commands went through a different interface. That’s all.
You keep ignoring (as you did last time we had this discussion!) that Wayland is a standard. It is not an implementation, it provides no code that deals with KMS-DRM or anything else. There is a reference implementation (Weston), but plenty of Wayland compositors do not use it at all!
Yeah, and? As I noted last time, there are multiple implementations of Wayland compositors, and each has their own code interfacing with KMS-DRM. Even SDL2 had a “raw” KMS-DRM backend, at some point, so you could run SDL apps on top of a KMS-DRM surface!
You are not a kernel programmer, so I don’t really know why you think you are qualified to weigh in with technical opinions. That you want acceleration, or support for modesetting on newer hardware at all, etc. etc. are obviously things that any user can (and should!) have opinions about. But opinions about the what/how/why we get there, please do not try to make when you simply don’t know what you are talking about.
Using wayland would not require rewriting app_server it would just become a Wayland compositor, or alternatively a client of an existing compositor. Regardless you and your stuck mindset clearly have been extremely productive in this area right???
I’m not relpying to you any more in this topic as you are clearly set in your mindset and unwilling to think outside the box, and want to keep the task for yourself as you envision it despite never working on it and submitting any code to do anything about it.
Also stop replying with quotes it’s completely unreadable. I know what I said I if I want to see it again I’ll scroll up 3 inches.
Right, in that case it would require completely rewriting the Interface Kit, the Decorators APIs, our Remote Desktop server, and probably some other things I’m forgetting, since right now all of these speak the app_server protocol exclusively (and it’s worth noting, they all rely on app_server to do their rendering and just send it drawcalls, so that would be an even more substantial change than it sounds.)
LOL.
I literally said earlier in this thread that I was in no way stopping (or even requesting as such) other people from working on this.
I also note that I do not have any magical authority here, and if the other Haiku developers thought my ideas and design were bad, there was a better way, etc. they would say so.
When posts have more than one idea in them and one is replying to each individual idea separately, they provide immediate context for what is being responded to. You can hide the quotes if you really don’t want to see them, so why criticize me for using them?
No you would just plunk it all in a buffer… and slap it on the screen with no changes to the current app_server code. You could do what you say…but none of that is needed for a functional system on top of a wayland compositor (I was going to just say wayland but that seems to get your hackles up). It would be basically doing the same thing XWayland or even nested app_servers do. But yes that may be silly if you can just target DRM/KMS/DRI directly… wayland is just a way to do that in a standardized way. The only reason I can think of to do that is you are following a beaten path.
