Hi all,
this is the second version of my multi-display support.
Compared to the first version:
The bug reported in the first patch that prevented booting when
"fbcon=cmap:01" was given is fixed (annoying NULL pointer in vc)
and a dummy vc_display_fg management was added to prevent
modifying vc structures we do not "own".
The second patch is new and a hack that allows graphic and console
applications to work concurrently.
Background:
At the moment only one display (in multi-display setups) will be
updated when
(1) multiple console applications run on different displays
(2) a graphic application runs in the active vt on one display and a
console application on another display
(3) multiple graphic (framebuffer) applications run on different
displays (usually)
The first patch fixes (1) and I'm pretty happy with it. Works well
for me except rarely cursor visibility glitches but that might be a
bug somewhere else.
(2) requires some sort of policy change. At the moment we forbid
any console from working just because on one vt a graphic
application started. Obviously that's not what I want and also not
what most applications require. Therefore changing it to only allow
the application to use the graphic resource associated with the vt
it switches to KD_GRAPHIC seems reasonable to me. If there are
concerns about compatiblity we could make this change an option or
introduce a new KD_PGRAPHICS which behaves as I want (though the
last one would be ugly and require changing all userspace to work).
My second patch gives this functionality but I do not expect it to
be acceptable as is. At first I wanted to revert f700d6e5 but for
some reason the result did not even boot so I hacked my way around
it. Basically my question here aside the policy change is why do we
blank when entering graphics mode and why do we not allow updates
to other consoles when one is blanked?
(3) is a completly different beast which will probably require
changes in userspace applications. Most framebuffer applications at
the moment just access the framebuffer if they are in the current
vt and stop on vt change. To make this working concurrently the
applications would need a way to get a notification when its
visibility changes. As this one requires much more work and thought
than the (1) and (2) I'll at first concentrate on solving those.
But if anyone has any suggestions on this one I'd be verry happy.
Best regards,
Florian Tobias Schandinat
Florian Tobias Schandinat (2):
fbdev: allow multiple concurrent visible consoles
vt: dirty hack
drivers/tty/vt/vt.c | 4 +---
drivers/video/console/fbcon.c | 34 ++++++++++++++++++++++++++++++----
drivers/video/console/fbcon.h | 1 +
3 files changed, 32 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
