> -----Original Message----- > From: xorg-devel-bounces+shashi.shekar=ti....@lists.x.org > [mailto:xorg-devel-bounces+shashi.shekar=ti....@lists.x.org] > On Behalf Of Tiago Vignatti > Sent: Thursday, June 10, 2010 4:38 PM > To: ext Daniel Stone > Cc: xorg-devel@lists.x.org; Richard Barnette > Subject: Re: performance of USB mouse initialization on startup > > 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? > That's better. 2 less drivers for people in Linux world to worry about!
-Shashi _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel