Raspberry Pi Buster no longer available for download

[sapnho]

I have just been contacted by a blog reader who told me that Raspberry Pi Buster is no longer available for download.

I will start experimenting with Bookworm on a Pi4 this weekend to see what still works and what might be broken in Pi3D PictureFrame.

[sapnho]

You guys are just so great! I was afraid it would take a long time to run PictureFrame on Bookworm! Thank you two so much!

[helgeerbe]

This is my minimum wayfinder.ini

[core]
plugins = autostart
#xwayland = false

[autostart]
picframe = /home/pi/start_picframe.sh

With this setting you will get a black screen with a mouse pointer in the middle of the screen, before picframe starts. We coud start wayfinder with a separate ini file, to keep the original wayfinder.ini untouch.

@paddywwoof I tried also to disable xwayland, but picframe is complaining, that it still need X11 to be running. I did some tests with SDL_VIDEODRIVER=wayland and checked that picframe is using wayland. So why pi3d needs still X11?

[paddywwoof]

@helgeerbe I've made a bit of progress:

1. I've done a major hack on pi3d using project.toml and getting rid of setup.py as well as binning the support for python2 and taking out a couple of other things that said they were deprecated. Hopefully it will all still work, I tried installing from wheels I've built here and it runs OK but I will put it on the RPi 3 and 4 at least and run the tests. At the moment it's in sdl2 branch, I've not yet merged to main.
2. I've managed to run pi3d with SDL_VIDEODRIVER=wayland on the lite version of bookworm. Essentially with your wayfire.ini setup - but I left the xwayland = false line in. I had the export SDL_VIDEODRIVER=wayland in the bash script but also added it to /etc/environment PS I've just run pi3d_demos at the moment rather than trying picframe, but I haven't had any complaints about no X11 PPS I've merged sdl2 branch into main and pushed to github. It all seemed to run OK on RPi 3 and 4 I will try making a new lite SD with picframe and see if I can remember what I needed to apt install! PPPS When testing, after the python application stopped I was left with an unresponsive wayfire screen obscuring the terminal. In order to progress I pressed Ctrl-Alt-F2 and in the second terminal logged in and ran pidof wayfire then kill 123 or whatever the pid was, the Ctrl-Alt-F1 to go back.

[paddywwoof]

@helgeerbe OK I've made a new SD card using 64 bit bookworm lite and basically followed your instructions with the following changes:

# apt update, upgrade etc
sudo apt install python3-venv git libsdl2-dev wayfire
sudo reboot

mkdir /home/pi/.config
nano /home/pi/.config/wayfire.ini
...
    [core]
    plugins = autostart
    xwayland = false

    [autostart]
    picframe = /home/pi/start_picframe.sh
...
mkdir {Pictures,DeletedPictures}

Also I have merged the sdl2 branch to main in pi3d and made pysdl2 a dependency so you can

pip uninstall picframe
pip uninstall pi3d
pip install git+https://github.com/tipam/pi3d
pip install git+https://github.com/helgeerbe/picframe@sdl2

All in all it seems simpler than the previous X11 descriptions

[helgeerbe]

I'll give it a try. I'm wondering what the load is. Using top I get on my bullseye (lite) pi3 a load of 0.3, on bookworm (desktop) it's 1.2. That is OK, but not as good as the old OS. Maybe it becomes better using lite)

[paddywwoof]

Seems to be around 1.1 to 1.2 so only a very marginal improvement. As time goes on it might be improved I suppose.

