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@xxxxxxxxxxxxxxxxxxx> 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
