performance of USB mouse initialization on startup

[Peter Hutterer]

On Thu, Jun 10, 2010 at 02:08:14PM +0300, Tiago Vignatti wrote:
> On Thu, Jun 10, 2010 at 01:04:34PM +0200, ext Daniel Stone wrote:
> > 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
> > > http://www.computer-engineering.org/ps2mouse/.
> > > 
> > > 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.
> 
> Does it makes sense to set a trap on autoconf to disables Linux on those
> drivers then?

no. we don't stop people from shooting themselves in the foot. we just
recommend they don't.

both drivers still work fine under Linux, for some definition of "fine"
anyway.

Cheers,
  Peter