You are not logged in.
I recently switched permanently to LxQt Wayland (lxqt-wayland-session labwc ) and starting the session with startlxqtwayland.
All is fine, except monitor suspend is not working:
sleep 2; wlopm --off '*'; read x; wlopm --on '*'results in:
- monitor osd states "DisplayPort no signal"
- monitor goes off for 23 seconds
- monitor goes on: monitor osd states "DisplayPort no signal"
- monitor goes off for 13 seconds
- monitor goes on: monitor osd states "DisplayPort no signal"
- monitor goes off for 13 seconds
- monitor goes on: monitor osd states "DisplayPort no signal"
...
Hardware: Asus PA248, DisplayPort used, monitor has no automatic input switch for vga<>dp<>hdmi<>dvi.
Same issue with
sleep 2; wlr-randr --output DP-1 --off; read x; wlr-randr --output DP-1 --onInteresting for both cases: the 1st off interval is 20-40 seconds, then further off cycles are only ~13 seconds long.
Found this with no solution:
"Monitor put to power off state but powers back on in seconds (wayland)" https://bbs.archlinux.org/viewtopic.php?id=298660
Under X11 dpms has worked, but as far as I understand this is not implemented in labwc, but instead via "zwlr-output-power-management-v1".
Does anybody has the same issue or an idea, or a solution ?
Thanks!
Edit: changed subject from wayland to Asus, striking false X11 oberservation
Last edited by ua4000 (Today 10:17:52)
Offline
https://bbs.archlinux.org/viewtopic.php … 2#p2299612 - does the output presence flicker when entering DPMS (udevadm monitor will work regardless of display server)
Offline
Thanks seth,
udevadm monitor --kernel --property does not produce any lines when using wlopm --off and waiting several minutes, while the monitor on/off cycling is happening.
Countercheck: switching the monitor with it's power button off, then on will produce two events:
$ udevadm monitor --kernel --property
monitor will print the received events for:
KERNEL - the kernel uevent
KERNEL[21085.821886] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card1
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=262
DEVNAME=/dev/dri/card1
DEVTYPE=drm_minor
SEQNUM=4312
MAJOR=226
MINOR=1
KERNEL[21100.673712] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card1
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=262
DEVNAME=/dev/dri/card1
DEVTYPE=drm_minor
SEQNUM=4313
MAJOR=226
MINOR=1I forget to write about my gpu
Intel Corporation Raptor Lake-P [Iris Xe Graphics] (rev 04)
Kernel driver in use: i915Edit:
I cannot notice any flickering, the monitor is simply turning off and on in long ~13s intervalls.
Last edited by ua4000 (2026-05-30 15:01:09)
Offline
![]()
Does the output behave similar on X11 for either of
xset dpms force off
xset dpms force suspend
xset dpms force standby?
The normal™ behavior is to standby, suspend and then off after some seconds of inactivity each.
Does the monitor come w/ a usb hub? Are any devices attached there?
Offline
Arg, I have to correct myself:
I remembered wrong: in X11 I have the same problem: monitor is cycling on/off in long intervals.
Happens on all above xset commands with same outcome.
The Asus PA248 is with a USB 3 Hub, but the hub is not in use and not connected to the machine.
In X11 the issue was hidden by my "xset dpms 601 602 603" - where I now noticed the monitor wrongly wakes up too, but then the cycles are much longer, and the monitor showing a black screen with backgroundlight on.
Did a new google search:
Maybe a specific hardware issue with my old Asus + Display Port + buggy DP 1.2 version...
options i915 enable_psr=0Did not help.
drm.vblankoffdelay=1Not tested yet, I can't find a docu, what it's doing exactly.
drm_kms_helper.poll=0... ah .. seems to work at a first glance, X11 and wayland...
I will test + observe longer.
Offline
https://elixir.bootlin.com/linux/v6.17. … per.c#L265
It polls the output every 10s, so that checks out.
Offline
setting can be changed and queried also via
/sys/module/drm_kms_helper/parameters/pollFor me it's now working fine.
Thanks for your time seth, and pushing me to recheck x11.
Marked as solved.
P.S.: is there a place in the wiki, where this would fit ? Or is this too hardware specific ?
Last edited by ua4000 (Today 10:21:46)
Offline
You could add a troubleshooting section to https://wiki.archlinux.org/title/Displa … _Signaling and explain the general phenomenon and mitigation.
Sure, it'll affect few HW combos but if most problems were common they would not have to be wiki'd but just be fixed ![]()
Offline