Well everyone has treated my thread as if it were IRC so… >:D
1 Like
But that checklist are useful, yeah Haiku now have office suite, and it make the operating system less useless, is the same with the gpu support, if we dont need graphics then we can pick a fbsd withouth xorg and it would be enough. And yes, when we have a 3d support we will want to have a good modern web browser to stay on haiku all the time and dont have to use linux, windows or fbsd. Is not so weird.
we need gpu support, obviusly we need a lot of things but it is a good start, or the office suite was so unuseful? no, is very useful.
1 Like
I’m joking of course but… what one person has gotten used to does not tend to match what most people would accept adapting to or even tolerate. Setting goals based on what the developers can tolerate… is well…intolerable to outside users.
1 Like
the alternative is simple here:
- I listen to you
- I put my focus on 3D acceleration that I don’t care about
- I can’t use my VGA display and I can’t use my web browser (the two things I’m working on currently)
- I give up, and start using Linux instead so I can use these two
- I stop working on Haiku
- Users still don’t get 3D acceleration
Is that a winning situation for you? It seems not for me.
So, I’ll keep my motivation for things that allows me to continue to run Haiku. It’s that simple. If I can’t achieve that, I’ll give up and use another OS. That’s all. We will look at 3D someday but at the moment I have much more important problems to deal with. There is no point racing into 3D support and letting all other parts of the OS fall apart.
8 Likes
@PulkoMandy I thought you weren’t the lead developer of Haiku a point you were very adamant about… there is a massive disconnect between your points and that. Nobody is asking anything of you personally. Keep doing what YOU do best and what you enjoy and that we continue to appreciate… all of this is tangential to that. If it happens it happens if not … nobodies fault really this is free software and people have priorities outside of Haiku and even different priorities as developers. Lets just continue to have this conversation and share ideas… honestly it feels way better than stagnation even if a few feathers get ruffled here or there.
Personally, I think the Haiku graphics architecture as far as kernel and drivers has been going down the wrong path… since it is so hard to get people with the skill and interest, the path of least resistance should be taken, basically port the entire Linux graphics stack with virtually no changes, and run app server on top of that if they dont’ have an accelerated driver at least the direct ported Linux Vesa drivers and fb drivers would provide basically identical support to what we have now, except support for newer hardware could just be direct ported the similarly to how the wifi and ethernet drivers from BSD are handled. From all I’ve read the advantages of the Haiku kernel have little to nothing to do with graphics drivers… since that design is stuck in 1998, so honestly why not just replace it with something completely new if it has no affect outside of the kernel itself (execpt maybe the screen/display preflet apps would need overhauls).
That would not even mean adopting wayland necessarily… even though I think that could work and would likely be less long term effort since it would imply more shared work with Linux. That basically leaves implemeting app server directly on KMS/DRM or on top of wayland… I would think the latter would be less work and have the potential for easier long term maintenance.
There are extremely few BeOS applications that interface with that side of things after all… so changing things to be maintainable… would be a big boon for everyone.
1 Like
Porting DRM and hardware accelerated graphics drivers can be done without any changes in userland Haiku code at all. Just add accelerant that setup framebuffer for app_server and make OpenGL render to offscreen GPU buffer, copy it to BBitmap and draw with BView::DrawBitmap. DRM drivers can be located in HaikuPorts and be optional. Any architecture improvements can be done later.
I already suggested that in Hardware graphics acceleration port idea.
Interacting with DRM to enumerate screens and setup framebuffer is not difficult. Porting Wayland feels more difficult for me and there are no need in it at all.
2 Likes
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.
1 Like
How would that interact with accelerated contexts… or even potentially implementing app_server with an accelerated fast path?
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.
3 Likes
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.
1 Like
Citation 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.
3 Likes
And too much of it is spent arguing with people on the forum instead of coding 
9 Likes
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?
2 Likes
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.
1 Like