Bug 1460423 - Windows button on Microsoft Sculpt mouse does not open shell overview
Windows button on Microsoft Sculpt mouse does not open shell overview
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
26
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-10 05:48 EDT by cowardlysnake
Modified: 2018-05-29 07:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-29 07:32:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cowardlysnake 2017-06-10 05:48:33 EDT
Description of problem:


Version-Release number of selected component (if applicable): Fedora 26 with all updates installed (as of 2017-06-10)


How reproducible: Always


Steps to Reproduce:
1. Click blue windows button on Microsoft Sculpt mouse

Actual results:  Nothing happens


Expected results:  Shell overview to appear as if I'd pressed the windows (super) key on the keyboard.


Additional info:  I'm using Gnome with wayland.  I don't believe it works on xorg either but I will double check that.
Comment 1 cowardlysnake 2017-06-10 05:50:58 EDT
I've checked and it doesn't work with Gnome on xorg either.
Comment 2 Christian Stadelmann 2017-06-12 03:48:22 EDT
What is the key code of this windows button?

Please run `$ xinput list`. Then take the ID of your Microsoft sculpt mouse (e.g. 12) and run `$ xinput test 12`. Press the windows key. Then terminate the tool. Post the output here. You might need to try several "slave pointer" devices if you don't get output for the first one you've tried. The output should at least contain something like "button press [number]" and "button release [number]" or "key press [number]" followed by "key release number".
Comment 3 cowardlysnake 2017-06-12 16:39:01 EDT
Using Gnome on Wayland xinput list returns

Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:13                    	id=8	[slave  keyboard (3)]

I tried xinput test with ids 2,4,6,and 7. Id2 couldn't find the device.  None of the others registered anything with the windows button or the main left click button.  Id 6 did record motion when I moved the mouse.

I'll switch to an xorg session and see if it behaves differently there.
Comment 4 cowardlysnake 2017-06-12 16:45:12 EDT
Using Gnome on Xorg xinput list returns

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® 2.4GHz Transceiver v9.0	id=10	[slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® 2.4GHz Transceiver v9.0	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Microsoft® LifeCam VX-2000             	id=8	[slave  keyboard (3)]
    ↳ Microsoft Microsoft® 2.4GHz Transceiver v9.0	id=9	[slave  keyboard (3)]
    ↳ Eee PC WMI hotkeys                      	id=12	[slave  keyboard (3)]
    ↳ Microsoft Microsoft® 2.4GHz Transceiver v9.0	id=13	[slave  keyboard (3)]

xinput test 10 returned motion output and also a button press/release 1 for the left mouse button.  Nothing was returned with the blue windows button.
Comment 5 Christian Stadelmann 2017-06-12 17:09:08 EDT
Yes, xinput is expected to work better on Xorg compared to Wayland. I should have mentioned that.
Can you try disconnecting the mouse (only the mouse) and get another `xinput list` output? Then compare both and find all IDs provided by your mouse. Or just try all of the IDs. Since your mouse has a non-standard key, it might also identify itself as keyboard to your computer.

If that does not work, what do you get when running `scankey -s` from a tty followed by repeatedly pressing the Windows button? (You might need to run it as root)?

You might want to try the trick from https://ask.fedoraproject.org/en/question/57497/how-to-use-microsoft-mouse-with-super-key/: Open some tool, e.g. gnome-control-center, and assign the button to a keyboard shortcut. Maybe that sheds some light on your device, maybe it does not work any more (as a comment on the first answer suggests). Or try https://superuser.com/questions/1194232/rebind-windows-key-of-microsoft-sculpt-ergo-mouse.

If that does not work, the Kernel might not be able to detect the device correctly or might not provide a driver for it. In this case, how is the mouse connected to your computer? Is it listed in the outputs of `lspci`, `lsusb`, `hciconfig`  or `lshw`? If yes, please post the output.
Comment 6 cowardlysnake 2017-06-14 13:59:46 EDT
Using gnome on xorg I tried testing each id as turning off the mouse didn't change the xinput list.

xinput test 9 recorded "key press 134" and "key release 134" when I pressed the blue windows button.

The mouse (and keyboard) connect via a usb dongle which shows up in lsusb as 

Bus 002 Device 004: ID 045e:07a5 Microsoft Corp. Wireless Receiver 1461C


I'll retry this on wayland and also take a look at the links you provided.
Comment 7 cowardlysnake 2017-06-14 14:02:22 EDT
I tried testing all of the ids that appear in wayland but none of them pick up this button
Comment 8 Christian Stadelmann 2017-06-19 07:10:55 EDT
(In reply to cowardlysnake from comment #6) 
> xinput test 9 recorded "key press 134" and "key release 134" when I pressed
> the blue windows button.

Ok, that looks good, so it is no kernel or driver bug. The key is identified correctly.

(In reply to cowardlysnake from comment #7)
> I tried testing all of the ids that appear in wayland but none of them pick
> up this button

Thinking of it, that is quite expected because gnome-shell consumes the "Windows" button.

Have you tried assigning a key combination to this button using gnome-control-center?
Comment 9 cowardlysnake 2017-06-19 15:31:26 EDT
I opened gnome-control-center and selected Keyboard.

I clicked the + at the bottom of the list. When I "Set Shortcut..." and click the windows button on the mouse, it is registered because a Cancel button appears.  However, there is no Save or OK button for me to proceed. My only options are "Cancel" or "Press Esc to cancel".

Am I missing something?
Comment 10 Florian Müllner 2017-06-19 15:48:22 EDT
On Linux, the Windows key is a modifier like Control. The keyboard Settings panel doesn't allow modifier-only shortcuts, so that's expected. There's actually an awful lot of code in mutter to make it work for a single key ...

Now regarding your problem, I suspect that the issue is that mutter only uses the left super key for the overlay, while your mouse simulates the right super key.

If that is the case, then
  $ gsettings set org.gnome.mutter overlay-key 'Super_R'
should fix it.
Comment 11 cowardlysnake 2017-06-20 02:56:12 EDT
That has fixed it although the keyboard left super key now doesn't work.  I restored the original behaviour with 

gsettings set org.gnome.mutter overlay-key 'Super_L'

Is it possible to have both keys enter the overlay?

I've checked that with the left super key entering the overlay, the mouse super key works as a super key modifier i.e. mouse super + s enters overlay, mouse super + a shows applications. 

I notice now that the Microsoft keyboard that comes with the mouse doesn't actually have a right super key.  I never use it on normal keyboards so I didn't notice it was missing.

Thanks very much for your help.
Comment 12 Florian Müllner 2017-06-21 05:21:24 EDT
(In reply to cowardlysnake from comment #11)
> Is it possible to have both keys enter the overlay?

No. There's a long standing feature request for that, but considering the amount of complex code that's required to have *one* key function as both a modifier and a shortcut of its own, everyone has shied away from extending it to multiple keys so far.
Comment 13 cowardlysnake 2017-06-25 05:26:21 EDT
I'm happy to close this bug then as the functionality I need is covered by this other feature request.

Can I close it or does it need to be someone from the project?

Thanks for your help.
Comment 14 Fedora End Of Life 2018-05-03 05:03:02 EDT
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

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 26 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.
Comment 15 Fedora End Of Life 2018-05-29 07:32:23 EDT
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
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.

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