Re: /dev/input/mice doesn't work in test9?

Re: /dev/input/mice doesn't work in test9?

["Andrey Borzenkov"]

> I'm sure I'm just missing something stupid, but google doesn't seem to turn 
> up anything, so...

> 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.".

> 'cat /dev/input/mice' also gives me "No such device".

> /dev/input/mouse0 (c 13 32) doesn't work either.

> I believe all of the relevant modules are loaded and the light on my 
> optical mouse is lit, indicating that it has been powered by the usbmouse 
> driver (as I understand it).

You are missing mousedev that is the driver that actually provides
/dev/input/mice. usbmouse (which is actually redundand with hid) speaks
with hardware and mousedev speaks with user :)

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. 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.

regards

-andrey

Re: /dev/input/mice doesn't work in test9?

[Shawn Willden]

On Friday 31 October 2003 01:03 am, Andrey Borzenkov wrote:
> Your best bet
> is to forcibly load mousedev during boot. 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.

Thank you very much.  Loading statically worked; I'll look into a nicer 
solution when I have a chance.

Shawn.

Re: /dev/input/mice doesn't work in test9?

[DervishD]

    Hi Andrey and Shawn :)

 * "Andrey Borzenkov"  <arvidjaar@mail.ru> 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/

Re: /dev/input/mice doesn't work in test9?

[Andrey Borzenkov]

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

Re: /dev/input/mice doesn't work in test9?

[DervishD]

    Hi Andrey :)

    Thanks for answering :)

 * Andrey Borzenkov <arvidjaar@mail.ru> 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/

Re: /dev/input/mice doesn't work in test9?

[Andrey Borzenkov]

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

Re: /dev/input/mice doesn't work in test9?

[DervishD]

    Hi Andrey :)

 * Andrey Borzenkov <arvidjaar@mail.ru> 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/

/dev/input/mice doesn't work in test9?

[Shawn Willden]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

I'm sure I'm just missing something stupid, but google doesn't seem to turn 
up anything, so...

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.".

'cat /dev/input/mice' also gives me "No such device".

/dev/input/mouse0 (c 13 32) doesn't work either.

I believe all of the relevant modules are loaded and the light on my 
optical mouse is lit, indicating that it has been powered by the usbmouse 
driver (as I understand it).

Any suggestions as to what might be wrong or how I could investigate it?

I'm attaching the output of lsmod, in case it's useful.  The test9 build 
I'm using is the one packaged by Debian.

Thanks,

Shawn.

[-- Attachment #2: lsmod --]
[-- Type: text/plain, Size: 2365 bytes --]

Module                  Size  Used by
md5                     3968  1 
ipv6                  234688  8 
sd_mod                 15776  0 
sg                     34840  0 
sr_mod                 15396  0 
scsi_mod              110136  3 sd_mod,sg,sr_mod
ide_cd                 38020  0 
cdrom                  32416  2 sr_mod,ide_cd
usbmouse                5376  0 
hid                    30528  0 
smbfs                  61944  0 
uhci_hcd               30224  0 
ohci_hcd               17536  0 
ehci_hcd               22532  0 
usbcore               101980  7 usbmouse,hid,uhci_hcd,ohci_hcd,ehci_hcd
parport_pc             34220  1 
lp                     10560  0 
parport                40552  2 parport_pc,lp
via82cxxx_audio        27144  0 
uart401                11460  1 via82cxxx_audio
sound                  77996  2 via82cxxx_audio,uart401
soundcore               9152  2 via82cxxx_audio,sound
ac97_codec             17292  1 via82cxxx_audio
rtc                    12344  0 
ext3                  107688  2 
jbd                    56728  1 ext3
ide_disk               16384  4 
via82cxxx              13596  1 [unsafe]
trm290                  4996  0 
triflex                 5508  0 
slc90e66                8200  0 
sis5513                15496  0 
siimage                13028  0 
serverworks            12308  0 
sc1200                  8584  0 
rz1000                  3200  0 
piix                   11936  0 
pdc202xx_old           15388  0 
opti621                 4740  0 
ns87415                 5064  0 
hpt366                 19396  0 
hpt34x                  5504  0 
generic                 4096  0 
cy82c693                4996  0 
cs5530                  6792  0 
cs5520                  6280  0 
ide_probe_mod          16384  1 cs5520,[unsafe]
cmd64x                 11676  0 
amd74xx                12312  0 
alim15x3               11404  0 
aec62xx                 9756  0 
pdc202xx_new           11548  0 
ide_mod               137260  27 ide_cd,ide_disk,via82cxxx,trm290,triflex,slc90e66,sis5513,siimage,serverworks,sc1200,rz1000,piix,pdc202xx_old,opti621,ns87415,hpt366,hpt34x,generic,cy82c693,cs5530,cs5520,ide_probe_mod,cmd64x,amd74xx,alim15x3,aec62xx,pdc202xx_new
unix                   26928  22 
font                    8576  0 
cfbcopyarea             4096  0 
cfbimgblt               3456  0 
cfbfillrect             3968  0