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

[nanonyme]

and many many more problems. your right, xorg is very very complex and good project, but have nasty bugs. i wait 3-4 years to fix them and no improve, reporting bugs does nothing, so i write them here, phoronix is place where sometimes developers can read what problems communities have.

i want you to motivate to fix old bugs, not add new features, that only 5% of linux users need to be happy.

How about using your undoubtedly enormous competence you've gathered as a hobbyist and actually go fix the bugs instead of letting them rot in tracker? Keep in mind a lot of the other people contributing aren't professionals either.

[V!NCENT]

@Gordboy,
I believe everybody deserves a second chance (except of relationships, but that's a different topic), so don't screw it up this.

Ofcourse; everybody can question things, but it's the way how one questions things. If you're figuratively out to suck the blood beneath people fingernails, so to speak, then be prepared for a dejavu.

[NomadDemon]

ignoring the huge amount of irony in your first sentence - no-one's stopping you! if you feel you can do better, then please do. if it's as fast as you suggest, there will doubtless be a huge flock of people switching to your new project.

all the best.

problem is, that i cant, programming is my hobby, not my profession.

i know computers very well, i can compare many software peaces, i try to tell you how to improve xorg, what you do wrong in my opinion, what is waste of time, what works, whats doesn't.

reporting bugs is not good, some bugs waits couple of years to be fixed

some bugs are very nasty, and using linux with this bugs are nightmare, thats why many new users say linux sux, because nothing works

i.e. : laptops with intel graphic, many of them have flicker in new ubuntu 10.04, something goes wrong...

i.e.2: catalyst needs XAA acceleration or you have black boxes in firefox/thunderbird

i.e.3: new game demo "amnesia" and old "openarena" have nasty mouse issue, every click or to fast move moves mouse to bottom right corner, these games are unplayable. i bet its mouse grab issue not from games, theres many games with this problem.

i.e.4: alt + tab brokes resolution very often with fullscren game

i.e.5: tv resolution cant be different than monitor resolution

and many many more problems. your right, xorg is very very complex and good project, but have nasty bugs. i wait 3-4 years to fix them and no improve, reporting bugs does nothing, so i write them here, phoronix is place where sometimes developers can read what problems communities have.

i want you to motivate to fix old bugs, not add new features, that only 5% of linux users need to be happy.

[daniels]

you talk talk and talk... but we still have shitty xorg and drivers performance...

i have idea, to make a mega lightweight version of xorg, but for a simple user, that dont need remote desktop and other useless stuff for "mr smith", just a simple xorg, that allows everything to works, and much faster, without 80% of useless code. wayland seems to be nice alternative, whats wrong with you guys? you forget what was your main goal? i dont care about features, while performance is sadly low

if i have to chose between performance and tv output, i chose performance
if i have to chose between stability and opencl i chose stability

like alt + tab in fullscreen games... they always end with crash, broken resolution on desktop, or cant restore app from taskbar, this sux sux sux

ignoring the huge amount of irony in your first sentence - no-one's stopping you! if you feel you can do better, then please do. if it's as fast as you suggest, there will doubtless be a huge flock of people switching to your new project.

all the best.

[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.

[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.

[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]

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

[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!).

[pingufunkybeat]

LOL, we missed you, this will be fun.