linuxconsole-dev

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

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

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

> > 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.
>
> Well, something is crazy like a fox, since my 2nd Radeon display gets
> disrupted.  Perhaps I should mention that both my displays are DFPs.  I
> did try hackvideo, that makes no difference.  How can I capture the state
> of the 2nd radeon before and after the disruption, to figure out in what
> way the 2nd radeon has been disrupted?

One backdoor exists. That is agpgart kernel module. All Radeon adapters
are AGP adapters. Please disable AGP kernel support or disable AGP support
in 2nd xf86. May be xf86 isn't slyboots.

> Or any other suggestions on how to
> debug this?
>
> A couple other comments about 2.6.0-test9-ruby:
>
> When I am using the text console (vgacon?) and switch from one vc to
> another on VT0, sometime the destination vc is restored with the cursor
in
> the wrong place.  Typically the cursor should be at the bottom of the
> screen and is restored instead half way up the screen.

Uh. First console is broken.

> After a fresh boot, if I run from a text vc on VT0 "startx --layout
> Layout1 vt17 &", where Layout1 is set up to use my second radeon, then X
> comes up fine on the 2nd radeon.  However, the text vc is now frozen.

I am not capable to patch xf86 VGA handling. Any xf86 1st or last freezy
VGA interface.

Aivils Stoss

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

[Wayne W. <wh...@Ma...>]

On Sat, 15 Nov 2003, Aivils Stoss wrote:

> One backdoor exists. That is agpgart kernel module. All Radeon adapters
> are AGP adapters. Please disable AGP kernel support or disable AGP
> support in 2nd xf86. May be xf86 isn't slyboots.

AGP kernel support is not loaded, since I have disabled dri in XF86Config,
so X doesn't load it.  I also removed any AGP options from XF86Config.
The problem is still there.  Of course, there are still comments about the
AGP bus in XFree86.log, since the 1st radeon is AGP.

Here's an additional twist: when I boot up gdm starts X on 1st and 2nd
displays, and as discussed, logging in and out of X on the 1st display
disrupts the 2nd display.  Then restarting the 2nd X restores the 2nd
display without disrupting the 1st display.  Now if after booting up, I do
a Ctrl-F1 to switch VT0 to vt1, then the 2nd display also gets disrupted.
Switching back to X on VT0 works fine.  However, in this situation,
restarting the 2nd X restores the 2nd display while disrupting the 1st
display.

BTW, has anyone discussed PrefBusID with the XFree86 folks?  If the
current implentation is a good one, I would think they might be willing to
integrate it into XFree86.  And presumably they could tell us if something
is missing.

> > When I am using the text console (vgacon?) and switch from one vc to
> > another on VT0, sometime the destination vc is restored with the cursor in
> > the wrong place.  Typically the cursor should be at the bottom of the
> > screen and is restored instead half way up the screen.
>
> Uh. First console is broken.

This must be a bug in vgacon?

Cheers,
Wayne

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

[Wayne W. <wh...@Ma...>]

On Thu, 13 Nov 2003, Aivils Stoss wrote:

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

Well, something is crazy like a fox, since my 2nd Radeon display gets
disrupted.  Perhaps I should mention that both my displays are DFPs.  I
did try hackvideo, that makes no difference.  How can I capture the state
of the 2nd radeon before and after the disruption, to figure out in what
way the 2nd radeon has been disrupted?  Or any other suggestions on how to
debug this?

A couple other comments about 2.6.0-test9-ruby:

When I am using the text console (vgacon?) and switch from one vc to
another on VT0, sometime the destination vc is restored with the cursor in
the wrong place.  Typically the cursor should be at the bottom of the
screen and is restored instead half way up the screen.

After a fresh boot, if I run from a text vc on VT0 "startx --layout
Layout1 vt17 &", where Layout1 is set up to use my second radeon, then X
comes up fine on the 2nd radeon.  However, the text vc is now frozen.  I'm
not sure if it is just output or both output and input.  Is this possibly
related to the "VGA routing" that X does for the 2nd radeon, disrupting
vgacon on the 1st radeon?

Thanks for your help.

Cheers,
Wayne