Bug 1031355

In settings -> window manager -> keyboard

what is the "Cycle windows (reverse)" set to?

(In reply to Kevin Fenzi from comment #1)
> In settings -> window manager -> keyboard
> 
> what is the "Cycle windows (reverse)" set to?

It says "<Alt><Shift>Tab" on both computers.

Could there be another application running thats capturing those keys? 

Can you also try running 'xev' and see if if it's seeing alt-shift-tab correctly ?

(In reply to Kevin Fenzi from comment #3)
> Could there be another application running thats capturing those keys? 

I have no idea which application that could be. I have tried closing as many windows and tray applets as I could, but of course that still leaves lots of processes running. It would have to be something that gets autostarted, as the problem has persisted across several reboots.

> Can you also try running 'xev' and see if if it's seeing alt-shift-tab
> correctly ?

Xev prints keypress and keyrelease events for both Alt and Shift as long as it has focus. When I press Tab it loses focus, and will print other events but not keypress or keyrelease. That seems to work the same way on both computers.

Strange. 

Are you by chance using the binary only nvidia video driver?

Nope. Intel HD Graphics 4000 with Intel's free driver. I try hard to buy the most freedom-friendly hardware I can.

I've installed a bunch of other desktops and made comparisons. I've found that Alt-Shift-Tab works in Cinnamon and Gnome Classic, but not in XFCE, KDE, LXDE, Mate or Openbox.

I've also found differences in Xev's output. In XFCE I see the string "Shift_L" or "Shift_R" in what Xev prints for the Shift keys when I'm not holding any other key, but when I'm holding Alt it prints "ISO_Next_Group" instead. For Alt it prints "Alt_L" when I'm not holding any other key, but "ISO_Next_Group" when I'm holding one Shift key, and nothing when I'm holding both Shift keys.

In Cinnamon, Xev prints "Shift_L" or "Shift_R" for the Shift keys and "Alt_L" for Alt when I'm not holding any other key, but when I press Shift while holding Alt or vice versa it prints a FocusOut event instead of KeyPress. Then when I release either key it prints FocusIn and KeymapNotify events instead of KeyRelease. It prints nothing for Alt when I'm holding both Shift keys.

In Gnome Classic, Xev prints "Shift_L" or "Shift_R" for the Shift keys whether I'm holding Alt or not. For Alt it prints "Alt_L" when I'm not holding any other key, but "Meta_L" when I'm holding one Shift key, and nothing when I'm holding both Shift keys.

In XFCE on the computer where I don't have the problem, Xev prints "Shift_L" or "Shift_R" for the Shift keys whether I'm holding Alt or not. For Alt it prints "Alt_L" when I'm not holding any other key, but "Meta_L" when I'm holding one or both Shift keys. That's almost like in Gnome Classic on the first computer, but not exactly.

This is a confusing mess, but it's starting to look unlikely that the XFCE window manager alone is at fault.

It appears that the problem was in the X configuration:

# LANG=en ls -l /etc/X11/xorg.conf.d
total 8
-rw-rw-r--. 1 root root 208 May  3  2013 00-anaconda-keyboard.conf
-rw-r--r--. 1 root root 266 Nov  8 01:52 00-keyboard.conf

# cat /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf
#This file was generated by the Anaconda installer
Section "InputClass"
	Identifier	"anaconda-keyboard"
	MatchIsKeyboard	"on"
	Option	"XkbLayout"	"se,us"
	Option	"XkbOptions"	"grp:alt_shift_toggle"
EndSection

# cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "se"
        Option "XkbModel" "pc105"
EndSection

Removing 00-anaconda-keyboard.conf made Alt-Shift-Tab work again.

The third of May was apparently the day I installed the system, and the eighth of November was about when I first noticed the problem. How odd then that the problem was in the older file and not the newer one.

I don't understand where Anaconda got the idea that I might want to switch keyboard layouts, how anyone could think that the combination of two modifier keys would be a good command, why I didn't have this problem immediately after installing the system, or why I ended up with two competing configuration files, but at least I now know where to look the next time this happens.

This bug should probably be reassigned either to Anaconda or to some component related to keyboard configuration.

"I don't understand where Anaconda got the idea that I might want to switch keyboard layouts"

At the time you installed, it was substantially different to how it is now. Back then, we were still on the fairly unsophisticated heuristic approach anaconda used in F18 and F19. It would pick a keyboard layout based mainly on the name of the language you picked on the welcome screen - it'd try and find the most similar name it could. There was a checkbox on the welcome screen: if you didn't check it, you got US English plus that native layout, if you did check it, you just got your native layout.

The basic problem here is that there's two different camps with keyboard layouts: there are layouts that can input ASCII characters and which are usually used alone, and layouts which can't input ASCII characters and which are usually used in combination with a US layout and a switcher key combo to switch between the two. Until July 12, anaconda didn't really get this right, it just had that checkbox on the Welcome screen which basically let you pick one of those two types of setup, but it wasn't particularly clear that this is what it did.

Since July 12 things should be a lot better, because anaconda doesn't work that way any more. It uses data provided by langtable: https://github.com/mike-fabian/langtable . langtable is a store for this kind of information, and it includes mappings from locales to keyboard layouts (which anaconda uses to pick an appropriate layout for your locale) and also has a field for declaring whether a layout can or cannot input ASCII, which anaconda uses to decide whether to only give you your native layout, or whether to give you your native layout and US and a switcher key. (Of course, you can always *change* this in the Keyboard spoke, we're only talking about defaults here).

langtable has Swedish marked as capable of inputting ASCII, so if you do an install with current F20, you should see that it would only configure the Swedish layout - it wouldn't also include US, and it wouldn't include a switcher key combo.

"how anyone could think that the combination of two modifier keys would be a good command"

It's actually usual for keyboard layout switching key combos, in my experience. Prior to F18, the default combo for switching layouts in X was both shift keys together. At the console, different layouts define different switcher combos (people in different countries are used to different combos, apparently) but alt+shift is one of the most commonly-used.

"why I didn't have this problem immediately after installing the system"

now, *that* one I don't have a very good answer for. Unless you were using GNOME at the time; GNOME was entirely ignoring X's layout switch combination setting for a while. Now it uses it as long as you have not set a per-user keyboard configuration within GNOME, IIRC. KDE respects the systemwide configuration by default but has a checkbox for using per-user KDE settings instead.

"or why I ended up with two competing configuration files"

The second looks like it was written by localed on Nov 8th. I'd guess you ran either localectl or system-config-keyboard (which is now backended by localed) at that time to try and fix things. This is another thing that's changed since you installed: anaconda now writes 00-keyboard.conf , the same filename as localed, so this competition will no longer happen, anything you do via localed post-install will supersede the anaconda-written config, as it should.

I think this bug can probably be closed, as all the problematic behaviour you identify has been changed since you installed, but you may want to do a test install (in a VM, perhaps) in Swedish and check everything behaves as you'd want.

vpodzime: one thing this does throw up is then when we do *correctly* configure two layouts and a switcher combo, there is going to be this conflict with alt+shift+tab. I remember I asked you once why we don't keep the pre-F18 Fedora default of both-shifts-together as the layout switch combo; I can't recall the conclusion to that discussion, but perhaps we should revisit it in light of this?

(In reply to Adam Williamson from comment #9)
> "why I didn't have this problem immediately after installing the system"
> 
> now, *that* one I don't have a very good answer for. Unless you were using
> GNOME at the time;

No, I've been using XFCE since I installed this system. I may have logged in to Gnome at first to get at an X terminal and run Yum to install XFCE and other packages, but not much more than that. (Incidentally, it was when I saw how they had complicated window switching that I concluded that Gnome 3 was useless to me.)

> "or why I ended up with two competing configuration files"
> 
> The second looks like it was written by localed on Nov 8th. I'd guess you
> ran either localectl or system-config-keyboard (which is now backended by
> localed) at that time to try and fix things.

Yes, I think I ran system-config-keyboard. It has been my experience over the years that every now and then the system resets itself to the US keyboard layout, and my quick fix is to run system-config-keyboard. I think I had such an incident around that time.

I think there must have been a second configuration file even before then though, or else something else changed in the system. If I use only 00-anaconda-keyboard.conf, then the keyboard layout changes every time I go too far in the window list and try to go back. I can't possibly have been using such a configuration for half a year without noticing.

> anaconda now writes 00-keyboard.conf , the same
> filename as localed, so this competition will no longer happen, anything you
> do via localed post-install will supersede the anaconda-written config, as
> it should.

OK, that sounds like an improvement.

(In reply to Adam Williamson from comment #10)
> vpodzime: one thing this does throw up is then when we do *correctly*
> configure two layouts and a switcher combo, there is going to be this
> conflict with alt+shift+tab. I remember I asked you once why we don't keep
> the pre-F18 Fedora default of both-shifts-together as the layout switch
> combo; I can't recall the conclusion to that discussion, but perhaps we
> should revisit it in light of this?
No problem, let's do it! To be honest, the only reason why anaconda uses Alt+Shift as a default is that nobody was able to give me any relevant information about what should be the default and since I myself use Alt+Shift and since it is the default on Windows, Alt+Shift it was and still is.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The anaconda default combo still appears to be alt+shift in current Rawhide.

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.