Slashdot Mirror


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

7 of 81 comments (clear)

  1. KGI, only much later and missing some features. by Bloater · · Score: 4, Informative

    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.

    1. Re:KGI, only much later and missing some features. by Bloater · · Score: 4, Informative

      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.

    2. Re:KGI, only much later and missing some features. by Bloater · · Score: 2, Informative

      "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

  2. Re:Thanks but no thanks by sticks_us · · Score: 3, Informative

    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.

    --
    "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
  3. Re:What for? by Anonymous Coward · · Score: 1, Informative

    What's the justification for moving modesetting into kernel space?

    The justification is, if the X server crashes, the kernel can restore the display to a usable state. It also ensures that the display is reinitialized properly after suspend/resume.
  4. Re:Cross platform X compatibility? by michaelmuffin · · Score: 2, Informative

    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
  5. BSOD explanation by Anonymous Coward · · Score: 2, Informative

    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.