new firmware and RFIC-MOUSE problem

[bacsom]

In our school, we use dozens of T3 AirMouses and since the latest versions of Stretch and Buster they don't work correctly. When I click on something the OS starts registering multiple mouse events (scrolling, clicking, etc...) up to the point that the system almost freeze. It must be a firmware related issue, because reverting back to an older firmware (using the command rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b (4.14.98)) solves the problem. Unfortunately, this is only a solution under Stretch, because in Buster it brakes Chromium.

Any help would be greatly appreciated!

(Maybe this is related: https://www.spinics.net/lists/linux-input/msg57789.html, similar symptoms)

[P33M]

You say a08ece3d48c3c40bf1b501772af9933249c11c5b is working, but which is the first version of rpi-update firmware that shows the issue?

[bacsom]

Thank you for your answer!

I used this website to see the available versions:
https://github.com/Hexxeh/rpi-firmware/commits/master?after=f8060224e53e26cdaea5b9f6f010ac8c3692e2ea+34

Nothing works since the Feb 12. 2019 (4.14.98) update. I have tried almost all of them. Do you know if there is anything between 4.14.98 and 4.19.23? Buster seems to work with 4.14 except Chromium.

[P33M]

In that case it's likely to be an upstream bug, since there were no (or very few) downstream changes other than those required to get 4.19 compiling/booting correctly. In particular there were no downstream changes to the USB host driver.

Can you post the output of sudo lsusb -v and dmesg with the device plugged in? Also, where can I buy one of these devices?

[bacsom]

Thank you again for your time, I am really grateful that somebody looks into it.

working 4.14.98:
lsubs 4.14.98
dmesg 4.14.98

not working 4.19.23:
lsubs 4.19.23
dmesg 4.19.23

You can buy these under several brands and places (offline or online). For example Amazon or Aliexpress. There are different versions, MX3, for example, has fewer keys, I don't know if it has the issue or not. I can replicate the problem with several T3s and Raspberries (Pi3 and Pi3+) and it only occurs when the gyroscope is active.

[lwpz]

If it is a firmware issue, then we would need @JamesH65 or @popcornmix to comment. The kernel should be handling devices and not the firmware (if I'm not wrong)...

[bacsom]

I don't know either, unfortunately I am not a Linux expert :-(

I have checked the output of dmesg and it seems that 4.19.23 recognises more devices than 4.14.98. Is it possible to simply disable the extras until somebody can figure out what is wrong?

4.14.98
[ 2.332113] usb 1-1.2: New USB device found, idVendor=25a7, idProduct=2402
[ 2.332128] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.332137] usb 1-1.2: Product: RFIC-MOUSE
[ 2.332145] usb 1-1.2: Manufacturer: FREEWAY TECHNOLOGY
[ 2.345128] input: FREEWAY TECHNOLOGY RFIC-MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:25A7:2402.0001/input/input0
[ 2.412506] hid-generic 0003:25A7:2402.0001: input,hiddev96,hidraw0: USB HID v1.01 Keyboard [FREEWAY TECHNOLOGY RFIC-MOUSE] on usb-3f980000.usb-1.2/input0
[ 2.419064] input: FREEWAY TECHNOLOGY RFIC-MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:25A7:2402.0002/input/input1
[ 2.419390] hid-generic 0003:25A7:2402.0002: input,hidraw1: USB HID v1.01 Mouse [FREEWAY TECHNOLOGY RFIC-MOUSE] on usb-3f980000.usb-1.2/input1

4.19.23
[ 2.383867] usb 1-1.2: New USB device found, idVendor=25a7, idProduct=2402, bcdDevice= 2.00
[ 2.383882] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.383891] usb 1-1.2: Product: RFIC-MOUSE
[ 2.383900] usb 1-1.2: Manufacturer: FREEWAY TECHNOLOGY
[ 2.398225] input: FREEWAY TECHNOLOGY RFIC-MOUSE Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:25A7:2402.0001/input/input0
[ 2.462932] input: FREEWAY TECHNOLOGY RFIC-MOUSE Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:25A7:2402.0001/input/input1
[ 2.463117] input: FREEWAY TECHNOLOGY RFIC-MOUSE System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:25A7:2402.0001/input/input2
[ 2.463316] input: FREEWAY TECHNOLOGY RFIC-MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:25A7:2402.0001/input/input3
[ 2.463757] hid-generic 0003:25A7:2402.0001: input,hiddev96,hidraw0: USB HID v1.01 Keyboard [FREEWAY TECHNOLOGY RFIC-MOUSE] on usb-3f980000.usb-1.2/input0
[ 2.469265] input: FREEWAY TECHNOLOGY RFIC-MOUSE as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:25A7:2402.0002/input/input5
[ 2.469657] hid-generic 0003:25A7:2402.0002: input,hidraw1: USB HID v1.01 Mouse [FREEWAY TECHNOLOGY RFIC-MOUSE] on usb-3f980000.usb-1.2/input1

