Thread (9 messages) 9 messages, 3 authors, 2021-03-20

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

From: Zhai Zhaoxuan <hidden>
Date: 2021-03-18 04:56:26

On Thu, Mar 18, 2021 at 9:58 AM Dmitry Torokhov
[off-list ref] wrote:
Hi Zhai,

On Mon, Mar 15, 2021 at 07:58:58PM +0800, Zhai Zhaoxuan wrote:
quoted
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.
quoted
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.)
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help