Trying to get a remote desktop. I’ve been reading
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?
Docker run commad:
docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=weston --net=host --env ENABLE_RDP=1 --cap-add CAP_SYS_TTY_CONFIG
-v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/
–device-cgroup-rule=‘c 4:* rmw’ --device-cgroup-rule=‘c 13:* rmw’
–device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’
torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE --developer weston-launch
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”
Does it need a port number too?
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.
I got this to work. I actually needed to ad port 5900 to the ip address ::5900
Odd, isn’t port 5900 the default port for VNC?
Maybe for some reason you had to explicitly define this in your setup. In any case glad to hear you got this working now.
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.
Please await a future fix for this.
i do have 10inch display from toradex attached via dsi to lvds adapter.
I can view screen and touch etc.
Well that complicates things. When I attach a HDMI display VNC works. I’ll forward your information here back to our team.
This is the docker file we are using for Weston and Chrome
Main XWAYLAND container customized to run on Torizon OS
# TAG Information → Docker Hub
# Accept the EULA required to run imx8 vivante graphic drivers
# Required to get udev events from host udevd via netlink
- type: bind
- type: bind
- type: bind
# Add Linux capabilities. (https://man7.org/linux/man-pages/man7/capabilities.7.html)
# Add device access rights through cgroup...
# ... 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.
test: ["CMD", "test", "-S", "/tmp/.X11-unix/X0"]
Chrome browser kiosk container based on Torizon OS (Provided by Toradex)
NOTE: Does not support hardware video rendering yet…
# TAG → Docker Hub
# Override the default labeling scheme for each container.
# --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.
# Add rules to the cgroup allowed devices list.
# ... for /dev/dri devices
# - 'c 226:* rmw'
# Mount host paths or named volumes. Named volumes need to be specified with the top-level
- type: bind
- type: bind
#- 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.
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.
I think using display=:1 could be the problem.
Hmm even with Youtube I’m not observing any significant slow-down with VNC enabled vs not enabled.
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?
Sorry for the confusion. Yes you are correct.
With out display VNC not working that Toradex is working on finding the root cause and fixing it.