[gentoo-amd64] Hurray! Radeon KMS in 2.6.31

[gentoo-amd64] Hurray! Radeon KMS in 2.6.31

[Duncan]

As I've mentioned a couple times recently, I run direct Linus kernel 
git.  Previously I've waited until rc2 or so before trying the new 
development kernel, but I got bored and decided to try following the 
kernel even in the merge window this time.

Sometime in the last 24 hours or so, Linus merged the Radeon KMS (kernel 
mode setting) code!  I've been looking forward to this for a couple 
versions now, so am glad it's finally here!

Presently, it's only thru the Radeon r5xx chip series, so thru the model 
x1950 cards.  They'll add the newer r6xx/r7xx chips (beyond x1950 and the 
hd* cards) later.

Of course I'm not actually running kms yet, as my X userspace isn't new 
enough (I don't think, AFAIK the xorg-server-1.6.1.901-r3 that I'm 
running should support it, but the xf86-video-ati-6.12.2 doesn't yet, I'd 
need the -9999 live git version for that, and would probably need to 
match it with the live-git xorg-server-9999 as well), so I've not enabled 
the kernel's radeon-kms-by-default option, which appears under the 
staging drivers for the moment.  But it's in the kernel mainline now, and 
I'm running that kernel (2.6.30-6553-g65795ef) with no general observed 
issues ATM.

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

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

[Mark Knecht]

On Wed, Jun 17, 2009 at 7:15 AM, Duncan<1i5t5.duncan@cox.net> wrote:
> As I've mentioned a couple times recently, I run direct Linus kernel
> git.  Previously I've waited until rc2 or so before trying the new
> development kernel, but I got bored and decided to try following the
> kernel even in the merge window this time.
>
> Sometime in the last 24 hours or so, Linus merged the Radeon KMS (kernel
> mode setting) code!  I've been looking forward to this for a couple
> versions now, so am glad it's finally here!
>
> Presently, it's only thru the Radeon r5xx chip series, so thru the model
> x1950 cards.  They'll add the newer r6xx/r7xx chips (beyond x1950 and the
> hd* cards) later.
>
> Of course I'm not actually running kms yet, as my X userspace isn't new
> enough (I don't think, AFAIK the xorg-server-1.6.1.901-r3 that I'm
> running should support it, but the xf86-video-ati-6.12.2 doesn't yet, I'd
> need the -9999 live git version for that, and would probably need to
> match it with the live-git xorg-server-9999 as well), so I've not enabled
> the kernel's radeon-kms-by-default option, which appears under the
> staging drivers for the moment.  But it's in the kernel mainline now, and
> I'm running that kernel (2.6.30-6553-g65795ef) with no general observed
> issues ATM.
>
> --
> 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

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

Thanks,
Mark

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

[Duncan]

Mark Knecht <markknecht@gmail.com> posted
5bdc1c8b0906170847u241d3f5fg34cc48d6e1a5ab3b@mail.gmail.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

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@cox.net> wrote:
> Mark Knecht <markknecht@gmail.com> posted
> 5bdc1c8b0906170847u241d3f5fg34cc48d6e1a5ab3b@mail.gmail.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

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

[Nikos Chantziaras]

On 06/17/2009 08:35 PM, Mark Knecht wrote:
> Good stuff.
>
> So guessing about the path:
>
> 1) Kernel get KMS.
> 2) Xorg-X11 develops and tests for awhile. (probably on-going now?)

Yup, it's working already because Intel graphics chips already had KMS 
for a while now.  It's already in Ubuntu and Fedora (though not enabled 
by default, I think.)


> 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?)

~arch means the same regardless of architecture ;)  It's "~x86" for 
IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc.


> 5) More bleeding edge users play with it
> 6) Becomes stable
> 7) I get it.
>
> What's that? About 1-2 years or something?

Probably sooner.  New X.Org releases will hit stable portage much sooner 
then it took for 1.5 to arrive since the jump from 1.3 to 1.5 was much 
harder than the future jump from 1.5 to 1.6.


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

Switching to a VT instantly (and it's really *instant*; it's like 
switching to another virtual desktop) is the most important feature for 
me.  Running X as user comes next.  The boot thingy isn't important at 
all to me.  Unfortunately, it will be a whole while for me to get it 
since I'm on a Radeon HD4870 which is not supported by any open source 
drivers at all right now.

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

[James Ausmus]

[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]

On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras <realnc@arcor.de> wrote:

> On 06/17/2009 08:35 PM, Mark Knecht wrote:
>
>> Good stuff.
>>
>> So guessing about the path:
>>
>> 1) Kernel get KMS.
>> 2) Xorg-X11 develops and tests for awhile. (probably on-going now?)
>>
>
> Yup, it's working already because Intel graphics chips already had KMS for
> a while now.  It's already in Ubuntu and Fedora (though not enabled by
> default, I think.)


Just as a note - the Radeon KMS uses a different implementation path than
the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management,
while Radeon (and Nouveau, and other upcoming) use the new TTM (which is
also new for .31) - I don't *think* this will affect how X interfaces with
the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened
in .29), it might still be a little bit before the wrinkles are worked out.
As far as the X server interfacing with the new kernel driver, I *believe*
that pretty much all the action behind the scenes happens in the X driver
itself, with the X server being pretty much unaware of the change (please
feel free to correct me if I'm wrong), so, just because the Intel driver has
already been utilizing the KMS kernel interface for a little while, doesn't
necessarily mean that it will make the Radeon X driver transition any
smoother/better/shorter.



>
>
>
>  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?)
>>
>
> ~arch means the same regardless of architecture ;)  It's "~x86" for
> IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc.
>
>
>  5) More bleeding edge users play with it
>> 6) Becomes stable
>> 7) I get it.
>>
>> What's that? About 1-2 years or something?
>>
>
> Probably sooner.  New X.Org releases will hit stable portage much sooner
> then it took for 1.5 to arrive since the jump from 1.3 to 1.5 was much
> harder than the future jump from 1.5 to 1.6.


Dunno - X server 1.6 has been out for quite a while (several months - X
server 1.7 is due out in just about 1.5 months at this point), and it just
very recently hit the portage ~ tree (not that I'm complaining Devs - I
understand that there were issues that would've bit lots of users), so it
might be a while before you see Radeon KMS support in the fully stable
portage tree - don't hold your breath quite yet. ;) Of course, if your
system isn't mission-critical, you could always install the -9999 versions,
or at least the ~ versions when they hit, and help move along the
debugging/stabilization process, so that they hit the stable tree faster...
;)


>
>
>
>  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.
>>
>
> Switching to a VT instantly (and it's really *instant*; it's like switching
> to another virtual desktop) is the most important feature for me.  Running X
> as user comes next.  The boot thingy isn't important at all to me.
>  Unfortunately, it will be a whole while for me to get it since I'm on a
> Radeon HD4870 which is not supported by any open source drivers at all right
> now.


Having run the Intel KMS kernel/fbcon/X driver for a little while now, I can
say that 2 things *really* stand out to me (at least from my usage model):

1. Native framebuffer console resolution on my 1680x1050 widescreen LCD - no
more 1280x1024 stretched! (Actually not sure if this is directly due to the
kernel updates for Intel/KMS, or just happened to happen at the same time,
but still - Yay!)
2. Perfectly fast X/virtual console switching - I mean - Wow! I still, from
time to time, just sit there switching between the two a couple times just
to watch the speed and smoothness - it's amazing...

-James

[-- Attachment #2: Type: text/html, Size: 5225 bytes --]

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

[Sebastian Redl]

James Ausmus wrote:
>
>
> On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras <realnc@arcor.de
> <mailto:realnc@arcor.de>> wrote:
>
>     On 06/17/2009 08:35 PM, Mark Knecht wrote:
>
>         Good stuff.
>
>         So guessing about the path:
>
>         1) Kernel get KMS.
>         2) Xorg-X11 develops and tests for awhile. (probably on-going
>         now?)
>
>
>     Yup, it's working already because Intel graphics chips already had
>     KMS for a while now.  It's already in Ubuntu and Fedora (though
>     not enabled by default, I think.)
>
>
> Just as a note - the Radeon KMS uses a different implementation path
> than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory
> management, while Radeon (and Nouveau, and other upcoming) use the new
> TTM (which is also new for .31) - I don't *think* this will affect how
> X interfaces with the kernel driver, but, since TTM is newer than GEM
> (GEM/Intel KMS happened in .29), it might still be a little bit before
> the wrinkles are worked out.
TTM is actually older than GEM, but the Intel guys didn't like TTM and
invented GEM. But GEM is more of an interface than an implementation.
Intel has their own implementation of the GEM interface, and Radeon and
Nouveau will probably share the TTM-based GEM implementation that has
entered the kernel now.

Sebastian

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

[Nikos Chantziaras]

On 06/17/2009 09:48 PM, Sebastian Redl wrote:
> James Ausmus wrote:
>>
>> On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras<realnc@arcor.de
>> <mailto:realnc@arcor.de>>  wrote:
>> Just as a note - the Radeon KMS uses a different implementation path
>> than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory
>> management, while Radeon (and Nouveau, and other upcoming) use the new
>> TTM (which is also new for .31) - I don't *think* this will affect how
>> X interfaces with the kernel driver, but, since TTM is newer than GEM
>> (GEM/Intel KMS happened in .29), it might still be a little bit before
>> the wrinkles are worked out.
> TTM is actually older than GEM, but the Intel guys didn't like TTM and
> invented GEM. But GEM is more of an interface than an implementation.
> Intel has their own implementation of the GEM interface, and Radeon and
> Nouveau will probably share the TTM-based GEM implementation that has
> entered the kernel now.

GEM is newer and more suitable for "non high-performance" chips, like 
integrated graphics chips from Intel.  High-performance GPUs (like 
AMD/ATI) don't come along with GEM very well.

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

[Duncan]

James Ausmus <james.ausmus@gmail.com> posted
b79f23070906171116v24babcedh47c1c9b5fca3931b@mail.gmail.com, excerpted
below, on  Wed, 17 Jun 2009 11:16:50 -0700:


