Kernel 5.15.33 AARCH64 mouse movement with V3D

[Dark-Sky]

Describe the bug

While booted into KMS or FKMS V3D with kernel 5.15.33 64bit the mouse movement is very erratic and when moving the mouse while using glxgears the gears completely stop until you cease moving the mouse. The same thing happens while playing a youtube video with the video stopping while moving the mouse. Everything seems ok if booted using llvmpipe.

Steps to reproduce the behaviour

Boot using KMS or FKMS V3D and start glxgears -info or a youtube video in the browser and move the mouse. Also notice erratic behavior of the mouse at all times when booted into the desktop using KMS or FKMS V3D.

Device (s)

Raspberry Pi 4 Mod. B

System

[ray@pi4 ~]$ vcgencmd version
Mar 24 2022 13:19:26
Copyright (c) 2012 Broadcom
version e5a963efa66a1974127860b42e913d2374139ff5 (clean) (release) (start)

[ray@pi4 ~]$ uname -a
Linux pi4 5.15.33-1-MANJARO-ARM-RPI #1 SMP PREEMPT Mon Apr 11 13:35:56 UTC 2022 aarch64 GNU/Linux

Logs

No response

Additional context

No response

[popcornmix]

Did this start recently? I wonder if it could be #4971

[Dark-Sky]

Did this start recently? I wonder if it could be #4971

I wondered the same thing remembering the commit. It was made after I had compiled 5.15.32.

[popcornmix]

Can you test latest 5.15 kernel with those two commits reverted? It would be useful to confirm they are to blame (based on the timing, it seems likely).

[Dark-Sky]

Sure. Be glad to....

[Dark-Sky]

@popcornmix

Sorry it took so long to respond back. My boy and his family showed up and had to wait for a thunderstorm to pass.

I reverted the 2 commits and the mouse issue went away on 5.15.33.

[popcornmix]

@mripard looks like #4971 has caused a performance regression.

[Dark-Sky]

I compiled 5.18-rc2 again today to add commits since my last compile and it now has the erratic mouse and V3D issue. Although I still can not get kernel 5.17.2 to compile yet to test it also looks to me it will have the issue also. #4987

[popcornmix]

I believe 5.15, 5.16, 5.17 and 5.18 all have the drm/atomic-helpers: remove legacy_cursor_update hacks commit and so I'd expect all to have this issue.

[mripard]

I wonder if it's a similar issue to #4571. Does it occur only when playing a video or rendering on the GPU, or does it also stall the rest of the display (so something like displaying a huge chunk of text in a terminal would be stalled as well?)

Either way, it looks like a severe regression that won't get fixed fast, we should probably revert it for now

[Dark-Sky]

I will test further in a little bit. Right now all I tested was with any graphic with movement ceased when moving the mouse but started back up when you rest the mouse. The mouse was very erratic/laggy trying to move the mouse around the Desktop when no graphic movement was being done with a program.

I have reverted all 3 kernels I maintain for our repo at the moment at released them.

[Dark-Sky]

Oops. I deleted the bad kernel. I can recompile if needed.

[popcornmix]

Not sure I can reproduce on RPiOS 32bit. Kernel: 5.15.33-v7l+
Booted to desktop and run glxgears. Mouse moves okay and gears do not stall.
Tried 1080p60 and 4kp60. Tried running neverball too.
Tried with mutter disabled and enabled.

[Dark-Sky]

Mine is 64 bit with XFCE and mesa 22.0.1-3.

[Dark-Sky]

I have a 32bit arch-arm image I here with MATE DE. I will see what it does. We mirror arch-arm's repo so it should be the same program versions but 64bit after I update everything.

[popcornmix]

Still seems fine with RPiOS bullseye 64-bit

[Dark-Sky]

Seems fine on 32bit arch-arm image with MATE DE I just compiled on the same pi4:

