Mike ack?

(In reply to Peter Hutterer from comment #0)
> Description of problem:
> Bringing the pen into proximity on a 27QHD triggers error messages in the
> Xorg.log. These errors look like this:
> 
> [704409.804] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is
> a BUG.
> 
> They are repeated frequently but usually stop once the pen has been in
> proximity for a while.
> 
> Version-Release number of selected component (if applicable):
> xorg-x11-drv-wacom-0.36.1-1.el7.x86_64
> 
> How reproducible:
> This can only be reproduced on a 27QHD
> 
> Steps to Reproduce:
> 1. watch the xorg.log
> 2. bring pen into proximity
> 3. notice the BUG warnings in the log
> 
> Actual results:
> The cause is an accelerometer packet sent by the device but filtered by the
> kernel. The filtering is incomplete, leaving a MSC_SERIAL event as the lone
> event in the frame. This then triggers the error message.
> 
> Expected results:
> Error-free interaction with the device.
> 
> Additional info:
> This can be triggered on current git master
> (71b35110478b8fce410c017e24072b6ab588d551) but only triggered on the RHEL7.x
> kernels because of how we backported the wacom device support. Not seen with
> upstream kernels or in Fedora.
> 
> 
> Note that this is a warning only and has no negative effect on pen
> functionality. The code paths triggered after this warning are all skipped,
> so the pen works as it would otherwise.



I keep having this bug for a year now with 27QHD.
Except mine doesn't seem to be related to bringing the pen into proximity.
The error message is triggered as soon as the 27QHD is plugged on USB port and doesn't stop unless unplugged :

14338.564] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[ 14339.076] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[ 14339.590] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[ 14340.102] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[ 14340.614] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[ 14341.127] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.

Version-Release number of selected component (if applicable):
xorg-x11-drv-wacom-0.34.2-5.el7.x86_64

xorg-x11-drv-wacom-0.36.1-2.el7 is available in brew

Still seeing "usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG." with the Cintiq 27QHD running xorg-x11-drv-wacom-0.36.1-2.el7.

Similar applies even to the newer xorg-x11-drv-wacom-0.36.1-4.el8.x86_64

Mike: can you please provide me with an evemu-recording of a sequence that triggers it? The one I have is definitely fixed with -2, so there must be some related issue here

Created attachment 1574435 [details]
evemu-record hovering pen

It is hard to capture the instance that triggers the error in the log. It always shows 5+ instances of the error when you plug in the tablet's USB. I think during this recording, the error popped up in the log once.

Thanks, unfortunately I can only reproduce the issue with the old package but not with the xorg-x11-drv-wacom-0.36.1-2.el7 package. I tried playing with the event sequence and shuffling a few things around that *may* trigger the error, but to no avail. Can you try again please, see if you can find a sequence that reproduces it? To verify, use evemu-play <recording> and hit enter, if that triggers the error message we've definitely captured it.

Created attachment 1574658 [details]
evemu recording

We have the same output all 500 msec, even without a pen nearby. Attached a evemu-recording, other recordings can be done if needed

Alright, I got it. The error is with the soft buttons located at the top of the pad. I attached a recording of me hitting each of them once. While watching the xorg log, hitting the soft buttons would trigger the xorg messages we have been seeing. When you plug the tablet in, that bug message pops up 3 times likely because of the three buttons. 

The three buttons from L -> R are as follows: tablet/pen settings | onscreen keyboard | display settings

Created attachment 1574995 [details]
27QHD Soft Buttons

Thanks for the logs.

Guenter: as far as I can tell (and reproduce), this sequence is the one already suppressed by the currently scheduled package. Each event frame only contains MSC_SERIAL events and those frames are now discarded. I can reproduce the error with the 7.6 package but not with the new one.

Michael: yours has two unhandled sequences. 
- KEY_PROG1/2/3 which are the soft buttons. Because they're EV_KEY events the frame doesn't get discarded as above and trigger that message. The key events themselves aren't actually handled, so except for the log message there's no side effect.
- a lonely ABS_X event (see the 6.547950 event frame). How this one sneaks in I'm not sure, it could be that the pen was at the very edge of the detectable range for just long enough to generate one event. This one is also harmless as the pen is out of proximity and updates don't get passed on.

In both cases, the actual effect is nil bar the log message, so rate-limiting the log message is the best option here. Any other solution is likely to be a cat-and-mouse game with the event sequences as they appear.

Dear Peter,

version used:
#rpm -qa|grep wacom
libwacom-0.31-1.el8.x86_64
xorg-x11-drv-wacom-serial-support-0.36.1-4.el8.x86_64
...

still see million of lines :)

[  6421.316] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6421.829] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6422.342] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6422.854] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6423.367] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6423.880] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6424.392] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6424.905] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6425.417] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6425.930] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6426.443] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
[  6426.956] (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.

or should we take the el7 package (running a RHEL 7.4 based PC).

Br, Günther.

Günther, can you please verify: are you using the RHEL8 package on a RHEL7 machine? If so, the error message is expected as the RHEL8 package does not contain the fix mentioned in comment #3.

The underlying source of the issue is a RHEL7 kernel backport that partially filters some events from this device, leading the erroneous ones to hit userspace and trigger the error message in the driver. The RHEL8 kernel should handle those events correctly though and thus no userspace driver fix is needed.

xorg-x11-drv-wacom-0.36.1-3.el7 is available in brew

Hello, 

the system engineers upgraded to a el8 package.

I downgraded the packages to latest el7 (from access.redhat.com) version: 

libwacom-data-0.30-1.el7.noarch
xorg-x11-drv-wacom-0.36.1-2.el7.x86_64
libwacom-0.30-1.el7.x86_64

Will do some tests an come back.

Here an updated Xorg log - at some point i turned of the display (loosing the input) and turned it on again.

Still see the message eventdriven, but the 2 per second logfilling is now gone

Created attachment 1577872 [details]
Xorg log with xorg-x11-drv-wacom-0.36.1-2.el7

I was able to reproduce the original error on xorg-x11-drv-wacom-0.36.1-2.el7 and verified the bug message was capped to five repetitions on xorg-x11-drv-wacom-0.36.1-3.el7. Guenther, the fixed version is xorg-x11-drv-wacom-0.36.1-3.el7, let me know if you have any issues with that package.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2079