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 -- [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
