[Fwd: Re: CVS Update: xc (branch: trunk)]

[Thomas Winischhofer]

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

Thomas Winischhofer wrote:
> Jon Smirl wrote:
>>>So, for example, they need to be added to the list of registers being
>>>saved/restored in the radeon driver. I also suspend that radeonfb in
>>>fbconsole mode is going to stomp on some registers EXA is using.
> 
> 
> Ok, just to be complete (even if that might not be an issue): You can't
> restore ALL registers on all cards. There are read-only registers, there

[erm.. meant "write-only", of course]

> are ring buffers and their registers (which can't just be restored, but
> restoring requires a reset of the command buffer...) and the like...
>
> 
>>>Resetting the card from a console session is a good way to make sure
>>>you are restoring all of the registers you need to.
> 
> 
> 
> So X must assume "everything is different" on every VT switch?
> 
> Surprises me. Does ANY driver save the entire card state in "EnterVT"?
> 
> So, does the radeon driver restore the display mode (and other
> registers) correctly, when
> 
> 1) you start X
> 2) switch away to another VT
> 3) start radeonfb and fbcon
> 4) return to X
> 5) return to another vt.
> 
> What happens? (Hm, might work though because 2.6 issues a set_par)


You sound like you see the fbdev/fbcon-combo as something one loads and
unloads like X. I don't agree that this is the meaning. The kernel's job
(and since fbdev is part of the kernel, this means also fbdev) is to
initialize the hardware (if neccessary), in order to make it usable. It
does this in the fbdev's "probe" call. (Likewise it is vgacon's job to
initialize text mode on PC boxes.)

If you now tell me that probe() in my fbdev driver is not allowed to
touch the hardware or needs to restore it to its previous state (which
you insinuate by your example of starting X, and from xterm modprobing
the fbdev driver), that is clearly against common practice.

I accept and totally agree that fbdev's probe() is not supposed to
change the display mode, that is the job of fbcon (through fbdev's
routines). But all fbdev drivers I have been looking at at least
initialize their accelerator engines during probe() - which of course
will lead to problems if this is done when X is active.

My point of view on this fbdev-X issue (under the current architecture -
I won't discuss architectual changes here and now): fbdev is the master.
It has to be started (if it's to be used) BEFORE any userland app that
also accesses the graphics. X has the responsibility to restore the card
state to the one it was when X was started. Not the other way round.

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz+9izydIRAktyUcRAvQDAKCO+8NGUna3dPj4Jp9bpql6YKVnoQCgzof4
M4xG4po0mZW9MnSpALGV5l8=
=tQmq
-----END PGP SIGNATURE-----