Luc Calls For A Dead Linux Desktop If Keith Gets His Way

[gordboy]

Jam Tomorrow

To me, the matter is quite simple. The current module model is simply not working. And the reason for that is patently obvious. Some of the ddx devs are to put it quite bluntly, not up to the task. And yet they still jealously guard their fiefdoms, uttering the same old tired refrains.

All we get is promises, promises, promises. Jam tomorrow. They can't even provide drivers for 5 year old hardware, so it is absolutely right that central control is restored. My guess is that the current (especially radeon) ddx driver "writers" will fade into well-deserved obscurity, despite the best efforts of some on this forum to keep them on their precarious pedestals.

Some ddx devs were not in attendance at the latest Xorg meet. The fact is, they were not missed in the slightest. In fact I'd go further than that : they stayed away because they knew they would be ruthlessly shown up to be muppets by people who actually know what they are talking about.

[allquixotic]

Welcome back, gordboy!

So tell me, what unsubstantiated crackpot reasons are you positing this time, for indirectly making ad-hominem attacks on people you don't even know for taking on a task you couldn't do better yourself?

And weren't you banned or something? Well, either way, go back under your bridge.

[ua=42]

wrong. You can pull just the git tree that was merged for that changes.

If you can't do that, you should not build your own kernels in the first place.

Yes. The average desktop user should be able to use git to pull only the specific driver updates they want and then recompile and install it themselves manually! This will definitely help ensure that Linux stays the #1 user friendly desktop.

[gordboy]

Playing Pontoon

Welcome back, gordboy!

So tell me, what unsubstantiated crackpot reasons are you positing this time, for indirectly making ad-hominem attacks on people you don't even know for taking on a task you couldn't do better yourself?

And weren't you banned or something? Well, either way, go back under your bridge.

Well since you asked, I'll be happy to provide some sort of answer to what I think is your question. People have every right to question the validity of a process that is clearly not working. And they do not need to know the perpetrators in order to make informed decisions.

As for the ad hominem question, it might be better if you examined exactly what you hope to achieve by making smug ad hominem attacks yourself. You have absolutely no basis to question my abilities. None whatsoever.

As for my previous ban, I think it is fair to say that many people here, even my detractors, think it was a step too far.

Indeed, it only made the adolescent, baying pack of idolaters scratching at the ground in impotent fury, demanding my instant dismissal, or better yet public execution, look like stupid bullies.

I thought the word from Camp AMD was that I was to be studiously ignored. Or did that message not reach your remedial facility ?

[pingufunkybeat]

LOL, we missed you, this will be fun.

[rafirafi]

Why?

Demodularize the xorg driver... sorry I've read the article but not seeing why? xorg developper are tired by lack of collaboration among them? with the graphics company? they are not enough (with competence)?
The messsage seems to be: work with us developping and correcting the bug or leave the boat...
and it makes not sense to think it is send to desktop users ("Dead linux Desktop") as servers don't use xorg.

My feeling is the work done with xorg is amazing and module system is great to use, and yes it happens you have to compile (even an input driver!).

[bridgman]

Keith's original post basically said "we should think about whether to move some things back into X - input probably makes sense, not so sure about video drivers, anyone want to volunteer to move their driver back into the tree and see how it goes ?".

The benefit of having all the drivers in the same tree as X is that you can change ABI with atomic commits, so the same commit touches both server and drivers. That allows git to give you compatible driver/server sets (in theory at least) without having to manually match commit X from the server with commit Y from the driver. The downside is that you would need to download source for the entire (server+drivers) tree in order to build a single driver (at least if you are using git). There is also a hope that developer and power user behaviour will change along the same lines as when the kernel graphics drivers were moved into the Linux kernel tree, where more people picked up an entire new kernel + driver rather than just patching a new driver into their existing kernel. The corresponding "desired behaviour" here would be picking up new X server and driver so that X server changes would get more testing during the development period.

All of the other concerns are "indirect", ie "if they do A then it's likely they will end up doing B, C and/or D as well". Put differently, making an ABI change today is a big pain in the *** for the developers and it doesn't happen very often... the concern is that if ABI changes become easier then they will happen more frequently and with less planning (resulting in more changes), so that the current ability to mix and match X server and driver versions will be reduced or eliminated.

