Why does xvimagesink disable mouse button events?

partap partapdavis at gmail.com
Wed Sep 12 23:21:12 UTC 2018


Hello all, 

I've just recently become aware of gstreamer because I needed it for a
project I am working on.  It seems very powerful, nice job!

I was trying to figure out how to capture mouse input for an overlay video
filter.  I was able to use navigationtest as a template and it was working
fine with mouse movement, but ignored all mouse button events (ButtonPress /
ButtonRelease).

Eventually I was able to track it down to this code in xvcontext.c:
https://github.com/GStreamer/gst-plugins-base/blob/8ffd15ab285b23779903c1146410535e33d1bea8/sys/xvimage/xvcontext.c#L1060

It feels like a bug, but looking at the code, it seems to have been done on
purpose. 

If a window handle is passed in (e.g. an existing window area in a user
interface), then gst_xwindow_set_event_handling() disables ButtonPress and
ButtonRelease event in the input mask.  But if the existing window id is not
passed in and it needs to create its own window, it enables the button
ebvents

For my immediate purposes, I can modify the code there and use a
custom-compiled xvimagesink plugin, but I'm wondering why this behavior is
there at all.  

I'm not too familiar with the overall architecture and life cycle of gst
plugins yet, so I don't know if there's a message or hook I'm supposed to
use later in my app to set an appropriate input mask for my window.  Also,
it appears to be threaded and just modifying the input mask willy-nilly from
anywhere outside of the plugin causes crashes...you'd have to access a mutex
from (I assume) private data.  Is it xvimagesink->context->lock?  Not sure
how I'd access it from the app...especially since I'm using autovideosink
instead of xvimagesink directly.

Thanks,
-partap






--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/


More information about the gstreamer-devel mailing list