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

[Jon Smirl]

The fbdev driver should not be initializing the acceleration engine
until fbconsole is loaded since fbconsole is the only user of it and
fbconsole may never get loaded.

For example my EGL drivers use fbdev and don't use the acceleration
engine. If the accel engine is turned on EGL will die. Radeonfb works
this way.

On 7/9/05, Thomas Winischhofer <thomas at winischhofer.net> wrote:
> -----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-----
> 


-- 
Jon Smirl
jonsmirl at gmail.com