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!

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.

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

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.

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.