Re: [Linux-fbdev-devel] [PATCH 0/7] Detaching fbcon

[Geert Uytterhoeven]

On Mon, 12 Jun 2006, Antonino A. Daplas wrote:
> Knut Petersen wrote:
> > I suggest to add the fb_unbinding / fb_binding fbops and to only allow
> > unbinding if we know that it will not leave the video hardware in a state
> > that is unusable for proper operation.
> > 
> > If there is nothing to be done inside those two fbops, they simply return
> > 0.
> > 
> > Other framebuffer drivers set the hardware to a state that is completely
> > unusable by a textmode console and that is incompatible with X. These
> > might need to know if X is active to decide if unbinding makes any sense at
> > that specific moment.
> 
> This is very ugly. Drivers should not care whether it's safe to load or
> unload, unbind or bind, or whether a specific application is open or not.
> This is not their job, this should be the job of the higher layer or an
> arbiter.  And yes, the state of graphics is currently ugly, witness the
> very long threads on how to to make everything work together.
> 
> Right now, the only thing I can claim is that trying to do an fbdev
> operation while inside X will result in undefined, if not fatal behavior.
> Don't do it. And no matter how many ugly hacks and workarounds we add
> for the framebuffer layer, this will always be true.

The main problem is that there are too many drivers for the same hardware:
  - vgacon
  - fbdev
  - X

All of them want to control the hardware, and all of them make assumptions
about its state...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/