Hi Andrey and Shawn :)
* "Andrey Borzenkov" <[email protected]> dixit:
> > I'm sure I'm just missing something stupid, but google doesn't
> > seem to turn up anything, so...
Exactly the same for me...
> > I'm trying to use 2.6.0-test9 on a machine with a USB mouse. With 2.4, I
> > have X configured to use /dev/input/mice (c 13 63) as my mouse pointer,
> > and it works great. With test9, XFree86 fails to start because it can't
> > open the mouse. The error is "xf86OpenSerial: Cannot open device /dev/
> > input/mice No such device.".
My problem is a bit different. I'm using 2.4.21, with an USB
mouse. I have 'input' built-in, and hid and mousedev as modules.
Well, if I do a cat /dev/mouse (c 13 32) or /dev/mice (c 13 63), I
always get ENODEV, unless I manually load hid and mousedev. The logs
doesn't say anything like 'cannot find driver for char-major-13' or
whatever. It just seems that 'mousedev' is never autoloaded :?
> The whole input subsystem has changed between 2.4 and 2.6.
> Unfortunately, input sysbsystem hotplugging is not currently
> implemented. Your best bet is to forcibly load mousedev during
> boot.
But hotplugging is for connecting and disconnecting devices, not
for autoloading modules. I mean, if I access any char-major-13, and
the corresponding modules is not loaded, it should autoload :?
The rest of devices in my system are properly autoloaded on
demand, but hid and mousedev are not :( Am I doing something wrong?
> Alternatively look into hotplug for usermap, it allows provide fake
> mapping for modules - you could add mapping from UDB IDs of oyur
> mouse to mousedev. Loading it statically is likely to be more
> simple.
Exactly... Anyway, if I build 'mousedev' into my kernel instead
of making it a module, should I do the same with 'hid' or
char-major-13 *is* autoloaded?
Thanks a lot in advance. I'm missing on this subject...
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
On Saturday 01 November 2003 23:56, DervishD wrote:
[...]
>
> My problem is a bit different. I'm using 2.4.21, with an USB
> mouse. I have 'input' built-in, and hid and mousedev as modules.
> Well, if I do a cat /dev/mouse (c 13 32) or /dev/mice (c 13 63), I
> always get ENODEV, unless I manually load hid and mousedev. The logs
> doesn't say anything like 'cannot find driver for char-major-13' or
> whatever. It just seems that 'mousedev' is never autoloaded :?
>
Well, major 13 is for all input devices not for mousedev alone. 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.
You may add explicit per-minor autoloading to input.c, see
drivers/input/input.c:input_open_file()
> > The whole input subsystem has changed between 2.4 and 2.6.
> > Unfortunately, input sysbsystem hotplugging is not currently
> > implemented. Your best bet is to forcibly load mousedev during
> > boot.
>
> But hotplugging is for connecting and disconnecting devices, not
> for autoloading modules. I mean, if I access any char-major-13, and
> the corresponding modules is not loaded, it should autoload :?
>
> The rest of devices in my system are properly autoloaded on
> demand, but hid and mousedev are not :( Am I doing something wrong?
>
no. Loading on demand simply is not supported.
If you are using hotplug, both should be loaded by hotplug. IMHO it is also
the right way to go.
> > Alternatively look into hotplug for usermap, it allows provide fake
> > mapping for modules - you could add mapping from UDB IDs of oyur
> > mouse to mousedev. Loading it statically is likely to be more
> > simple.
>
which is of course already available in hotplug, sorry for confusion.
> Exactly... Anyway, if I build 'mousedev' into my kernel instead
> of making it a module, should I do the same with 'hid' or
> char-major-13 *is* autoloaded?
>
char-major-13 is 'input'. Period. It is not mousedev or whatever. For this
reason it must implement its own autoloading if desired. Cf. misc driver.
Hid will never be autoloaded (without manual configuration) on access to
mousedev because they are independent. Mousedev provides use interface to any
mouse, not just USB mouse handled by HID. Mousedev has no way to know what
hardware is connected until driver for it has registered with input layer. So
hid should be loaded when mouse is detected (i.e. by hotplug) or manually if
you always know you have USB mouse. Building it in kernel is the easiest way
to ensure it is always available.
-andrey
Hi Andrey :)
Thanks for answering :)
* Andrey Borzenkov <[email protected]> dixit:
> > whatever. It just seems that 'mousedev' is never autoloaded :?
> Well, major 13 is for all input devices not for mousedev alone.
I know, but I just use it for mousedev O:)
> 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.
> 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? Currently input_open_file just returns
ENODEV in that case, but I don't know how to request for autoloading
O:) In fact, if Vojtech hasn't already done that surely there is a
very good reason not to do it... I prefer not modify the kernel for
that. If the only solution is making mousedev and hid built-in
instead of modules, I can do it.
> > The rest of devices in my system are properly autoloaded on
> > demand, but hid and mousedev are not :( Am I doing something wrong?
> no. Loading on demand simply is not supported.
OK..
> 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.
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).
> > Exactly... Anyway, if I build 'mousedev' into my kernel instead
> > of making it a module, should I do the same with 'hid' or
> > char-major-13 *is* autoloaded?
> char-major-13 is 'input'. Period. It is not mousedev or whatever. For this
> reason it must implement its own autoloading if desired. Cf. misc driver.
My excuses O:) I was refering to char-major-13-32 (or -64, is
just the same for me).
> Hid will never be autoloaded (without manual configuration) on access to
> mousedev because they are independent.
Yes, I knew that. It is loaded by hotplug or by hand (or even
with 'above' or 'below' when another module is autoloaded, I
suppose).
> Building it in kernel is the easiest way to ensure it is always available.
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'?
Thanks a lot for your help :))
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
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
Hi Andrey :)
* Andrey Borzenkov <[email protected]> dixit:
> > But not char-major-13-32, for example.
> for kernel device == major. It is assumed that complete major is
> handled by single driver.
OK, now all makes sense :)
> 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.
But, is it possible? Just guessing...
> > 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.
It's easier if I just build it in. No need to mess with
modules.conf for this one. The memory gain for having hid and
mousedev as modules is minimal.
Thanks for all the explanations :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/