public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@mail.ru>
To: DervishD <raul@pleyades.net>
Cc: Shawn Willden <shawn-lkml@willden.org>, linux-kernel@vger.kernel.org
Subject: Re: /dev/input/mice doesn't work in test9?
Date: Sun, 2 Nov 2003 20:45:41 +0300	[thread overview]
Message-ID: <200311022045.41928.arvidjaar@mail.ru> (raw)
In-Reply-To: <20031102120820.GC206@DervishD>

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


  reply	other threads:[~2003-11-02 18:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-31  8:03 /dev/input/mice doesn't work in test9? "Andrey Borzenkov" 
2003-10-31 14:27 ` Shawn Willden
2003-11-01 20:56 ` DervishD
2003-11-02 10:12   ` Andrey Borzenkov
2003-11-02 12:08     ` DervishD
2003-11-02 17:45       ` Andrey Borzenkov [this message]
2003-11-02 20:37         ` DervishD
  -- strict thread matches above, loose matches on Subject: below --
2003-10-30 18:32 Shawn Willden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200311022045.41928.arvidjaar@mail.ru \
    --to=arvidjaar@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raul@pleyades.net \
    --cc=shawn-lkml@willden.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox