Luc Modularizes Mesa, DRI Drivers

[miles]

So you think that my efforts to straighten out the X.org foundation are not very productive?

?

I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?

[libv]

?

I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?

Ok

Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me

[libv]

First; this is a very nice example where open source software is just awesome! Don't loke something change it.. sadly that is only true if you're a skilled programmer.

@luc (libv)
Why don't you simply fork xorg till they allow your structure to be THE structure to write drivers? You seem like someone that has the knowledge and will to do so and that will "fix" your issue of keeping your code working on xorg.. (if you fork, please enable ctrl+alt+bcksp by default again )

Anyhow, awsesome job however it turns out.

Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.

About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer

[miles]

Ok

Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me

That's ok, being an outsider anyway I do appreciate each and every one's work on Xorg, and I'm really happy to see developers like you working on improving the code

[mattst88]

Luc,

For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

Your work here on Mesa seems to be doing the opposite.

So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?

[libv]

Luc,

For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

Your work here on Mesa seems to be doing the opposite.

So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?

Moving drivers back into the X server is the single worst thing that people can do at this point.

Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

[libv]

at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

I am still working on a README, and will make more noise once i have had some shut-eye.

For the adventurous, here is the quick summary:
* pick versions that are very close to your current mesa version (libGL needs to match)
> ./autogen.sh [maybe want to add --prefix=/usr/]
> make dri-sdk
> make dri-sdk-install

Then you can build, install and run your dri driver.

[libv]

at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

I am still working on a README, and will make more noise once i have had some shut-eye.

For the adventurous, here is the quick summary:
* pick versions that are very close to your current mesa version (libGL needs to match)
> ./autogen.sh [maybe want to add --prefix=/usr/]
> make dri-sdk
> make dri-sdk-install

Then you can build, install and run your dri driver.

README: http://people.freedesktop.org/~libv/dri-sdk.txt

[daniels]

Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.

Tell me the story of radeonhd again? :P

About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer

We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?

[daniels]

Moving drivers back into the X server is the single worst thing that people can do at this point.

Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...