Alternative shortcut for layout switching Alt+Shift unexpectedly set by default

[Markus W]

[Impact]

The keyboard-configuration package provides a tool for configuring the keyboard via /etc/default/keyboard. However, there are desktop GUIs which provide such tools as well, and in the case of gnome-control-center it has another idea of what /etc/default/keyboard should contain. In short: The different tools don't play well together.

The proposed upload does not claim to fix all issues with this incompatibility. But one of the annoyances is that a pure upgrade of the keyboard-configuration package may result in a changed keyboard configuration without the user asking for it. The proposed upload does address that particular issue on desktop systems.

[Test Case]

1. On an Ubuntu 18.04 system, make sure that the contents of
   /etc/default/keyboard is 'the g-c-c style', for instance:

   XKBLAYOUT=se,us
   BACKSPACE=guess
   XKBVARIANT=,

2. Reboot.

3. Upgrade to the version of the keyboard-configuration package in
   bionic-proposed.

=> Find that /etc/default/keyboard was not changed through the upgrade.

4. Run the command

   sudo dpkg-reconfigure keyboard-configuration

=> Find that you are now offered to change your keyboard configuration.

[Regression Potential]

As a result of this upload, and unlike before, no keyboard configuration will happen behind the scenes on a desktop system due to an upgrade of the keyboard-configuration package. This is the desired change, and I can't think of a case when a user would want the configuration to be changed without having asked for it.

[Original description]

Version: Ubuntu 18.04 Final Beta with default Gnome Shell included in 18.04

Steps to reproduce:
1. Define two keyboard input methods in Settings -> Region & Language -> Input Sources
2. Open several applications
3. Observe that application windows can be iterated with Alt + Tab
4. Once application window iteration was begun with Alt + Tab, try to iterate backwards with Alt + Shift + Tab.
5. Try to change keyboard input method switching hotkeys in Settings -> Region & Language -> Input Sources -> Options.
6. Observe that Keyboard shortcut for "Alternative switch to next source" is set to "Alt + Shift" and that keyboard shortcuts can only be changed in Settings -> Devices -> Keyboard -> Keyboard Shortcuts.
7. Observe that the shortcut for "Alternative switch to next source" is not available for configuration in Settings -> Devices -> Keyboard -> Keyboard Shortcuts.

Actual state:
* Performing step 4 does not select the previous app in application switcher but instead changes keyboard input method.

Expected state:
* The shortcut for "Alternative switch to next source" can be changed and / or deactivated in Settings -> Devices -> Keyboard -> Keyboard Shortcuts.

Notes:
* The above was working fine in Ubuntu 17.10. I assume "Alternative switch to next source" did not exist in that version of Gnome Shell.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Markus W (z-mw)]

There is another aspect to this issue: It also becomes impossible to execute application-level keyboard shortcuts that contain Alt + Shift, such as `Alt + Shift + R`.

What is actually executed: Alt + R and Input method is switched

What should have executes: Alt + Shift + R and Input method is unchanged

It really needs to be possible to remove or change the `Alternative switch to next source` hotkey `Alt + Shift`.

[Carl-Erik Kopseng (carlerik)]

@Markus, that is a great comment. That explains why none of my WebStorm navigation shortcuts work consistently!

[Gunnar Hjalmarsson (gunnarhj)]

The default shortcut for switching input source is Super+Space. The conflict is present if you set an alternative shortcut, and pick just Alt+Shift. Please note that alternative shortcuts for switching input source can be controlled from Tweaks (gnome-tweaks or gnome-tweak-tool).

This is a related discussion:

https://community.ubuntu.com/t/keyboard-layout-switching-problems-and-poll/2876

[Markus W (z-mw)]

@Gunnar re: #6
`Alt + Shift` was set by default with the (in my case) upgrade to 18.04. I never set this alternative shortcut myself and there is no way to change it without additional tools. In fact, the entire bug report is about this alternative shortcut being an issue with the current default value.

[Markus W (z-mw)]

@Gunnar re: #6
I can confirm that this particular alternative shortcut can be deactivated with `gnome-tweaks` by unchecking the checkbox under `Keyboard & Mouse -> Additional Layout Options -> Switching to another layout -> Alt + Shift`.

[Gunnar Hjalmarsson (gunnarhj)]

On 2018-04-24 09:44, Markus W wrote:
> `Alt + Shift` was set by default with the (in my case) upgrade to
> 18.04. I never set this alternative shortcut myself

That's the odd part. No alternative shortcut should be set by default AFAIK. Other observations reported in this bug is expected behavior.

I just checked an (almost) fresh install of Ubuntu 18.04, and there it was not set. OTOH I just found that it was set on my 18.04 which I recently upgraded from 17.10. Can't remember that I set it myself (but I'm not sure; I often play with that kind of settings when providing support).

Hmm.. I think we need a reproducible use case which confirms this behavior.

[Gunnar Hjalmarsson (gunnarhj)]

The Ask Ubuntu question <https://askubuntu.com/q/963616> reports a similar thing, i.e. that Alt+Shift was set during an update of 17.10 without the OP had asked for it.

[Gunnar Hjalmarsson (gunnarhj)]

@Jeremy: Since you maintain Tweaks, does it possibly ring a bell?

[Carl-Erik Kopseng (carlerik)]

Just wanted to chime in on the upgrade path problem. I also upgraded from Ubuntu 17.10 and I also never set this shortcut anywhere. I have always used Super+Space and I have never used the Gnome Tweaks tool before. Using it to disable the shortcut fixed all the issues and the shortcuts using Shift - regardless of program - now work.

This seems to point to this being some kind of upgrade issue.

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for sharing that, Carl-Erik.

On 2018-04-24 21:25, Carl-Erik Kopseng wrote:
> This seems to point to this being some kind of upgrade issue.

It does, indeed. The question is which package sets it.

[Carl-Erik Kopseng (carlerik)]

By the way, the real, underlying problem is of course that overlapping shortcuts should be possible (like in Mac and Windows), which is caused by this XKB bug reported 14 years ago (and still active): https://bugs.freedesktop.org/show_bug.cgi?id=865

It is basically about activating shortcuts on keypress vs key release.

[Gunnar Hjalmarsson (gunnarhj)]

True. That's what the discussion I linked to in comment #6 is about, and there is a xorg-server patch in a PPA to address the issue. (Haven't tested it.)

[Gunnar Hjalmarsson (gunnarhj)]

I took the following steps:

* Installed Ubuntu 17.10.1
* Added an extra keyboard layout
* Updated the packages
* Rebooted

No additional layout switch shortcut so far.

Then I run "update-manager -d", and when it was installing the new and upgraded packages, a window for keybord configuration popped up and I was prompted to select method for switching between "setting for national and latin" (see attached image). Alt+Shift was pre-selected. I found no way to skip that setting, and clicked the "Forward" button. Result:

$ cat /etc/default/keyboard
XKBLAYOUT="se,us"
XKBVARIANT=","
BACKSPACE="guess"
XKBMODEL="pc105"
XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"

So there it is. And at first login those XKBOPTIONS values were imported by dconf (as expected).

I still can't tell which package is the culprit. Changed to ubuntu-release-upgrader for now, since it's probably closer to the truth than gnome-shell.

In any case the upgrade behavior in this respect needs to be reconsidered, at least for desktop upgrades. No program should make assumptions and gratuitously set XKBOPTIONS in /etc/default/keyboard, especially since g-c-c does not offer a way to modify it later. (Is there a reason for the upgrader to mess with keyboard configuration at all?)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gunnar Hjalmarsson (gunnarhj)]

Another example of reported confusion due to this issue:

https://askubuntu.com/q/1035383

[Gunnar Hjalmarsson (gunnarhj)]

Those XKB options are probably set by the keyboard-configuration.config script in the keyboard-configuration package. So maybe we need to figure out a proper way to make that script keep its hands off /etc/default/keyboard when a desktop is upgraded.

[Gunnar Hjalmarsson (gunnarhj)]

On 2018-05-13 04:47, Gunnar Hjalmarsson wrote:
> Those XKB options are probably set by the
> keyboard-configuration.config script in the keyboard-configuration
> package. So maybe we need to figure out a proper way to make that
> script keep its hands off /etc/default/keyboard when a desktop is
> upgraded.

The attached debdiff is an attempt at that. When the keyboard-configuration package is upgraded, the main code in the postinst script is not run. When installing, including reinstalling the package, it works as usual, and also when running "dpkg-reconfigure keyboard-configuration".

I uploaded the patch to this PPA (bionic):

https://launchpad.net/~gunnarhj/+archive/ubuntu/console-setup

(The proposed changes to d/control and d/rules proved to be needed for the PPA upload.)

[Łukasz Zemczak (sil2100)]

Thanks for your patch Gunnar! For now I only had a quick look the changes, was wondering why the debian/control and debian/rules changes were needed for the PPA upload. It didn't build without those? I would expect it to not really differ from what would happen in the archive.

Also, from the glimpse I had I saw you were doing `dpkg --compare-versions "$2" lt-nl "$PKGVERSION"` in the postinst - was is the reason for that? I might be missing context, but isn't it enough to just check for "$1" = "upgrade" to see if we're upgrading?

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for looking, Łukasz.

Right, it didn't build in PPA for me without those. As regards 'locales', according to the build log it looked for and failed to find /usr/share/i18n/charmaps. As regards the extra install directory in d/rules, it's obviously needed if the conditions for running the subsequent commands are satisfied. Can't explain why it differs from the archive uploads. I just run "debuild -S" and dput'ed (not from a clean chroot, though).

I think that $1 is always "configure" at the execution of postinst. Please note that the original code checks for precisely that. I struggled a bit to find a way to check whether we are upgrading, and the proposed way proved to work when I tested. But I'm not a Debian packaging wizard, and would be just as happy if there is a simpler way to check for it.

Actually, the fact that keyboard-configuration and g-c-c both write to /etc/default/keyboard, while they have different ideas of what it should contain, appears to be a bit odd. My proposal only addresses the most obvious issue as reported in this bug, i.e. it prevents the keyboard configuration from being changed without the user having asked for it.

[Łukasz Zemczak (sil2100)]

Indeed, this is postinst so the value is "configure" for all successful upgrades. What could be done is actually only checking if $2 exists or not, since if I remember correctly we only have postinst configure called with a version number in the case of upgrades or downgrades - which I suppose don't matter as in case of downgrading to an older version that we expect modify /etc/default/keyboard then anyway the destination version's postinst is executed. And I suppose the same thing happens for packages that are in the config-installed state, but that shouldn't be a problem for us (since it means postinst ran at least once anyway).

Probably needs checking.

Could you check if only doing a test for the existence of $2 would suffice? This could probably be added to the existing conditional and make the maintscript look better.

[Gunnar Hjalmarsson (gunnarhj)]

Only checking for the existence of $2 was the first thing I tried, after having read about that method somewhere. What I found when testing was that $2 always exists when executing postinst in keyboard-configuration. In case of an upgrade it's the previous package version, and otherwise it's the current package version.

[Gunnar Hjalmarsson (gunnarhj)]

When studying the variables I put a code snippet in postinst and built the package; something along these lines:

i=1
for p in $@; do
    echo "\$$i = $p"
    i=$((i+1))
done

[Łukasz Zemczak (sil2100)]

It shouldn't be like that. I just now did an experiment with a new empty package and I only saw $2 having the version number for upgrades - on first install $2 was empty. Anyway, I'll take your changes, tweak them a little bit and sponsor if they seem to work as expected.

[Gunnar Hjalmarsson (gunnarhj)]

