OSNews

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.

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

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

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

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/

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

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.

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

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

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.

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.

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.

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.

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.



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

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!".

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

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.

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

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.

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

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.

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

Pay them.

To: tyrione

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

https://bugs.freedesktop.org/

To tyrione:

https://bugs.freedesktop.org/show_bug.cgi?id=8583