Re: Some questions
flat view
From: Michel Dänzer <hidden>
Date: 2003-03-12 01:29:18
On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:quoted
On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:quoted
On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:quoted
quoted
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 riva, aty, radeon, etc can turn this on).What exactly is a "trusted" console?By default, the pid of each vt is -1. When X loads, it installs its own VT (ie vt7), which in that case the pid of that particular vt == X's pid. We can check this pid, and if switching from a vt with pid == -1, we can safely assume that the hardware state is still sane, and if not, assume the hardware state is undefined.Can you also detect when the app has opened the framebuffer device, and assume it's playing nice when it has? (for Option "UseFBDev")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.
I see, makes sense.
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.
I'm afraid I don't understand what you're saying here. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en