Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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.

Thanks.

-- 
Dmitry