-
Notifications
You must be signed in to change notification settings - Fork 14
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
L4/R4 and trackpad for GPD Win Mini #157
Comments
We're going to need some packet captures of the hid reports in action for the touchpad and back buttons. On arch Linux you can install the First we'll need the report descriptor for each device After that we'll need a udev attribute walk for each device Finally, an InputPlumber/src/drivers/lego/hid_report.rs Lines 33 to 35 in 1f2ad00
We need all that data so we can interpret it properly. For the back paddles, one capture where left is the only button pressed, one with right only, one with both where left is pressed first, and one with both where right is pressed first For the touchpad, one each with a single touch in each corner, and one with as many touches as it will detect. And for good measure one of each with nothing happening. The keyboard will be easy to add, but I don't recommend it unless there is a specific thing you want to translate on it. For gyro I just need the name. You should be able to use |
So just as some additional context, the L4/R4 on GPD devices are actually macro buttons that repeat an up to 3-key macro at a regular interval. This is built into the firmware, there's no way to turn them into simple buttons. HHD had to do some hacky logic to make the buttons pretend to be L4/R4 buttons that can support hold actions, and as a side effect of the hacky workaround, there's very noticeable latency when it comes to detecting when the button is released. You can see the hhd implementation here edit: here's a video recording on the Chimera discord of the L4/R4 button behavior |
It looks like the back buttons are hidraw1 and the trackpad is hidraw3.
Gyro is i2c-BMI0160:00 (but is actually a 260) |
I haven't forgotten about this, I've just been preoccupied with the ROG Ally X and some things I had to do for OrangePi. I'll try to take a look at this sometime this week. |
@justinweiss the timing for the back paddle events seems... sporadic. Its almost like they are randomly coming in between 0.02s and 0.3s. Can you confirm if there is a consistent delay when holding, and the delay from the last event is different in any way? It looks as though I will need to set a "Last event" timer that resets for every event received and is longer than the maximum observed delay between events when held. That won't be very difficult, but I'd like to ensure that delay is as low as is reasonable with a 10% margin to prevent erroneous up events. |
As for the trackpad, many of them support up to 10 fingers but used 4 inputs per report, and swap the index around as needed to report each to the kernel. We generally add this overhead to every touchpad device. Does this touchpad have a button BTW? Also, where is it physically located? |
Not a problem at all! Thanks for taking a look. There's no button on the touchpad and it doesn't depress, which is why having a tap is important :-) No other way to get a click. The touchpad is in the top center, between the sets of controls: Here's a longer capture: I held R4 for around 5 seconds, then released for about 5 seconds, then held for about 10 seconds, then released. It looks like it sends Pause for around 300ms and then releases for around 20ms, and repeats for as long as it's being held down. It's hard to tell whether the delay from the last event is different, but it seems like it always waits the full 300ms before sending the release event when you release the button. (I have not changed the mappings, and I think it's reasonable to only support the default mappings) |
This helps, thanks. Might take some time tuning but if you should get a new down event for the key in question within 20ms we should be able to use that as the trigger for the fastest response time. I think double hold might make this longer but we can test that. We actually already do something like this for touchpads to determine if a press is still being held or not so the logic is simple. |
I couldn't get L4/R4 on the GPD Win Mini to respond as paddles on "Test Device Inputs" in Steam, and I couldn't map them to anything with a yaml config.. They also don't show in the InputPlumber logs when pressed. I can see the GPD Win Mini recognized from the InputPlumber logs.
I verified that
usb-0000:63:00.3-3/input1
sends KEY_SYSRQ and KEY_PAUSE for the physical L4/R4 buttons. They act as a key repeat instead of a single press, hold, release though.I also noticed that the trackpad and physical keyboard aren't in the composite device config. The trackpad doesn't have a physical click, and gamescope-session doesn't support tap-to-click, so it would be perfect if inputplumber could map or handle a tap as a physical click.
the physical touchpad on the Win Mini is
and the physical keyboard is
Ultimately my goal would be to create a config that would map trackpad with simulated click, L4/R4, buttons, and gyro all to a simulated DS5 or Steam Deck controller, so I could use it all with Steam Input.
Happy to help collect data or try things.
The text was updated successfully, but these errors were encountered: