If we add another flag FB_ACTIVATE_USER for fb_var_screeninfo.activate, it can
be used to indicate that the video mode was changed by a user space program. If
this flag is set, the frame buffer device should assume that the supplied
parameters are valid, and just fill in the display structure.
Since the kernel can't change the video mode anymore, the video mode has to be
the same for all VCs associated with one video board, so it has to change for
all VCs at once (can be done by fbmem.c). I think that's acceptable.
Since hardware acceleration (bitblit) proved to be unnecessary for text
consoles on modern hardware, the frame buffer device needs to have less
knowledge about the hardware. All it needs to know is:
- where's the frame buffer?
- where's the MMIO region?
- how to change the color palette?
This would make frame buffer devices much simpler on machines were an initial
graphics mode was initialized by the Firmware (Open Firmware, VESA BIOS,
ARC/SRM console).
XFree86 can easily be made more compatible with vesafb. If it detects that a
frame buffer device is present, it can tell the kernel that it changed the
video mode.
Panning is more difficult: a user space program could pan the screen, but a VC
switch can no longer change the screen offsets. But since XFree86
disables/enables VC switching, it could restore the screen offsets.
What do you think about this?
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
-
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/