-
Notifications
You must be signed in to change notification settings - Fork 11
Mouse pointer position is not repeatable #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi again Maximilian I was hoping to be able to control the mouse accurately via a python script, to place the mouse in the same position each time. Ideally I need an absolute co-ordinate device rather than a relative one, so I tried altering the HID hex value in sdp_record.xml, changing 0x8106 to 0x8102, to see if it would change the relative position to an absolute position, but it did not work. I guess there is more to change in the HID descriptor. The change made no difference at all though, which surprised me. I thought it would break things but it just worked as before. Would you happen to have a HID descriptor for an absolute pointer device, like a Wacom touch pad or anything similar that uses absolute position coordinates rather than relative motion? I would like to send the value (100, 100) and have the pointer go to that absolute position on the screen, rather than move by 100 in the x and y direction. Thanks in advance Will |
Hi again I found a Wacom tablet at home and pasted its HID descriptor below. Will it just work if I use it in sdp_record.xml or are code changes required too? $ sudo usbhid-dump -s 001:005 $ sudo lsusb -s 001:005 -v Bus 001 Device 005: ID 056a:0374 Wacom Co., Ltd CTL-4100 [Intuos (S)] |
The whole HID descriptor is only real testable with the device in hand. I am not an expert is this domain. This was just a hobby project and I did some reading. To test HID descriptor changes you need to remove rpi-kvm from your pc‘s Bluetooth devices. The descriptor is saved on the clients machine and then always used. To update / test modifications you need to completely remove and reestablish the connection. I think the code needs adjustments to support absolute values. The hid descriptor describes the usb messages send to the client and the representation of the bytes. I don’t know if additional information needs to be send for absolute pointer devises. |
Thank you very much for your reply and the information, it’s very much appreciated. I will have to look into it and research it some more. Thanks again. :) Will |
As mentioned, mice operate in relative positioning mode while some touch pads, most touchscreens, and most graphics tablets operate in absolute positioning mode. The other thing to keep in mind is there are times even with a locally attached input device that the kernel will drop events it receives too quickly in order to keep the rest of the system responsive, as soon as you introduce any kind of hop whether via a wired connection over USB or ethernet or wireless via Wi-Fi or Bluetooth that introduces some extra latency as well as the potential for other buffers and congestion control to drop things. If you check out iSticktoit.net there's a good post on the Raspberry Pi gadget mode composite functionality where you can have the Raspberry Pi act as a keyboard and mouse and there are some descriptors for the HID capabilities there. |
Hi Maximilian
I have noticed that moving the mouse in a perfect square repeatedly does not result in the pointer drawing the same square repeatedly. The square can drift left, right, up or down. I checked this by using a grid as the wallpaper on my phone and moving the mouse by hand in a constrained square boundary.
I was pretty sure it was drifting, but to be sure, I modified mouse.py to draw a "square" over and over on the screen. For example, I moved the mouse pointer right by 100 five times, then down by 100 five times, then left by 100 five times, then up by 100 five times, over and over. The square being drawn by the mouse pointer drifted across and down the screen, in a jerky manner. I was expecting the square to remain in the same place and not move at all.
Is this expected behaviour? If so, why?
Thanks in advance
Will
The text was updated successfully, but these errors were encountered: