Page MenuHomeFreeBSD

vt: fix problems with trying to switch to a closed VT
ClosedPublic

Authored by avg on Sep 18 2019, 12:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 10, 8:33 PM
Unknown Object (File)
Sat, Apr 6, 10:25 AM
Unknown Object (File)
Feb 20 2024, 2:57 PM
Unknown Object (File)
Jan 15 2024, 8:59 PM
Unknown Object (File)
Dec 20 2023, 1:50 AM
Unknown Object (File)
Dec 18 2023, 6:03 PM
Unknown Object (File)
Dec 13 2023, 3:59 AM
Unknown Object (File)
Dec 8 2023, 12:02 AM
Subscribers

Details

Summary

If there is an attempt to switch from a process-owned VT to a closed VT,
then vt(4) first requests the process to release its VT and only then
realizes that the target VT is closed and, so, the switch is not
possible. So, the driver does not actually do any switch, but at the
same time the owning process is not notified about that and it does not
re-acquire the VT.

This change adds an early check for the target VT state, so that the
switch can be refused before the process coordination dance.
On top of that, the code now checks for a failure of vt_window_switch()
and calls vt_window_postswitch() for the current VT if it is in the
process mode.

Test Plan
  • configure VT1 - VT8 (ttyv0 - ttyv7) to be text consoles (run getty)
  • configure VT9 (ttyv8) to rn X server
  • make sure that the X server configuration allows VT switching
  • leave VT10 - VT12 unconfigured
  • while in the X server press Ctrl+Alt+F10
  • without the patch, observe strange screen content and problems with keyboard input
  • with the patch, observe that nothing happens

The problem has been observed and the fix has been tested with an nVidia
graphics card and the proprietary nvidia driver.
Not sure if that matters.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable