Chromium über RDP / VNC

Technical Support
,
1

Hello everyone,

I would like to create websites and test them on different touch displays connected to a carrier board with an Apalis iMX8QM module.

It is perfectly possible to activate RDP or VNC and to view the display in parallel with the respective clients.
I noticed via VNC that a click also wakes up the display.

However, I cannot perform any clicks on buttons or make any keyboard inputs.

Is this fundamentally impossible?
Or is it just in my configuration with Torizon OS 6.4 with Weston-Vivante:3?

To express myself more clearly:
Everything works on the physical touch display and with the connected keyboard and mouse.
However, it does not work via VNC or RDP.
Is this a Weston or Chromium problem?

Best
Gerald

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

VNC and RDP should support both display sharing and remote input (mouse and keyboard events) on Torizon OS (1). The fact that you can see the display but cannot interact with buttons or provide keyboard input suggests a configuration issue rather than a fundamental limitation.

Key Points About VNC/RDP on Torizon OS

Both VNC and RDP protocols are designed to transmit keyboard and mouse events when starting a Weston Container (1). The documentation specifically mentions that when you remotely display your Graphical User Interface, you should also be able to transmit keyboard and mouse events (1).

Troubleshooting Your Setup

Since you’re using Torizon OS 6.4 with Weston-Vivante, this should work properly. Here are some areas to investigate:

1. VNC Client Configuration

Ensure your VNC client is configured to send input events. Some VNC viewers have settings that control whether mouse clicks and keyboard input are transmitted to the remote session.

2. Container Setup

Verify that your Weston container is started with the correct parameters. For Apalis iMX8QM, you should use commands similar to:

# 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' \
             --device-cgroup-rule='c 253:* rmw' \
             torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE --developer \
            --tty=/dev/tty7

(1)

3. Input Device Configuration

The issue might be related to how input devices are being handled. Check if there are any conflicts between the physical touchscreen and the VNC input handling.

4. Consider Upgrading

Note that VNC and RDP are not yet fully released on Torizon 7 and while they may work, they are not guaranteed (1). However, you might want to test if the same issue persists with a newer version or consider using the feature on Torizon 6 where it’s more stable (1).

Recommendation

Since everything works with physical touch display and connected peripherals, this appears to be a VNC/RDP input handling issue rather than a Chromium problem. The display transmission works correctly, but the input event handling is not functioning as expected.

Try testing with different VNC clients to rule out client-side issues, and verify your Weston container startup parameters match the recommended configuration for your hardware.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

I can type in the Weston terminal… so key inputs are possible… and I can open the window by clicking on the terminal icon and close it using the X… it works with a delay… that’s OK… but it works.

In a Chromium window, absolutely nothing responds. It probably doesn’t get focus.

Best
Gerald

4

The issue you’re experiencing - where Weston terminal responds to VNC input but Chromium doesn’t - is a known behavior pattern. This appears to be related to how Chromium handles input focus in a VNC environment.

Focus and Input Handling

The fact that you can interact with Weston’s terminal and UI elements (clicking terminal icon, closing windows) but not with Chromium suggests that Chromium isn’t receiving proper input focus through the VNC session (1). This is a common issue where the Wayland compositor (Weston) correctly handles VNC input events, but specific applications like Chromium may not respond as expected.

Chromium-Specific Considerations

There’s a documented issue where Chromium uses its own mouse cursor by default, which can interfere with input handling (2). The kiosk container with Chromium uses its own mouse cursor by default, which can be overwritten by putting inside the container the custom left_ptr in /usr/share/icons/Adwaita/cursors/ (2).

Potential Solutions

1. Check Chromium Container Configuration

Ensure your Chromium container is launched with proper parameters for input handling. The container should have appropriate device access and security settings.

2. Try Mouse Cursor Configuration

You can change the mouse cursor by adding a custom X11 cursor named left_ptr in an icon theme folder and enabling it in weston.ini (2):

[shell]
locking=false
cursor-theme=hicolor
cursor-size=32

(2)

3. Consider Touch Input Settings

Since you mentioned this is for touch displays, check if there are any touch-to-pointer conversion issues. The documentation mentions touch2pointer functionality for applications that aren’t aware of touch events (2).

Known Performance Issues

Be aware that enabling VNC can significantly affect the performance of GUI applications, and the exact severity depends on the UI framework and overall graphic intensity (1). This could contribute to the delayed or unresponsive behavior you’re experiencing with Chromium.

The issue appears to be specific to how Chromium handles input focus in VNC sessions rather than a fundamental VNC limitation, since Weston itself responds correctly to your input.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

I have already noticed that.
Swipe gestures put an extreme load on the system.
I haven’t gotten around to testing that with RDP yet.

6

I will test that.

7

… and then … Does Chromium differentiate between clicks via RDP and touch events?

So, all one would have to do is lower the security level?

8

Hello @gerko

Remote access to a Chromium window will generally result in very poor performance. Before we recommend anything, we’d like to better understand what you’re trying to achieve so we can guide you properly.

Could you clarify:

  • What is the ultimate objective of your use case?
  • Is this primarily for development and debugging, or do you intend to access and control devices deployed in the field?

Depending on your requirements, the right solution may involve a custom implementation, potentially in collaboration with one of our technology partners, as this is ultimately a feature in user space outside the scope of the support we can provide.

looking forward to hearing from you
best regards
Max

9

Hi @Maximiliano.tx ,

I’ve gained some new insights in the meantime.

In a simple QtWebView, I can achieve the same results directly on the physical display as in a full Chrome browser (containerized). However, I’ve only been able to test this via RDP so far. I’ll get around to testing it on the actual displays we’re using later.

Passing through events in an RDP or VNC client works better here. At least I can swipe left and right using the keyboard without any extra effort.

The RDP or VNC functionality is only needed for the development phase. It might also be nice to have for maintenance.

Thank you anyway.

Best regards
Gerald

1 Like
10

Hi @gerko

thanks for the additional details and for sharing your findings. It is good to hear that you have a set up that is sorta working.
I am collecting the feedback related to the usage of RDP or VNC and pass it to our Dev Team for consideration of future features. As today I don’t think we can help much here. For this kind work we refer our partners.

In any case if you get stuck, do not hesitate to get back to us and we can have a look o discuss a bit more in depth.

best regards
Max

11

Thank you @Maximiliano.tx ,
As an aside, and without going into too much detail:

It seems there’s a Chromium solution:

I don’t have the skills or time to test it. Perhaps it’s time to apply this patch and integrate it into the Chromium container?

Best
Gerald

12

hi @gerko

thanks for the feedback. I have passed this input to our SW product manager and he has taking it into consideration for future discussions related the product roadmap.

he also motioned that he has been working with a partner on the topic remote access and control solution. If you are interested we can put in touch with them too.

best regards.
Max