Re: mouse driver bug in 2.6.0-test7?

From: 4Front Technologies (dev_at_opensound.com)
Date: 10/14/03

  • Next message: Martin MOKREJŠ: "Re: __alloc_pages: 0-order allocation failed on 2.4.23-pre5 and pre7" 
    Date:	Tue, 14 Oct 2003 13:59:11 -0700
To: Vojtech Pavlik <vojtech@suse.cz>

    Vojtech Pavlik wrote:
    > On Tue, Oct 14, 2003 at 01:04:03PM -0700, 4Front Technologies wrote:
    >
    >
    >>>Patch considered. I'll up the samplerate default to 80, but not more,
    >>>since samplerates above that cause trouble for a lot of people (keyboard
    >>>doesn't work when you're moving the mouse).
    >>>
    >>>The "set lower rate in case ..." part of the patch doesn't make sense.
    >>>If the user gives a too low (less than 10) samples per second, then the
    >>>original code will try to set 0, which is stupid, but harmless. The
    >>>added code will try to access beyond the bounds of the rates[] array.
    >>
    >>
    >>Hi Martin/Vojtech,
    >>
    >>Martin, many thanks for your fix - it works perfectly now.
    >>
    >>Oddly enough the sample rate of 200 seems to have fixed the problem.
    >>Vojetech, Martin's fixes are fully functional.
    >
    >
    > Not completely. One reason wht the sample rate of 200 probably fixed the
    > problem is that you have very high acceleration settings in X.
    >
    > Since with report rate 200 you get a medium speed movement as
    >
    > +1 +1 +1 +1 +1 +1 +1 +1 +1
    >
    > events, and with report rate 60 you get
    >
    > +3 +3 +3
    >
    > and the X mouse acceleration code is stupid enough to judge the mouse
    > speed from the event VALUE only, it thinks the mouse is moving much
    > faster in the second case.
    >
    > You need to up the acceleration threshold (or disable acceleration
    > completely).
    >
    > This also means that with report rate of 200, mouse acceleration is more
    > or less disabled, since you get +1's only even at quite high speeds of
    > mouse movement.
    >

    Vojtec/Martin

    You're right, the original problem still remains. The tracking is still
    2x compared to Linux 2.4.

    Here's how I did the measurement.
    Get a foot-scale and start xev. Ajust xev so that the coordiates of the
    window are 0,y (y is y-axis - don't care) in the X root window (my res is 1024x768).

    Now align the mouse so that it shows 0,0 on the top left corner in the xev window
    and move the mouse exactly one 1 inch and you'll see that under Linux 2.6.0-test7
    the x axis position is at something like 325. However repeating the same test under
    Linux 2.4.22 puts the mouse at x axis position 170 (gives me a accelearation factor
    of about 2x).

    This is a horribly crude test but it explains my problem that the mouse driver isn't
    tracking correctly.

    Hope this helps figuring out the problem.

    best regards

    Dev Mazumdar
    ---------------------------------------------------------------------
    4Front Technologies
    4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
    Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
    ---------------------------------------------------------------------

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Martin MOKREJŠ: "Re: __alloc_pages: 0-order allocation failed on 2.4.23-pre5 and pre7"