On 19 May 00 at 13:00, James Simmons wrote:
> > > 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
It does not (are you really looking into unpatched kernel?...) it does
'return -1' if display_fg does not exist. If
it exists, it uses this value if and only if
current->tty == NULL or
current->tty->driver.type != TTY_DRIVER_TYPE_CONSOLE or
MINOR(current->tty->device) < 1.
Under normal circumstances (you are on console), last line of
PROC_CONSOLE() takes effect. And this line say 'return
MINOR(current->tty->device) - 1;'.
> 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
Currently everything non-sleeping is guarded by lock_kernel() and
additionaly some sleeping functions by console_lock lock.
> 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.
No one says that I want to change videomode in the middle of console
switch.
> > 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.
Hell. Are you stupid or what? There is API in use for more than 4 years...
And you want to broke it for NO reason, except that you do not want
'con' in fbmem.c... I do not want 'var' and 'fix' in fb_info, but what
can I do?! It did not changed external behavior, only complicated fbdev
driver code, so I could live with it. But I cannot support dropping old
API without even introducing new, not talking about some (at least 2 years,
I think) overlapping period while both APIs work.
> > 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.
Ohhh. So slowly:
(1) sleep 5 is started on tty2
(2) foreground tty is changed from tty2 to tty5. Look, no fbset running...
(3) time passes... 1s, 2s, 3s, 4s, 5s... sleep finishes
(4) fbset -depth 16 is started on tty2. No change on tty5 occurs.
(5) fb_ioctl finds that PROC_CONSOLE() returns 2-1 == 1. fb_set_var(..,1,..)
is invoked. Resolution of tty2 is changed. No change on tty5. No
change on hardware. Even painting of any data to fb and/or tty5 by
any process running on tty5 can proceed in parallel without any race.
(6) fbset finishes. tty2 now uses 16bpp. tty5 unchanged.
There is no race. Even fbset was not started when you switched console.
But you are still saying something about nonexistant races, instead of
acknowleding that fbset started from tty2 will now suddenly play with
resolution of tty5 - and I'll never accept it.
With your changes, there is race between user and fbset - in your scheme
fbset cannot be ever sure whether it changed resolution of own display
or someone else's one. Yes, you can introduce new API to change size of
visible tty, but I (1) do not see need for it and (2) this functionality
can be achieved without changing API, purely from userspace.
Petr Vandrovec
vandrove@vc.cvut.cz
-
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