-
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
Refactor code making it easier to add new device types #249
base: main
Are you sure you want to change the base?
Conversation
Pending is an infinite loop, this means that if run() terminates the program will be stuck in an endless (unresponsive) loop: remove the usage of pending and replace it with a join on run so that if the program exits due to an error systemd can restart it; this also avoids using an unnecessary task. Also avoid losing reference to the spawned Ctrl+C task.
7b09cad
to
e7ccb08
Compare
…:devnode being populated For a future implementation of leds it is important checks of devnode being populated are pushed where devnode is acually used: do that while also splitting up a gigantic method that both leaked a reference to a spaned task and was very hard to work with.
…ctually requires it In order to implement LED(s) handling and potentially other device types that don't have a node in /dev early checks for devnode() being valid must be dropped.
e7ccb08
to
4bb68a9
Compare
81ba6f6
to
91d58d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor nits and a couple questions. Overall I like the changes, good work. Especially the simplified functions, that has been on my TODO list for a while.
08a0005
to
2927a34
Compare
d035686
to
e5a9f36
Compare
… the manager component This makes it easier in the future to add new device types suc as led devices.
e5a9f36
to
34d32d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When ManageAllDevices is set to true, Manager fails to create a CompositeDevice for an external controller. We get a false positive for a virtual controller when it should detect as a bluetooth device.
Tested on Xbox Elite Series 2 Controller.
[2025-01-09T00:46:30Z DEBUG inputplumber::input::manager] Xbox Wireless Controller (event21) is virtual, skipping consideration for /devices/virtual/misc/uhid/0005:045E:0B22.002C/input/input125/event21
"Unable to create UdevDevice from {base_path}/{name} to check initialization" | ||
); | ||
attempt += 1; | ||
tokio::time::sleep(Duration::from_millis(10)).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this was 10ms before, but my Elite 2 controller doesn't initialize fully before the 800ms have passed. It seems to connect fine if this is 50ms.
if let Err(e) = result { | ||
log::error!("Unable to send command: {:?}", e); | ||
} | ||
tokio::time::sleep(Duration::from_millis(10)).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
50ms here as well.
|
||
// Check if the virtual device is using the bluetooth bus | ||
// TODO: Can we get properties from UdevDevice::get_attribute_from_tree? | ||
let id_bus = device_info.properties.get("ID_BUS"); | ||
|
||
log::debug!("Bus ID for {dev_node}: {id_bus:?}"); | ||
log::debug!("Bus ID for {dev_path}: {id_bus:?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
devnode is required for virtual device checks, devpath will not match the bus ID .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a debug, am I missing something here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look at the two lines above. The device_info grabbed for devnode is not the same as devpath. devpath wont return the same udev device instance, so the info will be different.
Since LEDs devices do not have a devnode the hard requirement for source devices of having one is to be removed and the presence check must be postponed to type of devices that actually have one and requires it to work properly.
Refactor manager.rs to remove device specialization where no particular benefits are provided by that specialization.
This PR reduces the overall number of running threads, without changing how the application behaves.