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. And what do you think, Dmitry? > > thanks, > > greg k-h Thank you, Zhai Zhaoxuan
