On 19 May 00 at 12:04, James Simmons wrote:
> > No! old API passes PROC_CONSOLE() to this. And PROC_CONSOLE() uses
> > 'MINOR(current->tty->device) - 1' under normal conditions (if process has tty).
> > There is big difference between 'MINOR(current->tty->device) - 1' and
> > 'info->display_fg->vc_num' and I do not see any reason why you think that
> > MINOR(current->tty->device) - 1 == info->display_fg->vc_num...
> > It does not... PROC_CONSOLE does NOT return current foreground console,
> > but tty of that process. Unless you are running fbset from process which
> > is not attached to tty, such as if you run fbset remote - in that case
> > it will control currently visible VT. But only in this case. And at least
> > I do run fbset locally, not remote.
> Okay I see the confussion PROC_CONSOLE and info->display_fg->vc_num brings.
> I guess its time to analysis this code in depth. First lets look at
> display_fg and what it does. From console.c
[snip]
> return MINOR(current->tty->device) - 1;
> }
>
> 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.
> Why do we even use this
> function? Because all the fbdev driver currently update info in struct
> display[con] where con is the ACTIVE console for this particular video
> card returned by PROC_CONSOLE. My new API will eventually move this data
> from all the fbdev drivers to fbcon.c. Thus the fbdev function will no
> longer need PROC_CONSOLE. The major concept here is for every video card
> only one VT is active for it.
I have nothing against removing 'con' from fbdev API. But you must first
make either wrapper in fb_ioctl, which will do
x = PROC_CONSOLE(...); /* this is call to unchanged PROC_CONSOLE */
if (x != info->display_fg->vc_num)
return -ENOTVISIBLE;
fb->fb_xxxx(...., info);
or, better
x = PROC_CONSOLE(...);
if (x != info->display_fg->vc_num) {
if (x == -1)
return -ENOTTY;
/* return .var from fb_display[x] or build fix from fb_display[]
and info */
...
}
fb->fb_xxxx(...., info);
But without such change it is unacceptable for me.
> > So this is fatal difference. Please, could you bother at least to test
> > '(sleep 5; fbset -depth 16) & chvt 5' on clean 2.1.x, 2.2.x or 2.3.x kernel?
> > It really does not touch tty5 resolution, although you see this on screen
> > when fb_set_var is invoked. Really! (if driver bothers with 'con' parameter,
> > that is)
> Results using matroxfb.c with Matrox Millenium I card with 8 Meg of RAM:
> tty2
> [jsimmons@maxwell ~]$ (sleep 5; /usr/sbin/fbset -depth 16) & chvt 5
> mode "640x480-60"
> # D: 25.200 MHz, H: 31.500 kHz, V: 59.999 Hz
> geometry 640 480 640 6540 16
> timings 39683 48 16 33 10 96 2
> accel true
> rgba 5/11,6/5,5/0,0/0
> endmode
> ----------------------------------------------------------------------------
> tty5
> mode "640x480-60"
> # D: 25.200 MHz, H: 31.500 kHz, V: 59.999 Hz
> geometry 640 480 640 13081 8
> timings 39683 48 16 33 10 96 2
> accel true
> rgba 8/0,8/0,8/0,0/0
> endmode
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. With added either of two code
fragments above into fb_ioctl, it will either fail with error (with first
fragment) or even will work correctly (with second fragment) and I'll be
very happy... I'll send you patch with my idea later today.
Petr Vandrovec
vandrove@vc.cvut.cz
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.
-
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