Linked by Thom Holwerda on Sun 20th Apr 2008 12:52 UTC, submitted by Michael Larabel
X11, Window Managers Have you ever been annoyed by Linux' lack of a coherent graphical boot process? Graphics hardware causing problems during sleep/wake cycles? Problematic virtual terminal switches? Kernel-based mode-setting, a new feature of Xorg still in heavy development aims to solve many of these problems by moving the mode-setting code from the user-space X driver into the Linux kernel. Phoronix takes a look at this new feature.
Thread beginning with comment 310605
To view parent comment, click here.
To read all comments associated with this story, please click here.
sbergman27
Member since:
2005-07-24

Xorg is focusing on linux like it's the only OS using the software.

I lived through the Unix wars. So forgive me if I fail to weep over that. We've done *nothing* on this well known issue for 14 years. The last thing the POSIX world needs is to haggle for even more years over exactly the right way to do it. *BSD and Solaris need to get with the program or get left behind. Continued inaction is not an option.

Edited 2008-04-20 20:50 UTC

Reply Parent Score: 9

deadmeat Member since:
2006-08-04

If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.

At the moment there are no stable APIs being defined by linux. That's a central theme.

The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.

At the moment there are no stable APIs being defined by linux. That's a central theme.

The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.


Linux has a stated goal of no ABI or API stability. It's argued that such a restriction would shackle the kernel dev's hands, introducing artificial inflexibility. Whether or not that is true, it is true that Linux is not responsible for creating standards. If Linux devs and BSD devs wanted to get together and hash out a standard for something I'm sure they could do it, but nobody seems interested in doing that. Therein lies the real problem. We're a long way (in terms of time elapsed) from POSIX and I don't see new standards being developed by anyone, just new single-vendor APIs.

The exception here is the fine work at fd.o, but they don't really touch very low level stuff unless it's directly X-related.

Reply Parent Score: 3

SomeGuy Member since:
2006-03-20

If Linux would step and and actually settle on stable APIs or god forbid a stable ABI for some of these things then maybe other people would follow them.


Hahahaha. In the bad old Xfree86 days, Xfree86 had a stable API. In fact, it was so stable that nobody had been able to implement significant improvements for over a decade. This is why the Nvidia people gave up on them and wrote their *own* 2d acceleration framework for their linux drivers, and they wrote their *own* kernel acceleration infrastructure for their linux drivers.

At the moment there are no stable APIs being defined by linux. That's a central theme.

The innability for Linux (or any other unix) to set (or stick to) standards is the reason why this sort of thing has lagged for over a decade.


Actually, no. The fact that Xfree86 was run by a**hats who had no clue of how to run a project, scared away all their developers, and did jack to actually improve the state of the art is the reason that this has lagged for over a decade.

The willingness of the Linux people to break their API and get things working is why they're able to do kernel modesetting at all -- kernel modesetting is yet another API and ABI break for the Xorg drivers that want to take advantage of it. It's a significant change to DRI.

Reply Parent Score: 2