[P33M]

Annoyingly, lsusb doesn't dump the HID report descriptors.

Can you run sudo apt-get install hidrd and run the command sudo usbhid-dump -d 25a7:2402 | grep -v : | tr -d ' \n' | xxd -r -p | hidrd-convert -o spec, then post the output here?

[bacsom]

Of course. Here.

[rjsachse]

Having same issues with freeway mx3 mouse, upgraded stretch had issues with mouse, then installed buster and same issue. On stretch I have SSH and noticed CPU goes very high and runs out of memory and logs out, on buster mouse moves but clicks work.

[bacsom]

Yes, I also noticed the high CPU usage under Stretch. So MX3 is also affected. :-(

[P33M]

Can you try adding usbhid.mousepoll=0 to cmdline.txt?

[P33M]

If mousepoll doesn't change the behaviour then can you
a) remove the cmdline.txt option
b) run sudo apt-get install evtest and run it - you will get an option prompt, pick the input device corresponding to the mouse (I would guess input3).
c) post the output from evtest when the mouse has caused lag/misclick events.

[bacsom]

usbhid.mousepoll=0 had no effect at all :-(

Here is the log of evtest. The screen is quickly filled with these lines...

If it helps I am willing to order a T3 for you. In the school, we have about 30 classrooms with Raspberry based multimedia centres and the teachers operate them with the help of these remotes.

Thank you for your time.

[P33M]

The clue is that the mouse input is spamming scrollwheel events with completely nonsensical offsets - if I plug in a mouse and do the same test, I get one or two +1 / -1 events for each click of the wheel. Yet that device is reporting 6 mousewheel events every 16ms.

If you can email info@raspberrypi.org and quote the github issue in the link, we can start a dialogue about getting hold of the problem hardware.

[bacsom]

Email has been sent :-).

[lwpz]

I think that you're posting this in the wrong forum. If it's kernel related (which looks so), then it should be posted here. https://github.com/raspberrypi/linux/issues

HID devices are handled by the kernel and not the firmware (for GPU). Please post in the relevant forum to get a reply.

[bacsom]

Dear lwpz,

Thank you, I didn't know that. If it is possible I agree to move the whole topic under a different category. Can you help me with that? Because there are several comments here I think it would be a mistake to start it from scratch.

P.S.: The link does not work correctly, it points back to the firmware category.

[lwpz]

Hi Bacsom, I’m not able to move. You’ll need to post again and put a link to this post Try this link. https://github.com/raspberrypi/linux/issues You can see it being “Linux” and not “Firmware”. If the older kernel works for you, I don’t see why you can’t just stick to that? You might want to consider to speak to your manufacturer of the hardware? Thanks Regards, Wern Pin

…

On 20 Jul 2019, at 19:04, bacsom ***@***.***> wrote: Dear lwpz, Thank you, I didn't know that. If it is possible I agree to move the whole topic under a different category. Can you help me with that? Because there are several comments here I think it would be a mistake to start it from scratch. P.S.: The link does not work correctly, it points back to the firmware category. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[bacsom]

It has crossed my mind to write to the manufacturer directly, and maybe I will do so, but because these remotes are sold under different brands it is not as easy as it looks.

