linux-kernel - [RFC v2] allow multiple concurrent visible displays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat,  3 Sep 2011 01:29:19 +0000
From:	Florian Tobias Schandinat <FlorianSchandinat@....de>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fbdev@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	Dave Airlie <airlied@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Bernie Thompson <bernie@...gable.com>,
	Martin Decky <martin@...ky.cz>,
	Florian Tobias Schandinat <FlorianSchandinat@....de>
Subject: [RFC v2] allow multiple concurrent visible displays

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/