From: Andrey Borzenkov <arvidjaar@mail.ru>
To: DervishD <raul@pleyades.net>
Subject: Re: /dev/input/mice doesn't work in test9?
Date: Sun, 2 Nov 2003 20:45:41 +0300
User-Agent: KMail/1.5.3
Cc: Shawn Willden <shawn-lkml@willden.org>, linux-kernel@vger.kernel.org
References: <E1AFUFz-0008jt-00.arvidjaar-mail-ru@f20.mail.ru> <200311021312.15902.arvidjaar@mail.ru> <20031102120820.GC206@DervishD>
In-Reply-To: <20031102120820.GC206@DervishD>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200311022045.41928.arvidjaar@mail.ru>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3255
Lines: 83

On Sunday 02 November 2003 15:08, DervishD wrote:
[...]
>
> > You have input built-in which means there is no reason for kernel
> > to try autoload driver for char-13 as it is already available.
>
>     But not char-major-13-32, for example.
>

for kernel device == major. It is assumed that complete major is handled by 
single driver. In exception cases when there are different drivers either you 
have one acting like dispatcher (input case) or one that simply requests more 
specific driver (misc case). But again, mousedev is using range of minors and 
there is currently no established way to construct aliases for that. Short of 
defining

alias char-major-13-32 mousedev
alias char-major-13-33 mousedev
...
alias char-major-13-63 mousedev

looks rather weird.

> > You may add explicit per-minor autoloading to input.c, see
> > drivers/input/input.c:input_open_file()
>
>     But that code works with the 'input_table', and the
> input_handlers. The handlers are registered by the modules when they
> are already loaded. Do you mean that I should modify input_open_file
> in order to autoload the appropriate module in the case of the
> handler not being present? 

yes with the caveats above.

[...]
>
> > If you are using hotplug, both should be loaded by hotplug. IMHO it is
> > also the right way to go.
>
>     The problem is that hotplug doesn't work for me in this case. I
> mean, with hotplug in *this particular case*, since the mouse is
> always connected, the modules will be loaded on bootup and unloaded
> on shutdown, not when the mouse device is opened and closed,
> respectively.
>

that is what coldplug is for. Hotplug comes with initscript that (if enabled) 
looks for devices already connected and emulates "connect" event for them. I 
use it between other things to load mousedev for PS/2 mouse that is always 
connected ... but I am running 2.6 in the first place (it won't work on 2.4) 
and modified hotplug package that supports input handlers. So when it finds 
any driver for input devices it automatically loads input handler for events 
generated by those devices.

>     I've tested with hotplug (well, I don't have hotplug utilities
> installed, just a shell script that tells me if someone is calling
> /sbin/hotplug and logs the parameters), and /sbin/hotplug is not
> called when I try to open /dev/mouse (c 13 32).
>

of course not. It works differently. When you plug in USB mouse (or when 
hotplug initscript emulates plugging in USB mouse) hotplug calls USB agent. 
USB agent checks USB device ID and finds which modules to load. It is 
possible that it finds several modules. One of them is hardcoded - it is 
mousedev. Another one is hid that declares itself as driver for USB mouse. 
That simple.

[...]
>
>     Yes, I'm going to build in hid, but, should I do the same with
> mousedev (or event, joystick, etc...) or will it work with hid loaded
> when doing 'cat /dev/mouse'?
>

yes you should build it in. Or ensure it is loaded together with hid. 

-andrey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/