Bug 523211 - ctrl+alt+F2 doesn't switch from VT1 to VT2 in some cases.
Summary: ctrl+alt+F2 doesn't switch from VT1 to VT2 in some cases.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-14 13:41 UTC by Luinnar
Modified: 2009-10-07 23:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-07 23:32:29 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.