performance of USB mouse initialization on startup
tiago.vignatti at nokia.com
Thu Jun 10 04:08:14 PDT 2010
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
More information about the xorg-devel