Waylandsink: disabling keyboard focus
terry1 at beam.ltd.uk
Wed Mar 23 15:13:25 UTC 2022
On 23/03/2022 14:03, Matthew Waters wrote:
> On 23/3/22 20:09, Terry Barnaby via gstreamer-devel wrote:
>> I am creating a video processing application that will run on an NXP
>> IMX8MP embedded platform using GStreamer with Qt on a Wayland display.
>> This is using the NXP imx hardknott imx-5.10.52-2.1.0 release.
>> I have this mostly working but I am having a few lockup problems
>> probably due to Waylandsink vs Qt and perhaps threads.
>> As a workaround for now I have been trying to configure a gstreamer
>> pipeline to use its own created Waylandsink Wayland surface and just
>> position it over the area of the application. However the Waylandsink
>> takes over keyboard/mouse focus from the program. Is there any way of
>> preventing this on the waylandsink ?
>> As to my main problem when I set the Waylandsink's surface to be that
>> of an existing QWidgets surface in a gstBusCallback() function it all
>> works eventually (and the program has keyboard focus) but there is a
>> large delay before the video plays after a
>> gst_element_set_state(ogstPipeline, GST_STATE_PLAYING);. It appears
>> the program hangs in wl_display_read_events() awaiting a Mutex. Moving
>> the mouse (or sending mouse events via /dev/uinput) unlocks it. I
>> attach some bits of my test code that shows this. Any pointers as to
>> what may be happening and how to fix this ?
> This is an issue with Qt and Wayland presumably before this commit was
> added to Qt: https://codereview.qt-project.org/c/qt/qtwayland/+/301712.
> You would need a Qt build with that patch to avoid the wayland event
> processing happening in multiple threads from having a small chance of
> deadlocking inside Qt.
Many thanks both, for your replies. Versions are
I will have a look at that Qt commit.
More information about the gstreamer-devel