James Simmons writes:
> Now I realize the above is not. Say the process running on tty2 was not
> fbset but a program that mmaps the framebuffer and draws say random boxes
> in random colors all over the framebuffer. If I did the above it would
> scribble all over the the VT we switched too. Why? Because the active VT
> is drawing into the framebuffer to display text at the same time as the
> second process on the inactive VT is still drawing into the framebuffer
> those pretty boxes.
The way X does this is to register using the VT request stuff, save its
state, stop writing to the framebuffer, and then allow the VT switch.
Reverse is true for switch back to the X VT.
So, the above is ok, so long as your process on tty2 was using the above,
and obeyed the same rules. If it doesn't, technically your random box
process is buggy.
About /dev/fb, ioctls and memory...
Currently, the memory regions you access via /dev/fb refer to the
currently visible framebuffer, no matter what VT you are currently
switched to. This is correct, since we're using a framebuffer device,
not a virtual terminal device.
However, the ioctls to the very same framebuffer device have very
indeterminent results unless you go through a lot of pain. By this,
I mean that you're using a framebuffer device, but your ioctls are
treated as being via a virtual terminal device IF the current process
has a fbcon tty associated with it.
I'm about to suggest something that people will probably not like, but
what hell - this is how we move forward ;)
1. Everything, and I mean everything about /dev/fb should be reflecting
the current state of /dev/fb. This means that if you switch VT, then
it should reflect the new VT state.
2. /dev/tty* should reflect the current state of the VT associated with
that tty.
Yes, this greys the border between tty and fb, but what are we really
asking for when we open each of these devices? /dev/tty* is all about
the current VT state. /dev/fb refers to the framebuffer state.
We can easily pick up on (2) in console.c or vt.c, and pass them to the
{fb,vga}con drivers themselves. This should end up with a cleaner
interface in terms of the fbcon/fbdriver level. And yes, the fbdriver
level ioctls should affect the currently visible VT on that driver.
For example, running on /dev/tty1:
fbset /dev/tty1 800x600-60;\
fbset /dev/tty2 1024x768-75;\
chvt 2;\
fbset /dev/fb;\
should return to you the settings about /dev/tty2, ie 1024x768-75.
More over:
fbset /dev/tty1 800x600-60;\
fbset /dev/tty2 1024x768-75;\
chvt 2;\
fbset /dev/fb 640x480-60;\
fbset /dev/tty2;\
fbset /dev/tty1
should return 640x480-60 as the current mode of tty2, and 800x600-60
for the current mode of tty1.
Yes, this is an API change, but it appears that with the old way:
- people don't really know what the true effect of ioctls would be
on /dev/fb
- the behaviour of the device is not self-consistent
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
[preparing for a raft of complaints/objections]
-
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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:18 EST