Re: Successful ruby setup and a problem

[Boszormenyi Z. <zb...@fr...>]

Aiv...@un... írta:
>>This configuration is so good, even DRI works on both videocards!
>>Two kids can play tuxracer at once. :-)
> 
> 
> You are pioneer. Previously all users disable DRI.

:-) I did it previously, it locked up with the original
XFree86 release of FC1, 4.3.0-42 I think.
Then with the prefbusid3 patch I was unable to set up DRI,
it was with 2.4.0-ruby, official 2.4.0 and no other patches
besides ruby. (Old DRM kernel module.) I experimented with
many configurations including -mm kernels and even compiled
XFree86-4.4.0-RC2 into a different directory and changed every
symlink to point to it but I think the only thing that made
the difference is that the PCI Radeon7000 is :0.0 and the
AGP Radeon9200SE is :1.0 following the minor numbers
(reported by dmesg) of the updated DRM kernel module.
Previously there was only one DRI device (minor 0)
and this have caused problems when using a unified
XF86Config where Load "dri" is present or not in Section "Module".
Using different XF86Config files for different displays
would have solved it before. X has an option to specify which
config file to use.

Now glxgears reports 300+ fps for the PCI card,
510+ for the AGP one. Same numbers if I run it
on either one or on both. Must be hardware accelerated.
:-)

> Do You use open source "ati" driver?

Yes.

>>I use the Option "PciOsConfig" "1" tweak but I don't use the
>>echo "1" >/proc/bus/pci/hackvideo because it stalled one of
>>the cards, gdm could not start it until I logged in and out
>>on the other at first but then this card was stalled... Strange.
>>So I stayed with the -prefbusid XFree86 option.
> 
> 
> That -prefbusid is unofficial , unsupported and so on. I realy do
> not know how to works xf86 PCI handling :(

I think it would be more acceptable for the XFree86 developers
or to the Linux distribution makers if You (or whoever made the
prefbusid patch) fix the already existing BusID option so it does
not touch anything else besides the specified card.

>>There are few things that bugs me still. Some devices
>>(like /dev/mixer) can only be used by the first login,
>>no matter which display. Changes to /etc/security/console.perms
>>is needed, users should be put into groups to be able to access
>>devices but I can handle these kinds of problems.
>>
>>My main problem is that localhost:1.0 is destroyed by logging
>>out on localhost:0.0.
> 
> 
> Try this line in the gdm.conf
> AllwaysRestarServer=false

I tried it explicitely (it is the default BTW) and also tried
KillInitClients=false, where true is the default. Nothing helped.

> To make sure X server restart lead trouble try to kill it.
> Typicaly X servers are non-restartable with echo "1" >/proc/bus/pci/hackvideo
> 
> Without restart X may work very long period.

When there is a user logged in on both displays, they
indeed work for long time, no lockups, I can start OpenGL
games and quit them, xine work with XV on both, etc.
It can handle everything I throw at it but the logout on :0.0.
The fact that both cards are radeons could not be a problem
since I can login/logout on :1.0 any time I want.

Yesterday I compiled 4.3.0-62 from FC2 test and that fixed the
keyboard controller hardware access the kernel complained
constantly but it also "destroys" the :1.0 when I logout on :0.0.

Sorry, I did not described what it means in the first post.
The screen goes black on :1.0. It looks like it goes into
powersave mode. I think the X that drives :0.0 does some register
settings in the hardware of :1.0 and the X that drives :1.0 looses
track of what's going on. I pressed Ctrl-Alt-BkSpace on :1.0 after
the monitor went black and the gdm login screen came back.

-- 
Best regards,
Zoltán Böszörményi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.