linux-kernel - Re: drmfb console switching problems/questions

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <70ce31ca-5922-584c-8631-3853c488f3c7@yandex.ru>
Date:   Fri, 9 Oct 2020 15:16:25 +0300
From:   stsp <stsp2@...dex.ru>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        linux-fbdev@...r.kernel.org,
        Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: drmfb console switching problems/questions

09.10.2020 14:59, Thomas Zimmermann пишет:
> Fbdev exposes the video ram (or a shadow buffer of it) to all
> applications. Only one can draw at the same time. It's a limitation of
> the design. To fix this, your application has to stop drawing when you
> switch consoles.
OK, thanks for info.
Quite a sad news, if you ask me.
Is there any ongoing work at solving that?

Anyway, the fact that fb can
permanently hang, is, I suppose,
another problem - the one that
can't be worked around in an app.
I suspect it is the result of sdl doing
ioctl(console_fd, KDSETMODE, KD_GRAPHICS);
After which, I think, redrawing on a
VC switch became disabled.
Would it make sense to improve SAK
to unfreeze from that? Otherwise its
too easy to hang the screen permanently,
and no way to recover.