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
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?
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.
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 !).
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?
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.
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.
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.
@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.
@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.
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.
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.
