Skip to content
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

Ignore nonexistent /sys/class/leds/*/device/uevent in find_device_hardware_id #39

Merged
merged 1 commit into from Aug 11, 2020

Conversation

sainsaar
Copy link
Contributor

On a recent Raspberry Pi, "/sys/class/leds/default-on/device/uevent"
does not exist. Instead of failing with an exception, ignore it and
carry on.

…dware_id

On a recent Raspberry Pi, "/sys/class/leds/default-on/device/uevent"
does not exist. Instead of failing with an exception, ignore it and
carry on.
@tomoinn
Copy link
Member

tomoinn commented Aug 11, 2020

This is a strange one - do you have the exception trace and a bit more info about what you were doing to trigger it? I'd like to check that silently ignoring this doesn't cause problems somewhere else.

@sainsaar
Copy link
Contributor Author

Unfortunately I don't have access to the device at the moment, and I don't have the exact exception traceback saved anywhere.

I had a PlayStation 4 controller (DualShock 4) connected to a Raspberry Pi 4 Model B Rev 1.2 over bluetooth. The operating system was a recent Raspbian with kernel 5.4.51-v7l+. I paired the controller using bluetoothctl's commands "scan on", "pair ...", "connect ..." and "trust ...". Under /sys/class/leds the controller's leds were then all available and controllable. But there was also /sys/class/leds/default-on whose "device" directory had no "uevent". I suppose this represents a non-controllable LED...

Anyway, with my change, I could successfully control the controller's LED. My test code follows.

# The following three lines enable me to use a local copy of the approxeng.input library under lib/approxeng/input
#import os
#import sys
#sys.path.insert(0, os.path.join(os.path.dirname(os.path.abspath(__file__)), 'lib'))

import approxeng.input.controllers as ai_controllers
import approxeng.input.selectbinder as ai_selectbinder
import approxeng.input.dualshock4 as ai_dualshock4

def connect_ps4_controller():
    requirements = ai_controllers.ControllerRequirement(require_class=ai_dualshock4.DualShock4)
    return ai_selectbinder.ControllerResource(requirements)

with connect_ps4_controller() as ps:
    ps.set_leds(0.6, 1, 0.1)

@tomoinn
Copy link
Member

tomoinn commented Aug 11, 2020

Ah, yup. Hadn't looked at this code in a while - it's being triggered when the scan for all hardware happens, and as you say it's failing when it finds an LED that doesn't have a corresponding uevent. The code's looking for all LEDs and trying to match them up with controller instances, but when it hits this one it errors out. PR looks good, will merge.

@tomoinn tomoinn merged commit 68694bf into ApproxEng:master Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants