TF2 sometimes loses held mouse clicks with raw input

[Lysius]

Since I have raw input for the mouse enabled, I sometimes have the situation that I hold a mouse key and at some point it is no longer registered as pressed. I have to release and repress the mouse button to have it work again.
I'm not exactly sure about other situations (will pay more attention to it in the future), but it happened several times while using the right button to spin up the minigun as heavy while using the left button to fire. Sometimes I release the left button and the minigun spins down while it should still be spinning because the right button is still pressed.
Unfortunately I have not found a way to reliably reproduce the issue. It is not happening often, but when it happens it is often deadly (to my heavy).

[davidw-valve]

I can't reproduce after trying for some time. Have you tried a different mouse? What distribution and hardware are you using?

[Lysius]

I now found a way to reliably reproduce this issue. Just spin up the minigun as heavy with right mouse button and move the mouse around rapidly in a circular motion. After a few (around 10) seconds the minigun stops spinning. Tried this around 10 times and always happened within less than half a minute. It is not limited to the right mouse button but also happens with the left one. This happens also when I disable raw input, but I do not remember this happening before raw input was implemented for Linux.
This happens with my Logitech MX518 and also a no-name USB mouse. It also happens with one mouse holding the button and the other mouse moving around.
I'm currently running KDE 4.9.5 on Fedora 17 x86_64.

[Lysius]

I reproduced this on my notebook (software should be the same). It seems to happen less often, but it also happened there after some trying. This difference in likeliness does not seem to be caused by graphics settings, but might be caused by differences in computation power of CPU and GPU. I also tried with only one monitor enabled (no difference).
I also tried to reproduce this bug on plain X without any window manager. After two minutes of trying I gave up (my arm then told me to not try more). It either happens significantly less often when KDE is not running, or it is caused by KDE (or some other program running in the background).
All test performed today were with raw input enabled.

BTW, my desktop system:

Processor Information:
    Vendor:  GenuineIntel
    Speed: 3301 Mhz
    4 logical processors
    4 physical processors
    HyperThreading:  Unsupported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Supported
    
Network Information:
    Network Speed:  
    
Operating System Version:
    "Fedora release 17 (Beefy Miracle)" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.7.3-101.fc17.x86_64
    X Server vendor:  Fedora Project
    X Server release:  11204000
    
Video Card:
    Driver:  NVIDIA Corporation GeForce GTX 460/PCIe/SSE2
    Driver Version:  4.3.0 NVIDIA 313.18
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x10de
    DeviceID:  0xe22
    Number of Monitors:  2
    Number of Logical Video Cards:  1
    Primary Display Resolution:  1680 x 1050
    Desktop Resolution: 3360 x 1050
    Primary Display Size: 17.05" x 10.67"  (20.08" diag)
                                            43.3cm x 27.1cm  (51.0cm diag)
    Primary Bus: PCI Express 16x
    Primary VRAM: 1024 MB
    Supported MSAA Modes:  2x 4x 8x 16x 
    
Sound card:
    Audio device: SigmaTel STAC9750,51
    
Memory:
    RAM:  32130 Mb
    
Miscellaneous:
    UI Language:  English
    LANG:  en_US.UTF-8
    Microphone:  Not set
    Total Hard Disk Space Available:  492153 Mb
    Largest Free Hard Disk Block:  173375 Mb
    
Installed software:
    
Recent Failure Reports:
    Tue Feb  5 20:55:13 2013 GMT: file ''/tmp/dumps/crash_20130205215510_1.dmp'', upload yes: ''CrashID=bp-535401ae-fcda-4e59-b0fc-ea7bb2130205''
    Tue Feb  5 20:55:14 2013 GMT: file ''/tmp/dumps/crash_20130205215512_1.dmp'', upload yes: ''CrashID=bp-0f618cf0-38c2-4b4d-a37a-9ce472130205''
    

[mikesart]

This should be fixed in the next tf2 update (hopefully next week). Thanks!

[nigg]

Same here. I recognized that bug with CSS beta. In CSS the mouse1 button isn't used correctly. While holding a flash, this bug appears sometimes and the flash is thrown without releasing the mouse1 button.

My OS:
Gentoo Linux 64bit with KDE 4.9
My Mouse:
Logitech mx518

raw_input enabled!

[atomic-penguin]

Oh, I thought it was just me. That explains why I was having problems with the mini-gun in matches/scrims. I have swapped out three mice to troubleshoot. Also disabled the touchpad thinking I must have been fat-fingering the touchpad and nearby buttons while playing.

[doug65536]

I never had any trouble at all with input devices until I installed compiz (desktop enhancement/animation add-on). Since then I have trouble with missed clicks missed releases (may continue firing, may ignore clicks, same issue with both buttons). Try installing compiz to see if you can reproduce the issue.

[doug65536]

Turning off "raw input" fixes the issue (that started happening after installing compiz), but it disrupts my aim somewhat due to what feels like mouse acceleration.

[mmstick]

This bug still occurs as of today with Ubuntu 13.10.

[mmstick]

This bug still occurs as of today with Ubuntu 13.10.

[doug65536]

@mikesart Are you going to reopen this bug? It obviously isn't fixed. Thanks.