Re: 2.6.0-test9-ruby: console switch on VT0 disrupts XFree86 on VT1

[Aivils S. <Aiv...@un...>]

> I'm very happy to have gotten my dual user setup running under ruby,
> I'm quite impressed with it.  I am still having one problem, though,
> which was also present in my Miguel Freitas style setup.  When I
> switch from X to VGA console on VT0 (from vt7 to vt1, say), or if I
> just log out of X on VT0, it disrupts the X display on VT1 (vt17).
> That is, the DFP on VT1 reports that its input is out of range.
>
> Details:  VT0 is running on an AGP Radeon VE QY and VT1 is running on
> a PCI Radeon VE QY; the kernel is 2.6.0-test9-ruby, with the
> keyboard.c change as in CVS and the vt_ioctl.c change as in my
> previous email; X is XFree86 4.3.99.15 with the PrefBusID patch
> (version 3), which is enabled; I'm running gdm from Fedora Core 1.

PrefBusID hide video adapters from xf86. Actualy xf86 see and
use one video adapter given by PrefBusID. 1st xf86 schould not
touch 2nd. xf86 is crazy like as fox, if that destroy 2nd
desktop without access.

> Any ideas on how to avoid this?  I've tried enabling DEBUG in
> XFree86's xf86pciBus.c, to see if logging out of X on VT0 led to some
> PCI accesses, but the only PCI access debug statements that were
> logged occurred at the startup of X.  Is there an easy way for me to
> dump the state of the PCI Radeon both before and after the console
> switch/X logout?
>
> One workaround I've thought of is this:  X already has the code needed
> to restore its display after console switch, so if I had a simple way
> to initiate a fake console switch for X on VT1, it should restore the
> display.  Any suggestions on how to do this?
>
> Any help would be very appreciated.  I also included below a few minor
> questions I have.

Understanding of PCI handling under xf86 is quite hard.
May be You can try second method echo 1 > /proc/bus/pci/hackvideo ?

> 1) Why does section 4.3 of the HOWTO suggest using a different symlink
> for each instance of X?  Things seem to work for me without this, and
> I checked that this doesn't fix my problem.

That for gamers or wary. To kill xf86 You should know which.

> 2) Also, I don't seem to have any trouble with gpm.  I have it setup
> to use /dev/psaux, and my X instances are using /dev/input/miceX.  My
> gpm RPM is gpm-1.20.1-38.

Troubles under 2.4.XX. 2.6 has almost correct /dev/vc/0 important for gpm

> 3) If I understand correctly, the legacy VGA area is only routed to
> one video card at a time.  If the X on VT1 reroutes the legacy VGA
> area from the VT0 AGP card to the VT1 PCI card, behind the back of the
> already running X on VT0, won't this cause problems?  How does the
> kernel VT system handles the legacy VGA area routing?

No routes. Motherboard BIOS set up VGA interfce only for one video adapter.
Kernel uses memory maped output, set up some VGA registries.
Check out linux 1.3 2.0 kernels for understanding.
xf86 on start set up VGA registry "graphic mode".

To use up to date video adapter features, VIDEO BIOS inside video adapter
must be initialized - automatic by Motherboard BIOS during boot for VGA
adapter. All secondary cards are uninitialized. To set up secondary
video adapters xf86 use "CPU real mode" BIOS calls ("real mode" - same
as old best MS-DOS mode) libint10.a .
To prevent init of 1st VGA adapter BIOS again after boot, xf86 must
know , which is VGA - tech slang word "route". You cannot "unroute" VGA
even if You are programming god, who knows, may be You can.
Video adapter initializing is very much quite hard because of three
type of bus ISA,VLB,PCI. AGP for xf86 looks like PCI.

Aivils