Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Apr 2005 14:08:15 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Michael Nottebrock <michaelnottebrock@gmx.net>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: USB mouse troubles
Message-ID:  <20050407120815.GA39638@stack.nl>
In-Reply-To: <200504052117.58620.michaelnottebrock@gmx.net>
References:  <200504052117.58620.michaelnottebrock@gmx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 05, 2005 at 09:17:55PM +0200, Michael Nottebrock wrote:
> FreeBSD 5.x has had funky issues with usb mice for as long as I've
> been using a usb mouse with it, but since it almost works ok with the
> default configuration, I never got around to complain about it. ;-)

AFAIK FreeBSD 4.x has the same issues and some more, e.g. systems with
more than one USB bus require a manual MAKEDEV for hotplugging to work
correctly (as only /dev/usb0 is created by default).

> However: In various sitations and configurations, USB mice are not
> picked up.

I have not tested this at this point, but it agrees with my
understanding of how the code works.

> - With a GENERIC kernel and all of the usb support in the kernel, usb
> mice are usually recognized on boot, but they will cease to work after
> going single user and back to multiuser again. The /dev/ums0 device
> doesn't even get removed, but the mouse is dead. Unplugging and
> replugging usually gets it going again.

On the first startup, usbd will get the initial events (the mouse being
attached at boot time) and start moused. When going to single user,
moused is killed. If usbd is started later, it will not get the initial
events again (also the set of attached devices may have changed since
boot), so will not start moused again.

One fix could be to change usbd to throw away the initial events,
instead doing as if attach events were received for all present USB
devices. This would be nasty if usbd is restarted without a
reboot/single user, which could be fixed by making the new behaviour
optional. This is also nasty if usbd.conf contains an action for a
device instead of starting a process, e.g. automatically copying files
from a umass device. This might be fixed by distinguishing the two in
usbd.conf.

> - With all of usb compiled as modules and usbd enabled in rc.conf, ums
> usually doesn't even get loaded, but usbdevs will show the mouse
> plugged in. Even subsequent unplugging and replugging will not get ums
> loaded. Manually loading ums doesn't get the mouse working either, an
> unplug/replug is necessary first.

usbd loads only the "usb" kld, that will bring in the drivers for the
USB controllers, ugen and uhub and not much more. When the mouse is
plugged in, ugen will grab it (there being nothing better) and will not
release it, even when you subsequently load ums. This happens before
usbd gets to know about the device.

A somewhat crude workaround would be to load the drivers for the devices
to be used before starting usbd. This would mean /boot/loader.conf, most
likely.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050407120815.GA39638>