Re: AW: Levovo trackpoint events come delayed (reproducable with xev)

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

>>> You should then be able to see WM_MOUSEWHEEL messages being delivered in the
>>> debug output from XWin when you use the trackpoint scrolling.  Are they being
>>> delivered on time?

> Description of my testing that produced that log:
> 
> 1. with xterm
>    - second 304: I press center button and try to scroll with Lenovo trackpoint.
>      I don't release the center button for some seconds.
>      xterm shows no scrolling
>    - second 310: I release the center button. 
>      xterm jump scrolls a far distance all at once.
> 
> 2. same with xev
>    - second 360: I press center button and try to scroll with Lenovo trackpoint (ok, there is nothing to scroll in a xev, but I
> think you understand what I did).
>      I don't release the center button for some seconds.
>    - second 364: I release the center button. 
> 
> The rest is XWin startup or my "kill -9 [XWin]" or opening xterms or other irrelevant stuff.
> 
> Regarding "'WIN_DEBUG_MESSAGES=1": Because I start XWin from a tcsh shell, I added a 
> "setenv WIN_DEBUG_MESSAGES 1" before the XWin call. Did that work out, i. e. was that setting active?

Yes, these logs contain the required detail.

Unfortunately, they don't seem to show that XWin is doing anything wrong.

WM_MOUSEWHEEL [1] messages are only being sent to XWin at the point in time
you mention the center button being released, but are then correctly converted
into X events.

e.g.
[   309.303] winWindowProc - WM_MOUSEWHEEL - 0x07800000 0x0152030f
is converted into a sequence of press/release events for the zaxis up button
[   309.303] winMouseButtonsSendEvent: iEventType: 4, iButton: 4
[   309.303] winMouseButtonsSendEvent: iEventType: 5, iButton: 4

I have to say this really looks like some kind of issue with the trackpoint
software or it's configuration.

I also note that the 'configuration' of the trackpoint driver as described in
[2] matches on the executable name, so that won't be doing anything useful in
this case, as the executable is called 'XWin.20120806-git-25dd890818f3e308
.exe' and not 'XWin.exe'

It would be interesting to compare with a similar log when 'ico' is also
running, since apparently that makes things behave correctly.

[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617%28v=vs.85%29.aspx
[2] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/