i.MX ProcessorsのトピックRe: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

dennis_sparkcharge — Mon, 06 Nov 2023 20:07:50 GMT

When use-g2d=1 in /etc/xdg/weston/weston.ini and FB_MULTI_BUFFER is > 1 or not set, weston-imx/libweston/renderer-g2d/g2d-renderer.c:fb_query_screen_info() executes an FBIOPUT_VSCREENINFO ioctl to set the framebuffer's yres_virtual to a multiple of the framebuffer's physical Y resolution. In this configuration, repainting is handled with the FBIOPAN_DISPLAY ioctl.

When an HDMI hotplug connect event happens in the mxc_hdmi.c kernel driver, mxc_hdmi_set_mode() will call fb_vidmode_to_var(), which overwrites the framebuffer's yres_virtual with the same value as yres.

Once this has happened, the display stops updating on every repaint because g2d-renderer's FBIOPAN_DISPLAY ioctls start failing. /run/user/0/weston.log gets a line saying "FBIOPAN_DISPLAY Failed" every time this happens.

This is the default configuration for Yocto when use-nxp-bsp is set, so I would imagine this is affecting a lot of users. It is exacerbated by the fact that sometimes, changing the framebuffer resolution (e.g. with fbset) will cause a hotplug plugout/plugin cycle, so changing it right before starting Weston (e.g. in an ExecStartPre= on weston.service) risks triggering this behavior.

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

dennis_sparkcharge — Mon, 06 Nov 2023 20:07:16 GMT

Steps to reproduce:

1. Start Weston with `use-g2d=1` in `weston.ini` and `FB_MULTI_BUFFER` unset or set to a value > 1
2. unplug the display and plug it back in
3. `tail -f /run/user/0/weston.log` while interacting with Weston

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

Zhiming_Liu — Wed, 08 Nov 2023 02:37:32 GMT

Hi @dennis_sparkcharge

You can try to fix yres_virtual in mxc_hdmi_set_mode function.

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

dennis_sparkcharge — Fri, 10 Nov 2023 22:16:44 GMT

I don't think that would be an appropriate place to fix the problem, since mxc_hdmi_set_mode doesn't have access to information about how many multibuffers Weston initially configured. It could try to infer it from the ratio of physical to virtual y resolution in the original settings, but that seems pretty brittle.

At any rate, this was intended to be a bug report, not a direct request for help. Is there a more appropriate place to direct bug reports?

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

Zhiming_Liu — Mon, 13 Nov 2023 03:04:09 GMT

Hi @dennis_sparkcharge

Can you provide test log about weston and kernel?

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

dennis_sparkcharge — Thu, 16 Nov 2023 16:06:34 GMT

Attached:

* journal.txt created with `journalctl -b | grep -P 'kernel|[Ww]eston|dennis@' > journal.txt` showing kernel debug messages from `mxc_hdmi.c` and `mxc_ipuv3_fb.c` as well as messages prefixed with `dennis@sparkcharge.io` that I wrote to the logs describing the actions I was taking
* weston.ini showing `use-g2d=1`
* weston.service showing the use of strace to observe ioctls (note that the buggy behavior occurs regardless of using strace)
* weston.log showing the "FBIOPAN_DISPLAY" messages starting after the hotplug event
* weston.strace showing FBIOPAN_DISPLAY ioctls succeeding before the hotplug, and then two out of three failing after the hotplug event

I didn't attach `/etc/default/weston`, but it was an empty file.

Re: mxc_hdmi hotplug breaks Weston multi-buffering when use-g2d=1 and FB_MULTI_BUFFER != 1

Zhiming_Liu — Thu, 14 Dec 2023 00:29:55 GMT

Sorry, forgot to update here, i have reported this issue. No reply util now.