> 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
---------------------------------------------------------------------------
/*
* For each existing display, we have a pointer to console currently
* visible on that display, allowing consoles other than fg_console to be
* refreshed appropriately. Unless the low-level driver supplies its own
* display_fg variable, we use this one for the "master display".
*/
static struct vc_data *master_display_fg = NULL;
[snip]
int visual_init(
{
...
display_fg = &master_display_fg;
...
}
----------------------------------------------------------------------------
As you can see this hack is meant to allow more than one active VT at a
time in the allowed 32 VTs. Since fbcon provides a ioctl to map different
video hardware to different VTs we need to find out the active VT you
really are on. So fg_console does not always equal the active VT you are
on. Now lets take a look at PROC_CONSOLE itself:
int PROC_CONSOLE(const struct fb_info *info)
{
int fgc; /* Foreground console */
/*
Each fb_info represents each video card. In a multi display
system we could have say for example 8 struct fb_info. Now that
means we have 8 fg_console but in the console system only one
fg_console varaiable exist so we use the above display_fg variable
described above. Each fb_info since it represents one video
card and each video card will have a active display so each
of these struct fb_info must have a display_fg defined. This
way we know which VT is active for this video card.
*/
if (info->display_fg != NULL)
fgc = info->display_fg->vc_num;
else
return -1;
/*
* If this process is detached from a tty use info->display_fg->vc_num
* since the video card must be active on some VT. Remember each
* video card will be active on a different VT.
*/
if (!current->tty)
return fgc;
/*
* Okay we know this process is running on some type of console.
* Now lets test if its a non video type console. If it is then we
* grab the VT active for this particular video card.
*/
if (current->tty->driver.type != TTY_DRIVER_TYPE_CONSOLE)
/* XXX Should report error here? */
return fgc;
/*
* If the process has a invalid tty then we use the VT active on
* this video card.
*/
if (MINOR(current->tty->device) < 1)
return fgc;
/*
* Okay now we test the process does have a correct VT number.
* This will be the VT the process IS running on.
*/
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. 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. Thus fbcon can work with the data of the
current state in fb_info. A VT switch can change the video state thus
we preserve the orginal state and invoke the new state from the new VT.
Once the VT switch is completed then fbcon can work with the new state in
fb_info. You can think of struct display as a storage area for inactive
VT using fbcon.
Lets now look at void set_con2fb_map(int unit, int newidx) in fbcon.c.
The purpose of this function is to map a VT to a new video card. The
pieces of code to look at are:
/* Grab the VT we are taking over. Then we grab all it data */
conp = fb_display[unit].conp;
...
/* Then place all the data back since we replaced it with the new fbdev
display struct */
fb_display[unit].conp = conp;
...
/* Final piece of data is we run this VT with the new video card. */
fb_display[unit].fb_info = newfb;
/*
* Since this VT belonged to someone else we have to make it not only
* belong to the new video card but make it the ACTIVE VT for this
* video card.
*/
if (conp)
conp->vc_display_fg = &newfb->display_fg;
if (!newfb->display_fg)
newfb->display_fg = conp;
Final piece of code to look at is fbcon_init in fbcon.c. You have:
conp->vc_display_fg = &info->display_fg;
if (!info->display_fg)
info->display_fg = conp;
What this code basically does is at initialization time it first sets the
current VTs display_fg variable to the current fb_info value. This is done
to prevent excess updates. Next it looks to see if display_fg is actually
NULL for this fbdev driver. If it is then it sets display_fg to the
current ACTIVE VT. Makes sense since this fbdev driver was initialized on
the current active VT. Thus the current active VT belongs to this particular
video card. When PROC_CONSOLE is called then we will know which VT this
video card is active on because it's set at initalization time.
> 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 ~]$ ps -aux | grep login
root 420 0.0 0.9 2156 1248 tty1 S 09:32 0:00 login --
jsimmons
root 692 0.0 0.9 2156 1236 tty2 S 11:54 0:00 login --
jsimmons
jsimmons 781 0.0 0.3 1180 400 tty2 S 11:57 0:00 grep login
[jsimmons@maxwell ~]$ (sleep 5; /usr/sbin/fbset -depth 16) & chvt 5
[1] 791
[jsimmons@maxwell ~]$ /usr/sbin/fbset
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
[1] + Done ( sleep 5; /usr/sbin/fbset -depth 16)
----------------------------------------------------------------------------
tty5
[jsimmons@maxwell ~]$ ps -aux | grep login
root 420 0.0 0.9 2156 1248 tty1 S 09:32 0:00 login --
jsimmons
root 692 0.0 0.9 2156 1236 tty2 S 11:54 0:00 login --
jsimmons
root 771 0.0 0.9 2156 1236 tty5 S 11:56 0:00 login --
jsimmons
[jsimmons@maxwell ~]$ /usr/sbin/fbset
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
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