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

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

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

[Dmitri Pogosyan]

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

You know, I after some trouble I found a VESA code for my also not so standard
1440x900, so that vesafb happily provided me with native console since 2.6.27
(if not .25) (had a nice program that displayed supported framebuffer modes -
what was it ?)


> 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

I wonder, what are the negatives of moving modesetting to kernel from
userspace ? Will we be loosing some functionality (at least temperarily) ?
How will, say, choosing mode on external distplay work ?



--
Dmitri Pogosyan            Department of Physics
Associate Professor        University of Alberta
tel 1-780-492-2150         11322 - 89 Avenue
fax 1-780-492-0714         Edmonton, AB, T6G 2G7, CANADA

[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

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

[Nikos Chantziaras]

On 06/17/2009 10:19 PM, Dmitri Pogosyan wrote:
>> 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...
>
> I wonder, what are the negatives of moving modesetting to kernel from
> userspace ? Will we be loosing some functionality (at least temperarily) ?
> How will, say, choosing mode on external distplay work ?

No negative sides to it, really.  Speed will also benefit (not directly 
from KMS but rather from TTM/GEM) since the biggest problem with the 
open source drivers right now is the lack of a memory manager (this is 
the main reason why the closed source drivers perform better by an order 
of magnitude, even though they have the memory manager in user space).

I'm not sure about the mode for external displays.  The configuration 
will probably still happen at the same place, though under the hood the 
work will be done by the kernel.

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

[Duncan]

"Dmitri Pogosyan" <pogosyan@phys.ualberta.ca> posted
200906171919.n5HJJ7007690@webmail.phys.ualberta.ca, excerpted below, on 
Wed, 17 Jun 2009 13:19:07 -0600:

> I wonder, what are the negatives of moving modesetting to kernel from
> userspace ? Will we be loosing some functionality (at least temperarily)
> ? How will, say, choosing mode on external distplay work ?

The biggest negative for the Intel users has been the rough ride, and 
yes, some functionality is certainly lost during the transition.  It's 
about done for the Intel users but just starting for Radeon users.  Let's 
see if I can find the (Intel dev) blog I read on that...

http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/

The date posted was April 24, 2009

Excerpts...

Because all of these changes cross multiple projects (X/Mesa/Linux), 
we’ve tried to make sure we supported all of the possible combinations. 
Let’s see what options we’ve got:

Mode Setting
  1 User Mode
  2 Kernel Mode

Direct Rendering
  1 None
  2 DRI1
  3 DRI2

Memory Management
  1 X server + Old-style DRI
  2 GEM

2D acceleration
  1 None
  2 XAA
  3 EXA
  4 UXA

Pick One From Each [Category]

With 2 × 3 × 2 × 4 = 48 combinations, you can imagine that:
  Some of them can’t work together
  Some of them haven’t been tested
  Some of them haven’t been tuned for performance
  Some work well on i915, and poorly on 965GM
  Others work well on 965GM and poorly on 855
  None of them (yet) work perfectly well everywhere

The obvious result here is that we’re at a point where application 
performance goes all over the map, depending on the hardware platform and 
particular set of configuration options selected.

Light at Tunnel’s End

The good news is that our redesign is now complete, and we have the 
architecture we want in place throughout the system — global graphics 
memory management, kernel mode setting and per-window 3D buffers. This 
means that the rate of new code additions to the driver has dropped 
dramatically; almost to zero. Going forward, users should expect this 
‘perfect’ combination to work more reliably, faster and better as time 
goes by.

End excerpts...

As I said, it was quite the rough ride.  But that was nearing the end of 
April, and things have been better since.  Hopefully Radeon won't be 
quite as bad.  We'll see I guess.

As for the last question, the example of external display mode, at 
minimum, it shouldn't regress (except for temporary regressions of the 
type Keith explained in his blog).  The xorg folks have put an enormous 
amount of work into hotplug, and they won't be letting that go just for 
this.  I'm not entirely sure on this, but from my understanding, X will 
still be in control of the modes.  It'll simply use the kernel's EDID/DDC 
detection instead of its own to see what modes are there (and whether any 
additional modes as configured will work within the detected card and 
monitor parameters) and to do the actual mode switches, but it'll be 
telling the kernel what mode to use, tho the default will be native/
primary mode for both the CLI/text framebuffer and X initially, thus no 
mode change switching between them.

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

[Dmitri Pogosyan]

> 
> As I said, it was quite the rough ride.  But that was nearing the end of 
> April, and things have been better since.  Hopefully Radeon won't be 
> quite as bad.  We'll see I guess.

I am with Intel laptop since last September and passed through all of that.
It actually was not that bad, aspecially given that I don't need 3D
functionality much (although I tried to keep it in best working state)


> 
> As for the last question, the example of external display mode, at 
> minimum, it shouldn't regress (except for temporary regressions of the 
> type Keith explained in his blog).  The xorg folks have put an enormous 
> amount of work into hotplug, and they won't be letting that go just for 
> this.  I'm not entirely sure on this, but from my understanding, X will 
> still be in control of the modes.  It'll simply use the kernel's EDID/DDC 
> detection instead of its own to see what modes are there (and whether any 
> additional modes as configured will work within the detected card and 
> monitor parameters) and to do the actual mode switches, but it'll be 
> telling the kernel what mode to use, tho the default will be native/
> primary mode for both the CLI/text framebuffer and X initially, thus no 
> mode change switching between them.

Interestingly, I don't care much about VT switching (well, no flickering is
nice, but I switch perhaps once every few days), nor security (I use X for 16
years already from the epoch of X-terminals, and never really heard of any
specific case when X was used to break in mind doing any damage, again its
nice to be safer, but overall it seems like red herring) nor that much about
framebuffer resolution because I got may native 1440x900 from vesafb just fine. 

Multimonitor functionality is, however, a must. Think laptop as a presentation
tool. So I wonder how kernel will deal with two different resolutions on
separate pipes, whether one can force it to a specific mode (which sometimes
needed with this bloody projectors), I mean all this xrandr type mode-related
functionality. Hopefully this is all well though through and there will be no
extended period when it somehow does not work.

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

[Duncan]

"Dmitri Pogosyan" <pogosyan@phys.ualberta.ca> posted
200906172226.n5HMQ9o11978@webmail.phys.ualberta.ca, excerpted below, on 
Wed, 17 Jun 2009 16:26:09 -0600:

> Multimonitor functionality is, however, a must.

FWIW, I'm in 100% agreement with you.  I run dual 1920x1200 stacked for 
1920x2400, and if the new drivers don't do that, I'll be back to the old 
drivers faster than fsck!

But I don't expect it to be a problem, because while it's relatively 
uncommon to run dual desktop monitors and probably always will be as 
laptops are the majority seller now, there's a LOT of folks now days that 
will flat call it broken if their laptop can't work with both the 
internal and external monitors at the same time!  In fact, that was and 
remains the big push behind RandR and input hotplugging as well, and now 
that they've got it working reasonably well, they're NOT going to go back 
to having it broken, or people will be walking away, as I said, faster 
than fsck!

Plus, enough of the xorg devs work with laptops and do enough "mobile 
warrioring" that it's not as if they don't have the hardware or the need 
to keep it working just for themselves, because they do.

So I just don't see it as even a possibility that they'll implement it 
without that.

Still it's a a very good question, one that while it's important to me, I 
hadn't thought of, simply because I /don't/ believe it within the realm 
of reason.  So I'm glad /someone's/ thinking about it!

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

[Lie Ryan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> "Dmitri Pogosyan" <pogosyan@phys.ualberta.ca> posted
> 200906172226.n5HMQ9o11978@webmail.phys.ualberta.ca, excerpted below, on 
> Wed, 17 Jun 2009 16:26:09 -0600:
> 
>> Multimonitor functionality is, however, a must.
> 
> FWIW, I'm in 100% agreement with you.  I run dual 1920x1200 stacked for 
> 1920x2400, and if the new drivers don't do that, I'll be back to the old 
> drivers faster than fsck!
> 
> But I don't expect it to be a problem, because while it's relatively 
> uncommon to run dual desktop monitors and probably always will be as 
> laptops are the majority seller now, 

I'd rather say, because laptops are the majority now, dual monitor
support is going to be more important. I (and I'm sure many others)
prefer doing presentations from my own laptop, rather than using the
audience's computers (which always have issues with not having the
appropriate programs, etc; not to mention having to move the
presentation files, which is easier said than done).

One thing that always bugs me is that XRandR requires some
configuration[1] and X restart[2], which is a pity, since doing
presentations means setting up ad-hoc/temporary settings which is just
used for an hour or two, then tearing them apart again then doing that
again the next day, probably on a different venue.

Mirrored is okay, but I prefer Xinerama/extended desktop. Now that
OpenOffice 3 starts having support for Presenter View (where the
projector displays the presentation and your laptop's your notes), not
being able to just plug the cable in and have the whole thing set up
automagically is a big loss.

[1] not to mention I never get all the settings right, either hardware
acceleration or Xinerama. A separate X display is acceptable, but still
no hardware acceleration.
[2] to move between single display to Xinerama and back.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6Yh0ACgkQqC3FTmXeMUYJQwCdH6ZHqjzLELUm+suHjSlgIOln
HPkAnAtL5kIoNO2FoLQJlwW6jlg05iDs
=VtdP
-----END PGP SIGNATURE-----

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

[Dmitri Pogosyan]

> One thing that always bugs me is that XRandR requires some
> configuration[1] and X restart[2], 

Why are you say that ? One surely does not need to restart X, that's  the
whole point of XrandR


--
Dmitri Pogosyan            Department of Physics
Associate Professor        University of Alberta
tel 1-780-492-2150         11322 - 89 Avenue
fax 1-780-492-0714         Edmonton, AB, T6G 2G7, CANADA

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

[Duncan]

Lie Ryan <lie.1296@gmail.com> posted 4A3A621D.8010207@gmail.com, excerpted
below, on  Fri, 19 Jun 2009 01:49:49 +1000:

> I'd rather say, because laptops are the majority now, dual monitor
> support is going to be more important. I (and I'm sure many others)
> prefer doing presentations from my own laptop, rather than using the
> audience's computers (which always have issues with not having the
> appropriate programs, etc; not to mention having to move the
> presentation files, which is easier said than done).

I thought that's what I /was/ saying, with the additional bit that dual 
desktop display probably never will become the majority, because desktops 
are losing the majority, so there's no time left for dual desktop 
displays to become the majority -- the majority is now laptop, and dual 
display with a laptop is much more common than it ever became on the 
desktop.

> One thing that always bugs me is that XRandR requires some
> configuration[1] and X restart[2], which is a pity, since doing
> presentations means setting up ad-hoc/temporary settings which is just
> used for an hour or two, then tearing them apart again then doing that
> again the next day, probably on a different venue.

Well, in theory, you can setup the config once, and as long as the second 
display plugged in fits within the parameters set in the config, it'll be 
used as such, no X restart should be needed.

One of the CRITICAL bits of the config to get it to do that is to set the 
initial "Section Screen, Subsection Display, Virtual x y" size large 
enough to accommodate the maximum combined resolution, as I don't believe 
xorg yet knows how to increase that size once it's started. (But they're 
actively working on it for later xorg-server releases.)  Depending on the 
desktop environment and how it is configured, that /may/ put stuff 
offscreen.

Beyond that, everything should be hotpluggable and dynamically 
reconfigurable using xrandr or the like.  However, one of the problems 
I've observed so far is that at least the KDE krandrtray and kcontrol/
settings applets, and likely few of the other graphical applets, 
regardless of creator, have the full flexibility xrandr offers.  But 
xrandr is terminal window CLI, you have to read the manpage to groke it, 
and comparatively few people do that -- they like their GUI controls.  
FWIW I think the problem is development latency.  The RandR spec and 
featureset is developing quite rapidly in xorg, and while xrandr is kept 
upto date and shipped with xorg, the graphics widgets aren't, and must be 
developed and tested against the new xorg and RandR before they can ship, 
so they're always running behind what's actually available in the latest 
xorg release.

Meanwhile, RandR 1.3, available with xorg-server 1.6 (possibly 1.5 but I 
don't remember for sure), is finally starting to get back in RandR form 
the features, such as viewport panning, available pre-RandR.  When the 
viewport is smaller than the virtual desktop, panning can be rather 
useful, even critical, but it simply wasn't available with early RandR 
versions.  RandR 1.3 brings it back, in an even more advanced and 
flexible form than pre-randr panning, with a lot more configurability.  
With that, RandR is finally maturing into something actually reasonably 
useful for non-uniform resolution multi-monitor support.  I do hope that 
the graphical RandR clients catch up and support RandR 1.3 very well, as 
it does finally seem to be relatively mature, functionally, now.

Anyway, at least using xrandr, once RandR 1.3 and xorg-server 1.6 hit, as 
long as you start xorg with a large enough virtual desktop, you should be 
able to configure everything else without restarting again.  I know I've 
been able to activate and deactivate one or the other of my monitors 
here, without issue, except that when I reactivate one it starts out in 
clone mode and I have to run my xrandr script to get the two viewports 
set back to the normal configuration.

The other problem is that a lot of apps aren't particularly RandR aware 
yet, or only expect to be using it with a single monitor, so putting 
stuff in full-screen mode can have unexpected consequences, as it often 
changes the resolution for BOTH monitors, and either puts the full-screen 
app centered between them (but at the size of only one of them, so it's 
not really full-screen), or clones to both, instead of only cloning to 
one and leaving the other one alone.

But that's not xorg's or RandR's problem, that's the application's 
problem.  And with the appropriate scripted and hotkey invoked xrandr 
calls, as I have setup, it's relatively easy to get the system back to 
its proper configuration, even when the apps screw it up.

> Mirrored is okay, but I prefer Xinerama/extended desktop. Now that
> OpenOffice 3 starts having support for Presenter View (where the
> projector displays the presentation and your laptop's your notes), not
> being able to just plug the cable in and have the whole thing set up
> automagically is a big loss.

Indeed.  My config is dual monitor desktop and I'm not a "mobile 
warrior", but I can certainly see the use for that in mobile warrior 
presentation situations.

> [1] not to mention I never get all the settings right, either hardware
> acceleration or Xinerama. A separate X display is acceptable, but still
> no hardware acceleration.
> [2] to move between single display to Xinerama and back.

It'll be nice when the xrandr based graphical monitor/desktop config 
applets catchup, and Linux/X finally catches up to what MSWindows was 
doing over a decade ago back with Windows 98!  Linux/X has been more 
flexible in some areas, but unfortunately, that has never been one of 
them.  But it's getting there, FINALLY!

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

[Lie Ryan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dmitri Pogosyan wrote:
>> One thing that always bugs me is that XRandR requires some
>> configuration[1] and X restart[2], 
> 
> Why are you say that ? One surely does not need to restart X, that's  the
> whole point of XrandR
> 

For changing "Resolution and Rotation", you're correct; but with or
without randr, whatever I tried I can't switch between single monitor
and dual monitor and back without restarting X.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6pvsACgkQqC3FTmXeMUZp7ACfSxzIrQDUzk0WN/8YWqJa3+Nq
lhQAn3rn0EanTwlzBKhobRs7lB55U1/d
=mOYR
-----END PGP SIGNATURE-----

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

[Wil Reichert]

On Thu, Jun 18, 2009 at 1:43 PM, Lie Ryan<lie.1296@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dmitri Pogosyan wrote:
>>> One thing that always bugs me is that XRandR requires some
>>> configuration[1] and X restart[2],
>>
>> Why are you say that ? One surely does not need to restart X, that's  the
>> whole point of XrandR
>>
>
> For changing "Resolution and Rotation", you're correct; but with or
> without randr, whatever I tried I can't switch between single monitor
> and dual monitor and back without restarting X.

I do this hooking my laptop up to my livingroom TV frequently, works
great.  Something like

xrandr --output TV-6 --auto
xrandr  --output LVDS --off

is about all it takes.

Wil

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

[Duncan]

Lie Ryan <lie.1296@gmail.com> posted 4A3AA6FB.3010409@gmail.com, excerpted
below, on  Fri, 19 Jun 2009 06:43:39 +1000:

> For changing "Resolution and Rotation", you're correct; but with or
> without randr, whatever I tried I can't switch between single monitor
> and dual monitor and back without restarting X.

Four questions:

1.  What version of xorg and RandR (I'm not sure which *randr* package 
but they're all the same version here so I'll pick libXrandr)?

The ~arch xorg 1.6 and *randr* 1.3 work MUCH better than previous 
versions, which were flat-out missing certain very useful functionality.

2.  "Whatever I tried".  Did you try xrandr?

As I explained in another post, the GUI versions seem to be "functionally 
challenged" if not flat-out broken in some aspects.  xrandr 1.3 works 
very well here.

3.  Have you tried setting the virtual desktop size (as explained in that 
other post)?

I haven't actually tried it with the newest xorg-server (1.6.1.901, FWIW 
Gentoo revision 3), but last I was aware, xorg-server couldn't exand the 
virtual desktop from what it was when it initially started.  Since it 
defaults to the same size as the detected resolution, if you've not set 
it to a sufficient size in xorg.conf, you'll have issues trying to get 
anything other than clone mode without rebooting, since there's no 
further desktop for it to expand into.

4.  What graphics drivers?  Version?

I'm currently running the Radeon driver from xf86-video-ati, version 
6.12.2.  Certain drivers haven't been converted to RandR yet, or may not 
be updated to use use full current xorg-server and RandR functionality.

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

[Lie Ryan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Lie Ryan <lie.1296@gmail.com> posted 4A3A621D.8010207@gmail.com, excerpted
> below, on  Fri, 19 Jun 2009 01:49:49 +1000:
> 
>> I'd rather say, because laptops are the majority now, dual monitor
>> support is going to be more important. I (and I'm sure many others)
>> prefer doing presentations from my own laptop, rather than using the
>> audience's computers (which always have issues with not having the
>> appropriate programs, etc; not to mention having to move the
>> presentation files, which is easier said than done).
> 
> I thought that's what I /was/ saying, with the additional bit that dual 
> desktop display probably never will become the majority, because desktops 
> are losing the majority, so there's no time left for dual desktop 
> displays to become the majority -- the majority is now laptop, and dual 
> display with a laptop is much more common than it ever became on the 
> desktop.

Ah I see, I didn't notice you're saying it is dual monitor desktop that
is declining; instead of dual monitor setup.

>> One thing that always bugs me is that XRandR requires some
>> configuration[1] and X restart[2], which is a pity, since doing
>> presentations means setting up ad-hoc/temporary settings which is just
>> used for an hour or two, then tearing them apart again then doing that
>> again the next day, probably on a different venue.
> 
> Well, in theory, you can setup the config once, and as long as the second 
> display plugged in fits within the parameters set in the config, it'll be 
> used as such, no X restart should be needed.

But that means there will always be a second "monitor" that you can't
see, but is accessible by programs and the mouse. After unplugging the
external display, this invisible monitor could be quite... disturbing[1].

[1] e.g. OpenOffice trying to start the presentation on the invisible
screen. I can switch the configuration to display on the current
monitor, but that makes the default autodetect setting useless. Most of
the problems are minor and silly, but still...

In fact, that was the best set up I could do. I figured out a way to
allow X to start with single monitor setting with h/w acceleration if
there is no external monitor connected; and starting with a different
configuration when there is external monitor. However switching between
these two configs still requires a restart. At least this is acceptable,
since the most time-consuming and head-consuming part is figuring out
the right configuration when everyone in the room is looking at you (I
had to do exactly that on one of my first presentations with Linux[2])

[2] the very next day, I pulled out my old monitor and experimented with
approximately two thousand settings, before coming to that acceptable
setting

> The other problem is that a lot of apps aren't particularly RandR aware 
> yet, or only expect to be using it with a single monitor, so putting 
> stuff in full-screen mode can have unexpected consequences, as it often 
> changes the resolution for BOTH monitors, and either puts the full-screen 
> app centered between them (but at the size of only one of them, so it's 
> not really full-screen), or clones to both, instead of only cloning to 
> one and leaving the other one alone.
>
> But that's not xorg's or RandR's problem, that's the application's 
> problem.  And with the appropriate scripted and hotkey invoked xrandr 
> calls, as I have setup, it's relatively easy to get the system back to 
> its proper configuration, even when the apps screw it up.

But the most significant problem is hardware compatibility, I have a
laptop that works great with xrandr... as long as it's a single monitor.

>> Mirrored is okay, but I prefer Xinerama/extended desktop. Now that
>> OpenOffice 3 starts having support for Presenter View (where the
>> projector displays the presentation and your laptop's your notes), not
>> being able to just plug the cable in and have the whole thing set up
>> automagically is a big loss.
> 
> Indeed.  My config is dual monitor desktop and I'm not a "mobile 
> warrior", but I can certainly see the use for that in mobile warrior 
> presentation situations.

It gets even worse when you're the fifth person to present and "getting
there early and make sure everything is set up" is a naive theory.

You only have around of 2-3 minutes before the audience is waiting too
long for presenter switching[3]. If things goes smooth, we only need to
connect the cable and press F5 to switch from editing to presenting; but
for now: connect the cable, restart X, make sure the configs are right,
start OpenOffice (since restarting X closed it), then F5.

[3] I have a special condition where I often have to do presentations
that is just around 10-15 minutes and there are a couple of other
presenters going before and after. This makes a 2-3 minutes a very long
delay.

>> [1] not to mention I never get all the settings right, either hardware
>> acceleration or Xinerama. A separate X display is acceptable, but still
>> no hardware acceleration.
>> [2] to move between single display to Xinerama and back.
> 
> It'll be nice when the xrandr based graphical monitor/desktop config 
> applets catchup, and Linux/X finally catches up to what MSWindows was 
> doing over a decade ago back with Windows 98!  Linux/X has been more 
> flexible in some areas, but unfortunately, that has never been one of 
> them.  But it's getting there, FINALLY!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6tz8ACgkQqC3FTmXeMUZlaQCeNXtYMSU4rVPg3meG45RTHvEF
BLUAnj8o2us0qRTx/wdu9sl9y5GS4K0V
=aS1q
-----END PGP SIGNATURE-----

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

[Lie Ryan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Lie Ryan <lie.1296@gmail.com> posted 4A3AA6FB.3010409@gmail.com, excerpted
> below, on  Fri, 19 Jun 2009 06:43:39 +1000:
> 
>> For changing "Resolution and Rotation", you're correct; but with or
>> without randr, whatever I tried I can't switch between single monitor
>> and dual monitor and back without restarting X.
> 
> Four questions:

Howdy, I just realized that I talked several pages long and I never
thought to make 3 very important remarks, 1) my experience with
multimonitor was in Ubuntu 2) I'm no longer in a situation where I did
presentations all the time any more, 3) the Ubuntu have been reinstalled
with the current Gentoo

> 1.  What version of xorg and RandR (I'm not sure which *randr* package 
> but they're all the same version here so I'll pick libXrandr)?
> 
> The ~arch xorg 1.6 and *randr* 1.3 work MUCH better than previous 
> versions, which were flat-out missing certain very useful functionality.

I don't remember their exact version, although it should be last year's
latest in Ubuntu repository. I never switched to Intrepid because I
moved to Gentoo.

> 2.  "Whatever I tried".  Did you try xrandr?
> 
> As I explained in another post, the GUI versions seem to be "functionally 
> challenged" if not flat-out broken in some aspects.  xrandr 1.3 works 
> very well here.

Yeah. I've just replied on the other post that xrandr only works well in
a single monitor on my specific hardware configuration.

> 3.  Have you tried setting the virtual desktop size (as explained in that 
> other post)?
> 
> I haven't actually tried it with the newest xorg-server (1.6.1.901, FWIW 
> Gentoo revision 3), but last I was aware, xorg-server couldn't exand the 
> virtual desktop from what it was when it initially started.  Since it 
> defaults to the same size as the detected resolution, if you've not set 
> it to a sufficient size in xorg.conf, you'll have issues trying to get 
> anything other than clone mode without rebooting, since there's no 
> further desktop for it to expand into.

I tried a LOT of thing and many of them are not nice. I think virtual
desktop size was one of them. The result, as I remember, was a bit odd,
as setting the desktop larger than the monitor resolution gives panning
and not dual monitor. (or was that the effect of another setting, let me
check my memory first...)

> 4.  What graphics drivers?  Version?
> 
> I'm currently running the Radeon driver from xf86-video-ati, version 
> 6.12.2.  Certain drivers haven't been converted to RandR yet, or may not 
> be updated to use use full current xorg-server and RandR functionality.
> 

It was nvidia binary driver. Not sure of the exact version number as it
gets through several updates. It should be last year's latest
nvidia-glx-new in Ubuntu.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6v88ACgkQqC3FTmXeMUbrugCeNtySKPAByqTvJgOKiEE6/bI4
ttMAn0wQNEwDEK3bxnGUr8n41hvJfsgT
=U+xq
-----END PGP SIGNATURE-----

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

[Dmitri Pogosyan]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dmitri Pogosyan wrote:
> >> One thing that always bugs me is that XRandR requires some
> >> configuration[1] and X restart[2], 
> > 
> > Why are you say that ? One surely does not need to restart X, that's  the
> > whole point of XrandR
> > 
> 
> For changing "Resolution and Rotation", you're correct; but with or
> without randr, whatever I tried I can't switch between single monitor
> and dual monitor and back without restarting X.

hm, I have no problem doing that. I have setup  script at Fn-F7 which cycles
between one screen modes, mirror and extended monotir and it cycles just fine,
with non-uniform resolution and everthing. With projector, sometimes it need
CLI help to get a right mode, but never had to restart X.
And that is Randr 1.2 with 1.5 server on intel



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAko6pvsACgkQqC3FTmXeMUZp7ACfSxzIrQDUzk0WN/8YWqJa3+Nq
> lhQAn3rn0EanTwlzBKhobRs7lB55U1/d
> =mOYR
> -----END PGP SIGNATURE-----



--
Dmitri Pogosyan            Department of Physics
Associate Professor        University of Alberta
tel 1-780-492-2150         11322 - 89 Avenue
fax 1-780-492-0714         Edmonton, AB, T6G 2G7, CANADA

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

[Duncan]

Lie Ryan <lie.1296@gmail.com> posted 4A3AB740.4080109@gmail.com, excerpted
below, on  Fri, 19 Jun 2009 07:53:04 +1000:

> start OpenOffice (since restarting X closed it)

FWIW, at least KDE sessions should eliminate that bit.  If you have the 
option set to do so, it restarts apps you had running when you quit.  
(There's blacklists for apps you don't want restarted.  I have konsole 
listed there, for instance, as most of the time I was done with whatever 
anyway when I logged out, and if I wasn't, restarting is a two-key hotkey 
away.)  I normally keep a pan instance going all the time, since 
restarting it with a cold cache takes a bit, so having it restart with 
the session is particularly useful.

But I don't know if other desktop environments have that sort of session 
management.  Apparently whatever you were running didn't.

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

[Bob Sanders]

Duncan, mused, then expounded:
> 
> But I don't know if other desktop environments have that sort of session 
> management.  Apparently whatever you were running didn't.
>

Either .xinitrc or .xsession can be used. See -

http://www.acm.uiuc.edu/workshops/cool_unix/xinitrc.html

Bob 
-