Bug 28682

Summary: input drivers support limited device numbers (EVDEV_MINORS is 32)
Product: Drivers Reporter: Alexander Todorov (atodorov)
Component: Input DevicesAssignee: drivers_input-devices
Status: RESOLVED CODE_FIX    
Severity: normal CC: alan, atodorov, dmitry.torokhov, kay, nightguard2020
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.5 Subsystem:
Regression: No Bisected commit-id:

Description Alexander Todorov 2011-02-09 12:02:28 UTC
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).
Comment 1 Kay Sievers 2012-05-24 07:59:28 UTC
"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. :)
Comment 2 Dmitry Torokhov 2012-05-24 15:48:33 UTC
(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.
Comment 3 Jeffrey Plum 2012-08-21 12:13:16 UTC
 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.
Comment 4 Alexander Todorov 2013-11-25 14:59:59 UTC
Closing per:
https://bugzilla.redhat.com/show_bug.cgi?id=676300#c3