Open 3rdIteration opened 2 years ago
Hey! Very good stuff, especially with the bitcoin only firmware and the standard one.
I remember having some issue with hdmi output in 32 bits in the past when developing. Is this something you don't have with your special recipe handling the graphic libraries ? Did you testes it on the 3 raspberry pi model?
The sleep 1 can probably be removed with some synchronization with the pitrezor process. I will check how to handle this
My main concern is having a new process that is running live. Is this something that can be avoided? I want to avoid introducing a security hole by having a separate process that could interact with the pitrezor process maliciously.
No worries, thanks for the great work on the firmware :)
Basically the HDMI mirror stuff only works with the 32-bit platform, but for this to work in Yocto I basically needed to force the inclusion of some files via a special recipe. (It's a pretty dirty approach but doesn't mess with your existing graphics libraries)
It works fine on the Pi4 and PiZero 1.1, but the GPU driver stuff is handled slightly differently on the original Pi1A, so the build that I have for that doesn't include the HDMI mirror. It should be do-able with a Pi1A, but I don't think it's worth the extra work to get mirror going for the legacy hardware (The Pi1A stuff is in a separate branch on my Github)
Unfortunately this is a slight security downgrade as you need a separate process for the mirror (at the moment) and are also relying on some closed source stuff in the graphics drivers that the capture/mirror possible, so again, another possible hole. (When compared to directly driving the screen via SPI)
Other changes are minimal with the exception of a few spots in documentation, shell files where I link to my own repo. (Just so that it works standalone for now) I also didn't want to mess too much with the other packages you had in the build, so just have a cut-down vc-graphics recipe to include some of the files needed to build/run that will happily run alongside the mesa based stuff that you already have in the image.
The main catch is that the fbcp-ili9341 stuff doesn't build properly in an x64 environment, but simply using the x86 builds for RPi3 works great. Basically I figured that abstracting the display this way was simpler than directly supporting individual additional screens that are the wrong resolution, aspect ratio, colour, etc.