STICKY: Bullseye - Comments and bug reports thread.

[twilightened]

I'll post when a fix is pushed out.

A fix for blanking not working has been pushed to apt. It may take a little while (hour or so) to propagate to mirrors.
The version "2:1.20.11-1+rpt2+deb11u5" contains the fix.

Code: Select all

pi@raspberrypi:~ $ sudo apt policy xserver-xorg-core
xserver-xorg-core:
  Installed: 2:1.20.11-1+rpt2+deb11u5
  Candidate: 2:1.20.11-1+rpt2+deb11u5
  Version table:
 *** 2:1.20.11-1+rpt2+deb11u5 500
        500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     2:1.20.11-1+deb11u5 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

Great news can anyone confirm this is working I'm on the 64 bit and haven't installed the buggy version.

It works.

[chincheta0815]

Hej there,

as I do not know where and who to ask, I plave my issue here.

now that the RaspberryPI OS 64bit kernel version is at 6.1.19 it would be awesome to have the zfs packages in archives.raspberrypios.org being updated to a version that is more recent than zfs-2.1.5...

So long thing short: If there is anybody out there being able to ugrade the zfs-dkms package in archives.raspberrypios.org, please update the package to a version like zfs-dkms 2.1.9 or more recent to make it work "out-of-the-box". The bullseye-backports version does work, so probably there is someone hearing me.

Thanks in advance.

[aBUGSworstnightmare]

Hej there,

as I do not know where and who to ask, I plave my issue here.

now that the RaspberryPI OS 64bit kernel version is at 6.1.19 it would be awesome to have the zfs packages in archives.raspberrypios.org being updated to a version that is more recent than zfs-2.1.5...

So long thing short: If there is anybody out there being able to ugrade the zfs-dkms package in archives.raspberrypios.org, please update the package to a version like zfs-dkms 2.1.9 or more recent to make it work "out-of-the-box". The bullseye-backports version does work, so probably there is someone hearing me.

Thanks in advance.

refer to here viewtopic.php?t=348673

Fix the issue with the error related to licences and you should be able to compile a kernel yourself.

[marsland]

I'll post when a fix is pushed out.

A fix for blanking not working has been pushed to apt. It may take a little while (hour or so) to propagate to mirrors.
The version "2:1.20.11-1+rpt2+deb11u5" contains the fix.

Code: Select all

pi@raspberrypi:~ $ sudo apt policy xserver-xorg-core
xserver-xorg-core:
  Installed: 2:1.20.11-1+rpt2+deb11u5
  Candidate: 2:1.20.11-1+rpt2+deb11u5
  Version table:
 *** 2:1.20.11-1+rpt2+deb11u5 500
        500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     2:1.20.11-1+deb11u5 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

Great news can anyone confirm this is working I'm on the 64 bit and haven't installed the buggy version.

I confirm, it works. It looks like the fix required modifying more than one package, that's why it's delayed.

[rickzman]

Thanks for fixing the blanking bug.

[zepp]

I'll post when a fix is pushed out.

A fix for blanking not working has been pushed to apt. It may take a little while (hour or so) to propagate to mirrors.
The version "2:1.20.11-1+rpt2+deb11u5" contains the fix.

Code: Select all

pi@raspberrypi:~ $ sudo apt policy xserver-xorg-core
xserver-xorg-core:
  Installed: 2:1.20.11-1+rpt2+deb11u5
  Candidate: 2:1.20.11-1+rpt2+deb11u5
  Version table:
 *** 2:1.20.11-1+rpt2+deb11u5 500
        500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     2:1.20.11-1+deb11u5 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

Great news can anyone confirm this is working I'm on the 64 bit and haven't installed the buggy version.

Yes, in my case, the bug has been fixed with today's update. All is running as expected now.

[DarkElvenAngel]

I've install the updates and all seems well, screen blanking works. Thanks to all those who worked on this!!

[aBUGSworstnightmare]

I have a DSI bridge on an CM4 DSI-1.

Screen blanking works exactly one time! Display resumes on i.e. mouse movement but never blanks again.

Code: Select all

pi@DSI1-DUMB:~ $ uname -a
Linux DSI1-DUMB 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
pi@DSI1-DUMB:~ $ sudo apt policy xserver-xorg-core
xserver-xorg-core:
  Installed: 2:1.20.11-1+rpt2+deb11u5
  Candidate: 2:1.20.11-1+rpt2+deb11u5
  Version table:
 *** 2:1.20.11-1+rpt2+deb11u5 500
        500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages
        100 /var/lib/dpkg/status
     2:1.20.11-1+deb11u5 500
        500 http://security.debian.org/debian-security bullseye-security/main arm64 Packages
     2:1.20.11-1+deb11u3 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
pi@DSI1-DUMB:~ $ 

How to debug this?

[DarkElvenAngel]

I have a DSI bridge on an CM4 DSI-1.

Screen blanking works exactly one time! Display resumes on i.e. mouse movement but never blanks again.

Code: Select all

pi@DSI1-DUMB:~ $ uname -a
Linux DSI1-DUMB 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
pi@DSI1-DUMB:~ $ sudo apt policy xserver-xorg-core
xserver-xorg-core:
  Installed: 2:1.20.11-1+rpt2+deb11u5
  Candidate: 2:1.20.11-1+rpt2+deb11u5
  Version table:
 *** 2:1.20.11-1+rpt2+deb11u5 500
        500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages
        100 /var/lib/dpkg/status
     2:1.20.11-1+deb11u5 500
        500 http://security.debian.org/debian-security bullseye-security/main arm64 Packages
     2:1.20.11-1+deb11u3 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
pi@DSI1-DUMB:~ $ 

How to debug this?

Silly question for you are you using VNC and that wakes up the screen? If you are I've seen that screen blanking doesn't work after that, I believe it has to do with the local mouse and keyboard haven't triggered the wake up so a flag isn't set/reset properly and the screen blank only checks if those flags. Otherwise I suspect that the DSI may have been overlooked since most users would have been using HDMI and is a symptom of the the VNC and the flags are not reset properly and thus the DSI isn't told to sleep only the HDMI.

[aBUGSworstnightmare]

Silly question for you are you using VNC and that wakes up the screen? If you are I've seen that screen blanking doesn't work after that, I believe it has to do with the local mouse and keyboard haven't triggered the wake up so a flag isn't set/reset properly and the screen blank only checks if those flags. Otherwise I suspect that the DSI may have been overlooked since most users would have been using HDMI and is a symptom of the the VNC and the flags are not reset properly and thus the DSI isn't told to sleep only the HDMI.

Not a silly question! That's a good point on VNC! Will have to check if the result is the same when having keyboard/mouse connected and no VNC session running.

There is a user which reports non-working screen blanking with official 7in on RPi 3B, so maybe there is still something to be sorted.

[Sgt_Munchies]

The new screen blanking fix also doesn't work for me unfortunately. I have similar issues, the blanking starts and then screen comes right back on with no user interaction. I do not have VNC enabled. Device is EVICIV Raspberry Pi 10.1 Inch Touchscreen Display with Rear Housing. I have one Pi 4 8gb installed in the device and another Pi 4 8gb connected via external HDMI input. Both refuse to stay screen blanked. I confirmed I have the updated xserve package installed with the fix. Rebooted both, unplugged mouse/keyboard to ensure it wasn't a jittery mouse. Both used to blank no problem before the bugged xserve package from a month or so ago.

[twilightened]

There is another problem with screen blanking but this is an older issue which was already there even before the updates. Whenever Chromium is open (or running in the background as minimized, doesnt matter), screen blanking does not work. Chromium somehow takes precedence and prevents screen blanking from blanking the screen. I have to manually close Chromium for screen blanking to work again.

[aBUGSworstnightmare]

Silly question for you are you using VNC and that wakes up the screen? If you are I've seen that screen blanking doesn't work after that, I believe it has to do with the local mouse and keyboard haven't triggered the wake up so a flag isn't set/reset properly and the screen blank only checks if those flags. Otherwise I suspect that the DSI may have been overlooked since most users would have been using HDMI and is a symptom of the the VNC and the flags are not reset properly and thus the DSI isn't told to sleep only the HDMI.

Not a silly question! That's a good point on VNC! Will have to check if the result is the same when having keyboard/mouse connected and no VNC session running.

There is a user which reports non-working screen blanking with official 7in on RPi 3B, so maybe there is still something to be sorted.

Confirmed!
Screen blanking works as expected when keyboard/mouse were used on the DUT - > blanks/resumes without issues.

Screen blanking only works ONCE when in a VNC session. Resume is fine but screen never blanks again.

[aBUGSworstnightmare]

The new screen blanking fix also doesn't work for me unfortunately. I have similar issues, the blanking starts and then screen comes right back on with no user interaction. I do not have VNC enabled. Device is EVICIV Raspberry Pi 10.1 Inch Touchscreen Display with Rear Housing. I have one Pi 4 8gb installed in the device and another Pi 4 8gb connected via external HDMI input. Both refuse to stay screen blanked. I confirmed I have the updated xserve package installed with the fix. Rebooted both, unplugged mouse/keyboard to ensure it wasn't a jittery mouse. Both used to blank no problem before the bugged xserve package from a month or so ago.

Don't you think the answer is 'touchscreen'? Disconnect the touch and try again. Most likely your touch reports false touches which leads to a resume from blanking.

[klricks]

There is another problem with screen blanking but this is an older issue which was already there even before the updates. Whenever Chromium is open (or running in the background as minimized, doesnt matter), screen blanking does not work. Chromium somehow takes precedence and prevents screen blanking from blanking the screen. I have to manually close Chromium for screen blanking to work again.

Works correctly for me.
Blanking is enabled/disabled based on web page content. For example blanking is disabled when playing a YT video.
FF does the same.

[Sgt_Munchies]

The new screen blanking fix also doesn't work for me unfortunately. I have similar issues, the blanking starts and then screen comes right back on with no user interaction. I do not have VNC enabled. Device is EVICIV Raspberry Pi 10.1 Inch Touchscreen Display with Rear Housing. I have one Pi 4 8gb installed in the device and another Pi 4 8gb connected via external HDMI input. Both refuse to stay screen blanked. I confirmed I have the updated xserve package installed with the fix. Rebooted both, unplugged mouse/keyboard to ensure it wasn't a jittery mouse. Both used to blank no problem before the bugged xserve package from a month or so ago.

Don't you think the answer is 'touchscreen'? Disconnect the touch and try again. Most likely your touch reports false touches which leads to a resume from blanking.

I thought of that as well though it wasn't an issue for the last year and a half, always blanked fine. I did wipe down the screen to be sure. I'll disable the touch though and see if that makes a difference.

[twilightened]

There is another problem with screen blanking but this is an older issue which was already there even before the updates. Whenever Chromium is open (or running in the background as minimized, doesnt matter), screen blanking does not work. Chromium somehow takes precedence and prevents screen blanking from blanking the screen. I have to manually close Chromium for screen blanking to work again.

Works correctly for me.
Blanking is enabled/disabled based on web page content. For example blanking is disabled when playing a YT video.
FF does the same.

I don't think any "minimized" application should clash with screen blanking. I can understand that a "full screen" application preventing it. VLC for example, does not clash with blanking when not in full screen mode.

[Sgt_Munchies]

The new screen blanking fix also doesn't work for me unfortunately. I have similar issues, the blanking starts and then screen comes right back on with no user interaction. I do not have VNC enabled. Device is EVICIV Raspberry Pi 10.1 Inch Touchscreen Display with Rear Housing. I have one Pi 4 8gb installed in the device and another Pi 4 8gb connected via external HDMI input. Both refuse to stay screen blanked. I confirmed I have the updated xserve package installed with the fix. Rebooted both, unplugged mouse/keyboard to ensure it wasn't a jittery mouse. Both used to blank no problem before the bugged xserve package from a month or so ago.

Don't you think the answer is 'touchscreen'? Disconnect the touch and try again. Most likely your touch reports false touches which leads to a resume from blanking.

Unfortunately disconnecting the touch portion of the screen did not resolve it.

I also tried xrandr --output HDMI-1 --off and that also does not work. It turns the screen off for about 5 seconds, then it turns on again.

Edit: Well I changed the video driver to fkms and NOW it's blanking. Progress...

[aBUGSworstnightmare]

The new screen blanking fix also doesn't work for me unfortunately. I have similar issues, the blanking starts and then screen comes right back on with no user interaction. I do not have VNC enabled. Device is EVICIV Raspberry Pi 10.1 Inch Touchscreen Display with Rear Housing. I have one Pi 4 8gb installed in the device and another Pi 4 8gb connected via external HDMI input. Both refuse to stay screen blanked. I confirmed I have the updated xserve package installed with the fix. Rebooted both, unplugged mouse/keyboard to ensure it wasn't a jittery mouse. Both used to blank no problem before the bugged xserve package from a month or so ago.

Don't you think the answer is 'touchscreen'? Disconnect the touch and try again. Most likely your touch reports false touches which leads to a resume from blanking.

Unfortunately disconnecting the touch portion of the screen did not resolve it.

I also tried xrandr --output HDMI-1 --off and that also does not work. It turns the screen off for about 5 seconds, then it turns on again.

Edit: Well I changed the video driver to fkms and NOW it's blanking. Progress...

start with a fresh installation, update/full-upgrade to latest kernel and blanking should work again. I confirmed it working on 3 different Pi versions yesterday while testing.

[DarkElvenAngel]

Silly question for you are you using VNC and that wakes up the screen? If you are I've seen that screen blanking doesn't work after that, I believe it has to do with the local mouse and keyboard haven't triggered the wake up so a flag isn't set/reset properly and the screen blank only checks if those flags. Otherwise I suspect that the DSI may have been overlooked since most users would have been using HDMI and is a symptom of the the VNC and the flags are not reset properly and thus the DSI isn't told to sleep only the HDMI.

Not a silly question! That's a good point on VNC! Will have to check if the result is the same when having keyboard/mouse connected and no VNC session running.

There is a user which reports non-working screen blanking with official 7in on RPi 3B, so maybe there is still something to be sorted.

Confirmed!
Screen blanking works as expected when keyboard/mouse were used on the DUT - > blanks/resumes without issues.

Screen blanking only works ONCE when in a VNC session. Resume is fine but screen never blanks again.

Sorry late to reply,

I don't know how to fix it but at least we have confirmed it on more than one system. I'm using KMS as I'm mostly local on my system, not sure where a bug report for this should go. It would be nice to not have to remember to turn the screen off when I'm away and want to VNC into my desktop.

[chincheta0815]

Hej there,

as I do not know where and who to ask, I plave my issue here.

now that the RaspberryPI OS 64bit kernel version is at 6.1.19 it would be awesome to have the zfs packages in archives.raspberrypios.org being updated to a version that is more recent than zfs-2.1.5...

So long thing short: If there is anybody out there being able to ugrade the zfs-dkms package in archives.raspberrypios.org, please update the package to a version like zfs-dkms 2.1.9 or more recent to make it work "out-of-the-box". The bullseye-backports version does work, so probably there is someone hearing me.

Thanks in advance.

refer to here viewtopic.php?t=348673

Fix the issue with the error related to licences and you should be able to compile a kernel yourself.

Sorry, I do not get which error I should fix.

zfs-2.1.5 from bullseye-backports compiles and runs without any issue. As bullseye-backports has no license issues and does provide zfs-dkms, IMHO there should be no license issue as debian and raspberrypios are the same code base. (correct me if I am wrong).
The only thing I am asking is to put the zfs-dkms package into archives.raspberrypios.org, meaning updating the yet existing zfs-dkms to version 2.1.5, recovering the compatibility to the latest kernel in archives.raspberrypios.org. This will avoid issues...

[redvli]

My guess is that bullseye-backports is out-of-scope w.r.t. this topic. You will get in trouble with that if it is Pi0 and Pi1, I noticed myself. If you use alternative/extra repos, it is unsupported, you are on your own. For 64-bit it will all work if it is unrelated to any VC4/firmware issue, e.g. if it would also run on another brand SBC. You can read, not only between the lines, that RPF/RPT is doing closed/un-published testing of bookworm, another step ahead. So I guess that is their focus, that the next Debian GNU/Linux will run well existing Pi's and maybe new products.

[chincheta0815]

My guess is that bullseye-backports is out-of-scope w.r.t. this topic. You will get in trouble with that if it is Pi0 and Pi1, I noticed myself. If you use alternative/extra repos, it is unsupported, you are on your own. For 64-bit it will all work if it is unrelated to any VC4/firmware issue, e.g. if it would also run on another brand SBC. You can read, not only between the lines, that RPF/RPT is doing closed/un-published testing of bookworm, another step ahead. So I guess that is their focus, that the next Debian GNU/Linux will run well existing Pi's and maybe new products.

I totally agree to you concerning the compatiblilty of the overall bullseye-backports. Concerning the zfs-linux package the issue I have is that the package in the raspberrypi archives are not compatibile anymore with the latest raspberrypi kernel version. The zfs-linux is a packages that compiles code each time you install it. Right now with the latest 6.x kernel the zfs-linux has an issue not compiling as the zfs packages version is too old for that kernel. zfs-linux/2.1.9 compiles and works fine. That is why I asked whether it would be possible to upgrade the zfs-linux version in the official raspi repo.

[beta-tester]

my Rpi4B (4GB) completely freeze when i open on the https://blender.org webpage in Chromium and click the [Whats new] link.
then a picture moves from buttom to the view and Chromium freezes and all CPU'S of the RPi4 goes up to 100% and nothing reacting anymore (and never cames back).

is this only on my RaspiOS ?

Blender dot org whats new 2023-03-30.png (117.13 KiB) Viewed 2439 times

my RPi4 is uptodate.

Code: Select all

pi@rpi4:~ $ uname -a
Linux rpi4 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
pi@rpi4:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

[twilightened]

One of the latest updates has broken something in Chromium. The in page videos are turning completely black while playing back. The audio continues to play but with no video. Stoping and restarting the video fixes it but it happens again at some point. What triggers it i don't know.