> > So as you can see the whole point of PROC_CONSOLE is to grab the VT that's
> > active for one of the video cards in your system.
> If it was supposed to fetch active VT, it would contain only one line:
>
> return info->display_fg->vc_num;
>
> But it contains more lines... which cause that ioctls operate not on
> active VT, but on VT which is process's tty.
If this is true then why does PROC_CONSOLE exit if info->display_fg !=
NULL. This means the first test is to see if the framebuffer device is
attached to a active VT. With this new API you can directly access the
video card even if it's not attached to a VT. current->tty is the active
VT except when you VT switch. The console you switch to becomes the
new active VT. This is a bad race condition I have know about sometime.
What is needed is spinlocks per fb_info. You shouldn't be able to change
the hardware state while VT switching. With your command what should
happen is change video mode which locks to prevent a VT switch. Once the
video mode is changed then release the lock. VT switching in the middle of
a video mode change is very bad. The same goes with changing the color
map.
> I have nothing against removing 'con' from fbdev API. But you must first
> make either wrapper in fb_ioctl, which will do
> But without such change it is unacceptable for me.
I'm sorry but such functionality should be in the console layer. Not
fbdev. The reality is in the future linux will support other types of
consoles that don't have a framebuffer but allow changing of a video mode.
Their needs to be away to change non visiable VTs that's not dependent on
other type of video hardware.
> If you remove 'con' tests/operations from matroxfb_{get,set}_var (and so
> they'll operate on fbinfo->var/fix/... only instead), you'll get different
> result: fbset -depth 16, which was run while you were watching tty5, will
> set tty5 (currently active...) resolution.
If fbset is run before I VT switch then it should change the current VT
mode. Then VT switch. You shouldn't be able to VT switch while in the
process of changing a video mode. This is a nasty race condition.
> P.S.: I found one more difference in your changevar patch: if you exit
> from fbtv, it does FBIOPUT_VSCREENINFO with some strange yoffset (zeroed?).
> With old code you'll see some random part of screen buffer without cursor.
> With patch, you'll get same contents visible on screen, but hardware
> (matroxfb) cursor is on correct position on screen (i.e. it travels over
> innocent characters). I'm not able to explain it. As soon as screen scrolls
> up/down, problem is fixed.
It almost got it right. I will have to investigate more.
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:17 EST