Bug 29905 - acceleration for mouse wheel
Summary: acceleration for mouse wheel
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
Whiteboard: 2012BRB_Reviewed
Keywords: patch
Depends on:
Reported: 2010-08-31 06:15 UTC by Albert Zeyer
Modified: 2016-09-24 08:13 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:

mouse wheel acceleration patch - rev1 (16.53 KB, patch)
2010-09-01 20:40 UTC, Albert Zeyer
no flags Details | Splinter Review
mouse wheel acceleration patch - rev2 (16.64 KB, patch)
2010-09-02 09:05 UTC, Albert Zeyer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Zeyer 2010-08-31 06:15:03 UTC
It would be nice to have acceleration for the mouse wheel.

Report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/meta-kde/+bug/619403
Comment 1 Albert Zeyer 2010-08-31 06:31:11 UTC
I am trying right now to implement this myself.

As I am not that used to the Xorg sources, this is what I want to do in xf86-input-mouse:

* Add some attributes in the _MouseDevRec struct (in fx86OSmouse.h) which are about the acceleration properties.
* In MouseCommonOptions in mouse.c, I am adding some additional handling to read those acceleration attributes.
* At some point in the input handling in mouse.c, add that acceleration handling (at what point exactly?). I plan to just throw out multiple button 4,5 press events.

Please give some comments about how to do it right.
Comment 2 Albert Zeyer 2010-08-31 06:35:14 UTC
Or probably it is better to add those properties to mousePrivRec (in mousePriv.h).
Comment 3 Julien Cristau 2010-08-31 06:36:33 UTC
As far as X is concerned mouse wheel is a couple of buttons, so I'm not sure what acceleration would mean there.  This sounds like it should be implemented in clients.  In any case moving to evdev as you probably don't want to be doing that in the mouse driver anyway.
Comment 4 Albert Zeyer 2010-09-01 20:29:37 UTC
Ok, I am in the middle of a progress here. I am trying to optimise it a bit further. But I will attach my current progress so far so you can review it and give some comments because I actually have the problem that sometimes (mostly after I restart xinit on a running Xserver), somehow the device property names are messed up or at least xinput shows this:

az@acompneu 1275 (~) %xinput list-props 8
Device 'Microsoft Microsoft IntelliMouse® Explorer':
	NumLock (119):	1
	left_ptr (241):		... of unknown type _DBUS_SESSION_BUS_SELECTION_az_9797c07820e7488abd822c644c1f55a4

	KDE_FULL_SESSION (245):		... of unknown type _DBUS_SESSION_BUS_SELECTION_az_9797c07820e7488abd822c644c1f55a4

	KDE_SESSION_VERSION (246):		... of unknown type _DBUS_SESSION_BUS_SELECTION_az_9797c07820e7488abd822c644c1f55a4

	WM_PROTOCOLS (247):		... of unknown type _DBUS_SESSION_BUS_SELECTION_az_9797c07820e7488abd822c644c1f55a4

	Evdev Reopen Attempts (226):	10
	Evdev Axis Inversion (227):	0, 0
	Evdev Axes Swap (229):	0
	_NET_WM_CONTEXT_HELP (251):	"LevelFive" (127), "AltGr" (128)
	_NET_WM_SYNC_REQUEST (252):	"Alt" (120), "LevelThree" (121), "LAlt" (122), "RAlt" (123), "RControl" (124), "LControl" (125), "ScrollLock" (126), "_KDE_SPLASH_PROGRESS" (239), "WM_LOCALE_NAME" (240), "_XKB_RULES_NAMES" (238), "_XKB_RULES_NAMES" (238), "_XKB_RULES_NAMES" (238), "_XKB_RULES_NAMES" (238)
	Evdev Middle Button Emulation (230):	2
	Evdev Middle Button Timeout (231):	50
	Evdev Wheel Emulation (232):	0
	Evdev Wheel Emulation Axes (233):	0, 0, 4, 5
	Evdev Wheel Emulation Inertia (234):	10
	Evdev Wheel Emulation Timeout (235):	200
	Evdev Wheel Emulation Button (236):	4
	Evdev Drag Lock Buttons (237):	0

It looks a lot like some memory is messed up. I already tried to debug with valgrind but I didn't see anything related (a whole bunch of other messages show up there, so I also might have missed it).

Another thing which makes the debuggin a bit complicated: Most applications seem to scroll already for one event by multiple pixel; about 20 pixel in Chrome. And I have set it to the minimum possible value in the KDE settings (not sure if Chrome takes those or has its own settings). That makes the debugging quite hard because the scrolling is soon pretty much too fast.
Comment 5 Albert Zeyer 2010-09-01 20:40:33 UTC
Created attachment 38377 [details] [review]
mouse wheel acceleration patch - rev1
Comment 6 Denis Dzyubenko 2010-09-02 04:58:53 UTC
just added me to the CC. Sounds like a good idea to have acceleration.
Comment 7 Albert Zeyer 2010-09-02 06:57:26 UTC
Comment on attachment 38377 [details] [review]
mouse wheel acceleration patch - rev1

Note that this patch is already outdated. I have posted a new version to the mailinglist. I am not sure if I will keep updating the patch also here, so please watch out for the patch on the mailinglist.
Comment 8 Albert Zeyer 2010-09-02 08:49:48 UTC
good values to play with: speed-multiplier: 100, max-speed: 20
Comment 9 Albert Zeyer 2010-09-02 09:05:40 UTC
Created attachment 38386 [details] [review]
mouse wheel acceleration patch - rev2
Comment 10 Jeremy Huddleston Sequoia 2011-10-09 03:57:54 UTC
Can you please send your patches to xorg-devel for review.  Please rebase them 
on top of current git master if appropriate.  Thanks.
Comment 11 erick 2012-02-07 15:40:33 UTC
Don't work for xorg-server-1.11.4 :( Please fix it.
Comment 12 Claudius Ellsel 2016-09-23 11:44:46 UTC
Any updates on this?
Comment 13 Peter Hutterer 2016-09-23 12:20:38 UTC
i guess the only update is a WONTFIX, given that this has been languishing for 6 years now. input stuff like this is moving to libinput anyway, and I don't think I'll implement mouse wheel acceleration there either.
Comment 14 Claudius Ellsel 2016-09-24 08:13:28 UTC
Alright. It is a bit sad though that apparently no developer seems to be interested in making Linux competitive with the two other big operating systems in this case.

bug/show.html.tmpl processed on Dec 08, 2016 at 23:57:39.
(provided by the Example extension).