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.
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?
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....
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.
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.
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....
True with RC2 of 7.2 as well....
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.
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.
Created attachment 45117 [details] old working config
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.
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.
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?
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.
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.