performance of USB mouse initialization on startup

Daniel Stone daniel at
Thu Jun 10 04:04:34 PDT 2010

On Wed, Jun 09, 2010 at 12:26:34PM -0700, Richard Barnette wrote:
> "And for my next trick..."
> Initialization for PS/2 compatible mice uses a number of explicit calls
> to usleep().  The code mostly lives in src/pnp.c, under
> xorg/driver/xf86-input-mouse.
> The pattern of sleep calls is sufficiently systematic to suggest
> that they're specifically prescribed by a hardware spec.  Alas,
> hardware specs for the PS/2 mouse, MS IntelliMouse, IntelliMouse
> Explorer, etc. aren't readily available online to confirm this.  The
> best reference I've found is
> The Linux USB mouse driver for /dev/input/mice emulates the IntelliMouse
> and IntelliMouse Explorer (a.k.a. "ImPS/2" and "ExplorerPS/2" in
> src/mouse.c)
> in software.  AFAICT, the usleep() calls are unneeded for USB mice on
> Linux.  (I've tested and confirmed that deleting the calls has no
> immediately visible impact on Chromium OS).
> The usleep() calls during mouse initialization total up to 230 ms on my
> test configuration.  That's big enough to cry out for a fix.  However,
> I assume that merely deleting the calls will break a hardware config
> that
> somebody, somewhere still cares about.  My first cut a fix that
> preserves
> compatibility would be to add a new protocol (e.g. "LinuxUSB") that
> tracks either "ImPS/2" or "ExplorerPS/2", but omits unnecessary delays.
> Any advice on this?

Don't use xf86-input-mouse, or xf86-input-keyboard! Really, don't.  Use
evdev.  It's less shit, starts up quicker, supports a lot more stuff, is
actually maintained, has no unnecessary usleeps, and basically you'll
just hate your life less.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <>

More information about the xorg-devel mailing list