The concerns are just that -- concerns rather than direct consequences -- but all of them have some validity. The core issue IMO is that without being very specific about the rationale for moving driver back into the server people end up having to guess the reason, and some of those guesses (if true) would lead to complications for users.

The discussion that hasn't happened yet (unless it happened this week, which is a good possiblity) is :

- the original reason for thinking about merging driver code into X was an anticipated wave of ABI changes -- what are they and how much time is the implementation/transition likely to take ?

- is the time period short enough that it is feasible to treat the work as a "big bang" change and only worry about "before" and "after", or will there be a real need for users to deal with picking compatible versions of X server and driver versions during the transition

- if the time period is too long for a "big bang" change, what are the options for managing compatibility (merging code into a single repository is only one option, albeit a good one)

- are there real advantages to keeping drivers & server merged after the ABI changes, or is this really a temporary need

etc...

I imagine there was a lot of hallway discussion about the above at the conference, resulting in the final decision.

EDIT - one last point -- the drivers are kind of being pulled in multiple directions... there are arguments for merging ddx back into the X server tree, but there are also good arguments for moving the driver components (ddx, libdrm, drm, mesa) closer together (ie away from the X server), as well as the argument for moving the kernel graphics driver into the Linux kernel tree (which has already happened). One point of view is that the current state represents a compromise between all of the conflicting pulls -- the question is whether it is "the best compromise" or "the worst compromise".

All of the arguments that were made for and against moving the kernel driver into the kernel tree apply here, I guess. The reality is that there is no one good answer (at least we haven't found it yet) -- moving the X drivers into the X tree provides a nice symmetry with moving the kernel driver into the kernel tree, but you still have dependencies between the X driver and libdrm (mesa/drm) which may be just as significant as the dependencies between the X driver and the X server.

It's a good thing there was a lot of beer available, or the discussion would have been even harder

[mugginz]

......Put differently, making an ABI change today is a big pain in the *** for the developers and it doesn't happen very often... the concern is that if ABI changes become easier then they will happen more frequently and with less planning (resulting in more changes), so that the current ability to mix and match X server and driver versions will be reduced or eliminated.

Off the top of your head, just how often do they need to happen? Are we still at the stage were there is a need for ABI changes to occur often enough to warrant this change? And if so I assume we're still a fair bit away from the end game of easily pluggable drivers.

Isn't there a forward looking plan for module inter-action that takes into consideration all of the requirements? Have they not been able to fully enumerate those requirements for the different sub-systems? And if they're the case I assume that we're still a bit away from the position of a fully architectured system and are still really in the design stage, not the implementation stage.

[bridgman]

I don't really know. My impression from the mailing list was that a larger round of changes than normal was coming down the pipe, but I didn't have time to read back and figure out what the changes were.

The X graphics stack has been around for over 25 years, and has evolved through several major changes in graphics hardware (from basic 2d-only through fixed-pipeline 3d to fully programmable 3d), so instead of saying "we are in design stage rather than implementation stage" it would probably be more correct to say "we are in implementation stage for enhancement iteration #20 and design stage for iteration #21", or something like that

Drivers will be easily pluggable when the world above and below them stops changing. The "big picture" is a belief that the current programming model for graphics hardware will last long enough to justify re-syncing the stack around that model. The problem is that represents years of effort, starting from the bottom up (KMS, GEM/TTM, DRI2). At each level there is a round of figuring out "so what should we do with this level", and that is happening at the X server/DDX interface level now.

[Hephasteus]

I can only speak for myself, as one of the idiots that got stuck with a GMA500 and has been doing everything in his power to keep the drivers working despite Intel's efforts in killing them. The fact that this merge is proposed by an Intel employee is just the final irony - this move will kill any GMA500 or similar abandoned graphics driver, short of a "nouveau-like" reverse engineering that nobody has the resources to do.
And I can only imagine what would have happened if x had been "de-modularized" when the original psb drivers where released, we (me and the other users hacking on this) would still be stuck in a 2 years old x, with no way to upgrade, and with all the kernel integration we would also probably be stuck with the same old kernel.
So, as a end user that has already compiled and packaged kernel modules, libdrm variants, and xorg drivers, I can state I am against this merge. Not that I expect that my opinion will count much.

Counts or not. It's a very good explaination of what it would mean to everyone. Great post.