On Thu, Mar 18, 2021 at 9:58 AM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > Hi Zhai, > > On Mon, Mar 15, 2021 at 07:58:58PM +0800, Zhai Zhaoxuan wrote: > > > > In the real world, I think, it is nearly impossible that a physical > > device contains so many keys or buttons. > > > > But I think a virtual device may need this. Such as a server remote > > management card, it simulates a virtual keyboard, > > registers keys and forwards all keys from user's computer to server. > > And the user's computer may have any keys. So the card needs to > > register all possible keys and send them to the kernel. > > I believe the best approach is to forward input devices to the remote > system one by one, exactly as they are on the local end, instead of > trying to crate a frankenstein monster out of them. You will not be able > to do that in a meaningful way anyway, as for example a touchscreen > needs to be handled differently from a touchpad, and if you smash them > all together into one composite device you will get a mess on your > hands. > > > > > I have tried to register only all **known** keys instead of all keys, > > but it still fails on the kernel. > > (The userspace source file has been placed in attachment.) > > > > > What functionality does it allow that we do not have today? > > > > If programs are unable to register all known keys on only 1 uinput > > device, programs have to register > > keys on two or more devices. But this may result in unexpected behavior. > > > > For example, the program registers Key A on device1, and registers Key > > B on device2. > > When the program needs to send a key combination A+B to a target > > application, it has to: > > 1. emit Key A down on device 1 > > 2. emit Key B down on device 2 > > 3. SYN_REPORT on device 1 > > 4. SYN_REPORT on device 2 > > 5. emit Key A up on device 1 > > 6. emit Key B up on device 2 > > 7. SYN_REPORT on device 1 > > 8. SYN_REPORT on device 2 > > > > Then, the target application polls input events on both devices 1 & 2. > > It reads on device 1, and gets Key A pressed down and then released, > > so it does feature A. > > Then, it reads on device 2, and gets Key B pressed down and then > > released, so it does feature B. > > Finally, the target application loses the A+B key combination. > > Which is exactly what would happen in a real life with 2 hardware > devices. > Yep, but what expected is not 2 hardware devices. It should be one device. The user scripts just want to send a key combination. The user definitely doesn't want the target application to ignore the key combination. So, we are unable to do the key combination with only 1 input device. And as you can see, it does not work if we separate key combinations into two devices. Finally, this is "we do not have today". Thanks Zhai