top - 09:05:49 up  7:22,  2 users,  load average: 1.09, 1.14, 1.09
Tasks: 129 total,   2 running, 127 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.0 us,  1.5 sy,  0.0 ni, 96.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
MiB Mem :    908.5 total,    185.6 free,    441.9 used,    342.8 buff/cache     
MiB Swap:    100.0 total,    100.0 free,      0.0 used.    466.6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
    750 pi        20   0  769004 200292  76296 S   6.2  21.5  32:40.08 picframe 
    730 pi        20   0  234748  78540  55236 S   5.9   8.4  24:43.31 wayfire  
   1505 root      20   0       0      0      0 D   1.3   0.0   0:04.05 kworker+ 
   1531 pi        20   0   11712   4676   2776 R   1.0   0.5   0:04.10 top      
   1529 root      20   0       0      0      0 I   0.7   0.0   0:02.52 kworker+ 
     15 root      20   0       0      0      0 I   0.3   0.0   1:37.35 rcu_pre+ 
     25 root      20   0       0      0      0 S   0.3   0.0   0:01.51 ksoftir+ 
    636 root      20   0  262600  19120  16160 S   0.3   2.1   0:17.66 Network+ 
   1504 root      20   0       0      0      0 I   0.3   0.0   0:00.28 kworker+ 
   1507 root      20   0       0      0      0 I   0.3   0.0   0:00.43 kworker+ 
      1 root      20   0  168644  11816   8584 S   0.0   1.3   0:07.62 systemd  
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.16 kthreadd 
      3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp   
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par+ 
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 slub_fl+ 
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 netns    
     10 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 mm_perc+

[helgeerbe]

Looks good.

I have to test, if screenblanking is working with this minimal setup of wayfire.ini or if we have to load an additonal plugin.

I will change the wiki page.

[paddywwoof]

Helge, I've been trying screenblanking. At the moment I can blank with WAYLAND_DISPLAY="wayland-1" wlr-randr --output HDMI-A-1 --off but this seems to stop picframe running. i.e. after turning back --on the process is still there but only ticking over and certainly no rendering happening - just the grey screen with the mouse pointer. Also wayfire is using very little processor effort after attempting to turn the screen back on.

PS that did need an extra sudo apt install wlr-randr

[helgeerbe]

I updated the wiki.

• add missing wlr-randr for screen blanking
• update start_picframe.sh Blanking screen to have a nicer startup
• Add an additional tweak chapter
  • disable bluetooth
  • silent boot

[helgeerbe]

@paddywwoof how do you select the hdmi-port for picframe? Do we need a config to select the hdmi port? Using HMI-A-1 means we would assume that picframe is always running on the first hdmi port.

[paddywwoof]

I think I found a command to list the displays. I will dig around and see if I can find it. Does the wlr-randr --on and --off work on the desktop SD image for you? ... EDIT - just tried it on the other SD card and No. I can turn the screen --off but not back --on. At least the desktop re-appears but the systemd picframe process is still stalled.

[paddywwoof]

ls /sys/class/drm lists displays.

I'm wondering if we can turn the screensaver on and off as per raspi-config? We would have to set the time to something very short first.

[helgeerbe]

hm, could ist be more a sdl2 problem? I installed lxterminal. Run terminal and picframe (with reduced size). Then I run 'wlr-randr --output HDMI-A-1 --off; sleep 10; wlr-randr --output HDMI-A-1 --on`in the terminal.

picframe terminates with memory exception

[rock-meister]

@paddywwoof I can confirm that the latest instructions works on using 64 bit bookworm lite on Model 3B+. @helgeerbe both systemctl --user start picframe.service and systemctl --user restart picframe.service works fine over ssh. Not sure what errors you see.

[paddywwoof]

@rock-meister thanks for checking that. I'm not sure what causes the memory exception but the general problem is turning the screen on and off i.e. at night or if you have an infrared sensor. None of the old methods seem to work anymore on wayland but the nearest is using wlr-randr. However it seems to stop the slideshow as well as blanking the monitor, which could be solved by shutting everything down then restarting it again (i.e. with systemd) but that seems like overkill, and it's nice for the slideshow to pickup where you left it rather than re-shuffling everything.

[sapnho]

@helgeerbe I just made a clean install on a Pi4, and it works. Thanks! So, with Bookworm, there is no difference between installing on a Pi3 or 4 (and soon Pi5)? That makes it even easier for people to build some nice photo frames for Christmas!

@paddywwoof Is there any reason why the transitions shouldn't be as smooth as before? I may have noticed some jitter but I haven't tried it on my 32'' 4K frame in the living room yet, and it might have just been a long day.

At the moment sdl support for picframe and pi3d is not released

Is this a PictureFrame issue or is it something that has to do with Bookworm?

[sapnho]

@rock-meister thanks for checking that. I'm not sure what causes the memory exception but the general problem is turning the screen on and off i.e. at night or if you have an infrared sensor. None of the old methods seem to work anymore on wayland but the nearest is using wlr-randr. However it seems to stop the slideshow as well as blanking the monitor, which could be solved by shutting everything down then restarting it again (i.e. with systemd) but that seems like overkill, and it's nice for the slideshow to pickup where you left it rather than re-shuffling everything.

For a moment, I was happy having found this solution but in the new setup it doesn't work anymore.

Blanking the screen seems to be the last piece of the puzzle of the migration. This must be such a common issue on the Raspberry Pi, I wonder why it's so darn tricky.

[sapnho]

And Stop restart systemctl --user restart picframe.service (does not work over ssh) works well via Terminal.

[paddywwoof]

I'm not sure about the transitions. I did notice one of the pi3d_demos files, which is just a simple texture rendered onto a quad, seemed to have a slight flicker in brightness when I first tested it on wayfire with xWayland forced off. That seems very odd but it might be related to the compositor, I will do some more tests to see if I can narrow down the issue (or just check that there is an issue)

It is also slightly related to your other questions. The reason your xrandr solution doesn't work is because we have gone to some lengths to make SDL2 use wayland. Left to its own devices it would use xWayland, which is functionality built into wayland to allow X11 applications to still run. X11 is the old, tried and tested system (which is why SDL2 defaults to using it if both are available) but the intention is for everything to eventually switch over to wayland and X11 will gradually be shelved.

pi3d did actually run much of the time without any alteration on bookworm using xWayland (the hardest part was installing dependencies with the venv system) but there were a few issues, possibly with the way X11 functionality was being emulated so I decided now was a good time to make the switch to using SDL2 and, at the same time, switch to using wayland.

However (despite all the effort sorting out the issues) we don't have to switch to wayland right now. The picture frame I have running in the kitchen here has been going happily for several days and it's not running using wayfire (the windowing and input system for wayland) The trouble is that xrandr doesn't work with the DISPLAY=:0.0, `WAYLAND_DISPLAY="wayland-1" or anything else either, probably because of the differences between xWayland and X11 (or something else) At the moment I am just pausing and turning the brightness down to 0.0 but that's not really satisfactory.

Can you systemctl --user stop.. and start? I can certainly do that over ssh here.

[sapnho]

Can you systemctl --user stop.. and start? I can certainly do that over ssh here.

Yes, all the systemctl commands work well over ssh. (There is a typo in the Disable service systemctl --user disable picframe.servcie line).

[sapnho]

commands to blank screen under wayland on/off are

wlr-randr --output HDMI-A-1 --off
wlr-randr --output HDMI-A-1 --on

Why does this work in @helgeerbe 's script but not stand alone?

[paddywwoof]

Sadly it doesn't work in that script either! If you add at the end a series of off then on

sleep 20
wlr-randr --output HDMI-A-1 --off
sleep 20
wlr-randr --output HDMI-A-1 --on

you will find that the --off blanks the screen but also shelves the process. Apparently that's what it's supposed to do. And we should be trying to do something with screensaver but I just can't get the screensaver to work at all - the step in the setup instructions to turn screensaver off is redundant!!

[helgeerbe]

@paddywwoof

Can you do some tests on sdl2? When I run wlr-randr -off the display is listed as Enabled: no

Check SDL_DisplayModeChange event: SDL2 provides an event called SDL_DisplayModeChange to notify applications about changes in screen resolution and other display settings. Your application should listen for this event and respond accordingly. Here's an example of how to listen for the SDL_DisplayModeChange event:

SDL_Event event;
while (SDL_PollEvent(&event)) {
    if (event.type == SDL_DISPLAYMODECHANGED) {
        // Handle resolution change here
    }
}

So maybe pi3d can catch the event, and start drawing, when display is enabled again?

[helgeerbe]

using the screensaver on wayland does not work. SDL seems to disable it, if running.

And I can confirm that systemctl --user start picframe.servcice works on lite. I'm pretty sure I tested it on the desktop version, and was not able to start picframe.

[paddywwoof]

Helge, I'll have a look at the SDL side when I get home. From memory the python process has been terminated by wlr-randr --off so it might take a bit of working round!

[helgeerbe]

When I call wlr-randr --off I see that picframe stops with memory exception. So I thing it is loosing its display context (drawing to a non existing display). So my hope is, that you can catch the event, stopp drawing, and when the display returns, picframe resumes.

Don't know if I remember right, but I thought, that I read something that Wayland application should stop outputs to the display, if there is none. This will save cpu time, if there is nothing to do.

[paddywwoof]

OK, makes sense. As we're switching off the display we can stop the rendering first. I don't know if the SDL render surface will remain 'attached' and available for when the display is there again.On 5 Nov 2023 13:40, helgeerbe @.***> wrote: When I call wlr-randr --off I see that picframe stops with memory exception. So I thing it is loosing its display context (drawing to a non existing display). So my hope is, that you can catch the event, stopp drawing, and when the display returns, picframe resumes. Don't know if I remember right, but I thought, that I read something that Wayland application should stop outputs to the display, if there is none. This will save cpu time, if there is nothing to do.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[helgeerbe]

I was able to use the screensaver. Picframe also survive dpms mode.

export SDL_VIDEO_ALLOW_SCREENSAVER

with the idle plugin from wayfire I can toggle screensaver on and off by keyboard.

What I don't know is, how to send keystrokes from an sh script

[paddywwoof]

I tried using wtype but the screensaver wasn't working so I couldn't tell. I also couldn't get the screensaver to work with keyboard or wayfire.ini anyway!

[paddywwoof]

Still haven't managed to get the screensaver or dpms to work with wayfire. @helgeerbe did you do anything beyond setting the [idle] options in .config/wayfire.ini and adding export SDL_VIDEO_ALLOW_SCREENSAVER to start_picframe.sh?

I also tried stopping all rendering while wlr-randr --off ran but journalctl seems to show that if any possibility of keyboard, mouse or display are still present that's enough for wayland to kill off the python process somehow.

[helgeerbe]

Your have to load the idle plugin in the core setting. Wayfire.ini

[core]
plugins = alpha \
  animate \
  autostart \
  command \
  cube \
  decoration \
  expo \
  fast-switcher \
  fisheye \
  foreign-toplevel \
  grid \
  gtk-shell \
  idle \
  invert \
  move \
  oswitch \
  place \
  resize \
  switcher \
  vswitch \
  wayfire-shell \
  window-rules \
  wm-actions \
  wobbly \
  wrot \
  zoom
xwayland = false

[input]
xkb_layout = de

[idle]
disable_on_fullscreen = false
screensaver_timeout = 20
dpms_timeout = 30
toggle = <super> <shift> KEY_I

[autostart]
picframe = /home/pi/start_picframe.sh

start_picframe.sh

#!/bin/bash
#wlr-randr --output HDMI-A-1 --off
export SDL_VIDEODRIVER=wayland # sdl has to use wayland
export SDL_VIDEO_ALLOW_SCREENSAVER=1
source /home/pi/venv_picframe/bin/activate # activate phyton virtual env
picframe &  #start picframe
#wlr-randr --output HDMI-A-1 --on
lxterminal

I installed lxterminal and in configuration.yml I changed the size of picframe to a small window.

Booting up, I get picframe and a terminal window. Waiting 20 sec the screensaver starts and the windows wobble. After 30 sec the screen gets black when dpms is activated. Moving the mouse activates the screen. Picframe is still running. If I hit shift+Windowskey+i, screensaver is disabled. Hitting shift+Windowskey+i activates the countdown for the screensaver again.

[paddywwoof]

I thought I'd tried exactly that, but sure enough now I run it, it works! Still no further forward with wtype or other virtual keyboards.

[rock-meister]

alpha \
  animate \
  autostart \
  command \
  cube \
  decoration \
  expo \
  fast-switcher \
  fisheye \
  foreign-toplevel \
  grid \
  gtk-shell \
  idle \
  invert \
  move \
  oswitch \
  place \
  resize \
  switcher \
  vswitch \
  wayfire-shell \
  window-rules \
  wm-actions \
  wobbly \
  wrot \
  zoom

@helgeerbe are all these plugins needed? I used your Setup-guide-Bookworm-and-Wayland guide which only listed

[core]
plugins = autostart
xwayland = false

[autostart]
picframe = /home/pi/start_picframe.sh

[paddywwoof]

@sapnho I think not, certainly I only have autostart and idle in mine.

@helgeerbe I have added a couple of functions to pi3d.Display to call sdl2.SDL_EnableScreensaver() and Disable... I will test here then put the changes on GitHub if I can get it to work!

[helgeerbe]

@rock-meister this was only for testing. If we do any changes, I will put it in the wiki

@paddywwoof I had the same idea. I saw that sdl2 is providing such an api. Hope this will will work.

[paddywwoof]

I've put in a couple of changes. To picframe sdl2 branch: https://github.com/helgeerbe/picframe/commit/e4374406f21c51504b9bda7b836a788c45e62cf2 and pi3d sdl2 branch https://github.com/tipam/pi3d/commit/b370747c8fa5c8f57c6c482b88755144f3539504 I'm over at my mum's house at the moment, without a Raspberry Pi handy so I've only tested them on my laptop but it seems to work (after a fashion; the screensaver locks the screen requiring a password and if I attempt to turn that off it does something odd, turning the screen back on but minimising the python/sdl app)

Also I've not put any code in the @display_is_on.getter but there is a function SDL_IsScreenSaverEnabled() to get the state of the screensaver (a wrapper for which would have to be added to the pi3d.Display object)

[paddywwoof]

PS Tested this at home now and I'm struggling to get the the SDL_EnableScreenSaver() to work. i.e. If I comment out the line in viewer_display.slideshow_start() to disable the screensaver, it cuts in after a few seconds (set in .config/wayfire.ini) but when the line is not commented out, the screensaver is disabled, as it should be. If I then put a line immediately after the disable to enable the screensaver it continues to be disabled, and the same goes for calling viewer_display.display_is_on(True) which seems to work but display_is_on(False) doesn't.

[CraigeryTheKid]

I attempted a standard ctrl-f to check for this suggestion, so I apologize if it was tried already and did not work.

would adding the following to crontab -e work? I found this during my own searching/investigating:

[time stuff] /opt/vc/bin/tvservice -o [time stuff] /opt/vc/bin/tvservice -p && sudo systemctl restart picframe.service

edit: testing on buster (so not validating for the actual bookworm issue, sorry), it "works" perfect. So... I'm guessing there's already a reason this doesn't work on bullseye/bookworm

[paddywwoof]

@helgeerbe I thought I had solved the screensaver issue by using ydotool which I cloned and compiled giving two executables a) ydotoold which is a server and listens on a socket for b) ydotool and then accesses the linux io system directly (which requires root).

I added a few lines to viewer_display.py as shown below and, sure enough, when I set the venv and start picframe from a terminal it works perfectly. However when I do the same thing using start_picframe.sh (either manually or using .config/wayfire.ini and systemd) then the screen stays visible fine i.e. the synthetic mouse jiggling works, and the jiggling stops when I send the message to turn the screen off, and the screensaver cuts in. But then it doesn't wake up when I start the jiggling again.

I can't figure out what the problem is, or a way round it, but it does seem reminiscent of wlr-randr being able to switch off but not on again.

diff --git a/src/picframe/viewer_display.py b/src/picframe/viewer_display.py
index 8058725..3bb3f65 100644
--- a/src/picframe/viewer_display.py
+++ b/src/picframe/viewer_display.py
@@ -99,6 +99,8 @@ class ViewerDisplay:
         self.__clock_format = config['clock_format']
         self.__clock_opacity = config['clock_opacity']
         ImageFile.LOAD_TRUNCATED_IMAGES = True  # occasional damaged file hangs app
+        self.__mouse_jiggle_time = 0
+        self.__mouse_jiggle = True

     @property
     def display_is_on(self):
@@ -133,9 +135,11 @@ class ViewerDisplay:

         # do this anyway, shouldn't do any harm if pi3d.USE_SDL2 is not set TODO refactor the following section - use __display_power == 2 ?
         if on_off is True:
-            self.__display.disable_screensaver() # screensaver stops working - screen stays on indefinitely
+            #self.__display.disable_screensaver() # screensaver stops working - screen stays on indefinitely
+            self.__mouse_jiggle = True # stop screensaver by moving mouse
         else:
-            self.__display.enable_screensaver() # screensaver start - will turn after the the timeout period
+            #self.__display.enable_screensaver() # screensaver start - will turn after the the timeout period
+            self.__mouse_jiggle = False # leave mouse alone

         self.__logger.debug("Switch display (display_power=%d).", self.__display_power)
         if self.__display_power == 0:
@@ -450,7 +454,8 @@ class ViewerDisplay:
         self.__flat_shader = pi3d.Shader("uv_flat")

         # turn off screensaver
-        self.__display.disable_screensaver() # screen will stay on
+        #self.__display.disable_screensaver() # screen will stay on
+        subprocess.run("sudo /home/pi/ydotool/build/ydotoold &".split()) # start server

         if self.__text_bkg_hgt:
             bkg_hgt = int(min(self.__display.width, self.__display.height) * self.__text_bkg_hgt)
@@ -553,6 +558,11 @@ class ViewerDisplay:
             if block is not None:
                 block.sprite.draw()

+        if self.__mouse_jiggle and (tm - self.__mouse_jiggle_time) > 10: # NB set timeout to 30s
+            #subprocess.run("sudo /home/pi/ydotool/build/ydotool type a".split())
+            subprocess.run("sudo /home/pi/ydotool/build/ydotool mousemove -x 1 -y 0".split())
+            self.__mouse_jiggle_time = tm
+
         return (loop_running, False)  # now returns tuple with skip image flag added

     def slideshow_stop(self):

[sapnho]

So, I have included @paddywwoof's latest modifications and the slide show works great in Bookworm.

Are we closer to the screen on/off issue? It really is a tricky one, isn't it?

[paddywwoof]

Sounds good. I've been trying to get to the bottom of a couple of other quirks around picframe occasional not updating the db and not playing movies. Bothe we're fine before so it might be something I missed or a corruption, the power supply isn't really big enough so that's a likely cause of random problems.

I feel the screen off and on should be within reach. It works well if I start picframe manually rather than via a bash script so that must narrow down the cause of the problem. I could alway post a question on the RPi forum or stack exchange. (I did try the chat bots!)

Paddy PS Happy Christmas 🎄

[sapnho]

Merry Christmas, @paddywwoof ! In Germany, we celebrate on Dec 24, so tonight I have some time for tinkering.. :-)

It would be great to find a solution for the screen, as this is still the missing link to complete the migration. Fingers crossed!

[paddywwoof]

Hi, I might put a very quick how-to on here showing simple mods such as this https://youtu.be/IFycHagcdwA

[sapnho]

Very cool idea!

[sapnho]

Hi, I might put a very quick how-to on here showing simple mods such as this https://youtu.be/IFycHagcdwA

One idea for the next New Year party: Can you do fireworks as well? :-)

[Westpete]

Hi, another RPI newbie here.

I tried following the instruction here to set up RPI for PI3D on a clean SD card.

I tried the recommended Buster …arm64.zip and …armhf-full.zip on RPI 3A and 3B, neither combo even boots, despite trying editing hdmi settings directly on the SD card.

The latest install recommended by Imager is currently Debian Bullseye 32-bit, 2023-12-05. It boots and works like a charm to configure wifi, mount a usb disk, and Samba.

When following the step-by-step tutorial here to get PI3D running, I get similar messages described in this thread. And with few ideas what to do, google pointed me to this thread.

After reading this thread, it seems there might be a solution in sight but not yet an easy step-by-step instruction for less experienced users. Would this be a fair conclusion?

Is there any way to get my setup to work at this time, or should I put it to rest for a while until new ways are uncovered and documented?

[paddywwoof]

Hi I'm kind of obliged to use the latest default RPi OS here at home, and try to debug any issues in pi3d and picframe in the process. So I have a testing pi4 and Pi5 but the screen in the kitchen is 3b. All are running bookworm and the only disadvantage Seems to be the inability to turn the screen off.

That your pi fails to boot implies to me that there is a different problem, though not sure what.

[Westpete]

Thanks!

Is Bookworm a different release than Bullseye and Buster?

Both 3A and 3B are new out of the box, and with two new SD cards. RPI original power supply + HDMI. All combinations work with Bullseye, neither with Buster.

Since the topic of this thread is how to do without Buster, I hope there’ll be others like me, trying to set up PI3D on e.g. Bullseye.

[paddywwoof]

Hi, yes Bookworm is the latest version of the Pi Foundation's OS, there are some problems around the move from the older windows and input system (xorg) to the newer (wayland). However it does work in most respects and you can follow the instructions https://github.com/helgeerbe/picframe/wiki/Setup-guide-Bookworm-and-Wayland I didn't know that the Pi Foundation recommended Bullseye for RPi3 - that also sounds odd, maybe they found

Wolfang has stuck with the older Buster setup on his site as we know that it worked reliably. It should work in a similar way with Bullseye to be honest, if you can get that running, but you might not get the screen to turn off properly, having to make do with just turning the brightness down to zero. I'm away at the moment but I will try following his instructions when I get home, just to check how it goes.

The fact that you couldn't get the SD card to boot but you tried editing the HDMI settings on the SD card makes me think that you got some specific symptoms when you tried to boot that let you conclude that the problem was in the display setup or something. i.e. Maybe you could see from the LEDs flashing that it was infact booting, but you didn't get any output to the display?

Anyway, let us know how you get on.

[Westpete]

Thanks for helping out, much appreciated!The onboard LEDs led me to suspect the HDMI output was wrong. Red led constantly lit, while green was blinking in bursts indicating activity although nothing visible on screen. Seems to be Buster related though since HDMI works just fine with both Bullseye and Bookworm, with and without GUI.Today I tried Bookworm with RPI 3A+. The full 64-bit version was unstable, but 64-bit lite (command line only) seems good. The new step-by-step on github works great! It took me a while to get started with USB disk and network configuration, but getting there slowly. Will update more when I make it all the way or get stuck.Cheers!28 jan. 2024 kl. 17:59 skrev Paddy @.***>: Hi, yes Bookworm is the latest version of the Pi Foundation's OS, there are some problems around the move from the older windows and input system (xorg) to the newer (wayland). However it does work in most respects and you can follow the instructions https://github.com/helgeerbe/picframe/wiki/Setup-guide-Bookworm-and-Wayland I didn't know that the Pi Foundation recommended Bullseye for RPi3 - that also sounds odd, maybe they found Wolfang has stuck with the older Buster setup on his site as we know that it worked reliably. It should work in a similar way with Bullseye to be honest, if you can get that running, but you might not get the screen to turn off properly, having to make do with just turning the brightness down to zero. I'm away at the moment but I will try following his instructions when I get home, just to check how it goes. The fact that you couldn't get the SD card to boot but you tried editing the HDMI settings on the SD card makes me think that you got some specific symptoms when you tried to boot that let you conclude that the problem was in the display setup or something. i.e. Maybe you could see from the LEDs flashing that it was infact booting, but you didn't get any output to the display? Anyway, let us know how you get on.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>