Ok - I'm a freak - I do a 'pacman -Syu' just about every (or every 2nd) day.
About a week ago - and I do believe it was with 2.6.15-4, after the update the usb-mouse on my laptop can not be found.
The built-in poitning devices (glidepoint) is there OK, but I usually use an external optical usb mouse - which now just disappears into usb-hell !
"new low speed USB device using ohci_hcd and address 3"
but it is definitely not being associated with /dev/psaux or any of the 'usual' pointing devices!!
Please - help me get my mouse back!!!
Maybe /dev/input/mice would work?
sorry but no - I must be missing out on something.
Shouldn't dmesg at least show me that it made some kind of association between the 'low speed usb device' and one of the recognized pointing devices ...
It's all so friggin' complicated! We used to have /dev/mouse - and things kinda worked. Now we have /dev/psaux, /dev/misc/psaux and /dev/input/mice - go figger!!
Anyone - please enlighten me!
AFAIK: /dev/mouse always was a link to the actual device - usually /dev/psaux. DevFS structure put psaux in /dev/misc/psaux instead just like it put /dev/hda in /dev/discs/disc0/disc. Udev had some links to support the devfs structures, which I tihnk I heard were removed recently. /dev/input/mice is a new link to an actual mouse - now often /dev/input/mouse0. /dev/psaux link was retained for compatibility, but deprecated.
Correct me if I'm wrong.
do you have the usbhid module loaded? you need that for mice.
i've never used module autoloading, i always did it manually. for some reason, i never had put usbhid in my rc.conf. perhaps udev was loading it for me. i just had to start manually loading it, which i should have been doing in the first place anyway, to be consistent.
/dev/input/mice is the new symlink to an actual mouse - now often /dev/input/mouse0.
you're almost right, heh. /dev/input/mice is actually a device that copies /dev/input/mouse* ... that way, if you have more than one mouse connected, you can tell X to read them all in your xorg.conf
Thank y'all ever so much - using 'usbhid' did it!!
Guess I should be thankful (which I _am_) and leave it like that - but ...
What has changed around udev (within the last week) that prevents usbhid from loading by default?? (or should I not ask??)
Maybe if there is sufficient documentation somewhere - someone could point my nose in the right direction?
Again - thak y'all for helping me getting my mouse back - much appreciated!
are you using module autoloading?
i'm not, and i think i know why. autoloading was previously handled by hwdetect at bootup. udev would do some autoloading when you plug things in, but you couldn't disable that.
now, autoloading is all handled by udev, at bootup and runtime, and you can disable it all if you like.
so basically, usbhid must have been loaded by udev when your mouse was "plugged in" (ie detected by the newly loaded usb driver), and now with module autoloading completely disabled, it won't do it anymore.
this is just my theory, it doesn't make sense if you have autoloading on.