HI, On 2/6/20 12:14 PM, Filipe Laíns wrote:
Hello, Right now the hid-logitech-dj driver will export one node for each connected device, even when the device is not connected. That causes some trouble because in userspace we don't have have any way to know if the device is connected or not, so when we try to communicate, if the device is disconnected it will fail.
I'm a bit reluctant to make significant changes to how the hid-logitech-dj driver works. We have seen a number of regressions when it was changed to handle the non unifying receivers and I would like to avoid more regressions. Some questions: 1. What is the specific use case where you are hitting this? 2. Can't the userspace tools involved by modified to handle the errors they are getting gracefully? 3. Is there a bugreport open about this somewhere?
The reason we do this is because otherwise we would loose the first packets when the device is turned on by key press. When a device is turned on we would have to create the device node, and the packets received while we are creating the device node would be lost.
I don't believe that this is the reason, we only create hid child devices for devices reported by the receiver, but some of the non unifying hid receiver send a list of all devices paired, rather then the ones which are actually connected at that time.
This could solved by buffering those packets, but that is a bad solution as it would mess up the timings. At the moment the created node includes both normal HID and vendor usages. To solve this problem, I propose that instead of creating a single device node that contains all usages, we create one for normal HID, which would exist all the time, and one for the vendor usage, which would go away when the device disconnects. > This slight behavior change will affect userspace. Two hidraw nodes would be created instead of one. We need to make sure the current userspace stacks interfacing with this would be able to properly handle such changes. What do you think of this approach? Anyone has a better idea?
The suggested approach sounds fragile and like it adds complexity to an already not simple driver. It would be helpful to first describe the actual problem you are trying to fix (rather then suggesting a solution without clearly defining the problem) and then we can see from there. Regards, Hans
