Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FBCP blanks PiTFT screens after balenaOS 2.38 #1772

Open
chrisys opened this issue Dec 4, 2019 · 13 comments
Open

FBCP blanks PiTFT screens after balenaOS 2.38 #1772

chrisys opened this issue Dec 4, 2019 · 13 comments

Comments

@chrisys
Copy link
Member

chrisys commented Dec 4, 2019

Somewhere between balenaOS 2.38 and 2.43, the use of fbcp has started blanking the display output on small PiTFT screens (using the pitft35 and pitft28 dtoverlays).

On 2.43, starting fbcp clears the balenaOS splash screen and does not provide any further output. On 2.38, starting fbcp does not clear the splash screen and correctly copies to the framebuffer.

We (+ @petrosagg) disabled Plymouth on 2.43 and although the splash screen was no longer displayed, fbcp then works correctly again.

@chrisys chrisys changed the title FBCP blanks PiTFT screens after 2.38 FBCP blanks PiTFT screens after balenaOS 2.38 Dec 4, 2019
@balena-ci
Copy link
Contributor

[chrisys] This issue has attached support thread https://jel.ly.fish/#/support-thread~2b02df83-15b7-44af-999d-a492c3dab194

@denisinla
Copy link

Has this been resolved yet?

@drew1kun
Copy link

Using 2.47.01rev (supervisor: 10.6.27) and getting the white screen instead of correctly displayed PADD for pihole. Moreover, it seems that PADD in pihole does not even start:

13.04.20 17:16:35 (+0300)  pihole  /dev/fb1 not found. Disabling fbcp & PADD

Also, leaving this related discussion here:
https://forums.balena.io/t/padd-from-balena-pihole-project-does-not-work-with-pitft-2-8/48049/13

@drew1kun
Copy link

drew1kun commented Jun 16, 2020

That's unfortunate, that there was no activity on this issue (v2.51.1+rev1 still has this problem)

@denisinla
Copy link

Can confirm still broken.

@alexgg
Copy link
Contributor

alexgg commented Aug 6, 2020

An easy workaround for this is to stop plymouth from the application before starting the graphical subsystem (X11, Wayland). This can be done by issuing the following d-bus command:

DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1   org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"

@chrisys
Copy link
Member Author

chrisys commented Aug 10, 2020

@denisinla @drew-kun could you try this suggestion at let us know if it helps?

@eiddor
Copy link

eiddor commented Aug 10, 2020

@denisinla @drew-kun could you try this suggestion at let us know if it helps?

Is this done in the Device Configuration section under "Custom Configuration Variables?"

@drew1kun
Copy link

drew1kun commented Sep 7, 2020

@chrisys @denisinla @eiddor @alexgg
Sorry, I may misunderstood how to do this in order to test the solution...
This is what I have been trying to do:

Downloaded balena-cloud-pihole-dnscrypt-raspberrypi3-64-2.47.0+rev1-dev-v10.6.27.img and flushed it with Balena Etcher,
Then added the new Custom Configuration Variable and test...

But adding the config var getting this:
Screen Shot 2020-09-07 at 6 07 37 PM

Am I doing this wrong way? Any suggestions?

@alexgg
Copy link
Contributor

alexgg commented Sep 8, 2020

@denisinla @eiddor what I meant is that the application needs to instruct the OS to stop plymouth before launching a graphical subsystem. So this needs a change in the application entry script so that it uses dbus to send a command to the OS. On multicontainer applications they will need to set the io.balena.features.dbus label on the docker-compose file for this to work. See the documentation at https://www.balena.io/docs/learn/develop/runtime/#dbus-communication-with-host-os

Then, the application needs to issue the following command early on:

DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1   org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"

You can then check that the plymouth service in the OS is stopped.

The expected result is that if the graphical subsystem is launched after plymouth has been stopped it will work.

@eiddor
Copy link

eiddor commented Sep 8, 2020

@alexgg Thanks for the extra details - I think I understand the process better, but I'm not versed enough in the balena/containerization process to test it.

Piecing everything together, though, it sounds like I'd have to do this (on a new image so that I can keep my working "machine" handy):

Add this to docker-compose.yml in the package:

version: '2'
services:
  pihole:
    environment:
      - 'DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1   org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"'
    labels:
      io.balena.features.dbus: '1'

And add "dbus" to this in pihole/Dockerfile:

RUN install_packages cmake libraspberrypi-dev dbus

I know this is beyond the scope of the issue, so I appreciate the extra guidance.

Would the plymouth service need to be restarted again after the GUI loads?

@klutchell
Copy link
Collaborator

I've applied this workaround here with success on two different screen overlays so far.

klutchell/balena-pihole@6a8f4dc

@eiddor
Copy link

eiddor commented Oct 15, 2020

@klutchell Whatever changed in your last update from a few days ago fixed everything for me without any extra workarounds. I'm running balenaOS 2.58.3+rev1 (Supervisor 11.14.0) and my display is working perfectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants