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.Currently, the only driver that supports kernel-based mode-setting is a special branch of the open source Intel video driver, and the only distribution that supports this new method of mode-setting is Fedora 9, of which a peview has been released (review). There is an effort under way to port the Radeon driver to kernel-based mode-setting too.
Phoronix explains the benefits of kernel-based mode-setting:
Suspend and resume support is improved with kernel mode-setting as the kernel no longer relies upon external resources for restoring the graphics adapters. With the process now being in-kernel, it’s able to restore the mode automatically and more quickly. Likewise, virtual terminal switching is also improved as a result.
In addition to the above, the feature will also improve the debugging experience as graphical error messages can be displayed on the screen prior to the launch of the X server. You will also get a flicker-free graphical boot process, as the video mode needs to be set only once, instead of numerous times as is the case now (when the boot process starts and again when the X server finally loads).
Phoronix concludes that while still in its early stages, kernel-based mode setting will greatly improve the desktop Linux experience.
Kernel-based mode-setting is a great advancement for Linux and X.Org with it being a feature that delivers noticeable benefits to the end-user — a cleaner flicker-free boot process, fast and reliable VT switching, improved suspend-and-resume support, and soon enough will be making fast-user-switching even faster. This is just the tip of the iceberg and more benefits, such as graphical diagnostic capabilities, should be able to flourish as a result of kernel-based mode-setting.
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.
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.
No.
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).
cant wait to try it out in ubunut !!
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.
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.
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.
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.
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 …
Give me Quartz/WindowServer from OS X on Linux in a heartbeat.
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.
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.
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.
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.
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.
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!”.
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
So what about *BSD?
What about newer builds of Solaris?
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
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.
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.
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.
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.
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.
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 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.
> 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
HAHAHA put all into the kernel…
The only way to use linux