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

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

On Thu, Mar 18, 2021 at 12:54:48PM +0800, Zhai Zhaoxuan wrote:
> On Thu, Mar 18, 2021 at 9:58 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> 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".

If you want to create a contrived example - sure, you declare too many
events and run against uevent limits.

The point I am trying to make is that in more realistic use case, when
you are dealing with remote management, it is not a good idea to smash
all your input devices on the local side into one input device on the
remote side. And if you forward hardware devices one by one to the
remote side you will not run into this issue, as thankfully none of them
have 500 keys.

Thanks.

-- 
Dmitry