But it does not work. When I use windows remote desktop to try to connect it just times out. I’ve tried VNC as well. not luck. I do not have a display yet, so I need the remote to work. Anyone, try this on this SOM before?
Unfortunately the default Windows programs for RDP/VNC have been known to be problematic with the remote desktop stack we use in Torizon. There may be some way to get the default Windows programs to work, but it probably requires some advanced configuration that I’m not too knowledgeable about.
What I can do, is suggest an alternative program. On my Windows machine I use “TightVNC Viewer”. This works for getting a VNC remote desktop, at least for me. I would suggest to give this a try if possible.
I tried tightVNC as well. AFter running the docker script for VNC it come up with this error:
“Error in TightVNC Viewer: No connections could be made because the target machine actively refused it”
It shouldn’t need a port number. The VNC container uses the same IP address and networking as the device itself.
Also if I recall correctly, all I had to do was install TightVNC on my Windows machine and it more or less worked out of the box. No extra configurations required.
For us it is not working. Constantly connection refuses. Another issue with this is that our kiosk container does not and complains with X windows issues. If I disable ENABLE_VNC then reboot the 8M plus som then all good.
We need to access entire display remotely where we are using Kiosk container to show our web application on it.
There is a current issue with VNC where if there is no local display attached to the system then it will not work. This is unintended behavior and the team is currently investigating as to why.
This is the docker file we are using for Weston and Chrome
Main XWAYLAND container customized to run on Torizon OS
weston:
# TAG Information → Docker Hub
image: torizon/weston-vivante:2.6
platform: linux/arm64
# Accept the EULA required to run imx8 vivante graphic drivers
environment:
- ACCEPT_FSL_EULA=1
- ENABLE_VNC=0
# 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
# Add Linux capabilities. (https://man7.org/linux/man-pages/man7/capabilities.7.html)
cap_add:
- CAP_SYS_TTY_CONFIG
# Add device access rights through cgroup...
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'
# Override the default command.
command: --developer weston-launch --tty=/dev/tty7 --user=torizon
# Configure a check that’s run to determine whether or not containers for this service are “healthy”.
# See the docs for the HEALTHCHECK Dockerfile instruction for details on how healthchecks work.
healthcheck:
test: ["CMD", "test", "-S", "/tmp/.X11-unix/X0"]
interval: 5s
timeout: 4s
retries: 6
start_period: 10s
Chrome browser kiosk container based on Torizon OS (Provided by Toradex)
NOTE: Does not support hardware video rendering yet…
kiosk:
# TAG → Docker Hub
image: torizon/kiosk-mode-browser:2.5.0
platform: linux/arm64
# Override the default labeling scheme for each container.
security_opt:
- seccomp:unconfined
# --window-mode : runs the browser inside a maximized window without the navigation bar
# --browser-mode : runs the browser in a standard window with navigation bars and all user menus enabled
# --virtual-keyboard : enables a virtual keyboard for text entry
command: --virtual-keyboard --window-mode https://www.google.com/
# Set the size of the /dev/shm partition for this build’s containers. Specify as an integer value representing the
# number of bytes or as a string expressing a byte value.
shm_size: '256mb'
# Add rules to the cgroup allowed devices list.
#device_cgroup_rules:
# ... for /dev/dri devices
# - 'c 226:* rmw'
# Mount host paths or named volumes. Named volumes need to be specified with the top-level
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
# Express dependency between services. Service dependencies cause the following behaviors:
# docker-compose up starts services in dependency order. In the following example, db and redis are started before web.
# docker-compose up SERVICE automatically includes SERVICE’s dependencies. In the example below, docker-compose up web
# also creates and starts db and redis.
# docker-compose stop stops services in dependency order. In the following example, web is stopped before db and redis.
depends_on:
weston:
condition: service_healthy
And DSI to LVDS 10" screen with overlays applied as per easy installer guide.
When I enable VNC then connection always get refused and Chrome never starts.
The issue with VNC and Kiosk goes away if you add the environment variable DISPLAY=:1. You need to add this to both the Weston and Kiosk container environments.
It’s a weird interaction with XWayland, but adding this variable appears to fix it.
Thank you Jeremias. It works with display attached to board physically. As you have mentioned that with out display it does not.
Another thing to add here is that, once you enable VNC via Weston add this :1 display env. argument. Whether we use VNC via VNC viewer or not, performance on target gets really slow and laggy. CPU usage to quite high even we do not connect to target over VNC viewer. Just enabled add so much CPU usage.
Glad to hear VNC works now, with a display attached at least. If you require VNC without a display attached that is something that is being investigated by the team.
As for your comment, on CPU usage with VNC. I don’t notice any abnormal CPU usage by just enabling VNC, compared to not having it enabled. What kind of CPU usage are you seeing on your side?
On another note if CPU usage is a concern of yours, you might want to use the kiosk container that utilizes Cog instead of Chromium. Cog should be able to utilize the GPU of the SoC and thus less CPU load compared to Chromium.
To see that, I would recommend open heavy website, ex. Youtube.com (I used…) and try to just scroll with that 10 inch touch screen. You do not need to play any video. Just scroll.
After that, Disable VNC in Weston and remove both DISPLAY ENV flag and restart target and do the same , open youtube.com and scroll. You will see significant improvement.
For now we are ok with current solution. However we would certainly need VNC solution that your team is working on. Do let us know as soon as that is available.
When you say “VNC solution that your team is working on”, are you referring to the bug with VNC not working without a display attached? Or are you referring to something else?
