Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 08:07, Michel D=E4nzer wrote:
> On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > >=20
> > > > I actually prefer #3, and I already have working code for this.  We=
 can
> > > > also make this driver switchable (ie, drivers that are not affected=
 by X
> > > > can disable this, and only drivers that are affected such as the ri=
va,
> > > > aty, radeon, etc can turn this on).
> > >=20
> > > What exactly is a "trusted" console?
> >=20
> > By default, the pid of each vt is -1.  When X loads, it installs its ow=
n
> > VT (ie vt7), which in that case the pid of that particular vt =3D=3D X'=
s
> > pid.  We can check this pid, and if switching from a vt with pid =3D=3D=
 -1,
> > we can safely assume that the hardware state is still sane, and if not,
> > assume the hardware state is undefined.
>=20
> Can you also detect when the app has opened the framebuffer device, and
> assume it's playing nice when it has? (for Option "UseFBDev")
>=20

X using fbdev will also have the same limitation. I have implemented
something like this before.  For each fb_open, the current->pid can be
saved into a "white list" and removed for each fb_close.  fbcon can then
compare this to the pid of the vt it's switching from.

This is becoming to sound very ugly though.  I guess, the best way is to
really support Option "UseFBDev", or at least have the user decide if
he/she wants to have the hardware refreshed. =20

Tony  =20