search

balena-labs-projects / fbcp

fbcp driver for SPI based displays for Raspberry Pis via fbcp-ili9341
14 stars 1 forks source link

fbcp: build rpi-fbcp and fbcp-ili9341 with buildroot #5

Closed klutchell closed 3 years ago

klutchell commented 3 years ago

Note that dtoverlay is a new label and FBCP_DISPLAY option that relies on BALENA_HOST_CONFIG_dtoverlay being set in order to use the legacy rpi-fbcp driver (supports more displays via kernel device trees).

Change-type: major Signed-off-by: Kyle Harding kyle@balena.io

klutchell commented 3 years ago

The README could probably use some updates but I've tested this with 2 different screens:

FBCP_DISPLAY=adafruit-hx8357d-pitft
FBCP_DISPLAY=dtoverlay
BALENA_HOST_CONFIG_dtoverlay=piscreen
rahul-thakoor commented 3 years ago

hey @klutchell i will try to find some time to test this soon.

last time in the labs meeting, we discussed removing the per target tags and have all the image similar to latest tag that is including all binaries and specifying at runtime via the ENV VAR. i see you are currently building each individually and copying over the binaries in Dockerfile.all.

Will this be possible with the new build process?

klutchell commented 3 years ago

hey @klutchell i will try to find some time to test this soon.

last time in the labs meeting, we discussed removing the per target tags and have all the image similar to latest tag that is including all binaries and specifying at runtime via the ENV VAR. i see you are currently building each individually and copying over the binaries in Dockerfile.all.

Will this be possible with the new build process?

Anything is possible ;)

Yeah, in fact we can get the desired behaviour by only pushing the latest tag and not the individual display tags. They can stay local on the builder workstation and never be published, just a small tweak to push.sh.

I'll change this PR back to draft and make a couple small adjustments including that one.

klutchell commented 3 years ago

Closing this PR as the buildroot images are actually larger than the dockerize images. This is largely due to the way build vs runtime dependencies are included.

I also found that the buildroot method added several layers of complexity that were not necessarily beneficial for this particular project.