This is a discussion on Re: jerky mouse still in 7.0-RELEASE - FreeBSD ; On Thursday 28 February 2008 02:48 pm, Kris Kennaway wrote: > Jung-uk Kim wrote: > > On Thursday 28 February 2008 01:30 pm, Teemu Korhonen wrote: > >> Did anyone find a solution to the "jerky mouse" -problem? It > ...
On Thursday 28 February 2008 02:48 pm, Kris Kennaway wrote:
> Jung-uk Kim wrote:
> > On Thursday 28 February 2008 01:30 pm, Teemu Korhonen wrote:
> >> Did anyone find a solution to the "jerky mouse" -problem? It
> >> still exists in 7.0-RELEASE.
> >> I have pretty much exact same symptoms as in this post:
> > http://lists.freebsd.org/pipermail/f...008-January/03
> > No. However, the problem was well analyzed by delphij:
> > http://docs.freebsd.org/cgi/mid.cgi?47C320DB.70004
> > Jung-uk Kim
> Hmm, that is strange. The real question is why X is doing so many
> gettimeofday syscalls at all.
'For a motion event, the driver calls now xf86PostMotionEvent() and we
are back on the server's side. For button events it is
xf86PostButtonEvent(). Those in turn call GetPointerEvents()
(GetKeyboardEvents() for keyboard events) which creates the necessary
number of events and returns them to the caller. GetTimeInMillis() is
called inside GetPointerEvents() and timestamps the OS time on the
event. Inside the same function, miPointerSetPosition() is called to
re-paint the mouse on the screen. It calls miPointerMoved(). The
miPointerMoved() decides to start the hw or the sw
management/rendering of the cursor (see section Cursor rendering).
After this choose the events are put - one by one - onto the event
queue using mieqEnqueue().'
I believe GetTimeInMillis() is unavoidable. It uses gettimeofday(2)
or clock_gettime(2) depending on OS since xorg-server-18.104.22.168:
Somehow it was not used in FreeBSD, though:
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"