Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
Stuart Henderson writes: > On 2024/03/08 22:35, Mark Kettenis wrote: >> > Date: Fri, 8 Mar 2024 20:29:35 + >> > From: Stuart Henderson >> > >> > On 2024/03/08 14:34, Kenneth Westerback wrote: >> > > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks >> > > it won't come back until I reboot. >> > > >> > > Monitor is connected via HDMI. Happy to provide more details/info/tests >> > > if >> > > same deemed useful. >> > >> > Just tried xset s off, which I think _may_ be helping. >> >> I haven't done a ton of testing myself. Mostly just having machines >> sit idle in xenodm. There were some reports that quickly changing the >> display brightness causes similar firmware hangs. So I wonder if >> doing something more complicated in X would trigger the issue. >> >> I think tobhe@ has spent a bit more time on his m2 macbook air. But >> maybe he doesn't have the automatic screen blanking enabled. > > I added 'xset s off' on top of the existing 'xset -dpms' 2 hours ago > and the display is still on, so I think that's a winner. > > It didn't _always_ stay off after blanking, but did most of the time. I see the same thing. Adding 'xset -dpms' and 'xset s off' to my .xsession, logging in with only one xterm running, and the monitor stays on for >1 hour. -- Ken
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
In my case I rarely have the monitor connected to the macmini, so I can't say if this always happens or behaviour changed since I installed OpenBSD on it. In recent experiments, non-X related, I did have the monitor connected more often and never had the video come back once it blanked. I will do some more focused tests and try sthen's xset tweak. Ken On Fri, Mar 8, 2024, 5:18 PM Stuart Henderson wrote: > On 2024/03/08 22:35, Mark Kettenis wrote: > > > Date: Fri, 8 Mar 2024 20:29:35 + > > > From: Stuart Henderson > > > > > > On 2024/03/08 14:34, Kenneth Westerback wrote: > > > > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen > blanks > > > > it won't come back until I reboot. > > > > > > > > Monitor is connected via HDMI. Happy to provide more > details/info/tests if > > > > same deemed useful. > > > > > > Just tried xset s off, which I think _may_ be helping. > > > > I haven't done a ton of testing myself. Mostly just having machines > > sit idle in xenodm. There were some reports that quickly changing the > > display brightness causes similar firmware hangs. So I wonder if > > doing something more complicated in X would trigger the issue. > > > > I think tobhe@ has spent a bit more time on his m2 macbook air. But > > maybe he doesn't have the automatic screen blanking enabled. > > I added 'xset s off' on top of the existing 'xset -dpms' 2 hours ago > and the display is still on, so I think that's a winner. > > It didn't _always_ stay off after blanking, but did most of the time. >
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
On 2024/03/08 22:35, Mark Kettenis wrote: > > Date: Fri, 8 Mar 2024 20:29:35 + > > From: Stuart Henderson > > > > On 2024/03/08 14:34, Kenneth Westerback wrote: > > > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks > > > it won't come back until I reboot. > > > > > > Monitor is connected via HDMI. Happy to provide more details/info/tests if > > > same deemed useful. > > > > Just tried xset s off, which I think _may_ be helping. > > I haven't done a ton of testing myself. Mostly just having machines > sit idle in xenodm. There were some reports that quickly changing the > display brightness causes similar firmware hangs. So I wonder if > doing something more complicated in X would trigger the issue. > > I think tobhe@ has spent a bit more time on his m2 macbook air. But > maybe he doesn't have the automatic screen blanking enabled. I added 'xset s off' on top of the existing 'xset -dpms' 2 hours ago and the display is still on, so I think that's a winner. It didn't _always_ stay off after blanking, but did most of the time.
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
> Date: Fri, 8 Mar 2024 20:29:35 + > From: Stuart Henderson > > On 2024/03/08 14:34, Kenneth Westerback wrote: > > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks > > it won't come back until I reboot. > > > > Monitor is connected via HDMI. Happy to provide more details/info/tests if > > same deemed useful. > > Just tried xset s off, which I think _may_ be helping. I haven't done a ton of testing myself. Mostly just having machines sit idle in xenodm. There were some reports that quickly changing the display brightness causes similar firmware hangs. So I wonder if doing something more complicated in X would trigger the issue. I think tobhe@ has spent a bit more time on his m2 macbook air. But maybe he doesn't have the automatic screen blanking enabled.
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
On 2024/03/08 14:34, Kenneth Westerback wrote: > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks > it won't come back until I reboot. > > Monitor is connected via HDMI. Happy to provide more details/info/tests if > same deemed useful. Just tried xset s off, which I think _may_ be helping.
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks it won't come back until I reboot. Monitor is connected via HDMI. Happy to provide more details/info/tests if same deemed useful. Ken On Fri, Mar 8, 2024, 2:18 PM Stuart Henderson wrote: > No problems seen in text console, but when X is running and is left > inactive, the screen often blanks and won't come back. Same after > xset -dpms. Machine is still running ok at that point, I can ssh in. > Any clues / other info I can provide / ideas what might be triggering > blanking and whether it could be disabled? > > dmesg/pcidump/eeprom -p below. > > /var/log/messages entries (screen was on when pkg_add was running): > > Mar 8 18:40:41 burrow reorder_kernel: kernel relinking done > Mar 8 18:52:42 burrow pkg_add: Added flock-20110525p1 > Mar 8 18:52:52 burrow pkg_add: Added debug-openssl+openssl-3.1.5p2v0 > Mar 8 18:52:58 burrow pkg_add: Added node-18.19.1v0 > Mar 8 18:53:03 burrow pkg_add: Added cbindgen-0.26.0 > Mar 8 18:53:06 burrow pkg_add: Added wasi-compiler-rt-16.0.6 > Mar 8 18:53:09 burrow pkg_add: Added wasi-libcxxabi-16.0.6 > Mar 8 18:53:13 burrow pkg_add: Added wasi-libcxx-16.0.6 > Mar 8 18:53:17 burrow pkg_add: Added wasi-libc-0.20231121 > Mar 8 18:53:22 burrow pkg_add: Added py3-setuptools-68.0.0v0 > Mar 8 18:53:27 burrow pkg_add: Added libsigsegv-2.14p0 > Mar 8 18:53:28 burrow pkg_add: Added m4-1.4.18p1 > Mar 8 18:54:27 burrow pkg_add: Added llvm-16.0.6p23 > Mar 8 19:03:56 burrow /bsd: drm:pid49912:iomfb_poweroff_v13_3 *WARNING* > setPowerState(0) timeout 1000 ms > Mar 8 19:03:56 burrow /bsd: drm:pid49912:iomfb_poweroff_v13_3 *ERROR* > dcp_poweroff() done > Mar 8 19:06:01 burrow /bsd: drm:pid49912:iomfb_poweron_v13_3 *ERROR* > dcp_poweron() starting > Mar 8 19:06:02 burrow /bsd: drm:pid49912:iomfb_poweron_v13_3 *WARNING* > wait for power timed out > Mar 8 19:06:10 burrow /bsd: drm:pid49912:dcp_flush *ERROR* unexpected > busy command channel > > $ DISPLAY=:0 xrandr > Screen 0: minimum 320 x 200, current 3024 x 1890, maximum 16384 x 16384 > eDP-1 connected primary 3024x1890+0+0 (normal left inverted right x axis y > axis) 302mm x 189mm >3024x1890 60.00*+ 50.0059.9448.0047.95 > HDMI-1 disconnected (normal left inverted right x axis y axis) > > Xorg.0.log: > > $ cat /var/log/Xorg.0.log > [24.945] (--) Using wscons driver on /dev/ttyC4 > [24.975] > X.Org X Server 1.21.1.11 > X Protocol Version 11, Revision 0 > [24.975] Current Operating System: OpenBSD burrow.spacehopper.org 7.5 > GENERIC.MP#1 arm64 > [24.975] > [24.975] Current version of pixman: 0.42.2 > [24.975]Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [24.975] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [24.975] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 7 > 13:57:28 2024 > [24.981] (==) Using system config directory > "/usr/X11R6/share/X11/xorg.conf.d" > [24.984] (==) No Layout section. Using the first Screen section. > [24.984] (==) No screen section available. Using defaults. > [24.984] (**) |-->Screen "Default Screen Section" (0) > [24.984] (**) | |-->Monitor "" > [24.985] (==) No monitor specified for screen "Default Screen Section". > Using a default monitor configuration. > [24.985] (==) Automatically adding devices > [24.985] (==) Automatically enabling devices > [24.985] (==) Not automatically adding GPU devices > [24.985] (==) Automatically binding GPU devices > [24.986] (==) Max clients allowed: 256, resource mask: 0x1f > [25.000] (==) FontPath set to: > /usr/X11R6/lib/X11/fonts/misc/, > /usr/X11R6/lib/X11/fonts/TTF/, > /usr/X11R6/lib/X11/fonts/OTF/, > /usr/X11R6/lib/X11/fonts/Type1/, > /usr/X11R6/lib/X11/fonts/100dpi/, > /usr/X11R6/lib/X11/fonts/75dpi/ > [25.000] (==) ModulePath set to "/usr/X11R6/lib/modules" > [25.000] (II) The server relies on wscons to provide the list of input > devices. > If no devices become available, reconfigure wscons or disable > AutoAddDevices. > [25.000] (II) Loader magic: 0x3b4182aa0 > [25.000] (II) Module ABI versions: > [25.000]X.Org ANSI C Emulation: 0.4 > [25.000]X.Org Video Driver: 25.2 > [25.000]X.Org XInput driver : 24.4 > [25.000]X.Org Server Extension : 10.0 > [25.002] (II) LoadModule: "glx" > [25.007] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so > [25.048] (II) Module glx: vendor="X.Org Foundation" > [25.048]compiled for 1.21.1.11, module version = 1.0.0 > [25.048]ABI class: X.Org Server Extension, version 10.0 > [25.048] (==) Matched modesetting as autoconfigured driver 0 > [25.048] (==)
