[Bug] Long startup with channel errors on first report

[dripsnek]

During development of #518 it was noticed that there is a consistent delay in startup along with a set of channel timeout errors reported by InputPlumber. This is followed up by a separate one-off error the first time an interface is used. These do not appear to impact usage, but they are alarming and would seem to add 10-15 seconds startup delay.

A brief attempt to triage made me think it is something to do with

InputPlumber/src/input/manager.rs

Line 788 in 34ac603

async fn start_composite_device(

kicking off a read from the CompositeDevice via DBus before actually running it from a tokio thread, but I haven't looked deeper than that.

startup_log.txt

long_startup.webm

[pastaq]

Did this happen on your branch or in main?

[dripsnek]

I've managed to replicate the issue on a vanilla 0.72 release under openSUSE Tumbleweed 20260425 (distro package) using a dummy device config file. It is attached but for some reason github won't allow YAML extensions so it is renamed to .txt

60-lenovo-numpad.txt

https://support.lenovo.com/au/en/accessories/acc500161-lenovo-usb-numeric-keypad-gen-ii-overview-and-service-parts

The issue only seems to impact devices that call out hidraw in the config. If I comment out all hidraw groups the issue goes away, as does any usefulness.

Though if that were the actual cause surely it would be more widespread?

I've checked the other device configs which do call out hidraw and found a key difference

The files I wrote use the form

udev:
  attributes:
    - name: idVendor
      value: "<vid>"
    - name: idProduct
      value: "<pid>"
    - name: bInterfaceNumber
      value: "00"
  subsystem: hidraw

Which was based upon 60-ps4_gamepad.yaml & 60-flydigi_vader_4_pro.yaml.

But others e.g. 50-legion_go_2.yaml call hidraw directly

    hidraw:
      vendor_id: vid
      product_id: pid
      interface_num: 0

Using the latter form in both the dummy script and the proposed Razer Tartarus Pro config, it seems start up a lot faster with no errors.

This makes me wonder if the issue is present for PS4, Flydigi Vader 4 pro and Xbox One BT users?

[pastaq]

Interesting, so the newer udev based matching has some level of deadlocking and/or unoptimized code. Thanks, that helps narrow down the issue.

[dripsnek]

I suspect there are at least a couple of things going on:

1. The loop that pulls in device profiles doesn't de-duplicate or prioritize entries meaning running locally compiled builds could pull in multiple copies of the same profile where a distro version is installed, processing all the duplicates.
   

   InputPlumber/src/input/manager.rs

   Line 1657 in 85f5fd5

   for file in files {

2. Source devices which contain a udev section particularly with an open match seem to fall into:
   

   InputPlumber/src/config/mod.rs

   Line 589 in 85f5fd5

   pub fn has_matching_udev(&self, device: &UdevDevice, udev_config: &Udev) -> bool {

   
   which appears to be quite an expensive call as it visits a lot of (all?) /dev nodes in the system running a udev attribute check to match against the config, for every defined source device in the config. Using hidraw directly in configs OTOH skips right past it.

This does show up when instrumenting using samply/tracing-samply and flamegraph-rs. In my case culling the duplicate profiles seemed to be enough to get the trivial lenovo numpad case over the line but still fails on the Tartarus when its config is defined with udev fields.