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: NEW
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: 2017-06-25 05:26 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:
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.

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