[alarm@alarmpi ~]$ uname -a
Linux alarmpi 5.15.33-v7l+ #1 SMP Wed Apr 13 09:16:09 CDT 2022 armv7l GNU/Linux

Two 64 bit kernels 5.15.33 & 5.18-rc2 with XFCE had the issue right after the new commits were made. I never got to test 5.17.2 as I had gotten around to making patches that reversed the commits by then since I found out the commits landed there also. One thing for sure is the reversing of the commits makes the issue go away; so a little puzzling to me...

[popcornmix]

Does 32-bit arch-arm image have same version of mesa?
On rpios we can run fbturbo, xcompmgr, glamor, mutter in different configurations.
Do your 32-bit and 64-bit images run the same window managers/compositors/acceleration libs?

[Dark-Sky]

My 32 bit image has the same mesa version as my 64bit.

fbturbo got obsoleted as it is not maintained anymore. It did not have the proper APi for the new Xorg. We use xf86-video-fbdev now instead. We have so may images and pretty sure our people have tried the configurations you named at one time or the other. The images with wayland seem to give some issues but people have learned some workarounds.

Compositing is turned on in the 32 bit image but it is off in the 64bit image. My 64bit image has XFwm4 window manager. My 32bit image has Metacity (Marco) window manager

[Dark-Sky]

@popcornmix I started from the ground up building the kernel with make bcm2711_defconfig and left generated .config as is and compiled the kernel and installed it on a fresh 64bit Mate image and I get the same mouse issue as with the 64bit XFCE image.

I wonder if it's a similar issue to #4571. Does it occur only when playing a video or rendering on the GPU, or does it also stall the rest of the display (so something like displaying a huge chunk of text in a terminal would be stalled as well?)

@mripard
When testing the kernel with the new Mate image I tested moving the mouse while typing in the terminal and there is no text output until you stop the mouse and all of the text then appears. I also noticed dragging a window is horrible. You basically grab the window with the mouse and move the mouse to where you want to drag to and the window will make it there eventually.

Here is a pic of most of the info requested with the fresh x64 Mate image with newly compiled kernel that still has the issue.

[Dark-Sky]

@popcornmix I installed the same last kernel to a fresh 64bit RPi OS image and had no issues like you. I then got to looking at your group file and saw a render group so I went back to my XFCE image and logged in as root and the mouse seemed ok along with moving the mouse and glxgears did not stop. There seems to be an issue running a web browser as root so I did not get to test it. Did you all recently add something different with your udev rules between 5.15.32 and 5.15.33 or better yet did these 2 commits in question here do something involving permissions?

[Dark-Sky]

@popcornmix

Using the 5.15.33 kernel I had compiled using "make bcm2711_defconfig" and using the generated .config as is:

I have my XFCE image some what working as a normal user with KMS but it is still not quite right with some lagging with high bit rate videos. The same kernel performance wise is not as good as on the PiOS image. I added a few udev rules that I saw were missing involving 12c & gpio but with my limited knowledge I believe by adding me to the render group (along with adding me to the new gpio/i2c groups) might have got it working.

I then booted my XFCE image using FKMS and the mouse issue was back. I went back to the PiOS image that has the same 5.15.33 kernel that I compiled that has no issue with KMS and booted into FKMS and the mouse issue showed up in it also.

You can see each time when I moved the mouse in this pic looking at the frames/FPS in glxgears booted in the PiOS image:

[Dark-Sky]

@popcornmix

This is now showing up in the arch-arm forums:

https://archlinuxarm.org/forum/viewtopic.php?f=57&t=15999

[popcornmix]

I then got to looking at your group file and saw a render group

I have seen the render group on some systems, but pi doesn't seem to belong to it on RpiOS:

pi@pi4:~ $ groups pi
pi : pi adm tty dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio lpadmin

and I see nothing from sudo find /dev -group render
I think we use video group for all the 3d/drm/v4l2 nodes.
But this isn't something I set up, so I'm just going by what I see when poking around.

