GNOME Bugzilla – Bug 140279
Gnome needs mouse button bindings
Last modified: 2018-01-24 15:00:52 UTC
Gnome needs a feature to bind mouse buttons to functions, since many modern mice have 7 buttons (MS Intellimouse, etc). This would be useful for switching desktops or going forward/backward in epiphany. The best place to put this feature would be in the keyboard binding section, which should probably be renamed to keyboard/mouse bindings. I know that there is already a utility (imhweel) that can do mouse bindings, but it is too complex for the average user. A GUI is needed to assign these functions. Even though imwheel allows different windows to have different functions for the same button, I think gnome would only need something that works in the global context. Seems like this feature would be pretty easy to implement, but I am not familiar with the gnome (or Xserver) code, so I thought I'd leave it to the experts.
*** Bug 104764 has been marked as a duplicate of this bug. ***
*** Bug 125620 has been marked as a duplicate of this bug. ***
*** Bug 154563 has been marked as a duplicate of this bug. ***
Note: the work here could make use of the at-spi module which provides keyboard output stuff. E.g. http://developer.gnome.org/doc/API/2.0/at-spi/at-spi-cspi-Registry-queries.html#SPI-generateKeyboardEvent
*** Bug 358943 has been marked as a duplicate of this bug. ***
*** Bug 373936 has been marked as a duplicate of this bug. ***
This would have nothing to do in the keybindings though. Problem I found in my particular hardware is that the extra buttons are just buttons 1, 2, etc. but on another hardware device. And because X mixes them all into a core device, it's as if I clicked using the normal left-click button.
Keyboard/mouse separation is artificial, they're all input devices. Where are you going to put remote button binding if you don't handle all this stuff in the same place?
(In reply to comment #8) > Keyboard/mouse separation is artificial, they're all input devices. They're still 2 physically different devices on your desktop, and have different properties. > Where are you going to put remote button binding if you don't handle all this > stuff in the same place? We don't intend to. Remote buttons support will fix itself when Infra-red remotes actually show up as through the input layer, like the rest of the input devices.
remotes sold on the market have unmarked buttons that are intended to be user-assignable, just like keyboards and mice, so what you'll get through the input layer are generic event with no special semantics, that the user will need to bind just like keyboards and mice. They're all built by the same companies (microsoft, logitech...), they all have the same customization features
Maybe it's possible to look inside xev code (to test, type juste xev inside a console). Xev is able to differentiate every input on my laptop, is that the case for you ?
unfortunately my remote is a paperweight in linux right now been wondering lately if buying an USB HID one like the ms remote was worth the money
*** Bug 494840 has been marked as a duplicate of this bug. ***
*** Bug 495669 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > (In reply to comment #8) > > Keyboard/mouse separation is artificial, they're all input devices. > > They're still 2 physically different devices on your desktop, and have > different properties. I would disagree. As far as the event interface is concerned, the two can conflate. I have a USB keyboard that creates three event interfaces in /dev/input: pci-0000:00:02.0-usb-0:1.1:1.0-event-kbd -> ../event1 pci-0000:00:02.0-usb-0:1.1:1.1-event-mouse -> ../event2 pci-0000:00:02.0-usb-0:1.1:1.1-mouse -> ../mouse1 (ls -l from /dev/input/by-path) usb-062a_USB-compliant_keyboard-event-kbd -> ../event1 usb-062a_USB-compliant_keyboard-event-mouse -> ../event2 usb-062a_USB-compliant_keyboard-mouse -> ../mouse1 (ls -l from /dev/input/by-id) It has a scroll-wheel and multimedia keys. A number of those multimedia keys are events in event2 instead of event1 (in this case) and don't show up in xev or the Gnome keyboard shortcuts manager, presumably because these keys are events in a mouse device as far as the kernel and Gnome are concerned. Currently the only way I know of to use these keys is through a daemon called evrouter. It would be great if all USB-keyboards with a similar interface would work transparently to the user. Keyboard: Trust Multimedia Scroll Keyboard KB-2200 http://trust.com/15036 Distribution: Ubunutu 7.10 (Gutsy Gibbon) Kernel: 2.6.22-14-generic
(In reply to comment #15) > (In reply to comment #9) > > (In reply to comment #8) > > > Keyboard/mouse separation is artificial, they're all input devices. > > > > They're still 2 physically different devices on your desktop, and have > > different properties. > > I would disagree. As far as the event interface is concerned, the two can > conflate. I have a USB keyboard that creates three event interfaces in > /dev/input: No. They use 2 completely different interfaces in X and the kernel. Different event structures in the kernel, and completely different functions in X. > It has a scroll-wheel and multimedia keys. A number of those multimedia keys > are events in event2 instead of event1 (in this case) and don't show up in xev > or the Gnome keyboard shortcuts manager, presumably because these keys are > events in a mouse device as far as the kernel and Gnome are concerned. You can see that by checking what it reports as supported event types. The new X.org server with HAL support will use what HAL reports, so check the info.capabilities of the device in lshal. For example, on one of my keyboard/mouse combos: info.capabilities = {'input', 'input.keys', 'input.mouse', 'button'} (string list) Some keys of the keys are reported on the mouse device. They should still work given a new enough X.org stack with HAL support. > Currently the only way I know of to use these keys is through a daemon called > evrouter. It would be great if all USB-keyboards with a similar interface would > work transparently to the user. It should work, but at the same time, it won't be fixed by adding support for the mouse keys (as opposed to keyboard keys that show up on the mouse device, which is your problem).
Created attachment 106544 [details] Mockup
I have just filed a bug in Launchpad that you guys might find interesting: I suggest integrating BTNX as a backend for extra button recognition, and a new "extra buttons" tab in the mouse properties dialogue as a frontend. You'll find a quick mockup in my previous post. To see the new bug → https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/198313
*** Bug 508764 has been marked as a duplicate of this bug. ***
If a user has several mouses wouldn't they potentially want to customize each mouse differently? Questions: 1. Is gnome-mouse-properties still the best place for this enhancement? 2. Is gpointing-device-settings the right place to introduce this enhancement? 3. Or should the two apps be somewhat merged? I'm thinking option 3. User doesn't want to guess which app is appropriate for mouse or pointing device customization.
Added the same comment to these two bugs: https://bugzilla.gnome.org/show_bug.cgi?id=603103 https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/198313
Add pls Right click or Midle click title bar window Alweys On Top function Thanks
(In reply to comment #22) > Add pls > > Right click or Midle click title bar window Alweys On Top function > > Thanks File a bug against mutter suggesting this option
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/3.