Closed fhunleth closed 2 years ago
Updated to contain the 7" touchscreen drivers. This is untested.
Tried with vc4-kms-dsi-7inch but got a black screen.
I'm not sure if this error message is related somehow:
Otherwise it seems v3d is loading ok:
Btw, I noticed that regular RaspberryPI OS desktop uses vc4-kms-v3d as an overlay defined in the config.txt. So, scenic app runs fine on RP 7' screen with RPI4 with default raspberry pi os settings.
Please correct me if I'm wrong. The nerves_system_rpi4 image is not stripped down version of RaspberryPI OS? Is that correct? Thanks.
The WiFi error message is ok. The WiFi driver first tries a board specific firmware and then falls back to the generic firmware. In your case, it loads brcmfmac43455-sdio.bin
. There is a board-specific configuration file, brcmfmac43455-sdio.raspberrypi,4-model-b.txt
, that it loads in a subsequent load. It's unfortunate that the success message isn't printed.
Regarding the nerves_system_rpi4
image, it uses the same Linux kernel that Raspberry Pi OS does. I try to match them up so this is really helpful information about Raspberry Pi OS using vc4-kms-v3d.
To make sure that I understand, could you post the config.txt
that works for you.
Also, you're running a Scenic demo app, right? I have a 7" touchscreen and Pi4. Is it something that I could try out as well?
aaa, got it. Thank you for the explanation.
The nerves example app can be found here: https://github.com/rkenzhebekov/hello_nerves
The default RaspberryPI OS config.txt is here config.txt
In this video https://drive.google.com/file/d/1rXSb6lNdcNF41QmmiysdM5CVc_EohSXX/view?usp=sharing I show weird behavior that happens after reboot. The initial run of nerves app shows no issue after I burn firmware to SD card. However, after reboot the touchscreen response becomes much slower. Same firmware, same code and nothing is changed between reboot.
This video shows running hello_nerves app on Raspberry PI OS desktop version. https://drive.google.com/file/d/1vjrvbDzKTgal1t6PFKaWB29NCGjkYWGD/view?usp=sharing
Thanks for the links. The videos were very helpful. The only difference that I can think of between the first and second runs is that the data partition is formatted on the very first run. That takes a couple seconds. I have no clue why that would make a difference, though.
I will see try to find some time to reproduce here over the next couple days. Hopefully I'll notice another clue.
Good to know about data partition on first run. Perhaps, while partition process is running the other processes gets more time to load necessary drivers properly before nerves app starts.
I'm not using scenic butt another graphic library and ended up using the vc4-kms-v3d-rpi4
overlay. The normal RaspberyPI OS does refer to vc4-km3-v3d
but behind the scenes it is loading vc4-kms-v3d-pi4
using the overlay_map
I've done a little bit of testing with this, but I'm able to get the example project work. This is repeated in the logs:
11:02:37.176 [warn] Scenic.Driver.Nerves.Touch: Device not found: "raspberrypi-ts"
I also uncommented config.txt line to use dtoverlay=vc4-kms-dsi-7inch
as I'm using the official screen
It seems the full kms driver might be loaded, so I'm not sure if this is configuration issue, my connection, or something missing in this system. Below is some output from the test
The Crosshair demo is working for me now and it's responsive! The light mode/dark mode switch works, but I can't change the demo.
I want to review my changes to get rid of extraneous settings, but the branch should work with changes to the demo app:
config/target.exs
, change the touchscreen driver name from raspberrypi-ts
to "generic ft5x06"
Process.sleep(5000)
to the children
function in application.ex
. This hack is needed since the Scenic driver tries to open the GPU driver too quickly and gives up rather than retrying../deps/scenic_driver_local/c_src/device/drm.c
and change /dev/dri/card0
to /dev/dri/card1
Here are the main things that I did in the commits:
config.txt
to autodetect the display like Raspberry Pi OS does. This just seems easier going forward anyway.overlap_map.dtb
file to the overlays directory. Without this, the RPi was applying the non-rpi4 overlays./sys/firmware/fdt
. This was a bit tedious, but the process was to sftp it to my laptop, run dtc -O dts
on it, look at all of the "compatible" attributes, search them in the Linux tree and enable the kernel modules associated with them. I compared the device tree that we're getting to the one that you get with Raspberry Pi OS and it's the same now for the 7" touchscreen.
Thank you Frank for making this work!!! I would immediately test this out on my devices but unfortunately I'm currently out of town and don't have access to the devices. Otherwise, I would contribute at least with the testing
Hi @rkenzhebekov! Thanks for the update. Definitely no rush - just let me know when you're back and have time. We can pick up testing then.
@fhunleth the issue with 'dropdown' selection is related to Scenic.Driver.Nerves.Touch
. After I commented out Scenic.Driver.Nerves.Touch
the dropdown works fine and I can change demo scenes. I think this issue is unrelated to your changes.
I ran the demo app with your suggestions and with full-kms
branch and the screen is responsive!!! :100: Tried to reproduce w/ multiple reboot but problem is no longer reproducible. I guess it is due to additional 5 seconds sleep :)
I think the change in ./deps/scenic_driver_local/c_src/device/drm.c
should be discussed with the scenic_driver_local
team to see if possible to make it configurable or auto-detectable somehow.
@rkenzhebekov this is very exciting! How is the performance on the screen with this setup? Does it feel generally performant? (I know that previous versions felt extremely laggy)
I'm going to go ahead and merge this since it seems like it works good enough. We're planning a minor version bump to nerves_system_rpi4
soon, so this is a good time for a bigger change like this.
@rkenzhebekov Thank you for testing and the feedback!
@rkenzhebekov this is very exciting! How is the performance on the screen with this setup? Does it feel generally performant? (I know that previous versions felt extremely laggy)
@axelson it feels performant to me. The noticeable lag is gone. Also, tried with Boyd's Transform example and it is also fast.
That's great to hear!
This switches from the older fake KMS drivers that used to be the only option. It keeps the fake KMS device tree around just in case there's an issue and someone needs to check if there's a regression. After this gets more use, the plan would be to remove the fake KMS overlay.