Shop OBEX P1 Docs P2 Docs Learn Events
Accessing more Buttons on a Mouse (Propeller)? — Parallax Forums

Accessing more Buttons on a Mouse (Propeller)?

coryco2coryco2 Posts: 107
edited 2011-01-28 17:25 in Propeller 1
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!

Comments

  • AleAle Posts: 2,363
    edited 2011-01-19 06:17
    Assuming it is a PS/2 mouse... I'd monitor the DATA signal and decode what it returns when the buttons are pressed/released and then add a bit of code to the mouse object so it returns such actions along with the rest...
  • coryco2coryco2 Posts: 107
    edited 2011-01-19 16:03
    Thanks for the reply, Ale.

    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.
  • AleAle Posts: 2,363
    edited 2011-01-20 00:47
    Well... there is the PS/2 protocol for one http://www.computer-engineering.org/ps2protocol/, and the propeller is sampling the data line on every fall of the clock line. The clock is produced by the device. There are several PS/2 objects maybe one of them has a bit more information on the workings. Unless someone collaborates and adds those buttons... you may have to learn PASM. There is nothing better than a good goal to learn the skills needed to achieve it because the driving force is there :). To test assembler I always recommend my own simulator, it has built-in editor so you do not need a propeller or proptool or BST. pPropellerSim
  • homosapienhomosapien Posts: 147
    edited 2011-01-20 07:47
    Cory,

    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:
    ' Initialize mouse
    '
    init                    call    #receive                '$AA received, receive id
    
                            movs    crate,#100              'try to enable 3-button scrollwheel type
                            call    #checktype
                            movs    crate,#200              'try to enable 5-button scrollwheel type
                            call    #checktype
                            shr     data,#1                 'if neither, 3-button type
                            add     data,#1
                            mov     _present,data
    
                            movs    srate,#200              'set 200 samples per second
                            call    #setrate
    
                            mov     data,#$F4               'enable data reporting
                            call    #transmit
    
                            jmp     #update
    


    to this:
    ' Initialize mouse
    '
    init                    call    #receive                '$AA received, receive id
    
                            movs    crate,#100              'try to enable 3-button scrollwheel type
                            call    #checktype
                            movs    crate,#200              'try to enable 5-button scrollwheel type
                            call    #checktype
                            shr     data,#1                 'if neither, 3-button type
                            add     data,#1
                            
                            mov     _present,#3   'IT"S UGLY, BUT IT DOES THE JOB
    
                            movs    srate,#200              'set 200 samples per second
                            call    #setrate
    
                            mov     data,#$F4               'enable data reporting
                            call    #transmit
    

    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
  • homosapienhomosapien Posts: 147
    edited 2011-01-20 08:13
    Thinking about this issue, I just came up with an option 'd' as to why the mouse is not working.

    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.....
  • coryco2coryco2 Posts: 107
    edited 2011-01-27 16:51
    homosapien,

    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.
  • coryco2coryco2 Posts: 107
    edited 2011-01-27 17:31
    I found this, which seems to suggest a larger packet--an extra byte?-- and a "mode 3" for the tilt function. Perhaps the tilt is regarded as button 6 and 7? But how to activate the mode, and how to modify the driver to capture the extra data?

    * - * 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.
  • coryco2coryco2 Posts: 107
    edited 2011-01-27 17:59
    Closer...appears to be a "magic knock" for something called P/S2++

    http://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html
  • coryco2coryco2 Posts: 107
    edited 2011-01-28 13:37
    Thanks! This is the mouse, a Logitech LX6:

    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!
  • coryco2coryco2 Posts: 107
    edited 2011-01-28 17:25
    Bruce,

    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?
Sign In or Register to comment.