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

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

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

On Sat, Mar 13, 2021 at 9:07 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:

quoted

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 :)

quoted

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

quoted

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

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
[off-list ref] wrote:

quoted

On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:

quoted

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 :)

quoted

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

quoted

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

On Mon, Mar 15, 2021 at 3:30 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Mon, Mar 15, 2021 at 02:58:11PM +0800, Zhai Zhaoxuan wrote:

quoted

On Sat, Mar 13, 2021 at 9:07 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Sat, Mar 13, 2021 at 02:32:46PM +0800, Zhai Zhaoxuan wrote:

quoted

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 :)

quoted

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

quoted

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

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.)

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.

Thanks.

-- 
Dmitry

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

On Thu, Mar 18, 2021 at 12:54:48PM +0800, Zhai Zhaoxuan wrote:

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

quoted

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".

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

On Sat, Mar 20, 2021 at 12:05 PM Dmitry Torokhov
[off-list ref] wrote:

On Thu, Mar 18, 2021 at 12:54:48PM +0800, Zhai Zhaoxuan wrote:

quoted

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

quoted

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".

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