Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 16:25 UTC (Sun) by PO8 (guest, #41661)
In reply to: Christmas Comes In July For An Open ATI (Phoronix) by pheldens
Parent article: Christmas Comes In July For An Open ATI (Phoronix)

Kernel mode setting is where the graphics hardware is set up by the OS kernel, instead of
through some kind of weird peek-and-poke userland interface, as the OS Gods intended.  It
turns out that properly initializing a modern graphics chip, which typically has literally
thousands of bizarrely-organized registers, is usually the hardest part of getting it up and
running.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:42 UTC (Sun) by oringo (guest, #44517) [Link] (10 responses)

So does this mean that Linux kernel is on a fastrak to be as bloated as the NT kernel?
Seriously, I'm actually concerned.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:55 UTC (Sun) by yoshi314 (guest, #36190) [Link] (8 responses)

not really. this means that resolution switching code will move to the kernel, which means
that console framebuffer drivers (like vesafb) will work better with X.

as demonstrated on phoronix some months ago with a working kernel modesetting for intel cards,
VT switch (switch to console from X) is nearly instantenous, when using kernel modesetting.

so in short - kernel will manage resolution switching, and low-level video stuff. right now
you need separate framebuffer driver for hi-res console, and separate X driver. and they might
not play nicely with each other (think about nvidia and rivafb, for instance). sometimes VT
switch takes even 3 seconds, and it's not guaranteed to be stable.

all the high-level stuff, like opengl and 2d acceleration will still be done higher, working
on top of low-level DRM kernel modules, which will provide the necessary infrastructure.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:59 UTC (Sun) by nix (subscriber, #2304) [Link] (6 responses)

This is also a precondition for getting DRI working in multiple X servers 
on the same machine at once, and it's a substantial code *simplification* 
(or at least it would be if the non-kernel-modesetting code could be torn 
out, which it can't as that would break old kernels and non-Linux 
systems).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 22:12 UTC (Sun) by drag (guest, #31333) [Link] (4 responses)

Yep..

Better, faster, cheaper (simplier).

There are several important things going on with this:

* This makes a flicker-free Linux experience, as mentioned by other people. This means it's
possible to have full color and graphics from grub to shutdown.

* This will eventually improve reliability of power management as modsetting is a big problem
for suspend and wakeup. Users end up with blank screens or scrambled displays and that sort of
thing. 

* Along with improvements to the DRM interface for video card memory management it makes DRI
work better.

* It's a important step for moving X Windows out of the job of managing hardware. When they
manage to get the X Server using standard graphics APIs instead of mangling PCI resources and
having it's own special drivers, then that will allow users to have their X Server running
entirely under their own account. No root access required. This is important for security,
reliability, and multiuser improvements. 

Don't worry. Nobody wants to pull a Nvidia and stuff way to much functionality into a kernel
module. :)

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 23:03 UTC (Sun) by nix (subscriber, #2304) [Link] (3 responses)

Some people try to stuff a lot of functionality into the kernel: 
http://savannah.nongnu.org/projects/schemix/ (appears to be dead, 
perhaps because all the developers went insane).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 9:38 UTC (Mon) by wingo (guest, #26929) [Link]

I just want to say that that link is triple awesome.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 10:17 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)

Actually that is sort-of awesome. If you're going to bolt a language into the kernel then it
only makes sense for it to be Scheme, not only because it short-circuits Greenspun's Tenth
Rule but also because Scheme users won't be disappointed by the kernel's rather sparse
amenities. And even better on a modern kernel you'll run out of stack almost immediately which
makes it exactly like trying to use a real Scheme implementation on old hardware (or in my
case, thousands of them in parallel on 1990s hardware).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 14:47 UTC (Mon) by nix (subscriber, #2304) [Link]

Well obviously the sane thing to do is to make the Scheme stack not be implemented in terms of
the C stack.

This makes it easier to implement call-cc as well, and of *course* a kernel imeplementation of
Scheme needs call-cc. :)

(ideally you'd have jailed and non-jailed processes, where the jailed ones have access to no
more than a normal userspace process would except they're implemented by a kernel-space
interpreter. Ideally ideally it'd JIT-compile everything. I'm overthinking this.)

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 12:31 UTC (Mon) by jlayton (subscriber, #31672) [Link]

Another possibility that's been discussed (and one of the driving forces behind getting this
support in) is that this may allow us to display kernel oops messages to the screen even when
X is running.

That would be a wonderful, wonderful thing.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 21:25 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

> as demonstrated on phoronix some months ago with a working kernel modesetting for intel
cards, VT switch (switch to console from X) is nearly instantenous, when using kernel
modesetting.

The kernel in Fedora 9 has the modesetting for Intel chips that one can activate via passing
i915.modeset=1 to the kernel command line. When I activated it on my Latitude X1 laptop, the
kernel immediately during the boot switches to the native 1280x768 resolution for the console,
X startup does not flush any longer and the VT switch becomes really instant. 

For the moment the support is rather buggy. The display stays dead after the suspend and video
players show a garbage. But I do have high hopes for Fedora-10 :).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 9:46 UTC (Mon) by jamesh (guest, #1159) [Link]

The code for mode setting needs to go somewhere.  If it isn't in the kernel it will need to be
somewhere else.

If the code is in the kernel, then it should be able to reliably save and restore the video
mode over a suspend or resume (since the ACPI spec gives no guarantee over what state the
hardware will be in on resume).  This beats hacks like trying to rerun the video BIOS
initialisation code under an x86 emulator or VM86 mode.

I'm not sure why you wouldn't want the kernel to be able to initialise the primary output
device of your computer ...