Intermittent pickup of mouse wheel events with XCB

I have a mouse where QWidget.wheelEvent (and QWidget.event) do not happen when mouse movement occurs in between wheel events. This is 100% reliable, even though Qt is definitely receiving the xcb events, as confirmed by installing a native event filter. In addition,  many other applications (including xev, and raw /dev/input/eventN streams), detect the wheel events with this mouse with 100% accuracy, regardless of interleaved mouse movement.

The mouse that is having a problem is this one (although I expect other modern mice may also have similar issues, especially if they have a "fast" mousewheel... see below):

https://www.monoprice.com/product?p_id=37991

Again - Qt is definitely receiving the raw xcb events from that mouse, and many non-Qt applications have no issues with it. Maybe a timing issue?

I have tested several other mice and Qt has no problem picking up wheel events, regardless if interleaved mouse movement.

More detail below...

Installing a native event filter with QApplication.installNativeEventFilter confirmed the following things:

1. Qt is definitely receiving all of the xcb_generic_event_t events, including the ones for the wheel event
2. Qt only fires off QWidget.event (and QWidget.wheelEvent) to match the wheel events

Further to this, I found that if I lift the mouse to avoid mouse movement and then move the mouse wheel, Qt will never miss a wheel event. Conversely, if I specifically move the mouse between single wheel events, Qt will miss 100% of the single dedent wheel events.

It seems like this problem may be related to the DeviceChanged event in the XCB event stream that happens when switching between mouse movement and wheel movement (normal mouse/button actions occur on /dev/input/event2, while wheel events for the same mouse occur on /dev/input/event2).

I'm not sure what the difference is. A "good-with-Qt" mouse and a "bad-with-Qt" have the exact same Xinput2 stream, as tested with xinput test-xi2. The xinput events for a real wheelevent look like this (identically) for either mouse case:

EVENT type 1 (DeviceChanged)
    device: 2 (10)
    reason: SlaveSwitch
        Reporting 7 classes:
                Class originated from: 10. Type: XIButtonClass
                Buttons supported: 7
                Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
                Button state:
                Class originated from: 10. Type: XIValuatorClass
                Detail for Valuator 0:
                  Label: Rel X
                  Range: -1.000000 - -1.000000
                  Resolution: 0 units/m
                  Mode: relative
                Class originated from: 10. Type: XIValuatorClass
                Detail for Valuator 1:
                  Label: Rel Y
                  Range: -1.000000 - -1.000000
                  Resolution: 0 units/m
                  Mode: relative
                Class originated from: 10. Type: XIValuatorClass
                Detail for Valuator 2:
                  Label: Rel Horiz Scroll
                  Range: -1.000000 - -1.000000
                  Resolution: 0 units/m
                  Mode: relative
                Class originated from: 10. Type: XIValuatorClass
                Detail for Valuator 3:
                  Label: Rel Vert Scroll
                  Range: -1.000000 - -1.000000
                  Resolution: 0 units/m
                  Mode: relative
                Class originated from: 10. Type: XIScrollClass
                Scroll info for Valuator 2
                  type: 2 (horizontal)
                  increment: 15.000000
                  flags: 0x0
                Class originated from: 10. Type: XIScrollClass
                Scroll info for Valuator 3
                  type: 1 (vertical)
                  increment: 15.000000
                  flags: 0x0

EVENT type 17 (RawMotion)
    device: 2 (10)
    detail: 0
    flags: 
    valuators:
          3: 15.00 (15.00)

EVENT type 15 (RawButtonPress)
    device: 2 (10)
    detail: 5
    flags: emulated
    valuators:

EVENT type 16 (RawButtonRelease)
    device: 2 (10)
    detail: 5
    flags: emulated
    valuators:

Given that the Xinput2 streams are 100% identical, I suspected that it must be timing related. However, I've done a large number of timing measurements (albeit on the stdout stream of xinput, which may be impacted by buffer flush timing). and I can't see a difference that would make Qt 100% unreliable with the one mouse.

For example, with the event chain for a wheel event being DeviceChange->RawMotion->RawButtonPress->RawButtonRelease, here are some timing histograms comparing the time between DeviceChange and RawButtonPress (with "DM_" being the "bad" mouse, and "MS_" being a "good" mouse):

To recap:

1. Qt is 100% unreliable with that monoprice mouse in detecting discrete mousewheel events when doing: MouseMove->MouseWheel->MouseMove->MouseWheel->etc
2. Qt is 100% reliable in picking up wheel events from that monoprice mouse when very carefully avoiding movement and doing: MouseWheel->MouseWheel->MouseWheel->etc
3. Qt has no problem in either mousewheel case with all other mice I've tested
4. Qt is definitely receiving all the X events from the problematic mouse, as evidenced by installing a native event filter into Qt
   1. i.e. 100% of all xcb_generic_event_t events are received by Qt, but Qt does not create a QWidget.event for them when triggered after a mouse move