search

DanielOgorchock / joycond

userspace daemon to combine joy-cons from the hid-nintendo kernel driver
GNU General Public License v3.0
340 stars 68 forks source link

Set Combined Joycons' player LED status #49

Closed joaorb64 closed 3 years ago

joaorb64 commented 3 years ago

Possible solution to both https://github.com/DanielOgorchock/joycond/issues/48 and https://github.com/joaorb64/joycond-cemuhook/issues/27

evdev has set LED codes, so the virtual device mappings end up showing up as LED_NUML, LED_CAPSL, LED_SCROLLL, and LED_COMPOSE, but their codes are 0, 1, 2, and 3.

evtest displays:

Event type 17 (EV_LED)
    Event code 0 (LED_NUML) state 1
    Event code 1 (LED_CAPSL) state 0
    Event code 2 (LED_SCROLLL) state 0
    Event code 3 (LED_COMPOSE) state 0

while /sys/class/input/inputX has:

inputX::numlock/brightness
inputX::capslock/brightness
inputX::scrolllock/brightness
inputX::compose/brightness

I'm not sure if this is the best possible way to do this or if this is too much of a stretch, but this is what I could come up with.

joaorb64 commented 3 years ago

I tried running joycond-cemuhook as sudo to play with the Home LED and had another idea, actually. The individual joycons are accessible for sudo all the time and they have correct LED status. I could actually go by this route without these changes to joycond.

Edit: https://github.com/joaorb64/joycond-cemuhook/issues/27#issuecomment-755902069

DanielOgorchock commented 3 years ago

Looks cool, thanks! The only thing I can see as potentially problematic is if someone/something else decides to set the player LEDs. Shouldn't happen in practice for people just using the typical hid-nintendo->joycond->joycond-cemuhook stack. If they ever add uniq support to uinput, I guess we can change to using that for more robustness.