Hello there,
I try to connect to a container running x11vnc, on TorizonCore, on my imx8m-plus board (Yavia).
Whatever I do, when I try to connect, it is stuck in loading screen. Nothing is displayed in the logs, and it works on a raspberry pi 3 with docker, as well as my Ubuntu PC running docker.
Maybe I’m missing a configuration to do on the Toradex board host?
Thanks in advance for your help!
Hello @EmmanuelC,
Can you link what TorizonCore version you are using, and what method are you using to build the image? TorizonCore Builder?
When you say you are ‘trying to connect to the container’ what does this mean? Are you trying to access the container while ssh’d into the host? Are you inside the container trying to connect outside?
-Eric
Hello Eric,
I use TorizonCore version 6.1.0, and I flashed directly with Easy Installer.
The docker image is built with a Dockerfile, but it still doesn’t work for example with the official x11vnc image, with the same symptoms (Docker).
The idea is that I map the port 5900 with 5900, and x11vnc starts well in the Docker container.
However, when I try to connect from my PC to the VNC session (from which I can connect by ssh or a web page, so the connection is OK and there is no firewall rules), it tries to open the session indefinitely.
And I have the same issue with noVNC in front: it tries to open indefinitely the session.
Hey @EmmanuelC,
I initially would not expect these docker containers to be able to run. Mainly because the root of docker files need to have information relevant to the drivers/hardware . For your containers, there would need some cross compilation efforts in order to work.
The minimal Debian containers that we provide stem from Bulleye release of Debian. Her e is a guide on them: Debian Containers for Torizon | Toradex Developer Center
What is suggested to to take our base image (that’s appropriate for the application) and add compatible tools/features that are required.
***additional
One of our team members linked me an important article referencing X11.
It looks like its a specifically unsupported from the NXP IMX side of things.
-Eric
Hello @eric.tx!
Thank you very much for this interesting information. For now I focus on other topics, but for sure I will look in a way to use Wayland.
The application turns with pysimplegui (and then tkinter behind). I will let you know as soon as I have moved forward.
Do you any suggestion?
Hello!
I’m so sorry for the late reply, I was fully on other topics last weeks.
Firstly, when I try this tutorial with my Yavia dev board: VNC on Torizon/Wayland/Weston
I can’t connect to the board by VNC. It says the connection is refused.
Here are the logs:
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format…
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format…
touch: cannot touch ‘/tmp/nxp-eula-accepted’: Permission denied
Date: 2023-04-24 UTC
[14:44:44.484] weston 9.0.0
https://wayland.freedesktop.org
Bug reports to: Issues · wayland / weston · GitLab
Build: 9.0.0
[14:44:44.485] Command line: /usr/bin/weston
[14:44:44.485] OS: Linux, 5.15.77-6.1.0+git.349786b46e61, #1-TorizonCore SMP PREEMPT Wed Dec 28 09:58:45 UTC 2022, aarch64
[14:44:44.485] Using config file ‘/etc/xdg/weston-dev//weston.ini’
[14:44:44.485] Output repaint window is 7 ms maximum.
[14:44:44.486] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-9/drm-backend.so’
Bug reports to: Issues · wayland / weston · GitLab
[14:44:44.493] initializing drm backend
[14:44:44.494] logind: not running in a systemd session
[14:44:44.494] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[14:44:44.499] using /dev/dri/card1
[14:44:44.499] DRM: supports atomic modesetting
[14:44:44.499] DRM: does not support GBM modifiers
[14:44:44.499] DRM: supports picture aspect ratio
[14:44:44.499] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-9/gl-renderer.so’
[14:44:44.499] DRM: supports atomic modesetting
[14:44:44.499] DRM: does not support GBM modifiers
[14:44:44.499] DRM: supports picture aspect ratio
[14:44:44.508] EGL client extensions: EGL_EXT_client_extensions
EGL_EXT_platform_base EGL_KHR_platform_wayland
EGL_EXT_platform_wayland EGL_KHR_platform_gbm
[14:44:44.511] EGL version: 1.5
[14:44:44.511] EGL vendor: Vivante Corporation
[14:44:44.511] EGL client APIs: OpenGL_ES OpenVG
[14:44:44.511] EGL extensions: EGL_KHR_fence_sync EGL_KHR_reusable_sync
EGL_KHR_wait_sync EGL_KHR_image EGL_KHR_image_base
EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_lock_surface
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_lock_surface
EGL_KHR_create_context EGL_KHR_no_config_context
EGL_KHR_surfaceless_context EGL_KHR_get_all_proc_addresses
EGL_EXT_create_context_robustness EGL_EXT_protected_surface
EGL_EXT_protected_content EGL_EXT_buffer_age
EGL_ANDROID_native_fence_sync EGL_WL_bind_wayland_display
EGL_WL_create_wayland_buffer_from_image EGL_KHR_partial_update
EGL_EXT_swap_buffers_with_damage
EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float
[14:44:44.512] EGL_KHR_surfaceless_context available
[14:44:44.516] GL version: OpenGL ES 3.1 V6.4.3.p1.305572
[14:44:44.516] GLSL version: OpenGL ES GLSL ES 3.10
[14:44:44.516] GL vendor: Vivante Corporation
[14:44:44.516] GL renderer: Vivante GC7000UL
[14:44:44.516] GL extensions: GL_OES_vertex_type_10_10_10_2
GL_OES_vertex_half_float GL_OES_element_index_uint
GL_OES_mapbuffer GL_OES_vertex_array_object
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_compressed_paletted_texture GL_OES_texture_npot
GL_OES_rgb8_rgba8 GL_OES_depth_texture
GL_OES_depth_texture_cube_map GL_OES_depth24 GL_OES_depth32
GL_OES_packed_depth_stencil GL_OES_fbo_render_mipmap
GL_OES_get_program_binary GL_OES_fragment_precision_high
GL_OES_standard_derivatives GL_OES_EGL_image
GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3
GL_OES_EGL_sync GL_OES_texture_stencil8
GL_OES_shader_image_atomic
GL_OES_texture_storage_multisample_2d_array
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_OES_draw_buffers_indexed GL_OES_texture_border_clamp
GL_OES_texture_buffer GL_OES_texture_cube_map_array
GL_OES_draw_elements_base_vertex GL_OES_texture_half_float
GL_OES_texture_float GL_KHR_blend_equation_advanced
GL_KHR_debug GL_KHR_robustness
GL_KHR_robust_buffer_access_behavior
GL_EXT_texture_type_2_10_10_10_REV
GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888
GL_EXT_texture_compression_s3tc GL_EXT_read_format_bgra
GL_EXT_multi_draw_arrays GL_EXT_frag_depth
GL_EXT_discard_framebuffer GL_EXT_blend_minmax
GL_EXT_multisampled_render_to_texture
GL_EXT_color_buffer_half_float GL_EXT_color_buffer_float
GL_EXT_robustness GL_EXT_texture_sRGB_decode
GL_EXT_draw_buffers_indexed GL_EXT_texture_border_clamp
GL_EXT_texture_buffer GL_EXT_texture_cube_map_array
GL_EXT_multi_draw_indirect GL_EXT_draw_elements_base_vertex
GL_EXT_texture_rg GL_EXT_protected_textures GL_EXT_sRGB
GL_VIV_direct_texture
[14:44:44.516] GL ES 2 renderer features:
read-back format: BGRA
wl_shm sub-image to texture: yes
EGL Wayland extension: yes
[14:44:44.526] event1 - gpio-keys: is tagged by udev as: Keyboard
[14:44:44.526] event1 - gpio-keys: device is a keyboard
[14:44:44.530] event0 - 30370000.snvs:snvs-powerkey: is tagged by udev as: Keyboard
[14:44:44.530] event0 - 30370000.snvs:snvs-powerkey: device is a keyboard
[14:44:44.533] event2 - audio-hdmi HDMI Jack: is tagged by udev as: Switch
[14:44:44.533] event2 - not using input device ‘/dev/input/event2’
[14:44:44.553] libinput: configuring device “gpio-keys”.
[14:44:44.553] libinput: configuring device “30370000.snvs:snvs-powerkey”.
[14:44:44.553] DRM: head ‘HDMI-A-1’ found, connector 38 is disconnected.
[14:44:44.553] DRM: head ‘HDMI-A-2’ found, connector 40 is disconnected.
[14:44:44.554] Registered plugin API ‘weston_drm_output_api_v1’ of size 24
[14:44:44.554] Registered plugin API ‘weston_drm_virtual_output_api_v1’ of size 48
[14:44:44.554] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[14:44:44.555] Loading module ‘/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so’
[14:44:44.556] launching ‘/usr/lib/aarch64-linux-gnu/weston-keyboard’
[14:44:44.561] Loading module ‘/usr/lib/aarch64-linux-gnu/weston/screen-share.so’
[14:44:44.562] Cannot pick output: Pointer not on any output
[14:44:44.562] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-9/xwayland.so’
[14:44:44.584] Registered plugin API ‘weston_xwayland_v1’ of size 32
[14:44:44.584] Registered plugin API ‘weston_xwayland_surface_v1’ of size 16
[14:44:44.584] xserver listening on display :0
[14:44:44.584] launching ‘/usr/lib/aarch64-linux-gnu/weston-desktop-shell’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
Do you have any idea why it doesn’t work?
Sorry, the tutorial I talk about can be found here: Remote Access the TorizonCore GUI Using VNC or RDP | Toradex Developer Center
Hi @EmmanuelC !
So, if you are following Toradex’s tutorial, it is not related to x11vnc anymore, right?
Just to be sure, I followed the steps in the article above:
# docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=weston --net=host --env ENABLE_VNC=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 \
--tty=/dev/tty7 --user=torizon
remmina’s command line tool, vncview is different, but I tried using vncviewer as well and worked)$ remmina -c vnc://<MODULE-IP>
A question: is your module network accessible from your computer? E.g.: can you ssh into the module and ping it’s IP?
EDIT: I mistakenly pasted the RDP version of the command instead of the VNC one. I just replaced ENABLE_RDP with ENABLE_VNC to fix this mistake.
Best regards,
Hi Henrique,
Yes I try at least to see whether a remote connection is possible before going further into x11vnc.
Yes I can ping and ssh to the Toradex. But when I use remmina or vncviewer on the same IP address (without specifying any port number), it says the connection is refused. When I plug an HDMI cable on the Yavia dev board, the interface is displayed on a screen.
Also, I don’t understand your example: why do you use the environment variable ENABLE_RDP to use VNC?
Also another information: I use TorizonCore 6.2.0 without any demonstration container.
Best,
Hi,
I have just tried, and found that I need to plug a display on the HDMI port to make it work, which is quite weird for classical use of remote access. How can I do it in an headless mode?
Best,
Emmanuel
Ok, moving forward!
The X11 transfer works really fine with the ubuntu xenial docker image, and then:
Then first information: the imx8mp is compatible with x11 transfer, no need to set up Wayland, which is still experimental for a lot a software.
This also works with Debian Buster.
However, this doesn’t work with more recent versions of linux, such as Ubuntu Jammy or Debian Bullseye. Maybe a misconfiguration with the host kernel ?
This was a mistake. Sorry for that. I just replaced ENABLE_RDP with ENABLE_VNC in my answer.
You are right. This is known and I just asked internally if there is a fix for this. For now, you can force the HDMI connector to be enabled:
echo on > /sys/class/drm/card1-HDMI-A-1/status
Then you launch the Weston container with VNC enabled.
AFAIK, Ubuntu Jammy uses Wayland and Debian Bullseye (and Bookworm) uses Xorg on Desktop. But I don’t know how this information might help you 
Best regards,
Finally I understand why I wasn’t able to connect over VNC while a few days ago I could…
@henrique.tx, where exactly do you run this command? Everywhere I try I get a Read-only file system message.
I was also trying to expose port 8080 in a chromium container to access the GUI remotely (avoiding VNC) and hasn’t worked. Could it be related with this?
You can run this from your terminal of the module, outside of containers.
I tried it on Verdin iMX8M Plus with TorizonCore versions 5.7.0 and 6.2 as well. On both versions, I had the same outcomes and it worked for me with a little terminal “gotcha”. I share below what I did.
Trying to set the status of the card0-HDMI-A-1 to on:
torizon@verdin-imx8mp-07174160:~$ echo on > /sys/class/drm/card0-HDMI-A-1/status
-sh: /sys/class/drm/card0-HDMI-A-1/status: Permission denied
As you can see, I didn’t get the read-only issue, but the permission was denied.
It makes sense as torizon is not owner of the status file and the permissions do not allow a user other than root to write to it:
torizon@verdin-imx8mp-06849036:~$ ls -l /sys/class/drm/card1-HDMI-A-1/status
-rw-r--r-- 1 root root 4096 Jun 23 08:53 /sys/class/drm/card1-HDMI-A-1/status
Our first reflex is to simply try sudo it.
torizon@verdin-imx8mp-06849036:~$ sudo echo on > /sys/class/drm/card1-HDMI-A-1/status
-sh: /sys/class/drm/card1-HDMI-A-1/status: Permission denied
But it doesn’t work and it might confuse us, but actually, it makes sense.
In the command above, we are ““sudoing”” the echo command. But we must ““sudofy”” the file opening action (which obviously echo doesn’t perform).
Usually, the tee command is used be ran as sudo, receive the output from echo and write to the desired file:
torizon@verdin-imx8mp-06849036:~$ echo on | sudo tee /sys/class/drm/card1-HDMI-A-1/status
on
Just checking:
torizon@verdin-imx8mp-06849036:~$ cat /sys/class/drm/card1-HDMI-A-1/status
connected
Let us know if this helps 
Best regards,
Hi @henrique.tx,
I confirm that your suggestion allows to set the HDMI as ON. However, without a display plugged in weston container stops running:
[10:23:41.970] DRM: head 'HDMI-A-1' found, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
[10:23:41.971] Registered plugin API 'weston_drm_output_api_v1' of size 24
[10:23:41.972] Registered plugin API 'weston_drm_virtual_output_api_v1' of size 48
[10:23:41.972] no available modes for HDMI-A-1
[10:23:41.970] DRM: head 'HDMI-A-1' found, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
[10:23:41.971] Registered plugin API 'weston_drm_output_api_v1' of size 24
[10:23:41.972] Registered plugin API 'weston_drm_virtual_output_api_v1' of size 48
[10:23:41.972] no available modes for HDMI-A-1
[10:23:41.973] Cannot configure an output using weston_drm_output_api.
[10:23:41.973] Cannot configure an output using weston_drm_output_api.
Hi @jvieira !
Could you please try on the card1-HDMI-A-2 instead of card1-HDMI-A-1?
Be sure to have card1-HDMI-A-1 off (disconnected).
echo off | sudo tee /sys/class/drm/card1-HDMI-A-1/status
echo on | sudo tee /sys/class/drm/card1-HDMI-A-2/status
Best regards,