lkml.org 
[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Running JOBS list.

> But we can validate the contents of con2fb_map[] everytime it is used, right?

Okay fbcon_setup (video_setup before change) has

if (!strncmp(options, "map:", 4)) {
options += 4;
if (*options)
for (i = 0, j = 0; i < MAX_NR_CONSOLES; i++) {
if (!options[j])
j = 0;
con2fb_map[i] = (options[j++]-'0') % FB_MAX;
}
return 0;
}

but this is called before fbmem_init so you can't do any sanity checking
with num_register_fb. The two pieces of code effected by this problem is
fbcon_init. Its doesn't check to see if

/* on which frame buffer will we open this console? */
info = registered_fb[(int)con2fb_map[unit]];

actually exist. So we have to do sanity checking. I assume if it fails we
set it to fbcon_dummy. This is in case someone maps the first console to a
none existant framebuffer device.

The next is fbcon_switch. Here the problem can be avoided if we have the
display_switch set to fbcon_dummy. Ugly hacks that don't really solve
the problem. Also fbcon_switch assumes that the console you are switching
to is fbcon driven. This is not always the case. It might be vgacon. The
reason to ensure the user has to choose between vgacon and fbcon.

> > The second problem is vgacon and fbcon. Until this last kernel you can
> > boot vgacon and then inmod a fbdev driver and then fbcon would take over.
> > Now the problem is most video card when they go from VGA mode to a non VGA
> > mode can NOT go back to VGA mode. So if you go to rmmod the fbdev driver
>
> So we cannot go back, but we can go forward.
>
> And why can we rmmod the fbdev? It's supposed to be marked busy when
> fbcon is using it.

Right. Thats the fb_info->count field is for. So rmmod can never be. So
much for hot pluggable support. What if you have a server with one video
card and that video card goes bad. fbcon will still have that card marked
as busy. So we can't rmmod driver which is what you would want to do
before we remove the video card. In case the hot swappable bay for the
video card will not release the card until rmmod. Future systems will
probable be built this way. The best thing to do in this situation is to
kill all processes attached to the VTs using that fbdev and then rmmod
that driver. I guess this is for 2.5.X :(

> > you are fubar. I just made a patch that changes the config.in files to
> > have it so you either have to choose fbcon or vgacon. Its one or the
>
> Yuk. This is very bad.

Not really. That patch is actually good in that it moves all the console
driver config options to drivers/video/config.in

> BTW, can't we just call take_over_console() again in register_framebuffer()
> so we at least can do `insmod xxxfb' again?

The thing I don't like is the avaliable to have vgacon on some VTs and
fbcon on some other VTs. This can be done with fbcon=vc:. With one video
card in the system the first console could still be vgacon and then when
we VT switch to VT 2 which could be fbcon then the card switches into non
VGA mode. Then when we try to switch back to VT 1 with vgacon the card
can't go back to VGA mode. So it would be best that we make people choose
between vgacon and fbcon. If this is done then the issue of
take_over_console in register_framebuffer is solved. With vgacon their is
no fbcon and with no vgacon its fbcon which in turn takes over dummycon.

On PowerPC you have to build at least one of the fbdev drivers into the
kernel in order to boot right. Just like filesystem support. If you don't
select any filesystem then your machine will not boot. Actually a user
could do that now on ix86 by unselecting vgacon and using fbcon with all
driver modular. Vgacon has problems with fbcon as stated above. So I say
we force people to choice between fbcon and vgacon. It just means like all
the other platforms the user has to built at least one fbdev driver
directly into the kernel. Makes sense to me.

> > other. This brings me to another question. Can prom console run at the
> > same time as the framebuffers on a sparc station ? Same for some of the
> > SGI stations. Can a newport console also run at the same time as a
> > framebuffer console. This way my patch can ensure you can select between
> > fbcon or some other console type.
>
> Promcon runs before fbcon, AFAIK.

Okay so it can be compiled it with fbdev with no problems.

> SGI Indy boxes don't use fbcon, but solely newportcon.

From arch/mips

if [ "$CONFIG_VT" = "y" ]; then
mainmenu_option next_comment
comment 'Console drivers'
if [ "$CONFIG_SGI_IP22" = "y" ]; then
tristate 'SGI Newport Console support' CONFIG_SGI_NEWPORT_CONSOLE
if [ "$CONFIG_SGI_NEWPORT_CONSOLE" != "y" ]; then
define_bool CONFIG_DUMMY_CONSOLE y
else
define_bool CONFIG_FONT_8x16 y
fi
else
if [ "$CONFIG_DECSTATION" != "y" ]; then
bool 'VGA text console' CONFIG_VGA_CONSOLE
fi
bool 'Support for frame buffer devices' CONFIG_FB
source drivers/video/Config.in
fi
endmenu
fi

This makes sense since several SGI workstations have PCI bus. You could
place cheesy low end video cards in it (that puts shivers down my spine).

> This is another problem: because in many cases the vgacon and the fbcon card
> are the same device, there should be a possibility to ask vgacon to `release'
> the card (and its resources) first. Replace `vgacon' with `offb' on
> PowerMac/CHRP.

The nice thing about offb is it's going from one fbcon driver to another.
Thats not so bad.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.674 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site