> Just as a note - the Radeon KMS uses a different implementation path
> than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory
> management, while Radeon (and Nouveau, and other upcoming) use the new
> TTM (which is also new for .31) - I don't *think* this will affect how X
> interfaces with the kernel driver, but, since TTM is newer than GEM
> (GEM/Intel KMS happened in .29), it might still be a little bit before
> the wrinkles are worked out.

As Sebastian Redi indicated, TTM is actually older.  FWIW, from my 
viewpoint at least, it looks a bit like "NIH syndrome" (not invented here 
syndrome) from the Intel guys.  Whatever.  They didn't like TTM as it was 
already being implemented for Radeon and some of the other drivers 
(Nouveau, etc) and came up with their own thing, GEM, which works 
particularly well with the Intel hardware implementation but not quite as 
well with other implementations.  But for various reasons Intel's GEM hit 
the mainline kernel first.

Meanwhile, the TTM folks continued what they were doing, and now it's 
hitting mainline, but using the GEM interface (as SR again mentioned).  
It's all a bit confusing, even for those such as myself who follow Linux 
developments reasonably closely and have been reading pretty much 
anything they see on it.

> As far as the X server interfacing with the
> new kernel driver, I *believe* that pretty much all the action behind
> the scenes happens in the X driver itself, with the X server being
> pretty much unaware of the change (please feel free to correct me if I'm
> wrong), so, just because the Intel driver has already been utilizing the
> KMS kernel interface for a little while, doesn't necessarily mean that
> it will make the Radeon X driver transition any smoother/better/shorter.

Well, it's some of both, actually.  xorg-server has to support it, but so 
does the X driver, which with KMS ultimately becomes as I mentioned 
earlier, not a lot more than a wrapper around the kernel code, with xorg-
server in turn interfacing with the wrapper.  But since it'll be awhile 
before it can be assumed that the kernel has KMS drivers on its side, the 
driver will remain more than a wrapper for awhile, but disable most of 
itself and only act as a wrapper when KMS is turned on.

In addition to that, the first one is /always/ the hardest, and now that 
it is done, the rest will come easier.

So while you are indeed correct that there's some implementation details 
in the X driver that the Intel driver doesn't help with directly for 
others (particularly since it went its own way, implementing GEM 
directly, instead of the GEM interface to TTM that the others are using), 
that's only one piece of the puzzle.  With many of the other pieces, 
having the first one, Intel, in place and working out the general issues 
and testing the general idea, means the others have it MUCH easier.

>>> 4) Shows up in portage under ~amd64 (Is that the same as ~arch for
>>> AMD64?)
>>>
>> ~arch means the same regardless of architecture ;)  It's "~x86" for
>> IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc.

Exactly.  ~arch is simply the generic term, while ~amd64 would be the 
specific version the readers of this list will be concerned with.

> Dunno - X server 1.6 has been out for quite a while (several months - X
> server 1.7 is due out in just about 1.5 months at this point), and it
> just very recently hit the portage ~ tree (not that I'm complaining Devs
> - I understand that there were issues that would've bit lots of users),
> so it might be a while before you see Radeon KMS support in the fully
> stable portage tree - don't hold your breath quite yet. ;) Of course, if
> your system isn't mission-critical, you could always install the -9999
> versions, or at least the ~ versions when they hit, and help move along
> the debugging/stabilization process, so that they hit the stable tree
> faster... ;)

That's my take on it too.  Hopefully it won't be 2 years before stable, 
but it could well be 18 months, and will almost certainly be at /least/ 9 
months for Radeon, 6 months for Intel, and a year for others.  It's a big 
change and for Intel users so far, has been /anything/ but smooth.

> Having run the Intel KMS kernel/fbcon/X driver for a little while now, I
> can say that 2 things *really* stand out to me (at least from my usage
> model):
> 
> 1. Native framebuffer console resolution on my 1680x1050 widescreen LCD
> - no more 1280x1024 stretched! (Actually not sure if this is directly
> due to the kernel updates for Intel/KMS, or just happened to happen at
> the same time, but still - Yay!)

Well, the radeonfb drivers have existed in the kernel for years, so for 
older radeon users at least, they've had the possibility of full/native 
resolution framebuffer for some time.

And for those without a specific native hardware fb, there was always 
vesafb.

But you are correct in how nice that extra resolution can be.  Before I 
ran the framebuffer, I ran normal vgacon, but at the highest resolution I 
could figure out how to get, and with a small font (4x6 IIRC), so I did 
get a reasonable display (132x50 chars or some such).  However, 
framebuffer was even better, 1600x1200 resolution on my old CRTs, 
1920x1200 on the new LCDs, now 240x75 chars with the larger standard font 
(8x16).

But regular framebuffer still isn't KMS, lacking the other features 
mentioned.

> 2. Perfectly fast X/virtual console switching - I mean - Wow! I still,
> from time to time, just sit there switching between the two a couple
> times just to watch the speed and smoothness - it's amazing...

Now /that's/ what I'm looking forward to!  Well, that and the security of 
not having to run X as root. =:^)

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