Ok. Please note that I never tested a *first* install of keyboard-configuration (hard to do due to dependencies). Besides upgrade I tested reinstall and "dpkg-reconfigure keyboard-configuration". Especially in the latter case it's obviously important that all the postinst code does run.

[Gunnar Hjalmarsson (gunnarhj)]

To make sure that I'm not wandering, I made an own experiment, where I put some code in postinst which prints the variables. (I uploaded it to the same PPA.) Please see the result in the attached file.

So, considering that we must distinguish between upgrades and pure configuration, only testing if $2 exists is not sufficient. I still think that the code I proposed does the right thing. ;)

[Gunnar Hjalmarsson (gunnarhj)]

Yet another example:

https://askubuntu.com/q/1048831

[Łukasz Zemczak (sil2100)]

I somehow forgot about this bug! Ok, I think I know now what you're aiming for. Normally just checking for the existence of $2 would be sufficient but not if we're expecting the config changes to happen on package reinstall. I guess it's just a matter of design here - I obviously was thinking of more that reinstallation/reconfiguration should follow the same rules as an upgrade, as first install was already responsible for modification of the /etc/default/keyboard file. But there's also the approach of reinstall causing a complete 'fresh install' of the config, which indeed might sound a bit better.

Let's get this sponsored!

[Łukasz Zemczak (sil2100)]

Once this migrates to cosmic release, I'll SRU it to bionic.

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.178ubuntu3

---------------
console-setup (1.178ubuntu3) cosmic; urgency=medium

  * debian/keyboard-configuration.postinst:
    - Don't change /etc/default/keyboard at package upgrades on
      desktops, since it may conflict with how desktops deal with
      keyboard configuration (LP: #1762952).

 -- Gunnar Hjalmarsson <email address hidden> Tue, 15 May 2018 01:12:00 +0200

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[yoosofan (yoosofan)]

Is there a reason why we cannot use CapsLock for changing layout?
CapsLock is the most simplest key for changing layout when you want to work with both hand while writing a mixed text of two language. Actually CapsLock does not use to its main function because people barely write with a lot of bold words and using shift for occasionally one letter is very common,

[Gunnar Hjalmarsson (gunnarhj)]

@yoosofan: Several options, including CapsLock, are available to switch layout. If you want to suggest that to be the default option in Ubuntu, you'd better approach the GNOME developers:

https://gitlab.gnome.org/GNOME/gnome-control-center/issues

(The discussion seems unrelated to this bug.)

[Gunnar Hjalmarsson (gunnarhj)]

Hi Łukasz, I changed the bug description and added a test case. Hopefully that is sufficient to proceed with the bionic upload.

[Andy Whitcroft (apw)]

Hello Markus, or anyone else affected,

Accepted console-setup into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/console-setup/1.178ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Gunnar Hjalmarsson (gunnarhj)]

The build failed.

[error] cannot read character map directory `/usr/share/i18n/charmaps': No such file or directory

Looks like those extra changes, which I proposed in the original patch - and which proved to not be needed in cosmic - make a difference in bionic. (Yes, Łukasz, as you suggested on IRC it was in the bionic pocket of my PPA I tested originally.)

The above error should go away if locales is added to Build-Depends-Indep.

[Łukasz Zemczak (sil2100)]

Hey Gunnar! The build just now succeeded after a re-run (?). Probably some race-condition with the current package dependencies. Anyway, since the package is built let's not re-upload for no reason. You can proceed with testing!

[Gunnar Hjalmarsson (gunnarhj)]

Verified the test case by upgrading to version 1.178ubuntu2.1 of

- console-setup
- console-setup-linux
- keyboard-configuration

from bionic-proposed. Result as expected.

[Łukasz Zemczak (sil2100)]

Hello Markus, or anyone else affected,

Accepted console-setup into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/console-setup/1.178ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Gunnar Hjalmarsson (gunnarhj)]

Verified the test case again, this time by upgrading from version 1.178ubuntu2 to 1.178ubuntu2.2, which was uploaded to address the regression reported in bug #1782835.

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.178ubuntu2.2

---------------
console-setup (1.178ubuntu2.2) bionic; urgency=medium

  * debian/console-setup-udeb.postinst: Guard the dpkg call in the postinst,
    so it isn't attempted in the debian-installer environment (LP: #1782835)

console-setup (1.178ubuntu2.1) bionic; urgency=medium

  * debian/keyboard-configuration.postinst:
    - Don't change /etc/default/keyboard at package upgrades on
      desktops, since it may conflict with how desktops deal with
      keyboard configuration (LP: #1762952).

 -- Adam Conrad <email address hidden> Fri, 20 Jul 2018 14:22:45 -0600

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for console-setup has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Adam Conrad (adconrad)]

Re-opening this bug as we had to revert the fix, because it was causing an installer regression:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1783326

That said, I think the "run it sometimes, but not always" fix was probably naive at best. The only two options that seem to make sense for fixing this properly are:

1) Make GNOME stop writing things to that file that console-setup doesn't understand, or
2) Make console-setup understand the things GNOME writes to that file.

The second option is certainly the more appealing of the two, but it's clearly not going to happen before the point release in two days.

[Gunnar Hjalmarsson (gunnarhj)]

@Adam: Sad to hear that the proposed fix caused yet another regression, and sorry for the inconvenience it caused.

On 2018-07-25 03:31, Adam Conrad wrote:
> That said, I think the "run it sometimes, but not always" fix was
> probably naive at best. The only two options that seem to make
> sense for fixing this properly are:
>
> 1) Make GNOME stop writing things to that file that console-setup
> doesn't understand, or
> 2) Make console-setup understand the things GNOME writes to that
> file.

Basically it's the other way around; console-setup adds XKBOPTIONS to /etc/default/keyboard, sometimes behind the scenes, but GNOME does not include GUIs for controlling XKBOPTIONS system wide (only per user). At the same time, when you use the GNOME GUI to change the keyboard configuration system wide, it brutally drops any XKBOPTIONS in /etc/default/keyboard.

I'm going to bring it up with the desktop team, and try to figure out a better approach to handle this dissonance. Then let's make sure in advance that whatever we comes up with does not interfere with the installer.

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.178ubuntu6

---------------
console-setup (1.178ubuntu6) cosmic; urgency=medium

  * keyboard-configuration.{config,templates}: There is no good default for
    layout toggling, stop pretending there is. Console users can set one
    with dpkg-reconfigure or editing /etc/defaults/keyboard (LP: #1762952)

 -- Adam Conrad <email address hidden> Wed, 25 Jul 2018 05:50:59 -0600

[Chris J Arges (arges)]

Hello Adam, or anyone else affected,

Accepted console-setup into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/console-setup/1.178ubuntu2.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Gunnar Hjalmarsson (gunnarhj)]

I went through step 1 -3 in the test case in the bug description, thus upgraded to version 1.178ubuntu2.4 of keyboard-configuraion, console-setup and console-setup-linux from bionic-proposed. The result:

$ cat /etc/default/keyboard
XKBLAYOUT="se,us"
BACKSPACE="guess"
XKBVARIANT=","
XKBMODEL="pc105"
XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"

So keyboard-configuration still enforces grp:alt_shift_toggle to be written to /etc/default/keyboard.

If I change /etc/default/keyboard before the upgrade to only include one layout - in my case XKBLAYOUT=se - no XKBOPTIONS are added. But that's the behavior before the proposed change too.

So unfortunately the proposed change seems to not address the issue reported in this bug.

[Stéphane Graber (stgraber)]

Hello Markus, or anyone else affected,

Accepted console-setup into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/console-setup/1.178ubuntu2.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.178ubuntu8

---------------
console-setup (1.178ubuntu8) cosmic; urgency=medium

  * keyboard-configuration.config: Only treat missing XKBOPTIONS as empty.

 -- Adam Conrad <email address hidden> Wed, 08 Aug 2018 17:32:23 -0600

[Gunnar Hjalmarsson (gunnarhj)]

1.178ubuntu2.6 failed to build. My original patch:

https://launchpadlibrarian.net/370321046/console-setup_lp1762952.debdiff

contains proposed changed to d/control and d/rules which would prevent those build errors.

[Gunnar Hjalmarsson (gunnarhj)]

Hmm.. Another build attempt succeeded without changes.

I went through step 1 -3 in the test case in the bug description, thus upgraded to version 1.178ubuntu2.6 of keyboard-configuraion, console-setup and console-setup-linux from bionic-proposed. The result:

$ cat /etc/default/keyboard
XKBLAYOUT="se,us"
BACKSPACE="guess"
XKBVARIANT=","
XKBMODEL="pc105"
XKBOPTIONS="grp_led:scroll"

So no layout switching option was added behind the scenes.

[Launchpad Janitor (janitor)]

This bug was fixed in the package console-setup - 1.178ubuntu2.6

---------------
console-setup (1.178ubuntu2.6) bionic; urgency=medium

  * keyboard-configuration.config: Only treat missing XKBOPTIONS as empty.

console-setup (1.178ubuntu2.5) bionic; urgency=medium

  * keyboard-configuration.config: While sourcing config files to re-seed
    debconf, load missing variables as empty values of same (LP: #1762952)

console-setup (1.178ubuntu2.4) bionic; urgency=medium

  * keyboard-configuration.{config,templates}: There is no good default for
    layout toggling, stop pretending there is. Console users can set one
    with dpkg-reconfigure or editing /etc/defaults/keyboard (LP: #1762952)

 -- Adam Conrad <email address hidden> Wed, 08 Aug 2018 17:32:23 -0600

[C. Daniel Mojoli B. (cdmojoli)]

This bug made using emacs and IntelliJ Idea a nuisance. I found a simple workaround.
0
=1=

You can verify how ALT and SHIFT are not being detected simultaneously by running
$ xkbwatch

Notice how the blinky lights change for ALT and for SHIFT but not for both at the same time.

=2=

$ setxkbmap -query
rules: evdev
model: pc105
layout: us,us,us
variant: ,intl,
options: grp:alt_shift_toggle,grp_led:scroll
            ^^^^^^^^^^^^^^^^^^^^
            THIS IS THE PROBLEM

=3=

We will now unset ALT-SHIFT toggle.

$ setxkbmap -option -option grp_led:scroll
            ^^^^^^^
            DELIBERATELY EMPTY

The first empty -option erases all options, the second one just carries over an option we want to keep. Additional -option clauses can preserve other preexisting options.

I can still change to next/previous input source with whatever is configured in Settings/Keyboard/Typing

=4=

Do step =2= again and notice how ALT and SHIFT now play together simultaneously.

I am now a happy Emacs and IntelliJ user. This is a single command workaround.

[yoosofan (yoosofan)]

Thank you https://launchpad.net/~gunnarhj for your advice. I report this on https://gitlab.gnome.org/GNOME/gnome-control-center/issues/290

[Alkis Georgopoulos (alkisg)]

Hi, this fix caused a regression in ubiquity: LP: #1892014

Ubiquity doesn't put alt_shift_toggle in XKBOPTIONS anymore, so we cannot switch to e.g. Greek using Alt+Shift, after going through a normal installation (or even in the live session).

Are users expected to manually run `dpkg-reconfigure keyboard-configuration` right after a GUI installation of Ubuntu?

E.g. ubuntu-mate-18.04.2-desktop-amd64.iso is affected while 18.04.1 isn't.

Should this issue be resolved in console-setup or in ubiquity?

[Gunnar Hjalmarsson (gunnarhj)]

@Alkis: I added a comment on the new bug. Let's talk there. This one is closed.