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.

[RiotingPacifist]

woot in 2018 well get rieser4 :D

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.

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

[ThePhilips]

[...] the reason this is unsafe is only that the languages we use are unsafe.

Yeeees. Right. Absolutely.

This has nothing to do with sloppy programming and bunch of incompetent monkeys who managed to get to keyboard because it is cool.

The difference between good developer and bad developer is that good developer always listens to user feed back. To system developers that's application developers are users. To application developers that's end-users are users. To hardware developers that's system developers are users.

NT4 in that respect set all time record for shittiest programming ever. M$ with Win2k/WinXP/Vista was doing essentially one thing: making system simpler, system which wouldn't drive developers insane.

Most of previous Linux attempts to moving parts of graphics into kernel were hindered in some part by lack of documentation and most importantly oversized ego of some developers calling for revolution. But in fact there were no revolution and nothing extraordinary new was done: people were trying to randomly move stuff around kernel/user space, nothing more. GGI was classical example: you could do the same with X - but it wasn't ever tried nor done. Because its developers were dead set on changing everything - no compromises allowed. For sake of highly experimental project recrafting stable kernel interfaces? That will never happen. The fact now that most of the mod setting development is done under hood of X.Org is a sign that it is going to be done right - because it is going to be done using stable ground, not shaking foundation of highly experimental library.

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

[Bloater]

"They" (one group of kernel devs) didn't have more important things to work on than security in the face of 3d accelerated application support - which is why that group of kernel devs wrote KGI.

Unfortunately "They" (a larger group of kernel devs who only switched out of EGA mode for multiple terminals on one screen, a group that seems to have included Linus Torvalds) thought that companies who were paid to provide realtime 3d rendered displays of data/media for whatever reasons (eg medical visualisation, pilot training, etc), didn't deserve to have security.

I'm not joking, they actually said people who use 3d don't need secure computers and should not be provided with both 3d and security at the expense of running 3d rendering algorithms in ring 0. Even though no KGI drivers did that, at most (a couple of drivers) they fiddled a few words on the card to shift data precalculated in user space onto the card.

This was all because the second, larger, "They" thought that 3D meant "movie rendering" where the networks were already highly secure or "games" where it is only a child's computer and the family didn't share it for internet banking, etc - and nor should they ("Damned families, not giving their children a dedicated computer, they ought to be locked up").

Crazy

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:Confirmed, works and is very promising

[JackieBrown]

I wish I hadn't just bought a nvidia card.

Being a Linux user, I never thought I'd say that.

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:Cross platform X compatibility?

[michaelmuffin]

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? I was under the impression that Solaris already did this, to name one. solaris has its own x11 implementation -- http://en.wikipedia.org/wiki/Xsun -- although x.org is an option for the i386 platform

Re:Thanks but no thanks

[Goalie_Ca]

If I had a lot of money like google does then I would fund just enough work to keep the joke alive :D

Re:Hasn't this been settled ?

[laffer1]

Apple uses a hybrid kernel called XNU actually. http://en.wikipedia.org/wiki/XNU

Re:What for?

[Nutria]

The justification is, if the X server crashes, the kernel can restore the display to a usable state.

Every time I've had X crash, it's brought me right back to the console, with no issues or problems.

But then, I don't use [xgk]dm, nor do I use DRI. This seems like a really Microsoft-like Bad Idea to me...

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.

BSOD explanation

[Anonymous Coward]

BSOD here does not mean "Microsoft-style reliability".

Currently, if the kernel panic, and X is shown, the machine just locks up.

With kernel mode-setting, the kernel will be able to switch out of X and print panic to the screen. This is very helpful to developers, and for bug reports.

The downside is not decreased reliability, but that the normal user will panic too (and not just the kernel).

Of course, the more code we have in the kernel, the more reasons to oops, but that hardly happens on distribution kernels, as the bugs were mostly flushed out.

Re:What for?

[MrHanky]

Then you don't have a recent ATI card. The free driver will hard crash my system when playing video through Xv (this is with an experimental driver pulled from the GIT tree), the proprietary driver will freeze the system on log-out (with K/GDM). An X11 error can easily take down Linux, even if you don't use DRI.

Finally - Linux BSOD

[daffmeister]

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