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

[Mark Knecht]

On Wed, Jun 17, 2009 at 10:24 AM, Duncan<1i5t5.duncan@×××.net> wrote:
> 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
>
>
>

Good stuff.

So guessing about the path:

1) Kernel get KMS.
2) Xorg-X11 develops and tests for awhile. (probably on-going now?)
3) Gentoo devs and bleeding edge users play with it for awhile.
4) Shows up in portage under ~amd64 (Is that the same as ~arch for AMD64?)
5) More bleeding edge users play with it
6) Becomes stable
7) I get it.

What's that? About 1-2 years or something?

None the less, sounds like quite a nice improvement. I've had LOTS of
times where going back and forth between console and X hasn't been
perfect, and I certainly don't like the annoying blinks, etc.

Thanks,
Mark