Bug 1460423
Summary: | Windows button on Microsoft Sculpt mouse does not open shell overview | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | cowardlysnake |
Component: | gnome-shell | Assignee: | Owen Taylor <otaylor> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | fedora, fmuellner, otaylor |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-05-29 11:32:23 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
cowardlysnake
2017-06-10 09:48:33 UTC
I've checked and it doesn't work with Gnome on xorg either. 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". 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. 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. 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. 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. I tried testing all of the ids that appear in wayland but none of them pick up this button (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? 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? 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. 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. (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. 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. 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. 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. |