Bug 93303 - xinput doesn't recognize Logitech G600's side buttons as keyboard buttons but a mouse ones which leads to strange behavior
Summary: xinput doesn't recognize Logitech G600's side buttons as keyboard buttons but...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-09 17:10 UTC by kamil
Modified: 2018-08-10 20:31 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments
Logitech G600 Gaming Mouse - Event4 notated events (13.81 KB, text/plain)
2015-12-24 08:25 UTC, David Timms 		no flags Details
device 5 (keyboard like events) results for evemu-record (33.55 KB, text/plain)
2015-12-24 08:27 UTC, David Timms 		no flags Details
View All

Description kamil 2015-12-09 17:10:23 UTC 
As in summary - When I checked while it was working, G600's (http://gaming.logitech.com/pl-pl/product/g600-mmo-gaming-mouse) side buttons were seen as a keyboard from xinput, and then, they worked. Now they are recognized as mouse buttons and cursor instantly goes to left side of screen when I click any normal mouse button which makes it unusable until I disable secondary "pointer". 

I am not sure on which version it started, but now I am on:
  local/xorg-server 1.18.0-3 (xorg)
  local/xorg-xinput 1.6.2-1 (xorg-apps xorg)
and problem is still present.

# xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳                                         	id=10	[slave  pointer  (2)]
⎜   ↳                                      	id=12	[slave  pointer  (2)]
⎜   ↳ Logitech Gaming Mouse G600              	id=13	[slave  pointer  (2)]
⎜   ↳ Logitech Gaming Mouse G600              	id=14	[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)]
    ↳                                        	id=8	[slave  keyboard (3)]
    ↳                                         	id=9	[slave  keyboard (3)]
    ↳                                           id=11	[slave  keyboard (3)]

there's a xorg.conf section template that fixes it by enforcing to see side buttons as keyboard ones. It's discussed here: https://bbs.archlinux.org/viewtopic.php?id=204830

It's possible that this is how xinput should see that mouse by default as it's not typical mouse and then it's not bug of course - but I am not sure what's expected behaviour of xinput when such device is present.
Comment 1 Peter Hutterer 2015-12-09 22:05:21 UTC 
record the device with evemu-record please and attach the output here. if there are multiple event nodes, please record all of them.
Comment 2 David Timms 2015-12-24 08:25:58 UTC 
Created attachment 120675 [details]
Logitech G600 Gaming Mouse - Event4 notated events

I have this occurring also with the same mouse on Fedora 23 x86_64.
Linux davidtnotebook 4.2.8-300.fc23.x86_64 #1 SMP Tue Dec 15 16:49:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

xorg-x11-drv-evdev-2.9.99-2.20150807git66c997886.fc23.x86_64
xorg-x11-server-common-1.18.0-2.fc23.x86_64
xorg-x11-xkb-utils-7.7-16.fc23.x86_64

I understand that in windows, there is a special driver and config util that let's you set what the G7-G20 buttons do.

Problem at the moment for me is that left, right, far right click also move the cursor to screen far-left and then click there. A click is never generated in the mouse cursor position.

The same mouse works OK on a 5 year old AMD machine on F22, in case that helps.
Comment 3 David Timms 2015-12-24 08:27:43 UTC 
Created attachment 120676 [details]
device 5 (keyboard like events) results for evemu-record

The following was needed on Fedora 23 to make the command available:
dnf -y install evemu
Comment 4 Peter Hutterer 2016-01-04 02:55:28 UTC 
what xorg driver are you using? evdev or libinput? have you tried the libinput driver?

for testing: run sudo evtest --grab /dev/input/event5 (i.e. the keyboard) and then click the button. This grabs the keyboard device and stops events from going to the X server - does this still reset the pointer then? I suspect the ABS_MISC events are messing things up here. Please also attach your Xorg.log
Comment 5 GitLab Migration User 2018-08-10 20:31:30 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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.freedesktop.org/xorg/app/xinput/issues/4.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.