Libdrm now officially supports 2 operating systems upstream!

[cb88]

Lemme just quote myself since seem to think I didn’t originally say KMS/DRM… sheesh. Also all of those clients are things like terminals or SDL… not full featured desktops so yeah it is likely they don’t use every feature of KMS/DRM. If KMS/DRM is the ideal dividing line of where Linux driver land and then so be it…

I don’t see porting DRM/KMS/DRI lock stock and barrel as being harder or more work than porting just the parts needed for 3d drivers + updating existing drivers on Haiku to support that. It should be less work since you’d be leaving more things as is, as well as gaining a way of getting new hardware support in faster…

@cb88

That basically leaves implemeting app server directly on KMS/DRM or on top of wayland…

[cb88]

@waddlesplash

That’s simple… it would exist by now probably.

And everyone also loves to tell us how Haiku would be out of beta by now if we had just used the Linux kernel, etc. etc. It’s probably true, but it also completely misses the entire point of Haiku.

That was also uncalled for… it’s blatantly obvious that the Mesa3d drivers are the only way to get any modern open source 3d support. I know that, you know that, everyone knows that. I am only advocating using more of the graphics driver infrastructure from Linux built around that so that a) porting time is shorter, b) maintenance is ligher/faster/etc… c) we get more features sooner and more hardware support as as a nice bonus. By adopting what Linux has, you get something that is basically state of the art at this point. The only thing missing would be SLI, and that’s a dead technology.

There is nothing about the Haiku graphics driver architecture that makes it special unlike some other areas of the kernel or APIs… reason being there wasn’t a whole lot for it to do back in the day so.

I’m not contesting the fact that you could do this all as you planned previously and end up with a nice C++ graphics driver + Mesa3D and it work… but it almost certainly would not have even half of the features of the Linux graphics drivers… evidence to that effect is the current state of the 2D graphics drivers on Haiku… some of the output times don’t even work except on certain hardware! Then you have to consider how many man months all of that would take , and how many man months it would take to go the other way with it. app_server as a DRM/KMS client doesn’t sound like man months to me…

Precedent for this even exists already in Haiku… as I already mentioned with the wifi and network drivers from BSD.

Also some would say fork from BSD’s graphics… I would caution that leaves you at FreeBSD’s whims as to when drivers get updated, you’d only have access to trailing edge of the trailing edge driver updates. And it;s a lot harder to swap a graphics card/chip/IGP than swap a wifi card for compatibility.

All the comebacks for this are rehashes of what went on with the wifi drivers… but I don’t see a single soul complaining about them now.

Would I donate significantly to such an effort… yes. Would others I bet so… its been like the top most wanted thing on Haiku for a decade.

[waddlesplash]

@cb88

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 are missing the entire point. The Interface Kit, right now, has no idea how to draw a rectangle, or where it would even go if it did. It asks app_server to do that, by sending a “Draw Rectangle” command, and app_server draws the pixels into the back-buffer – or sends the command itself through to a remote desktop client.

If you deleted app_server, you couldn’t just “inline” the code it has into the Interface Kit, because there is no buffer management in the Interface Kit. So you would have to write all of that.

It’s also worth nothing that I don’t think Wayland allows or supports off-the-main-thread drawing operations. So you would also have to write a marshaling system of some kind to make buffer flips (at least) occur across threads.

Care to take any guesses at how many man-months it would take to re-engineer the Interface Kit like that?

@cb88

There is nothing about the Haiku graphics driver architecture that makes it special

This is blatantly wrong. Haiku offloads a lot of the graphics driver work into userland accelerants (more than was ever done in userland even before KMS-DRM modesetting, I believe, but I am not an expert.) Now, this is not “unique” in the sense that microkernels exist and also run drivers in userland, but it is still pretty different from Linux’s, both then and now, and moving all of that into the kernel is indeed a change in architecture.

@cb88

as you planned previously

I don’t know who this “you” is, I never planned to write the kernel/userland side of the graphics driver in C++ as Haiku-specific code. That idea was thrown around years ago, I think, but not by me.

@cb88

app_server as a DRM/KMS client doesn’t sound like man months to me…

Good, so you agree with X512 and myself, then!

@cb88

but I don’t see a single soul complaining about them now.

??? ??? ???

Do you, like, not even read the forums and the bug-tracker? Besides unported drivers from FreeBSD (like the USB ones), there are quite a lot of reports about chips that FreeBSD does not support (like Atheros 10k, or Realtek 8822BE, or newer Marvell chips…)

And if you read Hacker News comments on FreeBSD release announcements, what’s the top comment most of the time? “It doesn’t support this WiFi feature,” blah blah, etc. etc.

Now, you can argue this is evidence we should have gone with Linux, or maybe we should reconsider it now, or whatever, but that’s not the point, the point is that people absolutely complain about it, as you say that “not a single soul” does now.

[cb88]

@waddlesplash

You are missing the entire point. The Interface Kit, right now, has no idea how to draw a rectangle, or where it would even go if it did. It asks app_server to do that, by sending a “Draw Rectangle” command, and app_server draws the pixels into the back-buffer – or sends the command itself through to a remote desktop client.

DUDE… provide a single quote of me saying or implying deleting app_server you need to take that back and apologize. There are like 5 comments at least above where I explicitly say don’t modify app_server except for it to become a client of DRM/KMS and or Wayland which implies writing buffers not primitives. Also below… you’ve been out of line for about a day or two now and now you abuse your moderation abilities to close the thread instead of just leaving…

Also… I asked to have this thread closed about a 3-4 days ago because of your initial comments and where they were going but… frankly I agreed that the discussion was interesting and probably even beneficial so conceded to let it go.

[waddlesplash]

I am locking this thread. The discussion has run its course and nothing further of value is occurring. Find me elsewhere if you think there is more to be said.