Anbernic Win600 Buttons Not Working

[Ponjen]

This issue report originated from ChimeraOS, but was told to report here as well (ChimeraOS/chimeraos#1003)

For the Anbernic Win600, the Home, Windows Key button (Quick Access), and keyboard button don't work. Even trying to manually map them in the controller configuration doesn't work, as Steam doesn't recognize them. Volume keys and power tap to sleep works.

[fewtarius]

The Win600 does not correctly emulate an Xbox controller, minimally the xpad driver needs to be patched.

See this repo for reference: https://github.com/lualiliu/holoiso-win600-driver

[murilo-moraes]

Same issue here for my Win600. Were you able to patch the xpad driver? Here the build folder for kernel modules is missing.

[pastaq]

The Win600 does not correctly emulate an Xbox controller, minimally the xpad driver needs to be patched.

See this repo for reference: https://github.com/lualiliu/holoiso-win600-driver

This is new information to me. I thought the custom anbernic driver was just to grab one of the buttons as home. Does using the udev rule for a new xpad device not work?

[uejji]

#186 will hopefully help with this. Needs more work to be fully supported, though.

[pastaq]

What specifically is not working with that patch applied?

[Ponjen]

What specifically is not working with that patch applied?

Doesn't seem possible to install the patch on ChimeraOS, at least not as a typical user. It's due to the read only file system, and I can't find any info of a command to disable it like SteamOS.

[uejji]

What specifically is not working with that patch applied?

Let's consider the following capability map I've worked up for Win600 for testing (not with Lualiliu's patch):

# Schema version number
version: 1

# The type of configuration schema
kind: CapabilityMap

# Name for the device event map
name: Anbernic Type 1

# Unique identifier of the capability mapping
id: anb1

# List of mapped events that are activated by a specific set of activation keys.
mapping:
  - name: Home (Short Press)
    source_events:
      - keyboard: KeyLeftMeta
      - keyboard: KeyG
    target_event:
      gamepad:
        button: Guide
  - name: Home (Long Press)
    source_events:
      - keyboard: KeyEsc
    target_event:
      gamepad:
        button: QuickAccess
  - name: Keyboard
    source_events:
      - keyboard: KeyO
      - keyboard: KeyLeftMeta
      - keyboard: KeyLeftCtrl
    target_event:
      gamepad:
        button: Keyboard
  - name: Windows
    source_events:
      - keyboard: KeyLeftMeta
    target_event:
      gamepad:
        button: QuickAccess
  - name: Windows (Long Press)
    source_events:
      - keyboard: KeyEsc
      - keyboard: KeyLeftShift
      - keyboard: KeyLeftCtrl
    target_event:
      gamepad:
        button: QuickAccess2

# List of events to filter from the source devices
filtered_events: []

With this map you would expect Home to trigger the Guide button, long pressing Home to trigger Guide+A, Keyboard to trigger Guide+X, Win to trigger Guide+A and long pressing Win to trigger Guide+B.

But here's what actually happens:
Home: Guide+A
Home (Long press): Guide+A
Keyboard: Guide+X+A
Win: Guide+A
Win (Long press): Guide+A+B

Everything is hitting Guide+A in addition to whatever button or chord they're supposed to trigger. I suspect this is related to the Win key, because if I comment its entire section out, the following happens:

Home: Guide
Home (Long press): Guide+A
Keyboard: Guide+X
Win: Nothing
Win (Long press): Guide+A+B

I'm not actually sure what QuickAccess2 is used for, but I wanted to test it anyway. I'm not sure if that's the correct chord for it.

Lualiliu's patch, as brilliant as it is, doesn't really help with this issue, unless it were to be reconfigured to send alternate keyboard keys so InputPlumber can manage it.

I wonder if it's related to how InputPlumber is managing the Meta key, but I'm very unfamiliar with Rust, and so this is just a supposition, not an accusation.

[uejji]

Based on my conversation with @pastaq yesterday, I wanted to summarize what exactly seems to be the issue with the Win600 and InputPlumber.

InputPlumber doesn't seem to properly handle when one source event is a subset of another source event. E.g. Win600 home long press sends an Esc key command, and Windows long press sends Shift+Ctrl+Esc key command. This leads to InputPlumber recognizing the Windows long press as both a Windows long press (triggering on shift+ctrl+esc) and a home long press (triggering on esc). This conflict also happens between Windows short press (Meta), Home short press (Meta+G) and Keyboard press (Ctrl+Meta+O) with InputPlumber recognizing both Home short press and Keyboard press as also a Windows short press (due to triggering on Meta).

My submitted capability map kind of awkwardly sidesteps the issue for now, but it's not perfect.

[pastaq]

I have an idea of how we can handle this situation, but it might take some work and it will add complexity to an already fairly complicated portion of the code. The basic idea would be to do an analysis of all the source events in a capability map to check if any one mappings source events are a subset of any other. If they are we have two ways to handle it.
1.) When a full match is found that is a subset of another, queue its event to be emmited after a specific delay. If no other events come in that time, fire the event. If another event does come in that time, cancel it. This logic would also need to account for the difference between up/down events so it's own up events won't cancel it.

2.) When a full match is found that is a subset of another, block the event from being emmited. Instead, wait for the up event to occur and queue both the down and up events. This logic is easier to accomplish but doesn't permit long press holding for the affected button. In the case of the win button here that doesn't matter, but that will matter for the AYANEO 2021 which also has a win button and some macros that use win.

I'm leaning towards option 1 as that has the best user experience.

[uejji]

Fixed by #186

[pastaq]

I'll leave this open for now until we add a way to do partial match events