[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31

[Duncan]

Mark Knecht <markknecht@×××××.com> posted
5bdc1c8b0906170847u241d3f5fg34cc48d6e1a5ab3b@××××××××××.com, excerpted
below, on  Wed, 17 Jun 2009 08:47:57 -0700:

> So what would KMS do for me when I finally have access to it?

KMS, kernel mode setting, finally unifies the mode (resolution) setting 
between X and the text console framebuffer.  This has always been a very 
hairy and delicate area, with all sorts of potential and real bugs due to 
what's essentially two entirely separate sets of code handling the 
display.  Often, the bugs showed up as being unable to get a text console 
back once X took over, or in full machine crashes.

But there's more to it than simply avoiding that.  Among other things, 
for those who consider "boot" to mean starting X and getting to a 
graphical login (or auto-login all the way to the desktop), it'll mean 
avoiding the disconcerting blinks and moments of blank-screen as X 
starts, as X will (normally) continue to use the same mode the text 
framebuffer was using.  For those that like staring at rather 
uninformative picture during the boot process, rather than seeing all 
those text messages go by, that will work better and be smoother as well.

Also, the process will be much faster, as currently, the kernel runs its 
detection at boot, then X runs its detection when it starts, and now 
those will be combined into only a single detection run.  Switching 
between a text VT and the X VT (or more than one X VT, with fast-user-
switching) will be much faster and less prone to lockups, as well.

Another big feature KMS brings is that letting the kernel handle all that 
code will mean that the X userspace code doesn't need root privs any 
more, and can be started as a normal user.  For /decades/ (since before 
Linux even came to be) the fact that all that hard-to-audit X code runs 
as root, with X generally the biggest application by far to run as root, 
has made the computer security types extremely nervous, thinking about 
all the potential ways all that X code running as root might be exploited 
to get root privs.  Now X will be able to run as an ordinary user 
program, or as a non-root system level "xorg" user or the like, just as 
most other system level services do.  That's going to make a *LOT* of 
security folks MUCH happier! =:^)

Yet another KMS feature will be that finally, when there's a system crash 
within X, the kernel will be able to spit the kernel panic to the screen, 
where people can grab the info and report it, something that has only 
worked from a text console before, because X controlled the display when 
it was showing and the kernel, particularly an already panicking kernel, 
couldn't simply grab it and print the error like it could from text 
mode.  (FWIW, these sorts of problems can't be logged to local disk 
either, because by the time the kernel knows there's a problem, it dares 
not write anything else to disk because it can't be sure it's in a sane 
enough state to know where it's writing any more.  It can write to a 
network port if network logging is enabled, or to the screen, but not to 
disk, lest it overwrite something valuable because it's screwed up enough 
it doesn't know where on the disk it's writing.)  In a way, this brings 
the infamous BSOD to Linux -- Linux can spit out that final crash message 
just like Windows can, now -- but of course we think we can do it better 
than Windows does.  But one does hope that whatever they come up with for 
this doesn't in time become as famous as the BSOD on Windows!

Finally, the X graphics drivers, including the 3D/DRM hardware level 
drivers, are going to become much simpler.  Basically, after the change 
is complete, either the X hardware level drivers will be a thin wrapper 
around the interface the kernel exposes, or they'll not exist at all, 
with X sending everything to the kernel over a generic interface, say 
OpenGL, at least for newer hardware, that really doesn't have a dedicated 
2D hardware layer at all, only emulation running on the 3D layer.  In 
either case, however, X will be smaller and rather less complicated, 
while the much faster updating kernel handles the hardware.  Among other 
things, this will likely mean much faster support for new graphics cards, 
etc, again, because all the code is in one place now, not two very 
different code sets sharing and fighting with each other for control, 
that must be coordinated between themselves as well as updated for the 
new hardware.

Thus, in general, it'll be a much smoother, potentially much faster, and 
much safer, experience for the user.

OTOH, getting from here to there will involve some challenges.  The Intel 
graphics folks have been bearing the brunt of it, leading the pack, with 
quite some bleeding going on as well, as the various levels temporarily 
fell out of sync with each other, with some hardware supported best using 
one combination of kernel, x-driver, drm modules, and xorg-server, while 
other hardware was supported best with a different combination, so what 
worked best for one Intel graphics user might not work at all for another.

Fortunately, the rest of the pack was able to learn a lot from the Intel 
experience, and it should be much smoother for the Radeon and Nouveau 
(new open source nVidia graphics) drivers.  But with the level of change 
going on, there's going to be bumps regardless.  That'll mean some 
challenges for xorg-overlay and ~arch users, while it's likely to mean 
stable users will be left even further behind temporarily (much as they 
were with xorg-server 1.3 (1.4?) for so long), until it all settles down 
enough to stabilize the new setup for them.

For more, the phoronix.com site, focusing on Linux gaming and 3D, is very 
good on all things X hardware and driver related.  Here's a link to their 
display drivers page, with articles covering this and other developments 
both current and back some time.

http://www.phoronix.com/scan.php?page=category&item=Display%20Drivers

Also of interest, various articles from LWN, H-Online, and ArsTechnica, 
which all cover Linux, the kernel, and X, from varying angles in varying 
degrees of detail as part of their more general coverage.

http://lwn.net
http://h-online.com
http://arstechnica.com

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman