Raspberry Pi OS 12 (Bookworm) released

[Tim Curtis]

Does the power button on the 5 actually submit a Linux software poweroff command?

It definitely doesn't cut power to the Pi.

[TheOldPresbyope]

Does the power button on the 5 actually submit a Linux software poweroff command?

It definitely doesn't cut power to the Pi.

Quoting from the official Raspberry Pi documentation section on the Pi 5,

If you are running Raspberry Pi OS Lite in headless mode pressing the power button a single time will initite a shutdown.

If you want to force a hard shutdown, you should press and hold the Power Button.

If the Raspberry Pi board is shutdown, but still powered, pressing the power button will restart the board.

Default shutdown wattage is around 1 to 1.4W. However this can be decreased by manually editing the EEPROM configuration, sudo rpi-eeprom-config -e and change the settings to:

BOOT_UART=1
POWER_OFF_ON_HALT=1
BOOT_ORDER=0xf416

This should drop the shutdown power consumption to around 0.01W.

It's different if running full Bookworm Desktop.

I just checked journalctl after using the power button first to shut down Bookworm Lite and then to power up.

There's a ton of relevant output starting with the lines

Code:

Nov 11 22:08:32 raspberrypi systemd-logind[763]: Power key pressed short.
Nov 11 22:08:32 raspberrypi systemd-logind[763]: Powering off...
Nov 11 22:08:33 raspberrypi systemd-logind[763]: System is powering down.
...

followed by lots of lines concerning various processes shutting down and then ending with

Code:

Nov 11 22:08:43 raspberrypi systemd[1]: Reached target shutdown.target - System Shutdown.
Nov 11 22:08:43 raspberrypi systemd[1]: Reached target final.target - Late Shutdown Services.
Nov 11 22:08:43 raspberrypi systemd[1]: systemd-poweroff.service: Deactivated successfully.
Nov 11 22:08:43 raspberrypi systemd[1]: Finished systemd-poweroff.service - System Power Off.
Nov 11 22:08:43 raspberrypi systemd[1]: Reached target poweroff.target - System Power Off.
Nov 11 22:08:43 raspberrypi systemd[1]: Shutting down.
Nov 11 22:08:45 raspberrypi systemd-shutdown[1]: Syncing filesystems and block devices.
Nov 11 22:08:47 raspberrypi systemd-journald[284]: Journal stopped

The log continues with the first line of the next boot.

-----

Back to wayfire/chromium-browser, I now have a blank screensaver function working. Much more of this and I'll start thinking I actually understand Wayland compositors/window managers  (not!).

Regards,
Kent

[TheOldPresbyope]

Interesting.
- This "If I reboot, then this process starts over." seems odd or maybe its normal??
- I thought RpiOS Bookworm used X11 on < Pi 4/5 by some sort of detection mechanism.

Ya there will be some kernel and other updates before RpiOS Bookworm and the Pi Imager settles down. Pretty much par for the course for a major OS and hardware bump.

By "the process starts over..." I mean the first start of wayfire/chromium-browser takes longer than the second. This suggests to me there's something cached in a volatile directory such as /run. I'm still trying to figure out the whole wayfire plugin thing.

As for X11 vs Wayland, I believe that's entirely a function of detection code in Bookworm Full (e.g., Desktop). My experience with Bookworm Lite on the Pi3B+ / Pi4B / Pi5B suggests Wayland compositors/window managers can run on all of them.

And we both agree that major software/hardware releases see a lot of early updates (kinda like earthquakes beget aftershocks).

Regards,
Kent

[Tim Curtis]

Does the power button on the 5 actually submit a Linux software poweroff command?

It definitely doesn't cut power to the Pi.

Quoting from the official Raspberry Pi documentation section on the Pi 5,

If you are running Raspberry Pi OS Lite in headless mode pressing the power button a single time will initite a shutdown.

If you want to force a hard shutdown, you should press and hold the Power Button.

If the Raspberry Pi board is shutdown, but still powered, pressing the power button will restart the board.

Default shutdown wattage is around 1 to 1.4W. However this can be decreased by manually editing the EEPROM configuration, sudo rpi-eeprom-config -e and change the settings to:

BOOT_UART=1
POWER_OFF_ON_HALT=1
BOOT_ORDER=0xf416

This should drop the shutdown power consumption to around 0.01W.

It's different if running full Bookworm Desktop.

I just checked journalctl after using the power button first to shut down Bookworm Lite and then to power up.

There's a ton of relevant output starting with the lines

Code:

Nov 11 22:08:32 raspberrypi systemd-logind[763]: Power key pressed short.
Nov 11 22:08:32 raspberrypi systemd-logind[763]: Powering off...
Nov 11 22:08:33 raspberrypi systemd-logind[763]: System is powering down.
...

followed by lots of lines concerning various processes shutting down and then ending with

Code:

Nov 11 22:08:43 raspberrypi systemd[1]: Reached target shutdown.target - System Shutdown.
Nov 11 22:08:43 raspberrypi systemd[1]: Reached target final.target - Late Shutdown Services.
Nov 11 22:08:43 raspberrypi systemd[1]: systemd-poweroff.service: Deactivated successfully.
Nov 11 22:08:43 raspberrypi systemd[1]: Finished systemd-poweroff.service - System Power Off.
Nov 11 22:08:43 raspberrypi systemd[1]: Reached target poweroff.target - System Power Off.
Nov 11 22:08:43 raspberrypi systemd[1]: Shutting down.
Nov 11 22:08:45 raspberrypi systemd-shutdown[1]: Syncing filesystems and block devices.
Nov 11 22:08:47 raspberrypi systemd-journald[284]: Journal stopped

The log continues with the first line of the next boot.

-----

Back to wayfire/chromium-browser, I now have a blank screensaver function working. Much more of this and I'll start thinking I actually understand Wayland compositors/window managers  (not!).

Regards,
Kent

Right, journalctl since there's no syslog in Bookworm.

Thats fantastic that it's mapped by default to soft poweroff that sync's the file system :-) That moves the question "can I just pull pull the plug" to "how much power is consumed while shutdown" which is answered by the eeprom settings in an earlier post. 

Looks like the eeprom power setting would be a good option to have on System Config for the 5.
Also can look into having systemd-poweroff.service run the moOde shutdown script instead of it's default.

[Tim Curtis]

Interesting.
- This "If I reboot, then this process starts over." seems odd or maybe its normal??
- I thought RpiOS Bookworm used X11 on < Pi 4/5 by some sort of detection mechanism.

Ya there will be some kernel and other updates before RpiOS Bookworm and the Pi Imager settles down. Pretty much par for the course for a major OS and hardware bump.

By "the process starts over..." I mean the first start of wayfire/chromium-browser takes longer than the second. This suggests to me there's something cached in a volatile directory such as /run. I'm still trying to figure out the whole wayfire plugin thing.

As for X11 vs Wayland, I believe that's entirely a function of detection code in Bookworm Full (e.g., Desktop). My experience with Bookworm Lite on the Pi3B+ / Pi4B / Pi5B suggests Wayland compositors/window managers can run on all of them.

And we both agree that major software/hardware releases see a lot of early updates (kinda like earthquakes beget aftershocks).

Regards,
Kent

Ok only Desktop has the X11/Wayland detector switcher thing. Thats a relief.

[TheOldPresbyope]

I forgot to post my final wayfire.ini file

Code:

# initialize wayfire and run chromium-browser in full-screen kiosk mode
[core]
# load only essential plugins; if none specified then all available
# core plugins are loaded (>20) - doesn't materially affect startup time
# but seems like good housekeeping
plugins = \
autostart \
idle
[autostart]
# some say following two settings speed up app loading but that's not
# been my experience with this desktop-less kiosk application -
# reference - default wayfire.ini configuration file and
# bbs.archlinux.org/viewtopic.php?267232
#import-enviroment = systemctl --user import-enviroment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
#dbusupdate = hash dbus-update-activation-environment 2>/dev/null && dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY
# start chromium-browser with usual options + wayland protocol ; give process an arbitrary name
chromium=chromium-browser https://moodeaudio.org \
--ozone-platform=wayland \
--enable-features="OverlayScrollbar" \
--no-first-run \
--noerrdialogs \
--disable-infobars \
--kiosk
[idle]
# blank screen after timeout
screensaver_timeout = 60
dpms_timeout = -1
# required for fullscreen kiosk
disable_on_fullscreen = false

Raking through copious debugging output I can see where the first run and second run differ. The discrepancies in elapsed time show up  in the bowels of stuff like wayfire code executing "Framebuffer Reset..." and GLES2 "Updating shadow. ... for linear texture..." and even then only once out of many such lines.

I'm trying to figure out where best to ask...prolly the wayfire wiki.That's for another day, though; for now, I'm content with a usable Bookworm kiosk.

Regards,
Kent

[bitlab]

Meanwhile the moode image builder is also updated. It is now based on bookworm lite and including als moode specific packages.

Of course it missing the moode-player package it self (minor detail  )
Also for the moment the moode custom driver modules are missing.

For now it is a nice based todo the moode bookworm develop/testing on.

You can find it back in the git branch bookworm of the imgbuild repo.

[TheOldPresbyope]

Meanwhile the moode image builder is also updated. It is now based on bookworm lite and including als moode specific packages.

Of course it missing the moode-player package it self (minor detail  )
Also for the moment the moode custom driver modules are missing.

For now it is a nice based todo the moode bookworm develop/testing on.

You can find it back in the git branch bookworm of the imgbuild repo.

Terrific!

[Tim Curtis]

For sure thats a major step :-)

Is the plan to have OS named branches in imgbuild and pkgbuild or is a big merge into main going to happen at some point?

[bitlab]

@Tim Curtis I did keep it in separate branches because not to interfer with the 8.x.x release. When you are sure we are done with the 8.x.x release we merge the bookwork branches to the main/develop.
Another reason for holding back the merge for a while is that the develop for supporting CamillaDSP 2.x, currently only can be done with 8.x (requires working moOde ;-) ).