From: Kim Holviala <kim@holviala.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice
Date: Wed, 27 Oct 2004 09:32:58 +0300 [thread overview]
Message-ID: <417F411A.4090401@holviala.com> (raw)
In-Reply-To: <20041027055059.GB1211@ucw.cz>
Vojtech Pavlik wrote:
>>>>This patch limits the scroll wheel movements to be either +1 or -1 on
>>>>the event -> emulated PS/2 level. I chose to implement it there because
>>>>mousedev emulates Microsoft mice but the real ones almoust never return
>>>>a bigger value than 1 (or -1).
>>>>...
>>>>+#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
>>>>+ if (value) { value = (value < 0 ? -1 : 1); }
>>>>+#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
>>>
>>>This is really not a thing which we can put behind compile-time config.
>>>
>>>Can we come up with a fix which works correctly on all hardware? If not,
>>>this workaround will need to be enabled by some sort of runtime detection.
>>>
>>
>>Unless someone (Vojtech?) has an objection I think we should always have
>>this workaround activated - after all mousedev provides legacy emulation
>>mostly for XFree/XOrg benefit anyway. Clients accessing data through evdev
>>will see the full picture regardless.
>
>
> We can have a workaround for XOrg, but not one like this. This will make
> fast scrolling unreliable. I have standard Microsoft-compatible mice
> which do report more than one scroll tick per report, if you scroll the
> wheel fast enough, and this throws away the extra ticks.
It wasn't an optimal solution, but just a quick hack that made the
scrollpoint usable. BTW, I've tried with about a dozen wheelmice and all
of them needed real misuse to get a packet where the scroll amount was
more than 1....
Not that I'm claiming that those kind of mice don't exist. They do, one
of them is this ScrollPoint that I'm using now.
> We would have to split the value into multiple events which would each
> report a 1 or -1.
That would be the right solution - I thought about it but deciced not to
steal any more of my employers time.... Besides, I needed to slow the
wheel/stick action down anyway since a light touch of the stick
generates insane scroll events. In Windows with the default driver the
stick operated like Home/End...
Kim
next prev parent reply other threads:[~2004-10-27 6:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 8:45 [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice Kim Holviala
2004-10-27 0:11 ` Andrew Morton
2004-10-27 0:33 ` Dmitry Torokhov
2004-10-27 5:51 ` Vojtech Pavlik
2004-10-27 6:29 ` Dmitry Torokhov
2004-10-27 6:32 ` Kim Holviala [this message]
2004-10-28 12:42 ` Kim Holviala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=417F411A.4090401@holviala.com \
--to=kim@holviala.com \
--cc=akpm@osdl.org \
--cc=dtor_core@ameritech.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.