balena-os / meta-balena

A collection of Yocto layers used to build balenaOS images
https://www.balena.io/os
968 stars 115 forks source link

FBCP blanks PiTFT screens after balenaOS 2.38 #1772

Open chrisys opened 4 years ago

chrisys commented 4 years ago

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.

balena-ci commented 4 years ago

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

denisinla commented 4 years ago

Has this been resolved yet?

drew1kun commented 4 years ago

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 commented 4 years ago

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

denisinla commented 4 years ago

Can confirm still broken.

alexgg commented 4 years ago

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 commented 4 years ago

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

eiddor commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

https://github.com/klutchell/balena-pihole/commit/6a8f4dcfa0acb8881e56ca622c9398586474e72f

eiddor commented 4 years ago

@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.