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