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.
Order by: Score:
this...
by hobgoblin on Sun 20th Apr 2008 13:43 UTC
hobgoblin
Member since:
2005-07-06

have always been one of those weird interactions between kernel and X in unix os's.

that a user space app should take over full control of some hardware, to the degree that if said app should get into trouble, there is no way for the kernel to recover from it, was more or less insane.

but then i guess X was originally designed to run on a more bare bones kernel (if any at all) at the terminal end of things, and therefor needed the ability to handle said control.

Reply Score: 8

RE: this...
by sbergman27 on Sun 20th Apr 2008 14:15 UTC in reply to "this..."
sbergman27 Member since:
2005-07-24

It's always been somewhat embarrassing to me that switching from X to a character-based vt could sometimes lock up the console. Doesn't happen often. But on a busy machine it does occasionally happen. I take it that this enhancement corrects that situation.

Reply Score: 3

RE[2]: this...
by hobgoblin on Sun 20th Apr 2008 14:55 UTC in reply to "RE: this..."
hobgoblin Member since:
2005-07-06

one should think so as there is no longer a need for a "sync" between the kernel and X about what state the card is in.

btw, is it just me or have there yet to be a "sync" based system that works flawlessly under load, for any kind of use?

cvs/svn/git is sync for code, and we have heard horror stories about having to clean up large syncs.

calender sync is a hit or miss experience, even when both sides are from the same company.

and the list goes on...

Reply Score: 4

RE[2]: this...
by Havin_it on Mon 21st Apr 2008 08:20 UTC in reply to "RE: this..."
Havin_it Member since:
2006-03-10

I can assure you, with any recent Intel X-driver, it happens bl**dy constantly. I've tried every recent version but invariably end up going back to 1.7.4 so I can shut down without X falling over so badly I can't even SysReq out of it.

If this approach puts an end to this instability, I'm all for it. But I won't hold my breath...

Reply Score: 2

RE[3]: this...
by abraxas on Tue 22nd Apr 2008 01:33 UTC in reply to "RE[2]: this..."
abraxas Member since:
2005-07-07

I can assure you, with any recent Intel X-driver, it happens bl**dy constantly. I've tried every recent version but invariably end up going back to 1.7.4 so I can shut down without X falling over so badly I can't even SysReq out of it.

If this approach puts an end to this instability, I'm all for it. But I won't hold my breath...


I am using the 2.2.1 driver without issues. I experienced a ton of instability with earlier versions but the current version works without a hitch.

Reply Score: 2

have you ever ?
by l3v1 on Sun 20th Apr 2008 15:03 UTC
l3v1
Member since:
2005-07-06

Have you ever been annoyed by Linux' lack of a coherent graphical boot process?


No.

I'm not interested in seeing it boot. I'm preoccupied with using it.

Reply Score: 6

RE: have you ever ?
by Thom_Holwerda on Sun 20th Apr 2008 15:06 UTC in reply to "have you ever ?"
Thom_Holwerda Member since:
2005-06-29

I'm not interested in seeing it boot. I'm preoccupied with using it.


Well, in that case you should be really happy, as the new feature makes using Linux easier and less buggy (potentially).

Reply Score: 5

cool
by linuxdude on Sun 20th Apr 2008 15:45 UTC
linuxdude
Member since:
2008-02-26

cant wait to try it out in ubunut !!

Reply Score: 1

RE: cool
by kiddo on Mon 21st Apr 2008 00:38 UTC in reply to "cool"
kiddo Member since:
2005-07-23

I'm nuts about ubuntu too.

Reply Score: 2

RE[2]: cool (OT!)
by gilboa on Mon 21st Apr 2008 16:37 UTC in reply to "RE: cool"
gilboa Member since:
2005-07-06

I'm nuts about ubuntu too.


... This exchange more-or-less reminds me a line from Idiocracy. [1]
"Dude! You love money?"
"Ugh! I love money too"

- Gilboa
[1] http://www.imdb.com/title/tt0387808/

Reply Score: 2

RE[3]: cool (OT!)
by kiddo on Mon 21st Apr 2008 21:54 UTC in reply to "RE[2]: cool (OT!)"
kiddo Member since:
2005-07-23

Ok, I guess my spelling nazi pun did "woosh" ;)

Reply Score: 1

RE: cool
by Xenu on Mon 21st Apr 2008 02:03 UTC in reply to "cool"
Xenu Member since:
2008-03-02

I guess that'll have to wait until next year, unless you download and compile the kernel yourself when the 2.6.28 stable release comes out.

Reply Score: 1

More polished desktop experience
by abraxas on Sun 20th Apr 2008 16:00 UTC
abraxas
Member since:
2005-07-07

This is a great enhancement for Linux on the desktop. Modesetting issues with suspend/resume, X initialization, and between X and the console is a major sore spot with my desktop. Most of the remaining issues with my laptop are with the video/graphics and this is a major step at resolving a lot of those issues. The rest of the issues should be resolved with the TTM memory manager and Intel driver enhancements. Unfortunately it looks like I am going to have to wait until the end of the year until the TTM memory manager and kernel modesetting are fully integrated into the Linux kernel.

Reply Score: 6

sakeniwefu Member since:
2008-02-26

I am happy to hear we will finally get hibernation working in Linux. And it might even become useful if the booting process is parallelized and it doesn't take ages to recover from hibernation.

However I still cannot understand why they couldn't get the hibernation to work right without this hack. As I see it, hibernation means:

1- Take snapshot of running applications and services
2- Store to non-volatile memory
3- Shut down computer the rough way
4- Read from non-volatile memory
5- Jump to snapshot.

I realize a modern PC is not an old microcomputer, but the process is straightforward. Even with screen modesetting and other device problems needing some restarting, any sane windowing system can be restarted without losing the windows.

X is *cough* rotten *cough*.

Reply Score: 1

sbergman27 Member since:
2005-07-24

X is *cough* rotten *cough*.

No. Hibernation *does* work in Linux. I'll prove it right now by hibernating my laptop and restarting it. There. See? It worked! What you are forgetting is the huge volume of disparate, broken hardware out there that has been "fixed" by the manufacturer with a Windows driver update. That's what makes hibernation so difficult to solve in a general way. Confining low level control of the video hardware to user space, while depending upon the kernel to do the hibernate/wake up is a recipe for unreliability across the broad range of commodity hardware available.

I would not trade X for any other display system available. And I continue to be puzzled by the tendency of some to unjustly criticize it at every opportunity. What's rotten, and has been for a long time, is the fact that, for whatever reason, control of the basic state of the display hardware has been shunned by the kernel devs.

Don't get me wrong. The complex stuff belongs in user space. But responsibility for something so basic as setting the graphics mode lies squarely within the domain of the OS kernel.

We've been talking about something like this for at least 11 years. Linus rejected the original GGI out of hand back in 1997 or so. And here we are just getting this functionality which has been so sorely lacking for so long. And the delay was certainly no fault of X's.

Edited 2008-04-20 18:37 UTC

Reply Score: 9

sakeniwefu Member since:
2008-02-26

1- write "hibernate" in the terminal emulator
2- turn the computer on
3- wait
4- wait
5- find yourself in a useless brick of a session with a psychedelic screen
6- reboot
7- run fsck
8- Now you are free to reload your applications and data one by one.
9- ????
10- $$$$!!!
(This is more like it)

If the GFX driver can load usually there's absolutely no justifiable reason for it to hang the whole system on dehibernation. I don't care if the driver is Nvidia, ATI or open source as in my case. You set the screen to the right mode and restore the windows. At most I would understand some garbled graphics if I was running a 3d game when I hibernated the thing.

Reply Score: 1

sakeniwefu Member since:
2008-02-26

Okay, now the wise person who modded me down will please tell me which statement in my previous post is false? Is there any opinion for you to disagree with? Can you justify that the design of hibernate makes a working part of the OS hang the whole system up? If so, please enlighten me.
If you must have the immature attitude of modding people down because they happen to describe non-functional parts of your favorite OS, at least you could make a reason up to justify it rationally.

Reply Score: 0

elsewhere Member since:
2005-07-13

Just a guess, since I didn't mod you down (hence I wouldn't be able to reply), but as is often typical of whiners, you are applying your own system's inability to to perform xyz as applying to everyone else.

I close my lid, and my system suspends. I open it up, and it gives me a desktop in 3 seconds. Unstable KDE 4.1 combined with nvidia proprietary driver. Could I be asking for more trouble?

So while your own personal frustration is understandable, and certainly many others have issues with suspend and other functions in linux, don't assume it applies to everyone, and don't assume it is the fault of the kernel devs, or the xorg team. There are a lot of corner cases where different hardware combinations will cause problems, compounded by the fact that many of the drivers are reverse-engineered by necessity since the hardware manufacturers often don't provide support or documentation to the developers.

Do what I did, and research your hardware before purchasing it if you are looking for linux compatibility. If you are expecting arbitrary compatibility with whatever hardware you happen to be using, you could very well wind up disappointed.

And for what it's worth, my work laptop, an old Compaq NC6000, with Windows XP, crashes roughly 1 out of every 10 times when I close the lid to suspend. That's not Microsoft's fault, it can likely be tracked to a faulty driver much as it can in linux, but just points out how fragile the whole infrastructure is when we're dependent upon the interaction of independent hardware vendors interoperating together.

Reply Score: 5

Lighten up
by s_groening on Mon 21st Apr 2008 07:37 UTC in reply to "RE[4]: More polished desktop experience"
s_groening Member since:
2005-12-13

Not everyone, everything or every opinion is necessarily shared by everyone no matter whether you're right, but please don't whine about a silly mod ... There are much more important things to be concerned about if you ask me ...

Reply Score: 2

tyrione Member since:
2005-11-21

"X is *cough* rotten *cough*.

No. Hibernation *does* work in Linux. I'll prove it right now by hibernating my laptop and restarting it. There. See? It worked! What you are forgetting is the huge volume of disparate, broken hardware out there that has been "fixed" by the manufacturer with a Windows driver update. That's what makes hibernation so difficult to solve in a general way. Confining low level control of the video hardware to user space, while depending upon the kernel to do the hibernate/wake up is a recipe for unreliability across the broad range of commodity hardware available.

I would not trade X for any other display system available. And I continue to be puzzled by the tendency of some to unjustly criticize it at every opportunity. What's rotten, and has been for a long time, is the fact that, for whatever reason, control of the basic state of the display hardware has been shunned by the kernel devs.

Don't get me wrong. The complex stuff belongs in user space. But responsibility for something so basic as setting the graphics mode lies squarely within the domain of the OS kernel.

We've been talking about something like this for at least 11 years. Linus rejected the original GGI out of hand back in 1997 or so. And here we are just getting this functionality which has been so sorely lacking for so long. And the delay was certainly no fault of X's.
"

Give me Quartz/WindowServer from OS X on Linux in a heartbeat.

Reply Score: 1

sorpigal Member since:
2005-11-02

"[q]X is *cough* rotten *cough*.

I would not trade X for any other display system available
"
Give me Quartz/WindowServer from OS X on Linux in a heartbeat. [/q]

You're out of your mind. I assert that X is superior to quartz in every technical respect. If I were an OS maker using X as my display technology with a finite, known set of hardware as the target I could give you the *exact same* or *better* experience, compared to that found on OS X, without difficulty.

Just because Apple makes their system work well does not mean it is superior, just that it can be made to work well.

Let me say it clearly for those who don't seem to understand: X is good and it's not going anywhere. Fixes to its problems can and are being made without throwing it out. A better system is *possible* to construct, but *really* difficult to do properly. In reality no better system is likely to be adopted within at least a decade.

Reply Score: 4

drahca Member since:
2006-02-23

I assert that X is superior to quartz in every technical respect.


That is a pretty bold statement. Could you maybe show some sort of argument here as to why X is superior in every technical aspect to Quartz?

X is being fixed, but it needed fixing badly. There was and still mostly is no working acceleration framework for the RENDER extension. Sure we have EXA now but it does not work on most hardware and when it does it is slower than doing stuff in software. E.g. text rendering speed is less than optimal to say it mildy. They are fixing this, but we will have to wait another year or so to really see some improvements here.

Let me say it clearly for those who don't seem to understand: X is good and it's not going anywhere.


X is finally going somewhere! Things are moving along now, work is being done to address the most serious issues. X is finally catching up to comparable technologies. I would call X as it stands today as sufficient, but nowhere near excellent. Kernel modesetting is an incredible important step towards fixing some longstanding stability and security issues. Together with working EXA, hot-plugging, compositing, color management, TTM, DRI2, and many other exciting developments, X is getting in good shape.

Reply Score: 2

SomeGuy Member since:
2006-03-20

However I still cannot understand why they couldn't get the hibernation to work right without this hack. As I see it, hibernation means:

1- Take snapshot of running applications and services
2- Store to non-volatile memory
3- Shut down computer the rough way
4- Read from non-volatile memory
5- Jump to snapshot.


You're missing a very important stage -- the stage everything gets tripped up on. The "restore hardware settings and reinitialize the hardware to a sane state without knowing what state it's in at all, and when it's power-on sequence has been customized by manufacturers so that the same parts can potentially behave differently if they came from different manufacturers.

I realize a modern PC is not an old microcomputer, but the process is straightforward. Even with screen modesetting and other device problems needing some restarting, any sane windowing system can be restarted without losing the windows.


Well, I guess that means that there aren't any sane window systems on any modern desktops. Tough nuts.

Reply Score: 2

Well I'm excited
by thebackwash on Sun 20th Apr 2008 19:15 UTC
thebackwash
Member since:
2005-07-06

I like how over the last 2-3 years Linux has resolved many of what I see as low points for a modern desktop OS. Graphically, between X and Linux itself, it's been a mess. Hope to see more extensions to X in the future to further enhance the desktop experience.

I'd be interested in seeing some kind of cooperation between the common desktop app toolkits (GTK+, QT and Mozilla's widget toolkit,) and the window managers to give a more solid-feeling window resize. For right now, just drawing the border on resize is a compromise, but I know it can be done.

Reply Score: 1

RE: Well I'm excited
by sbergman27 on Sun 20th Apr 2008 19:35 UTC in reply to "Well I'm excited"
sbergman27 Member since:
2005-07-24

I like how over the last 2-3 years Linux has resolved many of what I see as low points for a modern desktop OS.

So do I. It always gives me pause when I read a claim that FOSS development proceeds at an incredible rate, when I know good and well that progress on some of the most fundamental things has been positively glacial in nature. GGI started raising these issues 14 years ago. So I can't help but temper my "Hip! Hip! Hurrah!" with "It's about freaking time!".

Reply Score: 7

Security considerations
by dannytm on Sun 20th Apr 2008 19:51 UTC
dannytm
Member since:
2008-04-20

According to keithp's talk at lca2008 kernel mode-setting should also make it possible to run the X server without special privileges.

http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/165-intel-...
http://mirror.linux.org.au/pub/linux.conf.au/2008/Fri/mel8-165.ogg

This is a huge development in terms of security because until now a large amount of user space code had more privileges than it ought to have.

http://marc.info/?l=openbsd-misc&m=114738577123893&w=2

Eventually kernel mode-setting should also find it's way in other platforms in the future.

http://blogs.sun.com/alanc/date/20070204

Reply Score: 4

What about everything that isn't linux?
by aesiamun on Sun 20th Apr 2008 20:27 UTC
aesiamun
Member since:
2005-06-29

So what about *BSD?

What about newer builds of Solaris?

Doesn't this kind of ignore them?

Reply Score: 1

sbergman27 Member since:
2005-07-24

Doesn't this kind of ignore them?

I don't understand what you mean by "ignoring them". If Solaris and *BSD want to benefit, their kernel people need to supply the capability. Xorg cannot do it for them. Fedora cannot do it for them.

Perhaps the FreeBSD kernel guys can take some time out from running and rerunning sysbench benchmarks long enough to implement this useful functionality. ;-)

Edited 2008-04-20 20:40 UTC

Reply Score: 8

aesiamun Member since:
2005-06-29

Xorg is focusing on linux like it's the only OS using the software. As it focuses more and more on linux peculiarities, the others are forced to adapt to the linux way or hack around them.

Reply Score: 1

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 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 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 Score: 3

sbergman27 Member since:
2005-07-24

Linux has a stated goal of no ABI or API stability.

I know that you already know this. But I feel that it's best to always be careful to state that this policy refers only to the internal kernel api. Otherwise some people get the false impression that the kernel's user space api is unstable.

Reply Score: 3

sorpigal Member since:
2005-11-02

"Linux has a stated goal of no ABI or API stability.

I know that you already know this. But I feel that it's best to always be careful to state that this policy refers only to the internal kernel api. Otherwise some people get the false impression that the kernel's user space api is unstable.
"

You are correct. I refer only to driver APIs.

Reply Score: 2

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 Score: 2

siki_miki Member since:
2006-01-17

Xorg isn't removing anything that would make BSD's or Solaris stop using it.

However, there are additions which make the graphical system more advanced in Linux. If others don't want to apply that strategy, it's their choice to continue with the old way of running X/DRI.

That said, I'm sure that eventually someone will pop up to implement or port kernel part of new DRI to BSD's and other systems. Maybe it's even better to wait util it becomes solid enough on Linux (also there is no need to have exact the same thing, e.g. nvidia and ATI have their own frameworks that easily plug in into the X).

Reply Score: 2

sbergman27 Member since:
2005-07-24

Maybe it's even better to wait util it becomes solid enough on Linux...

It is worth noting that the kernel interface to X is part of the userspace api, which is sacrosanct, so the alarmist FUD that someone was trying to spread earlier about Linux not guaranteeing a stable (internal) API is totally irrelevant to this situation. Once the API is in place, it will always maintain backward compatibility.

Reply Score: 2

tyrione
Member since:
2005-11-21

To Xorg Engineers:

How about you fix the fact I can see my mouse pointer randomly shootup to the top left, lower left, bottom right or top right in the middle of it's use, while not depressing the left mouse button [for right handed users].

That's a damn annoying bug that's been around for several revisions.

Reply Score: 1

superman Member since:
2006-08-01

> To Xorg Engineers:
> How about you fix the fact I can see my mouse pointer

Pay them.

Reply Score: 3

RJop Member since:
2007-01-08

To: tyrione

What about stop whining here and write a bug report to the Freedesktop/XOrg bugzilla?

https://bugs.freedesktop.org/

Reply Score: 4

v well done monolit
by sandorfal on Mon 21st Apr 2008 12:02 UTC