Messages in this thread | | | Date | Sun, 12 Mar 2000 15:58:30 -0500 (EST) | From | James Simmons <> | Subject | Re: 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/
| |