Hello, I've hit a problem with the evdev driver supporting up to 32 event* devices. This is because EVDEV_MINORS is hardcoded to 32. I experience this problem on a big multi-seat system where I have multiple keyboards and mice (all USB) and it happens that an input device becomes the 33rd device. I though that simply bumping EVDEV_MINORS will solve the issue but as it seems it's not that easy. Here's a comment that I got from Dmitry Torokhov: <quote> Input core splits minors into 32 devices groups and routs them thusly: drivers/input/inpit.c::input_open_file(): handler = input_table[iminor(inode) >> 5]; if (!handler || !(new_fops = fops_get(handler->fops))) { err = -ENODEV; goto out; } If you want to increase number of EVDEV_MINORS you need to disable mousedev & joydev, get rid of this selector (and hardcode to always get evdev handler). Obviously this a solution suitable for mainline... </quote> Filing here to track the issue and possible fixes. NB: I suspect that there will be a workaround for my particular case but it will be nice if there's no limit on input devices. (For example someone could attach 50 keyboards to their system for some reason).
"If you want to increase number of EVDEV_MINORS you need to disable mousedev & joydev, get rid of this selector (and hardcode to always get evdev handler)." That's a joke, right? Minors are 20 bits wide since quite some years. Dmitry, let me know if there are any unsolved technical problems in porting the input layer's device handling to the year 2012. :)
(In reply to comment #1) > Dmitry, let me know if there are any unsolved technical problems in porting > the input layer's device handling to the year 2012. :) Lack of patches from interested parties.
I know only a bit about C, but I caught another implicit hardcoding in the code snippet shown. EVDEV_MINORS is Hardcoded =32. Devices are divided into 32 unit groups and routed via 5 bit ( ">>5") shift. (2^5 = 32) It seems clear raising the EVDEV_MINORS limit actually runs up against other X=32 based limits. Given only EVDEV_MINORS and the code shown, I'd test like this. Old Code EVDEV_MINORS = 32 drivers/input/inpit.c::input_open_file(): handler = input_table[iminor(inode) >> 5]; if (!handler || !(new_fops = fops_get(handler->fops))) { err = -ENODEV; goto out; } New version (very much a blind test hack) EVDEV_MINORS = 64 drivers/input/inpit.c::input_open_file(): handler = input_table[iminor(inode) >> 6]; if (!handler || !(new_fops = fops_get(handler->fops))) { err = -ENODEV; goto out; } I'd also explore where input_table[] was dimensioned.
Closing per: https://bugzilla.redhat.com/show_bug.cgi?id=676300#c3