Bug 74713

I spent a few hours learning how to git-bisect, and I found the commit that introduced the issue for me:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=9bf46610a9d20962854016032de4567974e87957

Reverting this commit results in my mousewheel working correctly in my game

I would propose a patch that simply reverses it, but surely there is a way to keep the proposed changes in this commit and at the same time fix my issue.

For now I'll just revert on my system

Thanks

Jason

That would be a rather odd side-effect of that patch. Can you hook up xscope and check the actual values being sent are incorrect?

I think the issue will be related to the event/reply? being sent split between two different packets (from two separate calls to WriteToClient) and the reconstruction going wrong. If this is the case, the error would crop up randomly in normal usage if the Client buffer had just sufficient backlog to force the flush between the two WriteToClient. Checking the data on the wire is definitely the best first step in debugging this.

(In reply to comment #2)
> That would be a rather odd side-effect of that patch. Can you hook up xscope
> and check the actual values being sent are incorrect?

I will try to get xscope running (never used it myself, and by reading the manual I'm not sure yet how to set it up), but I highly doubt I'm in a position of knowing if values are correct or not. 

I found this commit with trial-and-error with git-bisect, recompiling each time and manually testing if the issue was present or not.

Once I have some output / log I'll attach it here

Thanks

Jason

$ echo $DISPLAY
:0
$ xscope -i4 -o0 > xscope.out
$ DISPLAY=:4 someprogram

-i and -o map to the numbers in the current display and the one you want to set for the program. usually $DISPLAY is :0, so 0, the other one is free for the choosing.

The output is human-readable so you should be able to debug at least the input events. if the button number itself changes in the event then we have some other issue, if it's a re-assembling issue then xscope may provide some hints there too.

Created attachment 93813 [details]
xscope data when the issue is present (commit not reverted)

Created attachment 93814 [details]
xscope data when the issue is NOT present (commit reverted)

Thank you Peter for your assistance regarding xscope

I have attached to the bug two versions of the output, one with the problem present, and another one where I reverted the commit (and the problem does not appear).

The buttons numbers seem to be the same (Mod2 on press, Mod2 | Button5 on release), so it must be something else?

I have not included output that happened before and after mouse movement. If needed I'll re-run it and include the entire file

Thanks

Jason

Hello.

Have you taken a look at the dumps I included in my previous post?

The issue is still present with 1.15.1, and reverting the commit still works to correct it.

(PS: This is not a major issue, but still is quite annoying. I can try contacting Valve again, there is a chance there's something on their end, but their communication is quite the opposite of "good"..)

Thanks

Jason

Hi all,

The issue is still present in 1.16. Is anyone working on it? I am about to recompile xorg to try and fix the issue myself on my system.

Thanks,
Dan

X.Org X Server 1.16.0
Release Date: 2014-07-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-70-generic x86_64 Ubuntu
Current Operating System: Linux pootar 3.16.0-31-generic #43-Ubuntu SMP Tue Mar 10 17:37:36 UTC 2015 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-31-generic root=UUID=7b53f358-e096-4c39-9f17-e21ca8b12e6a ro quiet splash
Build Date: 12 February 2015  02:46:23PM
xorg-server 2:1.16.0-1ubuntu1.3 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.32.4
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

the two xscope outputs don't hint at anything here. the button events are 4/5 in both outputs (well, one output only has button 5 events, but that's probably input data).

For the buttons to be thumb buttons, the button numbers would have to be 8 or higher. That's not the case here though. Two more questions: does this happen with open drivers, and does it happen in all apps or just the GoldSrc engine?

Peter, I was unable to run the game with open drivers so I can't comment on that. I also went back and re-installed xubuntu 13.10 because I know everything on my system worked just fine. I would like the update to the latest LTS release, but I'm fine with where I'm at. If there is anything I can do from 13.10 let me know, but I don't want to go through the hassle of another reinstall.

I would also like to add links to the research I've done on the topic:
https://github.com/ValveSoftware/halflife/issues/1466
http://steamcommunity.com/app/221410/discussions/2/558753804361168810/
http://webcache.googleusercontent.com/search?q=cache:t9TCeGcdoJ4J:https://bbs.archlinux.org/viewtopic.php%3Fid%3D176881+&cd=1&hl=en&ct=clnk&gl=us

Is there anything being done about this? I would love to upgrade from 13.10 but this specific bug is blocking me from doing so.

Here is more info about the bug:
https://github.com/ValveSoftware/steam-for-linux/issues/3302

Thanks,
Dan

judging by the comments in that bug, this is a GoldSrc issue, affecting only the binary driver. I'm not sure what exactly is going on, but since we don't know what the binary blobs are doing it'll be a bit hard to debug...

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/555.