Bug 33147 - Serial ThinkingMouse support doesnt work
Serial ThinkingMouse support doesnt work
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-25 19:53 EST by Chris Ricker
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-30 03:37:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
old working config (14.49 KB, text/plain)
2002-02-09 18:31 EST, Chris Ricker
no flags Details

  None (edit)
Description Chris Ricker 2001-03-25 19:53:24 EST
I'm running qa0322.

Serial ThinkingMouse support in XFree86 4 doesn't work.  Whether I use
ThinkingMouse or Auto as the protocol, the mouse is only recognized as
having two distinct buttons.  Playing with the Buttons option doesn't help.
Comment 1 Mike A. Harris 2001-04-02 08:36:37 EDT
Check out the XFree86 mouse manpage:

man -a mouse

THere is more than one page that will come up, when the right one is
there, try out various options listed there for your mouse.  Try different
drivers, button options, etc.

Also, be sure you're using the latest XFree86 4.0.3-5

Does any of the drivers and/or options fix it for you?
Comment 2 Chris Ricker 2001-04-02 09:33:41 EDT
Trust me, I've long since tried all those.  None of them work.  Here's the
canonical list of attempts with 4.0.3-5:

Protocol    "ThinkingMouse"
result:  2 unique buttons, cut-n-paste doesn't work

Protocol    "ThinkingMouse"
Buttons     "4"
result:  2 unique buttons, cut-n-paste doesn't work

Protocol    "ThinkingMouse"
Buttons     "4"
Emulate3Buttons "yes"
result: 2 unique buttons, can chord for 3rd to get cut-n-paste

All attempts at Protocol "Auto" fail miserably with inability to determine which
mouse it is:

(**) Mouse0: Protocol: "Auto"
(**) Mouse0: Core Pointer
(==) Mouse0: Buttons: 3
(II) Keyboard "Keyboard0" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(EE) Mouse0: cannot determine the mouse protocol

So far, the best I can do is setting protocol to ThinkingMouse, forcing 4
buttons, and turning on 3 button emulation.  That still only gives me 2 of the
four buttons, and it means I have to chord to paste, but it at least makes X
slightly usable.

This is a major regression in the serial ThinkingMouse driver from previous
versions.  Prior behavior in earlier RH releases was that I could set buttons to
4, leave out 3-button emulation, and set protocol to either auto or thinking
mouse, and then get all four buttons under X.  When I flipped to a VC and then
back into X, I would sometimes loose the 3rd and 4th buttons, but that was the
only bug I noticed there....
Comment 3 Mike A. Harris 2001-05-07 09:54:08 EDT
If this is the case, it is a general XFree86 bug, not specific to our
packages.  I will check the trunk code for possible bug fixes.
Comment 4 Chris Ricker 2001-08-15 14:53:22 EDT
Here's the sad state of affairs regarding RH 7.2 betas and the serial Thinking
Mouse.  It's on a machine with a G400, so I've been tracking the latest XFree86
4.1 RPMS.

By default, RH creates a config with:

Default does:

        Option      "Protocol" "ThinkingMouse"
        Option      "Device" "/dev/ttyS0"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"

