After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140279 - Gnome needs mouse button bindings
Gnome needs mouse button bindings
Status: RESOLVED OBSOLETE
Product: gnome-tweak-tool
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Tweak Tool maintainer(s)
GNOME Tweak Tool maintainer(s)
: 104764 125620 154563 358943 373936 494840 495669 508764 (view as bug list)
Depends on: 662564
Blocks:
 
 
Reported: 2004-04-16 16:16 UTC by Andrew Barrow
Modified: 2018-01-24 15:00 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Mockup (83.15 KB, image/png)
2008-03-04 11:56 UTC, David Prieto
Details

Description Andrew Barrow 2004-04-16 16:16:46 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.
Comment 1 Vincent Noel 2004-08-05 16:45:06 UTC
*** Bug 104764 has been marked as a duplicate of this bug. ***
Comment 2 Vincent Noel 2004-08-05 16:45:49 UTC
*** Bug 125620 has been marked as a duplicate of this bug. ***
Comment 3 Vincent Noel 2004-10-05 19:54:43 UTC
*** Bug 154563 has been marked as a duplicate of this bug. ***
Comment 4 David Bolter 2004-10-05 20:03:32 UTC
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
Comment 5 Jens Granseuer 2007-03-03 13:54:49 UTC
*** Bug 358943 has been marked as a duplicate of this bug. ***
Comment 6 Jens Granseuer 2007-03-03 13:56:08 UTC
*** Bug 373936 has been marked as a duplicate of this bug. ***
Comment 7 Bastien Nocera 2007-06-08 15:55:53 UTC
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.
Comment 8 Nicolas Mailhot 2007-06-08 16:07:45 UTC
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?
Comment 9 Bastien Nocera 2007-06-08 16:11:04 UTC
(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.
Comment 10 Nicolas Mailhot 2007-06-08 16:47:42 UTC
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
Comment 11 Sébastien Bertrand 2007-06-08 17:50:02 UTC
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 ?
Comment 12 Nicolas Mailhot 2007-06-08 17:57:40 UTC
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
Comment 13 Jens Granseuer 2007-11-08 17:47:54 UTC
*** Bug 494840 has been marked as a duplicate of this bug. ***
Comment 14 Jens Granseuer 2007-11-11 10:57:22 UTC
*** Bug 495669 has been marked as a duplicate of this bug. ***
Comment 15 Jeroen Hoek 2008-01-20 00:36:59 UTC
(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
Comment 16 Bastien Nocera 2008-02-21 21:43:17 UTC
(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).
Comment 17 David Prieto 2008-03-04 11:56:15 UTC
Created attachment 106544 [details]
Mockup
Comment 18 David Prieto 2008-03-04 11:57:27 UTC
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
Comment 19 Alexander Kojevnikov 2009-08-14 07:37:01 UTC
*** Bug 508764 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Cardenas 2010-05-15 22:47:04 UTC
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.
Comment 22 bambastik 2011-10-23 18:24:05 UTC
Add pls

Right click or Midle click title bar window Alweys On Top function

Thanks
Comment 23 John Stowers 2011-10-23 22:24:52 UTC
(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
Comment 24 GNOME Infrastructure Team 2018-01-24 15:00:52 UTC
-- 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.