[popcornmix]

Did you all recently add something different with your udev rules between 5.15.32 and 5.15.33 or better yet did these 2 commits in question here do something involving permissions?

No, I don't believe so.

[popcornmix]

I have my XFCE image some what working as a normal user with KMS but it is still not quite right with some lagging with high bit rate videos. The same kernel performance wise is not as good as on the PiOS image. I added a few udev rules that I saw were missing involving 12c & gpio but with my limited knowledge I believe by adding me to the render group (along with adding me to the new gpio/i2c groups) might have got it working.

I then booted my XFCE image using FKMS and the mouse issue was back. I went back to the PiOS image that has the same 5.15.33 kernel that I compiled that has no issue with KMS and booted into FKMS and the mouse issue showed up in it also.

So are you saying adding your user to render group fixes the regression from the two commits we've identified using kms?
What does sudo find /dev -group render show?

But fkms still has a similar issue with the two commits (although that is a deprecated configuration, so less critical than kms).

[Dark-Sky]

So are you saying adding your user to render group fixes the regression from the two commits we've identified using kms? What does sudo find /dev -group render show?

ray@raspberrypi:~ $ sudo find /dev -group render
/dev/dri/renderD128

It says this here on all of the images I have tested including PiOS.

It is fixed regarding the mouse movement issue on my XFCE image with KMS but there is lacking with performance with higher bitrate videos locally and on youtube. More dropped frames on youtube. I do not have this issue with the 2 patches reverted. 64 bit PiOS does not have this issue.

I had forgotten the PiOS Setup now lets you set up me as a user but the default in the 2022-04-04-raspios-bullseye-arm64 image has pi as a member of the render group when mounting the image on my x86. After going through the Setup and rebooting all mention of the user pi is removed from /etc/group and replaced with the user you set up:

But fkms still has a similar issue with the two commits (although that is a deprecated configuration, so less critical than kms).

Yes I am seeing this issue with PiOS with FKMS. I am a little sad about hearing FKMS being deprecated some of our DE's has issues from time to time with KMS like Sway and Plasma and it was nice to be able to switch back and forth. I am having a weird issue right now with the latest -rc kernel where KMS boots but FKMS will not even give a Rainbow at boot but a black screen with my VIZIO tv and using my Gateway monitor I see the boot lines flying by but stalls with a black screen trying to go in graphics mode..

[popcornmix]

ray@raspberrypi:~ $ sudo find /dev -group render
/dev/dri/renderD128

On RPiOS, render isn't used for that node:

$ ls -l /dev/dri/renderD128 
crw-rw----+ 1 root video 226, 128 Apr 20 11:18 /dev/dri/renderD128

but it should be accessible by a normal user. So you should be adding your user to the render group (or change group of that node to video, I assume in udev rules).

[Dark-Sky]

ray@raspberrypi:~ $ sudo find /dev -group render
/dev/dri/renderD128

On RPiOS, render isn't used for that node:

$ ls -l /dev/dri/renderD128 
crw-rw----+ 1 root video 226, 128 Apr 20 11:18 /dev/dri/renderD128

but it should be accessible by a normal user. So you should be adding your user to the render group (or change group of that node to video, I assume in udev rules).

Obviously we are not using the same RPiOS image. We have not been on the same page here a few times. Just so I did not mess up and got in the wrong window changing things on my desktop I have downloaded a new RPiOS image (2022-01-28-raspios-bullseye-arm64.zip) and went through the Setup where it asks me to create my user account then it did a package update then it rebooted. The default "pi" user was deleted and all pi references in /etc/group was removed and replaced with the user I created. I changed nothing and "ls -l /dev/dri/renderD128" still showed up as I previously posted.

So all I did in my image was to match what is in the latest RPiOS image.

[Dark-Sky]

More people reporting this issue in the arch-arm forums in the last few days.

https://archlinuxarm.org/forum/viewtopic.php?f=57&t=15999