this makes it a two-button mouse with chord for third button.  The ZAxisMapping
stuff is brain-dead, but doesn't actually hurt anything.  The Emulate3Buttons is
also brain-dead in theory (it's a 4-button mouse, and X supports all 4 buttons).

Changing that to just

        Option      "Protocol" "ThinkingMouse"
        Option      "Device" "/dev/ttyS0"

should fix things.  In theory, that will make it have four distinct buttons.  In
RH's X RPMS, this instead makes it acts like a two-button mouse with no third
button option.

Changing that to just

        Option      "Protocol" "Auto"
        Option      "Device" "/dev/ttyS0"

should work as well, and give 4 unique buttons.  With RH's X RPMS, however, Auto
support is extremely erratic.  If the system is cold-booted, gpm is never
started, and X is started with auto support, it will never find the mouse and
the mouse will just not work at all (ie, no cursor movement).  If it is
cold-booted, gpm is never started, X is started with ThinkingMouse support, X is
killed, and then X is re-started with Auto support, then X will correctly detect
the mouse and enable all 4 buttons.  However, the mouse support will then be
very fragile -- flipping to a VC and back will always convert it back to a
two-button mouse, and will often kill the mouse altogether (no cursor movement,
no buttons).


All of this is a regression from RH 6.x days, which is the last time this mouse
was reliably and correctly supported by RH.
Comment 5 Chris Ricker 2001-08-21 02:56:19 EDT
Still true with RC1 of the RH 7.2 betas.  RH simply doesn't ship an X which
works with the Kensington Thinking Mouse, even though XFree86 does....
Comment 6 Chris Ricker 2001-09-05 13:45:58 EDT
True with RC2 of 7.2 as well....
Comment 7 Mike A. Harris 2001-10-31 21:44:42 EST
The mouse code in Red Hat XFree86 is not modified.  It is possible that
the mouse is not properly configured by Xconfigurator et al. however,
if given a proper configuration, this mouse should work, if it works
with any other XFree86 release of 4.1.0.

I consider this purely a configuration problem.  Since I do not have,
nor have access to this piece of hardware, I need you, or someone who
does have access to it, to provide a working XF86Config-4 file that
makes this mouse work properly.  In general, in Linux, mice are not
auto detectable very well at all.

I would very much like to fix this for you, but it will require a
working configuration, or hardware to work with.

Comment 8 Mike A. Harris 2002-02-08 20:34:02 EST
Unable to look into this due to lack of hardware, and lack of adequate
information to troubleshoot.  Please report this bug to XFree86.org
if it is a general XFree86 bug, or provide me with a configuration
file that works with this mouse if it is just a configuration error
caused by our tools.

You indicate that XFree86.org ships working support for this mouse,
and our mouse support is unchanged from upstream, so whatever configuration
works for the upstream X should work with our X as well.  If not, then
I will require detailed info in order to debug this, and I cannot proceed
without it.
Comment 9 Chris Ricker 2002-02-09 18:31:14 EST
Created attachment 45117 [details]
old working config
Comment 10 Chris Ricker 2002-02-09 18:35:15 EST
I just attached an old, working, autogenerated config from RH 6.x days.  It's
for XFree86 3 -- RH's XFree86 4 packages have never seemed to do well with
thinking mice (though I know you say nothing's changed vis-a-vis mice from
upstream, last time I tried this mouse with Debian's XFree86 4, it did work
there using a config which doesn't work on RH).

Just leave this needinfo for now.  I'll try the mouse with the XFree86 4.2 that
I presume is in hampton beta1 and see if it's finally working.
Comment 11 Mike A. Harris 2002-02-09 19:32:10 EST
Ok, we seem to have a problem here.  This bug was filed against
RHL 7.1, and needlessly marked "beta team only".  There was absolutely
nothing in the bug report that pertained to being a beta team only
bug, and so I removed the beta team only flag.

Now you've put the flag back, and have purposefully included NDA
terms into the report to force me to not unmark it again.  This is
absolutely childish behaviour that is totally unnecessary.

Also, I dont like your attitude in bug reports as of late.  You seem
to have a personal issue with me.  THis sort of crap does nothing
whatsoever to improve the quality of Red Hat Linux, nor make my
job easier.

If you're going to play mind games, dont bother reporting bugs.
Comment 12 Chris Ricker 2002-02-09 20:52:06 EST
Mike, grow up!

Some basic points:

* I honestly don't have an issue with you.  I'm not trying to be a jerk.  I'd
just like for my hardware, which RH formerly supported and still claims to
support, to work with RH.
* I didn't re-mark this bug as RH Beta.  When I responded to it, it was
*already* marked that way.  Maybe you meant to change that, but didn't?
* The bug was originally filed against qa0322, as you'll see if you bother to
read it.  As such, it should have (and was) originally filed Beta Program only.
* I didn't "deliberately and childishly" include NDA info.  The basic state of
affairs is that RH has had a regression in hardware support ever since XFree86 4
shipped.  You can't / won't fix that, stating that it's an upstream problem. 
Fine.  All I can do now is hope that upstream fixes RH's regression.  So how,
pray tell, should I state that I plan on testing the upstream 4.2 release to see
if it fixes the regression, w/o invoking NDA on the fact that (I think) the
beta1 tree contains the 4.2 release?

Frankly, I'm a little frustrated.  You seem more willing to label my concerns as
personal attacks on you than to address them....

Let's start over from the beginning.  I have a serial Thinking Mouse.  It
doesn't work correctly with RH 7.1 beta or anything later, although XFree86
claims it should and prior releases of RH did correctly support it.  What
information do I need to give you to get this regression fixed and my mouse working?
Comment 13 Mike A. Harris 2002-02-09 21:15:56 EST
That sort of attitude is not a way to get me to listen to you at all.
I enjoy what I do, and when someone makes it unenjoyable, then I spend
my time working on one of the other areas that is more enjoyable and
affects the most amount of users.  There's one bug report against
this piece of hardware - yours.  Our sources are not modified from
XFree86 sources for this driver, it is _THAT_ simple.

Therefore, I require the hardware in order to trouble shoot it, you
can play with the bug report settings all you like.  That isn't going
to change anything.  When I've got a ThinkingMouse on my desk in front
of me, plugged into my computer that doesn't work, then I can begin
debugging.

Pulling an attitude with me, is not going to solve squat.

Bug deferred until direct access to hardware is obtained.
Comment 14 Mike A. Harris 2002-05-30 03:38:40 EDT
The situation is unlikely to change with respect to access to hardware,
so this is unlikely to be fixed unless someone else who has the hardware,
fixes things, and provides a patch that is sensible and sane.

Closing as WONTFIX.  Feel free to reopen with supplied fix.

Note You need to log in before you can comment on or make changes to this bug.