Screen Blanking not working #67
Comments
|
Let me add something I found after investigating.
It seems as it actually blanks the screen after set timeout but it turns it on again. |
|
it seems that some app requests to wake up... On my RPI4 bookworm 64 display blanking works ok. There was an issue in beta version, but it was already fixed. Also check that your mouse don't have false movements. It can leads to wake up. Some old mouses with dust inside can have such behavior. If this is your case, try to clean your mouse from dust. |
|
Thanks @qrp73 for the hints, but... Goes blank for ~10 seconds once after ~idle.dpms_timeout seconds after desktop shows after reboot. So no windows open and no mouse connected... same buggy behavior. |
|
More investigating. And blanking works if I switch to X11. |
|
In my case blanking works as expected on bookworm 64 with Wayland/wayfire. There is configuration in ~/.config/wayfire.ini The signal disappears after 300 seconds and display shows "NO SIGNAL" message and going to a sleep mode. It wake up when I move mouse or pressing keyboard. screensaver also works |
|
Here is my wayfire.ini I even tried adding your |
So USB-boot or from SD-card does not make a difference. |
|
Ok. Got hold of a Dell monitor that unfortunately only has DVI so I had to use and HDMI to DVI adapter but with that setup, blanking works. |
|
This log is just me switching the monitor of and on again. Similar pipewire messages as when blanking. |
|
Are you testing blanking on virtual console or graphical desktop? I found that display blanking doesn't works on virtual console. So there is probably another config file for virtual console blanking or it's just not implemented yet... |
|
Graphical desktop, nothing else. |
https://www.raspberrypi.com/documentation/computers/configuration.html#console |
|
for blanking in console, there is needs to add just tested, works ok |
|
Sorry @qrp75. Same issue in console mode. Goes blank for about 10 seconds then back but with cursor not blinking and no repeated blanks. |
|
@kmpm can you try adding I have a suspicion your display is waggling hotplug after it sees the display go blank (I don't know why). |
|
Could someone, where blanking works in graphical mode, please check with I'm curious about why xdg-desktop-portal-wlr fails and restarts. |
|
@popcornmix , with |
|
Is there a way of not starting the pipewire stuff at all. I'm really OK without sound while testing :) there must be a config somewhere that controls those kind of things but I haven't found it. |
no there is no log records when screen blanking happens. note: I'm using kernel 6.6.0-rc5-v8+, because there are some unfixed bugs on 6.1 |
There's an option in |
|
@lurch, thanks for what on paper would have been fine. |
|
Possibly: to stop now, and if you don't want it to restart after boot: |
|
I already tried that, even disable, but to no effect. And after reboot they were all enabled and running anyway. |
|
|
|
I wonder if you might need to remove the Bluetooth / Volume / etc. taskbar plugins first, and that's why wf-panel-pi isn't launching? |
|
@lurch, removing the taskbar plugins fixes wf-panel-pi. The issue with screen blanking still exists though. |
|
From response on Pi forum, adding vc4.force_hotplug=3 to end of command in /boot/cmdline.txt (value =1 for hda1, 2 hda2, 3 both) corrected the issue in pi400 with 2 monitors. |
|
Tried this on 1 MB Pi4 running bookworm. Now my GUI doesn't run at all, boots to console login. Removing it does not return to normal either, still boots to console. So this broke the GUI completely. |
|
But this lead to some really good news!! I did a fresh download/install of bookworm, then the usual sudo apt update/upgrade and now |
|
Are you able to do a cron job to the dell? |
|
these ones? if so what is the expected result? I can certainly try I just want to be sure ill be able to access my monitor again or will i have to enable through SSH ? 52 17 * * * /usr/bin/wlr-randr --output HDMI-A-2 --on |
|
It supposed to turn off on a specific set time and on at a specific time. This is inserted into the cron job. Those code that I gave does not function in cron as expected and I don’t know why… |
|
@1a2a3a1q2s3c your cron jobs don't pick up your env. so try setting the
wayland display name the same as suggested by @popcornmix
52 17 * * * WAYLAND_DISPLAY="wayland-1" /usr/bin/wlr-randr --output
HDMI-A-2 --on
…On Fri, Dec 8, 2023 at 11:24 AM 1a2a3a1q2s3c ***@***.***> wrote:
It supposed to turn off on a specific set time and on at a specific time.
This is inserted into the cron job. Those code that I gave does not
function in cron as expected and I don’t know why…
—
Reply to this email directly, view it on GitHub
<#67 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC37YZBZDK2BCD7GKMBYMP3YINLMLAVCNFSM6AAAAAA6ACNHISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBXGYZTINBTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Did that and it doesn’t work as well. |
|
|
|
Sorry what do you mean? I don’t quite understand. |
|
@pidloop was explaining that anything after the |
|
Yea so I did the wordings before the # and i still doesn’t works. |
|
I've had a go at experimenting with this myself... With just a single HDMI monitor plugged in to HDMI0, if I run over SSH, then the display turns off, and stays off even if I jiggle the USB mouse or type on the USB keyboard directly attached to the Pi. If I run over SSH then the display turns back on again, and everything is fully functional. If I swap the monitor over to HDMI1, then running the command above to turn off HDMA-A-1 says "unknown output HDMI-A-1", which is to be expected. If I run then the display turns off, but then automatically turns back on again after about 4 seconds! With a monitor plugged into each of HDMI0 and HDMI1, then running turns off the display connected to HDMI0, and it stays off. HDMI1 stays on, and any application-windows that were on HDMI0 then jump over to HDMI1. turns the display back on again. With both displays turned on, running turns off the second display (with the first display remaining enabled), and again the HDMI1 display automatically turns back on again after about 4 seconds. If I run the commands to turn off HDMI-A-1 and then turn off HDMI-A-2 then both displays are off briefly, but they both wake up again after a few seconds. I also ran the same tests on a Pi5, and that exhibited the same behaviour. TL;DR - it looks like the |
|
Can you add |
No dice for me even if I use the hdmi nearest to the usb c. The only way it work properly for me is to insert the vc hotplug command |
|
Ahhh, the culprit (and cause of my confusion) was that one of my micro-HDMI cables must have a broken (or unconnected) hotplug pin! So this "faulty" cable was the one that I was always connecting to HDMI1, and this is why the monitor connected to that display was "staying off" 🤦 So if I swap over my two HDMI cables, I then see the reversed behaviour - HDMI0 is the display that keeps "waking up" and HDMI1 is the display that "stays asleep". As @popcornmix said in an earlier comment, the act of sending the display to sleep causes the display to wiggle its hotplug pin, and that makes Wayland think that a new display has been plugged in, and so it switches the display back on again. So (as both @6by9 and @popcornmix suggested, thanks!), if I add Given that this is presumably quite a common occurrence, is there any way to get Wayland to ignore any HDMI hotplug events that occur in e.g. the 5 seconds immediately after |
|
Are you sure it is the cable and not the display? |
Ahh yes, it seems you're right - with so many different connections I must have been getting confused 😆 Based on all of that, does everyone agree that this issue can be closed now? |
Yes, many thanks to all involved. But I could use a recap. Please summarize:
|
Turn off HDMI0: If you're running over SSH (or from within a script) you might need to prefix those commands with
None.
We won't be adding those force_hotplug entries to |
|
Ive tried all of these commands over SSH but no matter what I get: Im using a Pi 5 x64 in CLI mode with Bookworm and Im trying to turn off my HDMI monitor. |
wayland isn't running in CLI mode, so wlr-randr isn't expected to do anything. |
|
Ok, so how can we send a command using CLI that will turn off the display? |
|
Things seem to have improved since this thread was started. After a fresh "sudo apt update; sudo apt upgrade" running bookworm on a Pi4 and Pi5 I can control the HDMI display connected next to power with these commands: |
|
Ha! I take it back. The previous lines were working a week ago but I just did another update/upgrade and now setting --off turns off the display but also logs me out! |
|
Ahh ok, Same boat, though I must have started on the version that logs you out with a new Pi5, its always just loged me out (started working on this 2 days ago) Im glad its not just me with the logout issue though. People are like, what are you talking about LOL |
|
Tried the new release posted today with full-update. The wlr-randr commands I posted work again. BUT now there are no mouse events delivered to my program while the screen is blank. This prevents me from detecting user activity to know when to turn the screen back on. This is new, events were delivered while off before. |
I can also turn off/on the attached screen but unfortunately turning on results in logout. Did anyone find a fix for this? |
|
See my comments in #219 |
Thanks @lurch. Weirdly after a reboot or many (I've lost track) I no longer get logged out. So the following works for my situation (for anyone else that lands on this thread): export WAYLAND_DISPLAY=wayland-1
wlr-randr --output HDMI-A-1 --off
wlr-randr --output HDMI-A-1 --on --transform 270 --custom-mode 1920x1080 |
I am running 64-bit bookworm (fresh install) on a 400 and I cant get screen blanking to work.
The screen never shuts of and it used to in bullseye.
I do get the same behavior as described in issue #63 and
wlr-randr --output HDMI-A-1 --offshuts of the screen, for a short while.Don't know if its related or not.
Edit (add some info):
The text was updated successfully, but these errors were encountered: