Chromium not fullscreen after disconnect hdmi monitor and then reconnect

Hi,

i have the following docker-compose file: https://github.com/toradex/torizon-samples/blob/bullseye/debian-container/demonstration/docker-compose.arm64.yml

When i unplug the hdmi monitor and the reconnect the chromium browser is not in fullscreen anymore but in window mode:

Is there any setting / workaround to prevent this?

Best regards,
Fabian

Environment:
Verdin i.MX8 M Plus
Dahlia Carrierboard
Linux verdin-imx8mp-06965606 5.15.77-6.1.0-devel+git.a8d2c55c6ae7 #1-TorizonCore SMP PREEMPT Wed Nov 30 08:37:42 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Greetings @wheeler,

I was able to reproduce your observation here. Upon further testing the issue seems to be due to the underlying Weston rather than with Chromium specifically. I had the same re-sized window behavior with a Cog browser and even with a simple wayland terminal window upon hot-plugging a display.

I’m still discussing with our team whether this behavior is intended by Weston or an actual bug.

Just to get a sense of your use-case. Will your system be expected to hot-plug displays like this in production? Or is this just something you’re dealing with in development?

Best Regards,
Jeremias

Hello @jeremias.tx ,

thank you.

Yes we will have this in production. We have an external USB-C Monitor (Display-Port over USB-C).
It’s not hdmi like in my example, but i think the behaviour will be the same.

So the customer can easily disconnect and reconnect the monitor and should be able to continue working without restarting the machine.

Best regards,
Fabian

Hi,

Just to confirm that I also see this effect.
In my case we are running our own Qt based app in full-screen mode. If you unplug-replug HDMI the app is displayed “windowed”.

iMX8 Colibri running Yocto based build based on the toradex multi-media image.

So I suppose it points more to Weston imho.

We’re in a similar use-case - in the field the screen HDMI cable could be disconnected by the user, and they might even reconnect it.

In our case, rebooting the system to recover is not an option, so we would also be interesed in a solution. Maybe a workaround in the software, which periodically checks if the window is fullscreen or not is feasible (albeit a horrible solution !).

All the best,

Tim

This behavior will require further investigation by our team. That said if it is indeed an issue/behavior with Weston itself I’m not sure if I can guarantee a good solution here, but I’ll see what the team thinks first.

@wheeler in terms of urgency and timeline can you comment on how this issue affects your project/development?

Best Regards,
Jeremias

Hi @jeremias.tx

It’s not very urgent, but I wanted to address it. At the moment we are in the development stage, but it would be great if we have a solution for production until Q3 2023.

Best regards,
Fabian

I’ve already reported this issue to our team for further investigation and possible fixing. I’ll try and make sure it’s given the appropriate priority given your timeline. If there’s any updates on this, I’ll share them here on this thread.

In the meantime if you discover any new information related to this please feel free to share so I can forward it along to our team here.

Best Regards,
Jeremias

Dear @jeremias.tx ,

I just found this thread in the NXP Community in which a similar problem is solved by modifying the device tree. Maybe it can be of help in our case.

Kind regards,

Víctor

Hi @vic,

Thank you for sharing that thread, though I’m not sure if that’s quite the same issue. The device tree change in that thread seems to touche on the MIPI-DSI to HDMI converter that NXP uses.

I can get this issue to occur with native HDMI. Also I can get it to happen with other SoCs like the i.MX8 that are quite different than the i.MX8M Mini/Plus.

Best Regards,
Jeremias

Just to add that I see this effect on Verdin iMX8M-Mini with DSI to HDMI converter running TorizonCore with Evaluation containers 6.2.0 monthly

@vix We haven’t done anything to fix this issue yet, so I’m not surprised it is still present. As said previously there is some suspicion it is an issue with how Weston behaves, in which case we might be limited in how much we can do from the Toradex side.

Best Regards,
Jeremias

Do you know how the issue can be reported to weston developers/mainteners?

Do you know how the issue can be reported to weston developers/mainteners?

I would assume the public Gitlab here would be the best place: https://gitlab.freedesktop.org/wayland/weston

@jeremias.tx
I did it - see issue 731.
The developer need to know if we’ve been using pure upstream Weston, or the version (very) heavily forked and patched by NXP.

Can you clarify this, please?
Here or in gitlab.

We use weston-imx as recommended by NXP which would mean we’re using their fork, in which case the problem might be with their fork then. It’s hard to tell since we don’t actively develop on these projects ourselves.

Do you mean this one https://github.com/nxp-imx/weston-imx is used?

Well the main repo for NXP projects/forks is here: weston-imx - i.MX Graphics Wayland Compositor

But I believe it’s a mirror to the Github one anyways.

At the bottom of that page I see this message
immagine

As a matter of fact, I see that codeaurora has been updated 8 months ago, instead the github link has been updated last week.
Can you double check that Toradex “links” to the up-to-date repos form NXP?

Our bullseye based containers use the “rel_imx_5.4.70_2.3.0” tag. While our upcoming bookworm containers use the “lf-5.15.32-2.0.0” tag. These are on recommendation from NXP on what tags to use for the release we are based on.

Both these tags point to the same commit on both the Github and Code Aurora repositories. So it doesn’t really matter which you inspect. Both these tags point to stable commits and are not meant to change which is the point for stability reasons.

Best Regards,
Jeremias

Hi @vix ,

Did you finally create a thread on this in the NXP community?

Thanks in advance.