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

[Thomas Winischhofer]

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

Jon Smirl wrote:
> As a test you should be about to switch to a console VT, run the
> attached program, and then switch back to X and still have X work. If
> it doesn't work then you probably need to save/restore more registers
> on VT swap. You can also use vbetool to reset the board.


Jon,

the registers or the card state are/were not the issue here. This has
worked for ages (well, at least with my drivers).

The issue is that the vram is eventually overwritten by the fbdev (yes,
including fbcon) during the time X is in the background (because of a vt
switch).

Exa, so far, simply assumes that no one will touch the vram. But that
assumtion is wrong. That's way I inserted a wrapper
EnableDisableFBAccess, which is called when switching from/to X. It
takes care that all pixmap data is kicked out into system RAM.


> Another thing to test is to load fbconsole on your fbdev driver. For
> example fbconsole on radeonfb. You should be able to VT swap to the
> console and X server and have everything stay working. Make sure you
> switched to graphical console mode.

Works with my patch.


> A harder test is start X, modprobe the fbdev driver from an xterm. Now
> VT swap to a console session and rmmod the fbdev driver. Everything
> should stay working. Try this the other way around too.

Works, of course.


> Of course all of these different combos need to work with suspend/resume too.

I fail to see how vram preservation is the driver's responsibility.

Thomas

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

iD8DBQFCz93qzydIRAktyUcRAoBiAJ0Uh56HP0zItnkDJi69Ium841Z38QCgnvIj
xLzTH5qzKqXX1T+7L26W28w=
=2NKZ
-----END PGP SIGNATURE-----