* [BUG]an input device can not support more than 568 keys due to uevent buffer too small
@ 2021-03-13 6:32 Zhai Zhaoxuan
2021-03-13 13:07 ` Greg Kroah-Hartman
0 siblings, 1 reply; 9+ messages in thread
From: Zhai Zhaoxuan @ 2021-03-13 6:32 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman; +Cc: linux-input, Markus Rechberger
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
Hi Dmitry and Greg,
I recently started making a keyboard utility. It basically helps the
user press some keys based on a user script.
So I tried to use the "uinput" driver to help me send keys to the kernel.
Due to any key and combination can be requested by the user script, I
tried to enable all KEYBIT on the uinput device. But it fails.
And more accurate, using a binary search, it seems that I am unable to
enable more than 568 keys.
The KEY_MAX (defined in linux/input-event-codes.h) is 0x2ff. So it
should be ok to enable 767 keys. The uinput device should not fail
with only 568 keys.
I read system logs. The log shows that the new input device fails due
to systemd-udevd trying to read
`/sys/devices/virtual/input/input4/uevent`, but this file is empty
unexpectedly.
Then ,I searched on the web about this and found a bug opened in
2016-05-24 by Markus:
https://bugzilla.kernel.org/show_bug.cgi?id=118861
The status of this bug is still NEW.
I tried to debug the kernel. And I got something that may be useful.
The "uevent" shows empty, because a -ENOMEM error returns by
`input_add_uevent_modalias_var`.
And this function returns -ENOMEM, because the `buf` on `struct
kobj_uevent_env` is not enough.
The size of `buf` is 2048 (UEVENT_BUFFER_SIZE). According to the
MODALIAS encoding algorithm (input_print_modalias_bits), if we allow
all 0x2ff keys to be enabled on the
uinput device, the buffer should have at least 2477 bytes. (2477 = 3
* (0xff - 0x71 + 1) + 4 * 0x200)
2048 is smaller than 2477, so it fails.
I have tried to set UEVENT_BUFFER_SIZE to 4096. After that,
everythings seems ok. The `/sys/devices/virtual/input/input4/uevent`
can show its content correctly. (See the attachment uevent.txt)
Since this change is related to the core feature kobject which is used
everywhere in the kernel, I don't know if doubling the
UEVENT_BUFFER_SIZE is the best way to fix it, or if it will cause
other serious problems.
Or maybe we can use a dynamic buffer size in `struct kobj_uevent_env`.
Thank you,
Zhai Zhaoxuan
[-- Attachment #2: uevent.txt --]
[-- Type: text/plain, Size: 2788 bytes --]
PRODUCT=3/1234/5678/0
NAME="Example device"
PROP=0
EV=3
KEY=7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe
MODALIAS=input:b0003v1234p5678e0000-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,100,101,102,103,104,105,106,107,108,109,10A,10B,10C,10D,10E,10F,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,120,121,122,123,124,125,126,127,128,129,12A,12B,12C,12D,12E,12F,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,13F,140,141,142,143,144,145,146,147,148,149,14A,14B,14C,14D,14E,14F,150,151,152,153,154,155,156,157,158,159,15A,15B,15C,15D,15E,15F,160,161,162,163,164,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,176,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,188,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1BE,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,206,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,218,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,260,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,272,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,284,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,296,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2BA,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2CC,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2DE,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-13 6:32 [BUG]an input device can not support more than 568 keys due to uevent buffer too small Zhai Zhaoxuan
@ 2021-03-13 13:07 ` Greg Kroah-Hartman
2021-03-15 6:58 ` Zhai Zhaoxuan
0 siblings, 1 reply; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-03-13 13:07 UTC (permalink / raw)
To: Zhai Zhaoxuan; +Cc: Dmitry Torokhov, linux-input, Markus Rechberger
On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:
> Hi Dmitry and Greg,
>
> I recently started making a keyboard utility. It basically helps the
> user press some keys based on a user script.
> So I tried to use the "uinput" driver to help me send keys to the kernel.
>
> Due to any key and combination can be requested by the user script, I
> tried to enable all KEYBIT on the uinput device. But it fails.
> And more accurate, using a binary search, it seems that I am unable to
> enable more than 568 keys.
As that's not a "real" device, that makes sense :)
> The KEY_MAX (defined in linux/input-event-codes.h) is 0x2ff. So it
> should be ok to enable 767 keys. The uinput device should not fail
> with only 568 keys.
>
> I read system logs. The log shows that the new input device fails due
> to systemd-udevd trying to read
> `/sys/devices/virtual/input/input4/uevent`, but this file is empty
> unexpectedly.
>
> Then ,I searched on the web about this and found a bug opened in
> 2016-05-24 by Markus:
> https://bugzilla.kernel.org/show_bug.cgi?id=118861
> The status of this bug is still NEW.
>
> I tried to debug the kernel. And I got something that may be useful.
> The "uevent" shows empty, because a -ENOMEM error returns by
> `input_add_uevent_modalias_var`.
> And this function returns -ENOMEM, because the `buf` on `struct
> kobj_uevent_env` is not enough.
>
> The size of `buf` is 2048 (UEVENT_BUFFER_SIZE). According to the
> MODALIAS encoding algorithm (input_print_modalias_bits), if we allow
> all 0x2ff keys to be enabled on the
> uinput device, the buffer should have at least 2477 bytes. (2477 = 3
> * (0xff - 0x71 + 1) + 4 * 0x200)
> 2048 is smaller than 2477, so it fails.
>
> I have tried to set UEVENT_BUFFER_SIZE to 4096. After that,
> everythings seems ok. The `/sys/devices/virtual/input/input4/uevent`
> can show its content correctly. (See the attachment uevent.txt)
>
> Since this change is related to the core feature kobject which is used
> everywhere in the kernel, I don't know if doubling the
> UEVENT_BUFFER_SIZE is the best way to fix it, or if it will cause
> other serious problems.
> Or maybe we can use a dynamic buffer size in `struct kobj_uevent_env`.
>
>
> Thank you,
> Zhai Zhaoxuan
> PRODUCT=3/1234/5678/0
> NAME="Example device"
> PROP=0
> EV=3
> KEY=7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe
> MODALIAS=input:b0003v1234p5678e0000-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,100,101,102,103,104,105,106,107,108,109,10A,10B,10C,10D,10E,10F,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,120,121,122,123,124,125,126,127,128,129,12A,12B,12C,12D,12E,12F,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,13F,140,141,142,143,144,145,146,147,148,149,14A,14B,14C,14D,14E,14F,150,151,152,153,154,155,156,157,158,159,15A,15B,15C,15D,15E,15F,160,161,162,163,164,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,176,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,188,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1BE,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,206,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,218,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,260,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,272,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,284,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,296,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2BA,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2CC,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2DE,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
>
What about encoding the keys as ranges instead of individual ones, would
that make more sense?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-13 13:07 ` Greg Kroah-Hartman
@ 2021-03-15 6:58 ` Zhai Zhaoxuan
2021-03-15 7:30 ` Greg Kroah-Hartman
0 siblings, 1 reply; 9+ messages in thread
From: Zhai Zhaoxuan @ 2021-03-15 6:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, Dmitry Torokhov; +Cc: linux-input, Markus Rechberger
On Sat, Mar 13, 2021 at 9:07 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:
> > Hi Dmitry and Greg,
> >
> > I recently started making a keyboard utility. It basically helps the
> > user press some keys based on a user script.
> > So I tried to use the "uinput" driver to help me send keys to the kernel.
> >
> > Due to any key and combination can be requested by the user script, I
> > tried to enable all KEYBIT on the uinput device. But it fails.
> > And more accurate, using a binary search, it seems that I am unable to
> > enable more than 568 keys.
>
> As that's not a "real" device, that makes sense :)
>
> > The KEY_MAX (defined in linux/input-event-codes.h) is 0x2ff. So it
> > should be ok to enable 767 keys. The uinput device should not fail
> > with only 568 keys.
> >
> > I read system logs. The log shows that the new input device fails due
> > to systemd-udevd trying to read
> > `/sys/devices/virtual/input/input4/uevent`, but this file is empty
> > unexpectedly.
> >
> > Then ,I searched on the web about this and found a bug opened in
> > 2016-05-24 by Markus:
> > https://bugzilla.kernel.org/show_bug.cgi?id=118861
> > The status of this bug is still NEW.
> >
> > I tried to debug the kernel. And I got something that may be useful.
> > The "uevent" shows empty, because a -ENOMEM error returns by
> > `input_add_uevent_modalias_var`.
> > And this function returns -ENOMEM, because the `buf` on `struct
> > kobj_uevent_env` is not enough.
> >
> > The size of `buf` is 2048 (UEVENT_BUFFER_SIZE). According to the
> > MODALIAS encoding algorithm (input_print_modalias_bits), if we allow
> > all 0x2ff keys to be enabled on the
> > uinput device, the buffer should have at least 2477 bytes. (2477 = 3
> > * (0xff - 0x71 + 1) + 4 * 0x200)
> > 2048 is smaller than 2477, so it fails.
> >
> > I have tried to set UEVENT_BUFFER_SIZE to 4096. After that,
> > everythings seems ok. The `/sys/devices/virtual/input/input4/uevent`
> > can show its content correctly. (See the attachment uevent.txt)
> >
> > Since this change is related to the core feature kobject which is used
> > everywhere in the kernel, I don't know if doubling the
> > UEVENT_BUFFER_SIZE is the best way to fix it, or if it will cause
> > other serious problems.
> > Or maybe we can use a dynamic buffer size in `struct kobj_uevent_env`.
> >
> >
> > Thank you,
> > Zhai Zhaoxuan
>
> > PRODUCT=3/1234/5678/0
> > NAME="Example device"
> > PROP=0
> > EV=3
> > KEY=7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe
> > MODALIAS=input:b0003v1234p5678e0000-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,100,101,102,103,104,105,106,107,108,109,10A,10B,10C,10D,10E,10F,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,120,121,122,123,124,125,126,127,128,129,12A,12B,12C,12D,12E,12F,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,13F,140,141,142,143,144,145,146,147,148,149,14A,14B,14C,14D,14E,14F,150,151,152,153,154,155,156,157,158,159,15A,15B,15C,15D,15E,15F,160,161,162,163,164,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,176,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,188,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1BE,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,206,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,218,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,260,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,272,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,284,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,296,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2BA,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2CC,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2DE,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
> >
>
> What about encoding the keys as ranges instead of individual ones, would
> that make more sense?
I think this solution is ok in most cases.
But, just a notice, MODALIAS may be used in user code (such as hwdb in
/lib/udev/hwdb.d). For example, the user may have a pattern "k*74*" in
hwdb to match the new input device which has a POWER button (0x74 is
the key code of power button). Then, the user could use udev to run
some programs, when an input device with power button has been added.
If we use a "range" to describe the keys, the user may be unable to
detect the power button with only hwdb. They have to move the matching
code into their own programs.
And what do you think, Dmitry?
>
> thanks,
>
> greg k-h
Thank you,
Zhai Zhaoxuan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-15 6:58 ` Zhai Zhaoxuan
@ 2021-03-15 7:30 ` Greg Kroah-Hartman
2021-03-15 11:58 ` Zhai Zhaoxuan
0 siblings, 1 reply; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-03-15 7:30 UTC (permalink / raw)
To: Zhai Zhaoxuan; +Cc: Dmitry Torokhov, linux-input, Markus Rechberger
On Mon, Mar 15, 2021 at 02:58:11PM +0800, Zhai Zhaoxuan wrote:
> On Sat, Mar 13, 2021 at 9:07 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:
> > > Hi Dmitry and Greg,
> > >
> > > I recently started making a keyboard utility. It basically helps the
> > > user press some keys based on a user script.
> > > So I tried to use the "uinput" driver to help me send keys to the kernel.
> > >
> > > Due to any key and combination can be requested by the user script, I
> > > tried to enable all KEYBIT on the uinput device. But it fails.
> > > And more accurate, using a binary search, it seems that I am unable to
> > > enable more than 568 keys.
> >
> > As that's not a "real" device, that makes sense :)
> >
> > > The KEY_MAX (defined in linux/input-event-codes.h) is 0x2ff. So it
> > > should be ok to enable 767 keys. The uinput device should not fail
> > > with only 568 keys.
> > >
> > > I read system logs. The log shows that the new input device fails due
> > > to systemd-udevd trying to read
> > > `/sys/devices/virtual/input/input4/uevent`, but this file is empty
> > > unexpectedly.
> > >
> > > Then ,I searched on the web about this and found a bug opened in
> > > 2016-05-24 by Markus:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=118861
> > > The status of this bug is still NEW.
> > >
> > > I tried to debug the kernel. And I got something that may be useful.
> > > The "uevent" shows empty, because a -ENOMEM error returns by
> > > `input_add_uevent_modalias_var`.
> > > And this function returns -ENOMEM, because the `buf` on `struct
> > > kobj_uevent_env` is not enough.
> > >
> > > The size of `buf` is 2048 (UEVENT_BUFFER_SIZE). According to the
> > > MODALIAS encoding algorithm (input_print_modalias_bits), if we allow
> > > all 0x2ff keys to be enabled on the
> > > uinput device, the buffer should have at least 2477 bytes. (2477 = 3
> > > * (0xff - 0x71 + 1) + 4 * 0x200)
> > > 2048 is smaller than 2477, so it fails.
> > >
> > > I have tried to set UEVENT_BUFFER_SIZE to 4096. After that,
> > > everythings seems ok. The `/sys/devices/virtual/input/input4/uevent`
> > > can show its content correctly. (See the attachment uevent.txt)
> > >
> > > Since this change is related to the core feature kobject which is used
> > > everywhere in the kernel, I don't know if doubling the
> > > UEVENT_BUFFER_SIZE is the best way to fix it, or if it will cause
> > > other serious problems.
> > > Or maybe we can use a dynamic buffer size in `struct kobj_uevent_env`.
> > >
> > >
> > > Thank you,
> > > Zhai Zhaoxuan
> >
> > > PRODUCT=3/1234/5678/0
> > > NAME="Example device"
> > > PROP=0
> > > EV=3
> > > KEY=7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe
> > > MODALIAS=input:b0003v1234p5678e0000-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,100,101,102,103,104,105,106,107,108,109,10A,10B,10C,10D,10E,10F,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,120,121,122,123,124,125,126,127,128,129,12A,12B,12C,12D,12E,12F,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,13F,140,141,142,143,144,145,146,147,148,149,14A,14B,14C,14D,14E,14F,150,151,152,153,154,155,156,157,158,159,15A,15B,15C,15D,15E,15F,160,161,162,163,164,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,176,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,188,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1BE,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,206,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,218,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,260,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,272,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,284,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,296,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2BA,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2CC,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2DE,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
> > >
> >
> > What about encoding the keys as ranges instead of individual ones, would
> > that make more sense?
>
> I think this solution is ok in most cases.
>
>
> But, just a notice, MODALIAS may be used in user code (such as hwdb in
> /lib/udev/hwdb.d). For example, the user may have a pattern "k*74*" in
> hwdb to match the new input device which has a POWER button (0x74 is
> the key code of power button). Then, the user could use udev to run
> some programs, when an input device with power button has been added.
>
> If we use a "range" to describe the keys, the user may be unable to
> detect the power button with only hwdb. They have to move the matching
> code into their own programs.
Yeah, you are right, that's not going to work, I didn't realize that
this was a modprobe matching field, but should have.
I don't mind bumping up the size of the uevent buffer, but just how
realistic is this device "in the real world"? What does offering up a
device with that many keys actually provide userspace with? What
functionality does it allow that we do not have today?
If you change UEVENT_BUFFER_SIZE to be larger, does all of the problems
go away? This is a short-lived memory buffer, there should not be any
real issue with increasing it as the memory is used and then freed
quickly.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-15 7:30 ` Greg Kroah-Hartman
@ 2021-03-15 11:58 ` Zhai Zhaoxuan
2021-03-18 1:58 ` Dmitry Torokhov
0 siblings, 1 reply; 9+ messages in thread
From: Zhai Zhaoxuan @ 2021-03-15 11:58 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dmitry Torokhov, linux-input, Markus Rechberger
[-- Attachment #1: Type: text/plain, Size: 9366 bytes --]
On Mon, Mar 15, 2021 at 3:30 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Mar 15, 2021 at 02:58:11PM +0800, Zhai Zhaoxuan wrote:
> > On Sat, Mar 13, 2021 at 9:07 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:
> > > > Hi Dmitry and Greg,
> > > >
> > > > I recently started making a keyboard utility. It basically helps the
> > > > user press some keys based on a user script.
> > > > So I tried to use the "uinput" driver to help me send keys to the kernel.
> > > >
> > > > Due to any key and combination can be requested by the user script, I
> > > > tried to enable all KEYBIT on the uinput device. But it fails.
> > > > And more accurate, using a binary search, it seems that I am unable to
> > > > enable more than 568 keys.
> > >
> > > As that's not a "real" device, that makes sense :)
> > >
> > > > The KEY_MAX (defined in linux/input-event-codes.h) is 0x2ff. So it
> > > > should be ok to enable 767 keys. The uinput device should not fail
> > > > with only 568 keys.
> > > >
> > > > I read system logs. The log shows that the new input device fails due
> > > > to systemd-udevd trying to read
> > > > `/sys/devices/virtual/input/input4/uevent`, but this file is empty
> > > > unexpectedly.
> > > >
> > > > Then ,I searched on the web about this and found a bug opened in
> > > > 2016-05-24 by Markus:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=118861
> > > > The status of this bug is still NEW.
> > > >
> > > > I tried to debug the kernel. And I got something that may be useful.
> > > > The "uevent" shows empty, because a -ENOMEM error returns by
> > > > `input_add_uevent_modalias_var`.
> > > > And this function returns -ENOMEM, because the `buf` on `struct
> > > > kobj_uevent_env` is not enough.
> > > >
> > > > The size of `buf` is 2048 (UEVENT_BUFFER_SIZE). According to the
> > > > MODALIAS encoding algorithm (input_print_modalias_bits), if we allow
> > > > all 0x2ff keys to be enabled on the
> > > > uinput device, the buffer should have at least 2477 bytes. (2477 = 3
> > > > * (0xff - 0x71 + 1) + 4 * 0x200)
> > > > 2048 is smaller than 2477, so it fails.
> > > >
> > > > I have tried to set UEVENT_BUFFER_SIZE to 4096. After that,
> > > > everythings seems ok. The `/sys/devices/virtual/input/input4/uevent`
> > > > can show its content correctly. (See the attachment uevent.txt)
> > > >
> > > > Since this change is related to the core feature kobject which is used
> > > > everywhere in the kernel, I don't know if doubling the
> > > > UEVENT_BUFFER_SIZE is the best way to fix it, or if it will cause
> > > > other serious problems.
> > > > Or maybe we can use a dynamic buffer size in `struct kobj_uevent_env`.
> > > >
> > > >
> > > > Thank you,
> > > > Zhai Zhaoxuan
> > >
> > > > PRODUCT=3/1234/5678/0
> > > > NAME="Example device"
> > > > PROP=0
> > > > EV=3
> > > > KEY=7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe
> > > > MODALIAS=input:b0003v1234p5678e0000-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,100,101,102,103,104,105,106,107,108,109,10A,10B,10C,10D,10E,10F,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,120,121,122,123,124,125,126,127,128,129,12A,12B,12C,12D,12E,12F,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,13F,140,141,142,143,144,145,146,147,148,149,14A,14B,14C,14D,14E,14F,150,151,152,153,154,155,156,157,158,159,15A,15B,15C,15D,15E,15F,160,161,162,163,164,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,176,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,188,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1BE,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,206,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,218,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,260,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,272,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,284,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,296,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2BA,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2CC,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2DE,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
> > > >
> > >
> > > What about encoding the keys as ranges instead of individual ones, would
> > > that make more sense?
> >
> > I think this solution is ok in most cases.
> >
> >
> > But, just a notice, MODALIAS may be used in user code (such as hwdb in
> > /lib/udev/hwdb.d). For example, the user may have a pattern "k*74*" in
> > hwdb to match the new input device which has a POWER button (0x74 is
> > the key code of power button). Then, the user could use udev to run
> > some programs, when an input device with power button has been added.
> >
> > If we use a "range" to describe the keys, the user may be unable to
> > detect the power button with only hwdb. They have to move the matching
> > code into their own programs.
>
> Yeah, you are right, that's not going to work, I didn't realize that
> this was a modprobe matching field, but should have.
>
> I don't mind bumping up the size of the uevent buffer, but just how
> realistic is this device "in the real world"? What does offering up a
> device with that many keys actually provide userspace with? What
> functionality does it allow that we do not have today?
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 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.
If the program has a uinput device with Key A and Key B enabled, the
program can do this:
1. emit Key A down on device 1
2. emit Key B down on device 1
3. SYN_REPORT on device 1
4. emit Key A up on device 1
5. emit Key B up on device 1
3. SYN_REPORT on device 1
The target application has no chance to lose the key combination.
>
> If you change UEVENT_BUFFER_SIZE to be larger, does all of the problems
> go away? This is a short-lived memory buffer, there should not be any
> real issue with increasing it as the memory is used and then freed
> quickly.
I will do more tests about uinput on the modified kernel, and see if
there is still something broken.
But please wait for me some time. I don’t have much time on that
keyboard utility. Since I have a 996 working. :(
>
> thanks,
>
> greg k-h
[-- Attachment #2: uinput.c --]
[-- Type: text/x-csrc, Size: 12315 bytes --]
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <linux/uinput.h>
static int known_keys[] = {
KEY_ESC,
KEY_1,
KEY_2,
KEY_3,
KEY_4,
KEY_5,
KEY_6,
KEY_7,
KEY_8,
KEY_9,
KEY_0,
KEY_MINUS,
KEY_EQUAL,
KEY_BACKSPACE,
KEY_TAB,
KEY_Q,
KEY_W,
KEY_E,
KEY_R,
KEY_T,
KEY_Y,
KEY_U,
KEY_I,
KEY_O,
KEY_P,
KEY_LEFTBRACE,
KEY_RIGHTBRACE,
KEY_ENTER,
KEY_LEFTCTRL,
KEY_A,
KEY_S,
KEY_D,
KEY_F,
KEY_G,
KEY_H,
KEY_J,
KEY_K,
KEY_L,
KEY_SEMICOLON,
KEY_APOSTROPHE,
KEY_GRAVE,
KEY_LEFTSHIFT,
KEY_BACKSLASH,
KEY_Z,
KEY_X,
KEY_C,
KEY_V,
KEY_B,
KEY_N,
KEY_M,
KEY_COMMA,
KEY_DOT,
KEY_SLASH,
KEY_RIGHTSHIFT,
KEY_KPASTERISK,
KEY_LEFTALT,
KEY_SPACE,
KEY_CAPSLOCK,
KEY_F1,
KEY_F2,
KEY_F3,
KEY_F4,
KEY_F5,
KEY_F6,
KEY_F7,
KEY_F8,
KEY_F9,
KEY_F10,
KEY_NUMLOCK,
KEY_SCROLLLOCK,
KEY_KP7,
KEY_KP8,
KEY_KP9,
KEY_KPMINUS,
KEY_KP4,
KEY_KP5,
KEY_KP6,
KEY_KPPLUS,
KEY_KP1,
KEY_KP2,
KEY_KP3,
KEY_KP0,
KEY_KPDOT,
KEY_ZENKAKUHANKAKU,
KEY_102ND,
KEY_F11,
KEY_F12,
KEY_RO,
KEY_KATAKANA,
KEY_HIRAGANA,
KEY_HENKAN,
KEY_KATAKANAHIRAGANA,
KEY_MUHENKAN,
KEY_KPJPCOMMA,
KEY_KPENTER,
KEY_RIGHTCTRL,
KEY_KPSLASH,
KEY_SYSRQ,
KEY_RIGHTALT,
KEY_LINEFEED,
KEY_HOME,
KEY_UP,
KEY_PAGEUP,
KEY_LEFT,
KEY_RIGHT,
KEY_END,
KEY_DOWN,
KEY_PAGEDOWN,
KEY_INSERT,
KEY_DELETE,
KEY_MACRO,
KEY_MUTE,
KEY_VOLUMEDOWN,
KEY_VOLUMEUP,
KEY_POWER,
KEY_KPEQUAL,
KEY_KPPLUSMINUS,
KEY_PAUSE,
KEY_SCALE,
KEY_KPCOMMA,
KEY_HANGEUL,
KEY_HANGUEL,
KEY_HANJA,
KEY_YEN,
KEY_LEFTMETA,
KEY_RIGHTMETA,
KEY_COMPOSE,
KEY_STOP,
KEY_AGAIN,
KEY_PROPS,
KEY_UNDO,
KEY_FRONT,
KEY_COPY,
KEY_OPEN,
KEY_PASTE,
KEY_FIND,
KEY_CUT,
KEY_HELP,
KEY_MENU,
KEY_CALC,
KEY_SETUP,
KEY_SLEEP,
KEY_WAKEUP,
KEY_FILE,
KEY_SENDFILE,
KEY_DELETEFILE,
KEY_XFER,
KEY_PROG1,
KEY_PROG2,
KEY_WWW,
KEY_MSDOS,
KEY_COFFEE,
KEY_SCREENLOCK,
KEY_ROTATE_DISPLAY,
KEY_DIRECTION,
KEY_CYCLEWINDOWS,
KEY_MAIL,
KEY_BOOKMARKS,
KEY_COMPUTER,
KEY_BACK,
KEY_FORWARD,
KEY_CLOSECD,
KEY_EJECTCD,
KEY_EJECTCLOSECD,
KEY_NEXTSONG,
KEY_PLAYPAUSE,
KEY_PREVIOUSSONG,
KEY_STOPCD,
KEY_RECORD,
KEY_REWIND,
KEY_PHONE,
KEY_ISO,
KEY_CONFIG,
KEY_HOMEPAGE,
KEY_REFRESH,
KEY_EXIT,
KEY_MOVE,
KEY_EDIT,
KEY_SCROLLUP,
KEY_SCROLLDOWN,
KEY_KPLEFTPAREN,
KEY_KPRIGHTPAREN,
KEY_NEW,
KEY_REDO,
KEY_F13,
KEY_F14,
KEY_F15,
KEY_F16,
KEY_F17,
KEY_F18,
KEY_F19,
KEY_F20,
KEY_F21,
KEY_F22,
KEY_F23,
KEY_F24,
KEY_PLAYCD,
KEY_PAUSECD,
KEY_PROG3,
KEY_PROG4,
KEY_DASHBOARD,
KEY_SUSPEND,
KEY_CLOSE,
KEY_PLAY,
KEY_FASTFORWARD,
KEY_BASSBOOST,
KEY_PRINT,
KEY_HP,
KEY_CAMERA,
KEY_SOUND,
KEY_QUESTION,
KEY_EMAIL,
KEY_CHAT,
KEY_SEARCH,
KEY_CONNECT,
KEY_FINANCE,
KEY_SPORT,
KEY_SHOP,
KEY_ALTERASE,
KEY_CANCEL,
KEY_BRIGHTNESSDOWN,
KEY_BRIGHTNESSUP,
KEY_MEDIA,
KEY_SWITCHVIDEOMODE,
KEY_KBDILLUMTOGGLE,
KEY_KBDILLUMDOWN,
KEY_KBDILLUMUP,
KEY_SEND,
KEY_REPLY,
KEY_FORWARDMAIL,
KEY_SAVE,
KEY_DOCUMENTS,
KEY_BATTERY,
KEY_BLUETOOTH,
KEY_WLAN,
KEY_UWB,
KEY_UNKNOWN,
KEY_VIDEO_NEXT,
KEY_VIDEO_PREV,
KEY_BRIGHTNESS_CYCLE,
KEY_BRIGHTNESS_AUTO,
KEY_BRIGHTNESS_ZERO,
KEY_DISPLAY_OFF,
KEY_WWAN,
KEY_WIMAX,
KEY_RFKILL,
KEY_MICMUTE,
BTN_MISC,
BTN_0,
BTN_1,
BTN_2,
BTN_3,
BTN_4,
BTN_5,
BTN_6,
BTN_7,
BTN_8,
BTN_9,
BTN_MOUSE,
BTN_LEFT,
BTN_RIGHT,
BTN_MIDDLE,
BTN_SIDE,
BTN_EXTRA,
BTN_FORWARD,
BTN_BACK,
BTN_TASK,
BTN_JOYSTICK,
BTN_TRIGGER,
BTN_THUMB,
BTN_THUMB2,
BTN_TOP,
BTN_TOP2,
BTN_PINKIE,
BTN_BASE,
BTN_BASE2,
BTN_BASE3,
BTN_BASE4,
BTN_BASE5,
BTN_BASE6,
BTN_DEAD,
BTN_GAMEPAD,
BTN_SOUTH,
BTN_A,
BTN_EAST,
BTN_B,
BTN_C,
BTN_NORTH,
BTN_X,
BTN_WEST,
BTN_Y,
BTN_Z,
BTN_TL,
BTN_TR,
BTN_TL2,
BTN_TR2,
BTN_SELECT,
BTN_START,
BTN_MODE,
BTN_THUMBL,
BTN_THUMBR,
BTN_DIGI,
BTN_TOOL_PEN,
BTN_TOOL_RUBBER,
BTN_TOOL_BRUSH,
BTN_TOOL_PENCIL,
BTN_TOOL_AIRBRUSH,
BTN_TOOL_FINGER,
BTN_TOOL_MOUSE,
BTN_TOOL_LENS,
BTN_TOOL_QUINTTAP,
BTN_STYLUS3,
BTN_TOUCH,
BTN_STYLUS,
BTN_STYLUS2,
BTN_TOOL_DOUBLETAP,
BTN_TOOL_TRIPLETAP,
BTN_TOOL_QUADTAP,
BTN_WHEEL,
BTN_GEAR_DOWN,
BTN_GEAR_UP,
KEY_OK,
KEY_SELECT,
KEY_GOTO,
KEY_CLEAR,
KEY_POWER2,
KEY_OPTION,
KEY_INFO,
KEY_TIME,
KEY_VENDOR,
KEY_ARCHIVE,
KEY_PROGRAM,
KEY_CHANNEL,
KEY_FAVORITES,
KEY_EPG,
KEY_PVR,
KEY_MHP,
KEY_LANGUAGE,
KEY_TITLE,
KEY_SUBTITLE,
KEY_ANGLE,
KEY_FULL_SCREEN,
KEY_ZOOM,
KEY_MODE,
KEY_KEYBOARD,
KEY_ASPECT_RATIO,
KEY_SCREEN,
KEY_PC,
KEY_TV,
KEY_TV2,
KEY_VCR,
KEY_VCR2,
KEY_SAT,
KEY_SAT2,
KEY_CD,
KEY_TAPE,
KEY_RADIO,
KEY_TUNER,
KEY_PLAYER,
KEY_TEXT,
KEY_DVD,
KEY_AUX,
KEY_MP3,
KEY_AUDIO,
KEY_VIDEO,
KEY_DIRECTORY,
KEY_LIST,
KEY_MEMO,
KEY_CALENDAR,
KEY_RED,
KEY_GREEN,
KEY_YELLOW,
KEY_BLUE,
KEY_CHANNELUP,
KEY_CHANNELDOWN,
KEY_FIRST,
KEY_LAST,
KEY_AB,
KEY_NEXT,
KEY_RESTART,
KEY_SLOW,
KEY_SHUFFLE,
KEY_BREAK,
KEY_PREVIOUS,
KEY_DIGITS,
KEY_TEEN,
KEY_TWEN,
KEY_VIDEOPHONE,
KEY_GAMES,
KEY_ZOOMIN,
KEY_ZOOMOUT,
KEY_ZOOMRESET,
KEY_WORDPROCESSOR,
KEY_EDITOR,
KEY_SPREADSHEET,
KEY_GRAPHICSEDITOR,
KEY_PRESENTATION,
KEY_DATABASE,
KEY_NEWS,
KEY_VOICEMAIL,
KEY_ADDRESSBOOK,
KEY_MESSENGER,
KEY_DISPLAYTOGGLE,
KEY_BRIGHTNESS_TOGGLE,
KEY_SPELLCHECK,
KEY_LOGOFF,
KEY_DOLLAR,
KEY_EURO,
KEY_FRAMEBACK,
KEY_FRAMEFORWARD,
KEY_CONTEXT_MENU,
KEY_MEDIA_REPEAT,
KEY_10CHANNELSUP,
KEY_10CHANNELSDOWN,
KEY_IMAGES,
KEY_DEL_EOL,
KEY_DEL_EOS,
KEY_INS_LINE,
KEY_DEL_LINE,
KEY_FN,
KEY_FN_ESC,
KEY_FN_F1,
KEY_FN_F2,
KEY_FN_F3,
KEY_FN_F4,
KEY_FN_F5,
KEY_FN_F6,
KEY_FN_F7,
KEY_FN_F8,
KEY_FN_F9,
KEY_FN_F10,
KEY_FN_F11,
KEY_FN_F12,
KEY_FN_1,
KEY_FN_2,
KEY_FN_D,
KEY_FN_E,
KEY_FN_F,
KEY_FN_S,
KEY_FN_B,
KEY_BRL_DOT1,
KEY_BRL_DOT2,
KEY_BRL_DOT3,
KEY_BRL_DOT4,
KEY_BRL_DOT5,
KEY_BRL_DOT6,
KEY_BRL_DOT7,
KEY_BRL_DOT8,
KEY_BRL_DOT9,
KEY_BRL_DOT10,
KEY_NUMERIC_0,
KEY_NUMERIC_1,
KEY_NUMERIC_2,
KEY_NUMERIC_3,
KEY_NUMERIC_4,
KEY_NUMERIC_5,
KEY_NUMERIC_6,
KEY_NUMERIC_7,
KEY_NUMERIC_8,
KEY_NUMERIC_9,
KEY_NUMERIC_STAR,
KEY_NUMERIC_POUND,
KEY_NUMERIC_A,
KEY_NUMERIC_B,
KEY_NUMERIC_C,
KEY_NUMERIC_D,
KEY_CAMERA_FOCUS,
KEY_WPS_BUTTON,
KEY_TOUCHPAD_TOGGLE,
KEY_TOUCHPAD_ON,
KEY_TOUCHPAD_OFF,
KEY_CAMERA_ZOOMIN,
KEY_CAMERA_ZOOMOUT,
KEY_CAMERA_UP,
KEY_CAMERA_DOWN,
KEY_CAMERA_LEFT,
KEY_CAMERA_RIGHT,
KEY_ATTENDANT_ON,
KEY_ATTENDANT_OFF,
KEY_ATTENDANT_TOGGLE,
KEY_LIGHTS_TOGGLE,
BTN_DPAD_UP,
BTN_DPAD_DOWN,
BTN_DPAD_LEFT,
BTN_DPAD_RIGHT,
KEY_ALS_TOGGLE,
KEY_ROTATE_LOCK_TOGGLE,
KEY_BUTTONCONFIG,
KEY_TASKMANAGER,
KEY_JOURNAL,
KEY_CONTROLPANEL,
KEY_APPSELECT,
KEY_SCREENSAVER,
KEY_VOICECOMMAND,
KEY_ASSISTANT,
KEY_KBD_LAYOUT_NEXT,
KEY_BRIGHTNESS_MIN,
KEY_BRIGHTNESS_MAX,
KEY_KBDINPUTASSIST_PREV,
KEY_KBDINPUTASSIST_NEXT,
KEY_KBDINPUTASSIST_PREVGROUP,
KEY_KBDINPUTASSIST_NEXTGROUP,
KEY_KBDINPUTASSIST_ACCEPT,
KEY_KBDINPUTASSIST_CANCEL,
KEY_RIGHT_UP,
KEY_RIGHT_DOWN,
KEY_LEFT_UP,
KEY_LEFT_DOWN,
KEY_ROOT_MENU,
KEY_MEDIA_TOP_MENU,
KEY_NUMERIC_11,
KEY_NUMERIC_12,
KEY_AUDIO_DESC,
KEY_3D_MODE,
KEY_NEXT_FAVORITE,
KEY_STOP_RECORD,
KEY_PAUSE_RECORD,
KEY_VOD,
KEY_UNMUTE,
KEY_FASTREVERSE,
KEY_SLOWREVERSE,
KEY_DATA,
KEY_ONSCREEN_KEYBOARD,
KEY_PRIVACY_SCREEN_TOGGLE,
KEY_SELECTIVE_SCREENSHOT,
KEY_MACRO1,
KEY_MACRO2,
KEY_MACRO3,
KEY_MACRO4,
KEY_MACRO5,
KEY_MACRO6,
KEY_MACRO7,
KEY_MACRO8,
KEY_MACRO9,
KEY_MACRO10,
KEY_MACRO11,
KEY_MACRO12,
KEY_MACRO13,
KEY_MACRO14,
KEY_MACRO15,
KEY_MACRO16,
KEY_MACRO17,
KEY_MACRO18,
KEY_MACRO19,
KEY_MACRO20,
KEY_MACRO21,
KEY_MACRO22,
KEY_MACRO23,
KEY_MACRO24,
KEY_MACRO25,
KEY_MACRO26,
KEY_MACRO27,
KEY_MACRO28,
KEY_MACRO29,
KEY_MACRO30,
KEY_MACRO_RECORD_START,
KEY_MACRO_RECORD_STOP,
KEY_MACRO_PRESET_CYCLE,
KEY_MACRO_PRESET1,
KEY_MACRO_PRESET2,
KEY_MACRO_PRESET3,
KEY_KBD_LCD_MENU1,
KEY_KBD_LCD_MENU2,
KEY_KBD_LCD_MENU3,
KEY_KBD_LCD_MENU4,
KEY_KBD_LCD_MENU5,
BTN_TRIGGER_HAPPY,
BTN_TRIGGER_HAPPY1,
BTN_TRIGGER_HAPPY2,
BTN_TRIGGER_HAPPY3,
BTN_TRIGGER_HAPPY4,
BTN_TRIGGER_HAPPY5,
BTN_TRIGGER_HAPPY6,
BTN_TRIGGER_HAPPY7,
BTN_TRIGGER_HAPPY8,
BTN_TRIGGER_HAPPY9,
BTN_TRIGGER_HAPPY10,
BTN_TRIGGER_HAPPY11,
BTN_TRIGGER_HAPPY12,
BTN_TRIGGER_HAPPY13,
BTN_TRIGGER_HAPPY14,
BTN_TRIGGER_HAPPY15,
BTN_TRIGGER_HAPPY16,
BTN_TRIGGER_HAPPY17,
BTN_TRIGGER_HAPPY18,
BTN_TRIGGER_HAPPY19,
BTN_TRIGGER_HAPPY20,
BTN_TRIGGER_HAPPY21,
BTN_TRIGGER_HAPPY22,
BTN_TRIGGER_HAPPY23,
BTN_TRIGGER_HAPPY24,
BTN_TRIGGER_HAPPY25,
BTN_TRIGGER_HAPPY26,
BTN_TRIGGER_HAPPY27,
BTN_TRIGGER_HAPPY28,
BTN_TRIGGER_HAPPY29,
BTN_TRIGGER_HAPPY30,
BTN_TRIGGER_HAPPY31,
BTN_TRIGGER_HAPPY32,
BTN_TRIGGER_HAPPY33,
BTN_TRIGGER_HAPPY34,
BTN_TRIGGER_HAPPY35,
BTN_TRIGGER_HAPPY36,
BTN_TRIGGER_HAPPY37,
BTN_TRIGGER_HAPPY38,
BTN_TRIGGER_HAPPY39,
BTN_TRIGGER_HAPPY40,
};
void emit(int fd, int type, int code, int val)
{
struct input_event ie;
ie.type = type;
ie.code = code;
ie.value = val;
/* timestamp values below are ignored */
ie.time.tv_sec = 0;
ie.time.tv_usec = 0;
write(fd, &ie, sizeof(ie));
}
int main(void)
{
struct uinput_setup usetup;
int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
if (fd < 0) {
switch (errno) {
case EACCES:
fprintf(stderr, "Please run this program as root\n");
break;
case ENOENT:
fprintf(stderr, "Please load \"uinput\" module\n");
break;
default:
fprintf(stderr, "Error open /dev/uinput: %s\n", strerror(errno));
break;
}
exit(1);
}
/*
* The ioctls below will enable the device that is about to be
* created, to pass key events, in this case the space key.
*/
ioctl(fd, UI_SET_EVBIT, EV_KEY);
for (int i = 0; i < sizeof(known_keys) / sizeof(*known_keys); i++) {
ioctl(fd, UI_SET_KEYBIT, known_keys[i]);
}
printf("%d known keys registered\n", sizeof(known_keys)/ sizeof(*known_keys));
memset(&usetup, 0, sizeof(usetup));
usetup.id.bustype = BUS_USB;
usetup.id.vendor = 0x1234; /* sample vendor */
usetup.id.product = 0x5678; /* sample product */
strcpy(usetup.name, "Example device");
ioctl(fd, UI_DEV_SETUP, &usetup);
ioctl(fd, UI_DEV_CREATE);
/*
* Give userspace some time to read the events before we destroy the
* device with UI_DEV_DESTOY.
*/
sleep(1000);
ioctl(fd, UI_DEV_DESTROY);
close(fd);
return 0;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-15 11:58 ` Zhai Zhaoxuan
@ 2021-03-18 1:58 ` Dmitry Torokhov
2021-03-18 4:54 ` Zhai Zhaoxuan
0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Torokhov @ 2021-03-18 1:58 UTC (permalink / raw)
To: Zhai Zhaoxuan; +Cc: Greg Kroah-Hartman, linux-input, Markus Rechberger
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-18 1:58 ` Dmitry Torokhov
@ 2021-03-18 4:54 ` Zhai Zhaoxuan
2021-03-20 4:05 ` Dmitry Torokhov
0 siblings, 1 reply; 9+ messages in thread
From: Zhai Zhaoxuan @ 2021-03-18 4:54 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Greg Kroah-Hartman, linux-input, Markus Rechberger
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".
Thanks
Zhai
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-18 4:54 ` Zhai Zhaoxuan
@ 2021-03-20 4:05 ` Dmitry Torokhov
2021-03-20 19:00 ` Zhai Zhaoxuan
0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Torokhov @ 2021-03-20 4:05 UTC (permalink / raw)
To: Zhai Zhaoxuan; +Cc: Greg Kroah-Hartman, linux-input, Markus Rechberger
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG]an input device can not support more than 568 keys due to uevent buffer too small
2021-03-20 4:05 ` Dmitry Torokhov
@ 2021-03-20 19:00 ` Zhai Zhaoxuan
0 siblings, 0 replies; 9+ messages in thread
From: Zhai Zhaoxuan @ 2021-03-20 19:00 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Greg Kroah-Hartman, linux-input, Markus Rechberger
On Sat, Mar 20, 2021 at 12:05 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> 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.
This is a utility that helps the user press keys by reading and
executing user scripts.
At least, on Windows, there are many software programs that can record
users' mouse and keyboard action to a file, and replay the file.
So, do you mean that the user shouldn't be able to do this on linux?
>
> 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.
>
The source of the keys may not come from real physical devices. The
events may be generated from a virtual device, a keyboard utility, or
just a window message. All keys are possible in this situation.
For example, the user can use RDP to connect to a relay server. Then
the user runs remote management software, and presses keys. The remote
management software should receive these keys from the window messages
and it is unable to access the physical keyboard.
> Thanks.
>
> --
> Dmitry
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-20 19:02 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-13 6:32 [BUG]an input device can not support more than 568 keys due to uevent buffer too small Zhai Zhaoxuan
2021-03-13 13:07 ` Greg Kroah-Hartman
2021-03-15 6:58 ` Zhai Zhaoxuan
2021-03-15 7:30 ` Greg Kroah-Hartman
2021-03-15 11:58 ` Zhai Zhaoxuan
2021-03-18 1:58 ` Dmitry Torokhov
2021-03-18 4:54 ` Zhai Zhaoxuan
2021-03-20 4:05 ` Dmitry Torokhov
2021-03-20 19:00 ` Zhai Zhaoxuan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).