xpra icon
Bug tracker and wiki

Opened 10 months ago

Closed 10 months ago

Last modified 10 months ago

#1428 closed defect (fixed)

Mouse wheel works only down but not up

Reported by: Lukas Haase Owned by: Lukas Haase
Priority: major Milestone: 2.0
Component: client Version: 1.0.x
Keywords: wheel win32 Cc:

Description

This bug report is created based on the following thread:

http://lists.devloop.org.uk/pipermail/shifter-users/2017-February/001852.html

With Xpra 1.0 client under Windows 10 the xpra client does not transmit messages for mouse wheel "up" but it does so for mouse wheel "down". When testing with xev, scrolling down displays the following messages:

ButtonPress event, serial 36, synthetic NO, window 0xc00001,
    root 0x25d, subw 0x0, time 1389734833, (177,154), root:(445,445),
    state 0x0, button 5, same_screen YES

ButtonRelease event, serial 36, synthetic NO, window 0xc00001,
    root 0x25d, subw 0x0, time 1389734833, (177,154), root:(445,445),
    state 0x1000, button 5, same_screen YES

whereas scrolling up generates none.

The problem is on the Windows xpra client because when using an X server (Xming) under the same Win 10 system and connecting via "xpra attach" from within PuTTY works.

Starting the client with "-d mouse" generates the following messages when scrolling down:

2017-02-02 17:29:41,362 mousewheel: send 1 wheel events to the server for distance=-120, remainder=0
2017-02-02 17:29:41,382 mousewheel: orientation=vertical distance=-30.0, units=-1, new value=-30.0, keys=0x0, x=434, y=375, client=gtk2.client, wid=218

The messages are displayed everytime the wheel is turned a bit. When scrolling up, only the following is displayed:

2017-02-02 17:28:29,496 mousewheel: orientation=vertical distance=30.0, units=0, new value=0.0, keys=0x0, x=439, y=360, client=gtk2.client, wid=218

Again, every small turn generates this message. Note however, that the "send 1 wheel events" message is missing in this case.

It works in VirtualBox? in a Win7 VM. The host is Win 10. Maybe this is the issue. The issue occurs with four different mice.

Please let me know if I can attach more information.

Attachments (2)

wheel_up.log (100.9 KB) - added by Lukas Haase 10 months ago.
Log with mouse only
wheel_up_all.log (166.0 KB) - added by Lukas Haase 10 months ago.
Log with mouse and win32

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 months ago by Lukas Haase

I forgot to mention that there is never any event received by xev when scrolling up; not even when scrolling up for a minute. While the "mousewheel: orientation=vertical distance=-30.0" are generated every single touch, the "send 1 wheel events to the server" messages never appear.

comment:2 Changed 10 months ago by Antoine Martin

Owner: changed from Antoine Martin to Lukas Haase

Please include a series of scrolling up log event messages with "-d mouse" so we can see the "distance" accumulating. (or not perhaps..)
If the distance stays the same, it may be worth running with "-d mouse,win32" or event "-d all" to see what is resetting the distance in between events.

Last edited 10 months ago by Antoine Martin (previous) (diff)

Changed 10 months ago by Lukas Haase

Attachment: wheel_up.log added

Log with mouse only

Changed 10 months ago by Lukas Haase

Attachment: wheel_up_all.log added

Log with mouse and win32

comment:3 Changed 10 months ago by Lukas Haase

Added the log files.

For both I moved the mouse into the X client window and tried not moving the mouse except scrolling the wheel up for many seconds.

I think they do not provide too much more insight. Distance changes but in a very strange way ...

comment:4 Changed 10 months ago by Antoine Martin

Keywords: wheel win32 added
Milestone: 2.0

It's an interesting bug: it only occurs if the mouse wheel acceleration value is lower than the default (30 vs 120).

We use this ratio to decide if we need to send an event or not:

python -c "print(30//120)"
0
python -c "print(-30//120)"
-1

And when we weren't sending an event, we failed to store the left over.

r14960 (+improved in r14961) fix that and will be backported to the 1.0.x branch.
You can find a new beta 2.0 build with this fix here: http://xpra.org/beta/windows/.
Please close if this works for you.

comment:5 Changed 10 months ago by Lukas Haase

Resolution: fixed
Status: newclosed

Great, works for me! Thanks

comment:6 Changed 10 months ago by Antoine Martin

Applied to v1.0.x in r14967.

Note: See TracTickets for help on using tickets.