Linux Gets Kernel-Based Modesetting

An anonymous reader writes "Next month when Fedora 9 is released it will be the first Linux distribution with support for kernel mode-setting, which is (surprisingly) a feature end-users should take note over. Kernel-based modesetting provides a flicker-free boot process, faster and more reliable VT switching, a Linux BSOD, and of most interest is much-improved suspend/resume support! The process of moving the modesetting code from the X.Org video driver into the Linux kernel isn't easy, but it should become official with the Linux 2.6.27 kernel, and the Intel video driver can already use this technology. Phoronix has a preview of kernel-based modesetting covering more of this new Linux feature accompanied by videos showing the dramatic improvements in virtual terminal switching."

Comments

Oh boy!

[Malevolyn]

Just what we need: a Linux BSOD!

Re:Oh boy!

[PenisLands]

Indeed. It would be nice to actually have some helpful error messages so users can work out what on earth has gone wrong.

Waitasec...

[jamstar7]

A BSOD? Lemme guess, that patch came from Novell, right?

KGI, only much later and missing some features.

[Bloater]

It's about time, KGI was a patch to Linux many many years ago to enhance Linux graphics support just like combining this kernel modesetting with DRI (except that KGI had decent security measures designed in right from the start).

As usual the old guard says something like "Graphics isn't relevant" and holds back progress for years on end.

Re:KGI, only much later and missing some features.

[jd]

KGI was a damn good system - somewhat overshaddowed by GGI and other similar efforts, though, as the argument of the time was that the kernel shouldn't do what userspace can do. KGI might have stood a better chance if development had been faster, or some significant card could not be made to work correctly in userspace, or there was a demonstrable vulnerability implied.

As I recall, there was also the arument that grahics in the kernel risked instability that would impact the system and be hard to trace. I can sympathize with this argument a bit more, but in the end it is true of all hardware drivers - hence the efforts of microkernel and exokernel developers to move such stuff into isolatable containers. It's a good idea, not terribly efficient because of all the message passing, but I can understand the reasoning.

Re:KGI, only much later and missing some features.

[techno-vampire]

As I recall, there was also the arument that grahics in the kernel risked instability that would impact the system...

How true that is! I once worked at a shop where everybody was on NT4, and my box kept blue-screening because of a bug in the graphics driver. Putting drivers like that in kernel space just to get a little more speed is downright stupid, especially when you consider that NT 4 was largely marketed as a server OS where graphics weren't exactly important. I can't help but feel, given my experience, that this isn't exactly the best of ideas.

Re:KGI, only much later and missing some features.

[Bloater]

KGI never put graphics into the kernel, it only put mode setting into the kernel and provided a means to communicate with graphics hardware other than dumb MMIO to userspace. Individual drivers could do graphics in the kernel, but most cards could do either dump mapping if it is secure, or userspace could fill a buffer with a list of writes to be done and the driver would check them for safety and then just perform the described writes. Most of the cards that would need a full kernel graphics driver were slower than software rendering.

Re:KGI, only much later and missing some features.

[RAMMS EIN]

``KGI was a damn good system - somewhat overshaddowed by GGI and other similar efforts, though, as the argument of the time was that the kernel shouldn't do what userspace can do.''

There is a point to that. On the other hand, it is questionable whether, in Linux, userspace _should_ be able to do all the things needed to drive the graphics card. Userspace directly accessing hardware and reading and writing arbitrary memory locations?

On the gripping hand, the reason this is unsafe is only that the languages we use are unsafe. They don't gurantee that processes don't access things that aren't theirs. Essentially, we solve this by imposing a sort of dynamic type checking: we run these unsafe processes in a restricted mode, where the hardware limits their access to memory and I/O ports. Of course, sometimes, you _do_ need more than this restricted access, and that's what the kernel does. We trust the kernel to do it right. But now we've used indirection into the process: to access the hardware, a process needs to go through the kernel, which (hopefully) restricts the process to only doing benign things to the hardware. This is, of course, slower than it could be. Especially on x86, where switching from user mode to kernel mode is quite an expensive operation. This is the real reason why microkernels are slow.

An alternative would be to have the compiler perform or insert the checks that, in current systems, are performed by the kernel and the hardware at run-time. This way, processes don't have to run in restricted mode and go through the kernel anymore, because they aren't going to do any of the things the kernel would prevent them from doing anyway. Of course, this requires a rather safer type system than C's, and it shifts trust from the kernel to the compiler - which raises issues about how you can know that the code you want to run was indeed compiled by a trustworthy compiler. However, these issues can be solved, and you end up with a system that can be more modular _and_ more efficient.

Re:KGI, only much later and missing some features.

[Kjella]

as the argument of the time was that the kernel shouldn't do what userspace can do. Well, from what I can read out of the description this has absolutely zero benefits for servers so I figure the discussion in 1998 went a little differently. KDE 1.0 was released in july 1998 and Gnome 1.0 wasn't out either, and things like "smooth graphical booting process" probably wasn't a major issue to say the least. There's always a balance between creating layers and hindering features, like for example ZFS which breaks the traditional file system model. At the time, I think it was probably right for Linux as they had more important things to focus on.

Confirmed, works and is very promising

[Enleth]

I've been trying it out since it became usable at all in the relevant git trees, with Intel driver of course - and it works wonders. Probably one of the best inventions after sliced bread. Well, seriously, it will definitely help the authors of graphics drivers, providing a unified framework for all modesetting kludges and simplify the actual drivers, especially direct rendering. AFAIK all the new Radeon drivers (those made with the specifications AMD released) will be using it, as well as DRI2, so not only Intel GMA users will benefit very soon.

Re:Thanks but no thanks

[sticks_us]

I've tried contributing code, but they're stuck in a cathedral and won't acknowledge me.

I hear ya...I've better luck with the Debian Hurd project, give them a shot:

http://www.debian.org/ports/hurd/

If it's been a while, you might be pleasantly surprised: you can get a decent GNU/Hurd install going without too much trouble, there are things happening, development-wise (including possible "summer of code" participation) and so on.

Good luck.

Cross platform X compatibility?

[jensend]

Does anybody have some insights on how this will affect those not using Linux kernels with this patch?
Are the *BSDs and commercial Unices planning on similar work? Will support for modesetting eventually be dropped from X drivers?

Re:What for?

[siride]

Because the kernel manages hardware resources. Modesetting and graphics memory management should be done by real drivers in the kernel, just like everything else. Right now, you basically have two driver frameworks managing the video hardware (and possibly more): the kernel's own framebuffer and the X.org drivers, which already have DRM shims in kernelspace. That is way too complicated and why anybody thinks having two drivers competing for a single piece of hardware is a good idea is beyond me. There is a segment of the Unix population that seems to think that anything that's been done for longer than, say, 10 years, is automatically correct and anybody who chooses to change things is automatically wrong. FWIW, Linux and the open source BSDs are the only Unices that have had X modesetting and basic video driver functionality OUTSIDE the kernel. The commercial Unices had special X drivers in the kernel, Mac OS X obviously has kernel mode graphics support, as does Windows, although it is partitioned off from the rest of the kernel to some degree. And which OS has the most problems with graphics drivers, crashes and lockups related to that? Linux...

iKonqueror == Safari

[tepples]

iKonqueror A Mac-style web browser using a KHTML fork? We already have that, except the i is at the other side of "Safari".

emac.. err imacs Apple has made both iMac and eMac computers. The eMac was introduced when some teachers found the Luxo Jr. style iMac G4 not durable enough for the K-12 market.

even ililo? You'll get iLilo only if you buy Apple's embroidery machine, the iStitch. Thanks to a deal between Apple and Disney, brokered with the help of Disney plurality shareholder Steve Jobs, the iStitch comes preloaded with Disney patterns.

Finally - Linux BSOD

[daffmeister]

The final impediment removed to allow "the year of linux on the desktop".