Xorg Server started to change terminal on Alt+Fn instead of Ctrl+Alt+Fn. Some WM depends by default on the previously default behaviour. Alt+Fn event is still passed. I don't have xorg.conf file.
how are you starting X?
By gdm. Reported process as: /usr/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
what keyboard layout do you use and how do you set this layout? can you please attach your xorg.log file.
(In reply to comment #3) > what keyboard layout do you use and how do you set this layout? tweaked en_uk: % cat ~/.Xmodmap !charset "utf-8" keycode 26 = e E e E eogonek Eogonek eogonek Eogonek keycode 32 = o O o O oacute Oacute oacute Oacute keycode 38 = a A a A aogonek Aogonek aogonek Aogonek keycode 39 = s S s S sacute Sacute ssharp section keycode 52 = z Z z Z zabovedot Zabovedot guillemotleft less keycode 53 = x X x X zacute Zacute guillemotright greater keycode 54 = c C c C cacute Cacute cent copyright keycode 57 = n N n N nacute Nacute nacute Nacute > can you please > attach your xorg.log file. > 1. i observed it might be connected with hibernation. Sometimes after hibernation X.org and gpm seems to be mixed (two mouses are displayed - one X and one gpm. 2. I cannot reproduce this error with xorg from git 3. I will post log ASAP (probably I will 'play' with xorg this weekend).
Created attachment 34503 [details] Xorg.0.log
(In reply to comment #5) > Created an attachment (id=34503) [details] > Xorg.0.log there's not a lot of changes between RC2 and the 1.8.0 release so I'd be surprised if that is really fixed. nonetheless, please give 1.8.0 a try so we can double-check. is only VT switch affected or other keys as well? xev should tell you the modifier state for key presses so you can compare before and after.
> is only VT switch affected or other keys as well? xev should tell you the > modifier state for key presses so you can compare before and after. Hmm. Since Alt+Fn[1] is passed to program anyway I would be surprised if anything else would appear different in xev (including Alt+Fn). The only problem is that X changes VT in addition to sending it to program. [1] Ups. Now I noticed that Fn is name of the function key. I meant function keys as in F1, F2, F3 etc. Sorry if it caused any confusion.
(In reply to comment #7) > Hmm. Since Alt+Fn[1] is passed to program anyway I would be surprised if > anything else would appear different in xev (including Alt+Fn). The only > problem is that X changes VT in addition to sending it to program. no, by that I mean the following: if you run xev and you hit Alt + a, then the events are the following: KeyPress event, serial 33, synthetic NO, window 0x5800001, root 0xc2, subw 0x0, time 46320480, (119,123), root:(1563,219), state 0x18, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x5800001, root 0xc2, subw 0x0, time 46320624, (119,123), root:(1563,219), state 0x18, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False (note the state field) If you hit ctrl+Alt, then the state is 0x1c KeyPress event, serial 33, synthetic NO, window 0x5c00001, root 0xc2, subw 0x0, time 46410880, (131,122), root:(1575,218), state 0x1c, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (01) "" XmbLookupString gives 1 bytes: (01) "" XFilterEvent returns: False so in your case, the interesting thing would be - when this problem occurs and you hit other keys, what's the state. this would tell us if there's a stuck modifier or if it's just the VT switching keys busted for some reason. when the issue occurs and you run setxkbmap -layout us, does this fix it? > [1] Ups. Now I noticed that Fn is name of the function key. I meant function > keys as in F1, F2, F3 etc. Sorry if it caused any confusion. that's how I read it anyway, no problem :)
Created attachment 35273 [details] Log of xev The log from xev showing: Alt+a And Alt+F2
It may be one of the problems of bug 27922. After applying patch I cannot reproduce it (which does not mean I won't).
(In reply to comment #10) > It may be one of the problems of bug 27922. After applying patch I cannot > reproduce it (which does not mean I won't). Reproduced several time with patch. It seems to happen after hibernation using tuxonice and ususpend. It happens at the same time as blackening of screen: - At some point (randomly?) screen becomes blank (black). Only mouse pointer is shown. If gpm is enabled both pointers are shown and are moving independently (i.e. one moves fater and one slower but both responds to mouse). - I can switch by Alt+Fn to any other vt - Then when I switch back to X all is normal. Except that Alt+Fn switches VT and is sent to applications (inclusing one from previous step. Alt+Fn switches VT after hibernation independently of the blackening - i.e. even if it did not happened yet.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.