Bug 523211

Summary:	ctrl+alt+F2 doesn't switch from VT1 to VT2 in some cases.
Product:	[Fedora] Fedora	Reporter:	Luinnar <luinnar>
Component:	xorg-x11-server	Assignee:	X/OpenGL Maintenance List <xgl-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	airlied, peter.hutterer, xgl-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-10-07 23:32:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Luinnar 2009-09-14 13:41:37 UTC

Description of problem:
There are some problems with switching from VT1 to VT2 when ctrl and alt buttons aren't released.

Version-Release number of selected component (if applicable):
LiveCD distribution testday-20090909-x86_64.iso.

How reproducible:
Steps to Reproduce:
ctrl+alt+F2 does't work in the following workflow:
- press ctrl+alt+F2 and release only F2 button, ctrl and alt should remain pressed - the system switches to the second virtual terminal.
- then press F1 and again don't release ctrl and alt - the system switches to the first virtual terminal.
- then press F2 - the system doesn't switch to the second virtual terminal, it's a BUG.

Actual results:
ctrl+alt+F2 doesn't work.

Expected results:
ctrl+alt+F2 should switch the system to VT2.

Additional info:
Motherboard: Asus M3A-H/HDMI
Video: ATI Radeon HD3200 GPU (Integrated).

Comment 1 Dave Airlie 2009-10-07 08:54:12 UTC

reassigning to server.

Comment 2 Peter Hutterer 2009-10-07 23:32:29 UTC

The current architecture makes this quite difficult.
Key repeats are triggered in the server only, the driver only forwards actual key presses and key releases*. When you VT switch and come back, the server doesn't know if a key is still down until the next event _for this key_ comes. Changing this would require that the server - after coming back from the VT switch - pokes the driver to query the state of the keyboard, then update the internal state accordingly.
Given the work required to implement this and the limited practical benefit I doubt this will be implemented (or even accepted upstream) anytime soon. I'll have to close this as WONTFIX, sorry.

* not quite true for kbd, but evdev is the default these days.