0.0.9 opens interface 0, which the README warns interferes with typing

[dwaycik]

_open_device() in 0.0.9 opens the device by vendor/product id:

self.device.open(self.config.vendor_id, product_id)

hid_open() takes the first match from hid_enumerate(), which on an RT100 is interface 0. The README states interface 0 carries key input and using it interferes with normal typing.

On my RT100 (3151:4010):

>>> [e["interface_number"] for e in hid.enumerate(0x3151, 0x4010)]
[0, 1, 2]

So open(vendor_id, product_id) gets interface 0 every time.

This looks like a regression rather than a deliberate change. 0.0.8 avoided it indirectly: _find_device_path() matched DEVICE_DESCRIPTION_REGEX ("ROYUAN .* System Control") against /sys/class/input/*/device/name and opened by path, which lands on interface 1. 0.0.9 removed that lookup.

Opening by path preserves the choice:

path = next(e["path"] for e in hid.enumerate(vendor_id, product_id)
            if e["interface_number"] == interface)
self.device.open_path(path)

I am doing exactly that in a downstream GTK front end, defaulting to interface 1.

Happy to send a PR, but the interface probably wants to be configurable rather than hard-coded — and if 0.0.9 opens interface 0 on purpose for some reason I have missed, I would rather hear that first. Hence an issue rather than a patch.

[kbrddestroyer]

Thank you for your report, I'll double check this code when I get home

[kbrddestroyer]

As I remember, that was an attempt to bring Windows support to epomaker_controller.
Since we never finished that I think you can try to patch it, I don't see any issues with that atm