>>> 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/

Reply via email to