Antonino A. Daplas wrote:
Overall, this feature is a great help for developers working in the
framebuffer or console layer.
Well, it has long been possible to load / unload framebuffer hardware
drivers using the vfb module as an intermediate step. It even has been
possible to load both vesafb and another framebuffer driver for the same
hardware, to assign vesafb to tty{a,b,c..}, the other framebuffer driver
to tty{m,n,o...} and to switch between those drivers using the usual
keyboard hotkeys.
So the main addition of your patchset is the possibility to replace
fbcon and helper modules, a nice feature I missed in the past.
But should a framebuffer driver terminate and leave the hardware in
graphics mode or in text mode? Up to now that was not a real question,
as we all knew that another framebuffer driver would take over control.
With your patches it is possible that a user really wants to switch to text
mode and to remove the complete fbcon layer. So should we switch the
hardware to text mode upon unloading a framebuffer driver?
Maybe unbinding of the framebuffer console is not followed by an
unloading of the framebuffer module. You tell us that an
"echo 1 > /sys/class/graphics/fbcon/detach" has the simple effect of a
corrupt display unless vbetools is used. No, that´s not ok.
Think about an echo 1 > /sys/class/graphics/fbcon/detach inside of an
xterm session.
I think we need new fbops, eg.
int fb_fbcon_unbind(...)
int fb_fbcon_bind(...)
If these are not implemented, unbinding is not allowed. Any requests to do
so will be ignored.
If these are implemented the fbcon_unbind() function of the framebuffer
driver is called first. If it does not return an error, unbinding can
continue,
otherwise it fails.
With implemented fb_restore_state() and fb_save_state() fbops the
framebuffer
driver knows best about the current hardware state and can act in a way that
there is no need for vbetools & friends as well as no possibility of fatal
interactions with X.
Unbinding requests should only be honored if the framebuffer driver decides
that it is safe. Don´t enable it by default.
cu,
knut
-
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]