Accessing more Buttons on a Mouse (Propeller)?
coryco2
Posts: 107
Hello,
Does anyone have any information on accessing the button states on mice with extra buttons with the Mouse object? I have been able to do the left/right scroll wheel and scroll click on every mouse I've tried, but all five buttons only on certain mice, but not others. Specifically, I would like to access the scroll wheel's tilt left/right buttons on a Logitech mouse. I can see these on a Labtec mouse (they show up as two high bits each--i.e. 01100 and 10100), but nothing on the Logitech, which is the mouse I'd like to use. Any suggestions?
Thanks!
Does anyone have any information on accessing the button states on mice with extra buttons with the Mouse object? I have been able to do the left/right scroll wheel and scroll click on every mouse I've tried, but all five buttons only on certain mice, but not others. Specifically, I would like to access the scroll wheel's tilt left/right buttons on a Logitech mouse. I can see these on a Labtec mouse (they show up as two high bits each--i.e. 01100 and 10100), but nothing on the Logitech, which is the mouse I'd like to use. Any suggestions?
Thanks!
Comments
How could one go about doing that, please? It is a PS/2 mouse, so I am guessing it is some type of serial signal, but I don't program in Propeller Assembly yet, so I don't understand the protocol involved or how exactly the Mouse object is acquiring the data. I am am just using the mouse.buttons method in Spin.
Is there a more detailed explanation of how the Mouse object works anywhere? Thanks again.
I am somewhat new to the Prop, but do have some experience in ASM language. If you are willing to be led by the blind, so to speak, read on.
Looking at mouse.spin, the ASM routine looks to be documented pretty well. The driver assumes the mouse is either a 'plain vanilla' mouse that sends 3 data bytes per (normal/streaming) transmission, or a more complicated one that sends 4 data byes per (normal/streaming) transmission. Your Logitech mouse that will not work is either:
a) not sending data as is expected (ie data in 3 or 4 bytes but not in the expected bitwise order)
b) sending data in more or less (doubtful) bytes per transmission (again, data not in expected format)
c) being mis-identified by the driver as a mouse with less buttons that is really has.
If I assume your Logitech mouse works EXCEPT for the 'scroll wheel's tilt left/right buttons' (which I am not really understanding what these are - sorry simple upbringing with not many bells and whistles ), I would believe that option 'c' is the best bet for what the problem is.
Being a simple guy, I would alter the ASM routine and "stuff" the '_present' parameter (which holds a different value, $1, $2 or $3, depending on the type of mouse detected) with a few different values and see if any of them make your mouse start working.
To do this, I would modify the initialize section of the code:
to this:
I changed the code that puts 'data' into the _present var to putting $3 into the_present var. If this doesn't work, you could try changing the $3 to a $2, but I think $3 is a more likely fix, if this is really the issue anyhow. If this is the issue, you will want to update the code so it is more robust (ie in case you did attach a 'plain vanilla' mouse), but this is a quick and dirty method to see if option 'c' really is the issue.
-h
The ASM part of mouse.spin goes through a kind of complicated loop of sending all sorts of different data rates to the mouse (used to tell the mouse what speed to send data at). Not being a mouse guru, I kind of ignored it because it just seemed random/weird to me, but now a reason for it has occurred to me - I think some mice might need a way for them to 'activate' their more advanced options, and if these advanced options are not activated, the mouse defaults to acting like a 'plain vanilla ' mouse. Why a mouse would not just have an 'activate advanced features' instruction I do not know, but the comments alongside the 'initialize mouse' section would seem to indicate this is what is being done. So option 'd' is:
d) Logitech mouse is not getting the instruction it needs to activate the advanced features (tilt function)
Anyhow, I would still try the hack I suggested in my earlier post, if that doesn't work you may need to find a better description of the protocol the Logitech mouse is using.....
Thanks very much for the suggestions. I did try them, but unfortunately, no joy.
A page related to the link Ale posted earlier does give some information on why mouse.spin is sending all the data rate code: http://www.computer-engineering.org/ps2mouse/
Under the Intellimouse section it explains how sending the data rates 200 200 80 is supposed to activate the extra buttons ( evidently what the object doc calls a "knock sequence"). And, as I said in the original post, it does seem to work with a Labtec mouse (and if it didn't have such a weak scroll wheel design that is prone to stick, I'd use the Labtec). But evidentally, as you suggest, the Logitech mouse needs some other magic word.
Any suggestions for where one might find protocols for Logitech mice? Googling it only seems to bring up old obsolete three button protocols Logitech used to use.
* - * an "extended sysmouse" protocol has been added to permit
* * * * the driver to send "tilt" data to the consumer, for use
* * * * in horizontal scrolling. *This extended protocol is not
* * * * used unless the consumer app asks for it (mode level 3).
* * * * Patches are available to allow the current Xorg mouse
* * * * driver to read this protocol and set the mode level on
* * * * open of the device. *Note that the existing ums driver
* * * * (at least the 7.0 one) and X mouse driver "handle" tilt
* * * * data, but are unable to communicate the data because
* * * * the protocol packetsize is too small; this establishes
* * * * a protocol by a new number which is nearly identical,
* * * * save for a larger packetsize and inclusion of the tilt
* * * * data.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html
http://www.logitech.com/en-us/mice-pointers/mice/devices/3879
I think the design is 2-3 years old now. Any info you can find would be much appreciated!
Thanks for looking; I appreciate it. It appears that the DDK has been superseded by the WDK? I'm not sure if this download http://www.microsoft.com/whdc/devtools/wdk/wdkpkg.mspx is freely available (seems to be), but it may be a bit deeper into Windows software development than I want to wade just to try to find the serial protocol for this mouse. What all is in these kits? Would it, for example, have plain English documentation for protocols for mice from other manufacturers? Or, as it says, would I need a "working knowledge of C" even to use it?
I did find a Logitech forum, though and posted a query there, too. I also found this info there:
Modern, complex mice and SUSE do not mix well. Buttons beyond 1 (left click), 2 (wheel click), 3 (right click, 4 (wheel forward), and 5 (wheel back) are usually ignored.
In SUSE 11.1 the problem is aggravated by the fact that the LX6 is seen as a Logitech Gaming Mouse instead of what it is.
...
Note the number reported by xev for each button pressed in each mouse:
Button pressed xev number LX6 xev number V220
Left Click 1 1
Scroll Wheel Click 2 2
Right Click 3 3
ScrollWheel Forward Roll 4 4
Scroll Wheel Back Roll 5 5
Left Horizontal Scroll 11 7
Right Horizontal scroll 12 6
That is it. As you can see, xev sees all 7 mouse button functions, but does NOT see any 6, 7, 8, 9, or 10 buttons in the LX6 and sees no 8 or 9 buttons in the V220.
Don't know if this is directly applicable to building a Spin/PASM driver or not, but it appears this mouse behaves as one with more than five buttons, though they don't physically all exist. Do you have any idea how mouse drivers for gaming mice (i.e. greater than 5 buttons) are structured? Are additional data packets used for the extra button data? I am assuming there would also be a different "knock sequence" sent to activate those buttons on the mouse as well?