Basically my application is to be configured as follows:
Image: goji-io - [based on torizon/debian] - should not be accessible outside, but communicates to goji-server over UDP. e.g networks: - backend
image: goji-server - based on [based on torizon/debian] - main webserver which is accessible by users from outside the box on port 80. e.g networks: -backend -frontend
image: goji-display - [based on torizon/weston-vivante] - Chromium browser which displays on the main screen and access goji-server but is not accessible outside the box. e.g networks: - backend
image: goji-flightsim - based on [based on torizon/debian] - an internal tool whihc communicates to goji-server over UDP but is not accessible outside the box. e.g networks: - backend
I’m not sure I quite understand what you mean by “implement” this example in OTA. But, let me try and see if I can clarify things.
Our OTA update system can update the docker-compose.yml on a TorizonCore device. This in turn updates the containers when the system tries to pull the new container images based off the docker-compose.yml. If you push an update, this will replace the current docker-compose.yml with a new one based on what you chose to update.
This is what I meant by our system currently only “manages” a single docker-compose.yml at a time. So if you have two docker-compose files docker-compose.yml and docker-compose.override.yml you can only really have one of these on the system at a time.
The example you’re referencing does not take our OTA system into account at all. I hope this helps clear things up.
I didn’t pick this example by accident, I took the example because the OTA code recommends it when you are uploading a Docker Compose Package as you can see in the screen snapshot.
Oh well that example was referenced on how to use multiple containers via docker-compose. Not so much on how to use multiple docker-compose files concurrently, which as I said is not possible currently.
But I can see how one might make that assumption. I’ll provide this feedback to the team.
After merging the docker-compose.override.yml file into my docker-comose.yml file, I was unable to get the kiosk container to launch. After tracking down the logs I found that it was failing with a message .
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[1:1:0316/221015.355959:FATAL:zygote_host_impl_linux.cc(190)] Check failed: ReceiveFixedMessage(fds[0], kZygoteBootMessage, sizeof(kZygoteBootMessage), &boot_pid).
#0 0xaaaaebb0a800 (/usr/lib/chromium/chromium+0x4da67ff)
.... (stack trace lines deleted)
#18 0xaaaae969a8f4 (/usr/lib/chromium/chromium+0x29368f3)
[end of stack trace]
Calling _exit(1). Core file will not be generated.
However, that gets me a bit further with the container coming up but doesn’t display my web page, and it gives me a new set of problems that I can see in the logs for the container. Is there some additional configuration I am missing?
[1:61:0316/230015.140470:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:61:0316/230015.147319:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:61:0316/230015.148657:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[1:40:0316/230015.172368:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.172482:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.853796:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[1:40:0316/230015.854860:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Fontconfig error: Cannot load default config file
[41:48:0316/230016.261972:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.315601:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.386334:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.417169:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230016.648764:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230017.178262:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230017.501325:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230022.273571:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230022.537803:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230052.309329:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
[41:48:0316/230052.600708:ERROR:xproto_internal.cc(109)] Cannot send request of length 32568648
Here’s my docker-compose file
version: "2.4"
services:
pilot:
container_name: pilot
networks:
- backend
- frontend
volumes:
- type: bind
source: /mnt/gojimedia
target: /mnt/gojimedia
ports:
- "80:80"
- "8809:8809"
- "8810:8810"
- "8811:8811"
image: johntoebes/goji:goji-server
weston:
# pass environment variables to the container
# in this example, you accept the NXP EULA with regards to use of Vivante
# binaries for GPU-accelerated graphics
environment:
- ACCEPT_FSL_EULA=1
container_name: weston
# For i.MX 8-based modules use this image:
image: torizon/weston-vivante:2
# Required to get udev events from host udevd via netlink
network_mode: host
volumes:
- type: bind
source: /tmp
target: /tmp
- type: bind
source: /dev
target: /dev
- type: bind
source: /run/udev
target: /run/udev
cap_add:
- CAP_SYS_TTY_CONFIG
# Add device access rights through cgroup rules
device_cgroup_rules:
# ... for tty0
- 'c 4:0 rmw'
# ... for tty7
- 'c 4:7 rmw'
# ... for /dev/input devices
- 'c 13:* rmw'
- 'c 199:* rmw'
# ... for /dev/dri devices
- 'c 226:* rmw'
kiosk:
container_name: kiosk
image: torizon/kiosk-mode-browser:2
# run a custom command, equivalent to CMD on a Dockerfile
command: --window-mode http://0.0.0.0/map?bulkhead
security_opt:
- seccomp:unconfined
networks:
- frontend
volumes:
- type: bind
source: /tmp
target: /tmp
- type: bind
source: /var/run/dbus
target: /var/run/dbus
- type: bind
source: /dev/dri
target: /dev/dri
# only bring-up this container if others are successfully started
depends_on:
- weston
- pilot
# size of shared memory between containers
shm_size: '256mb'
device_cgroup_rules:
# ... for /dev/dri devices
- 'c 226:* rmw'
networks:
backend:
internal: true
frontend:
internal: false
Well I can’t reproduce this exactly since I don’t have access to your johntoebes/goji:goji-server container image. However when I run your docker-compose (minus the parts related to pilot), it does work if I target other websites. That is to say there doesn’t seem to be issues with the weston and kiosk part of the compose file.
Also as a side-note the following errors/warning:
kiosk | [1:60:0317/203015.173918:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk | [1:60:0317/203015.177671:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk | [1:60:0317/203015.179392:ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
kiosk | [1:40:0317/203015.194748:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk | [1:40:0317/203015.195432:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk | [1:40:0317/203015.875570:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
kiosk | [1:40:0317/203015.875986:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Usually pop up with chromium, but they can be ignored and are not typically fatal errors. So the only abnormality I see in your logs is the lines about Cannot send request of length 32568648. Since I don’t have any knowledge about your Web UI container I can’t really assume too much more. The only thing I would suggest is to make sure the endpoints you’re trying to reach can be contacted by the kiosk container.
I’ve decided to run in --browser-mode to see what is going on and discovered that I am getting the dreaded Chromium “The browser supports WebGL, but initialization failed” message. It appears that WebGL isn’t enabled on the iMX8. I’ve created a simple docker compose which shows this going to webglreport.com
So since it appears that Webgl isn’t supported on Chromium (Chromium is not accelerated ( webgl not activated )) on the iMX8 I switched to using Cog and it shows that webgl1 is enabled, but not webgl2. You can see it with this example docker compose Docker-Cog.yml (1.7 KB)
I’ve managed to launch a COG version going to our application, but to to be honest, the frame rate with Cesium is really bad.
What are my options to get a WebGL enabled browser on the iMX8?
I see, I wasn’t aware your web UI was using CesiumJS. As you noticed our chromium is currently lacking hardware acceleration for webgl. On the other hand while Cog is hardware accelerated it has it’s own issues. I’ve heard reports that it has not the best performance with various JS frameworks.
For chromium the team is looking into if it is now possible to get proper hardware support. For Cog we’ve raised the performance issues with Igalia (company behind cog) already. However for either case I don’t have any definite timelines or roadmaps. Since some of this stuff is outside of Toradex control.
As for alternative browsers besides chromium/cog. We haven’t identified any browsers yet that behave well on i.MX while also providing GPU support. If you happen to hear of any such embedded browsers it would be appreciated if you let us know.
In summary, we are aware of such issues. But there is no good answer yet at this time.
I will agree with that. After only a few hours, Cog goes from an initial state of extremely slow to a complete crawl updating only once every 10-20 seconds.
Do any of the other Apalis SOMs provide support for accelerated CesiumJS? We moved from the TK1 to the iMX8 in hope of getting better performance.
Given that the Raspberry Pi is using the Arm Cortex and has implemented supported for WebGL 2.0 with Chromium (one article here) is there any possibility of benefiting from the work that was done there?
Also, has anyone talked to the Flow Browser people?
Given that the Raspberry Pi is using the Arm Cortex and has implemented supported for WebGL 2.0 with Chromium (one article here ) is there any possibility of benefiting from the work that was done there?
The issue is that i.MX based devices use a proprietary GPU from NXP. For a browser to be properly hardware accelerated there needs to be support in that browser for this specific GPU.
Now there was recent news that Chromium now supports i.MX GPUs. However, this was rather recent and still hasn’t been investigated, tested, and integrated in our Chromium.
This is what I mean by a lot of this is outside of Toradex control. Since we have little to no control over the browser side or the GPU side of the issue. We’re actively investigating possible solutions for both Cog & Chromium. But such things take time.