As I mentioned in my first post, older kernel works, but only under Stretch. In Buster, reverting back 4.14.98 brakes Chromium (it doesn't start). Also, maybe it is still easier to hunt this bug down now, then in the future, when Stretch won't be an option at all.

I will consider an other topic under the right category, thank you for the suggestion.

[P33M]

The issue is with the Linux kernel rather than videocore firmware, but there's no point in cross-posting, as the same people watch both repositories.

[P33M]

I am now in possession of a device kindly provided by @bacsom.

Initial observations on latest 4.19 (and a Pi 4):

• Pressing any key causes event spam from the mouse reporting endpoint (event4) - which only stops if I hold the mouse still. I guess this is the gyro input. There are sensible x and y event deltas, but lots of scrollwheel spam.
• Pressing number and letter keys report on event0, the keyboard endpoint
• Pressing the special function keys like mail/"internet explorer" cause reports on event1 but not event0
• Pressing the power button causes events on the system control device (event2) - and unilaterally shuts down my Pi without the desktop prompting me 🙃
• I don't get events on event3, no matter what I do to it

[bacsom]

You are welcome, I hope it will help to get to the bottom of this. :-) It definitely has to do something with the gyroscope because when I turn the mouse function off, it works correctly.

[P33M]

As an immediate workaround, it should be possible to stop X.org from seeing or interpreting the bogus scrollwheel events. This would probably be better configured in userspace rather than as a kernel quirk.

As a separate line of investigation, figuring out why the kernel is reporting these events in the first place (in an apparent regression since 4.14) is the way to go. This is likely to take a long time.

[bacsom]

If it is not too complicated, can you tell me how to do that? I am getting better at Linux, but this is beyond my knowledge.

[P33M]

imwheel looks like a useful program:
https://manpages.ubuntu.com/manpages/bionic/man1/imwheel.1.html
It allows for arbitrary mouse event filtering/remapping in Xwindows.

[bacsom]

Since yesterday I have tried different methods, unfortunately without much of a success. By remapping button 4 and 5 to button 9 imwheel stops scrolling inside of a window. BUT it also disables the OK button and scrolling still happens outside of the window (like when the cursor is above the taskbar). Using xmodmap (pointer = 1 2 3 0 0 6 7 8 9 10), scrolling still occurs inside of a window, but OK button works and outside of the window everything is fine.

[P33M]

So on 4.9/4.14, the same endpoint is being polled for data, and the same data is being returned. It appears that Linux is incorrectly decoding the HID report as seen in evtest:

Event: time 1564580973.813432, -------------- SYN_REPORT ------------
Event: time 1564580973.829433, type 2 (EV_REL), code 0 (REL_X), value 67
Event: time 1564580973.829433, type 2 (EV_REL), code 1 (REL_Y), value 12
Event: time 1564580973.829433, type 2 (EV_REL), code 11 (?), value -124
Event: time 1564580973.829433, type 2 (EV_REL), code 12 (?), value 1
Event: time 1564580973.829433, type 2 (EV_REL), code 13 (?), value 45
Event: time 1564580973.829433, type 2 (EV_REL), code 14 (?), value -8
Event: time 1564580973.829433, type 2 (EV_REL), code 15 (?), value -84

In 4.19 these are decoded as multiple "EV_WHEEL" events.

Looking at the raw packet data, it looks like the "wheel" events are actually 16-bit values but Linux is fetching 8-bit values out of the responses - hence the huge offsets for some of these reports.

The "wheel" events sort of look like accelerometer data as
a) there are 3 nonzero 16-bit values in the 7 "wheel" reports - 3 axes, perhaps?
b) I can make larger signed 16-bit values appear by shaking the remote.

For now, if we can't find a way of filtering out the event forwarding to Xwindows I'd recommend using 4.14 on Stretch as upstream bugs can take a while to fix.

[P33M]

This works for me:
xmodmap -e "pointer = 1 2 3 0 0 0 0 8 9 10"

Edit: but not in Chromium. Because Chromium is special and ignores modified events.

[bacsom]

Thank you! Unfortunately, CLI and LibreOffice are also affected. Xmodmap definitely better than imwheel, but not a solution. :-(

[rjsachse]

Also the media keys not working in Kodi either. Most of my life I have used windows and this seems like a driver issue but not 100% sure how Linux drivers works. Oh and I'm still using a rpi 3 and tried with stretch updated Kernal and new buster os, A lot of people seem to use the mx3 mouse with Kodi and surprised not many have complained about this issue yet.