After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634431 - xvimagesink: event handling fixes
xvimagesink: event handling fixes
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-09 16:28 UTC by Levente Farkas
Modified: 2018-11-03 11:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (3.79 KB, patch)
2010-11-12 11:12 UTC, Levente Farkas
none Details | Review

Description Levente Farkas 2010-11-09 16:28:18 UTC
(by default) on linux if we use xvimagesink as an overlay component it's does not propagate mouse move, enter and leave events (but automatically redraw itself as needed). if we set xvimagesink's "handle-events" properties to false then we got mouse move, but still can't get mouse enter and mouse leave. but in this case (ie. "handle-events" false) xvimagesink don't handle expose events either (even if "handle-expose" still set to true).

in gstreamer-java we capture all XEvents and propagate the expose and all mouse events by ourself, but imho it's a bug in the current xvimagesink implementation.

it'd be nice to clearly document what is the 
handle-events
handle-expose
means and be able to somehow get our expected result. which is:
- got mouse move, enter, leave
- and also automatically redraw itself in case it's needed (ie: ExposureMask | VisibilityChangeMask | StructureNotifyMask | FocusChangeMask)

ps. anyway on windows's videosinks (all) everything working as expected.
Comment 1 Levente Farkas 2010-11-10 12:46:14 UTC
I try to create a patch for xvimagesink but I've never do any kind of X programming, so I got a few questions about the current implementation in xvimagesink.c:

why not add VisibilityChangeMask in anywhere to the XSelectInput's mask? imho it'd be useful eg. if a tooltip or popup menu partially overlaying the window than it'd be useful to expose even in this case.

in line 2869 and 2912 what if not xvimagesink->xwindow->internal (or xwindow_id is 0 which is the same) why not add ButtonPressMask | ButtonReleaseMask? is there any reason for this?

is there any reason not to handle EnterWindowMask and LeaveWindowMask? they are properly handled on windows direct video sinks.

thanks in advance.
Comment 2 Levente Farkas 2010-11-12 11:12:17 UTC
Created attachment 174317 [details] [review]
proposed patch

i attached my proposed patch for xvimagesink to make it clear under which properties settings what events are handled.
Comment 3 Levente Farkas 2010-12-01 10:14:08 UTC
any change to check my patch?
Comment 4 Tim-Philipp Müller 2016-04-11 14:10:00 UTC
Not sure what to do with this, probably doesn't apply any more, may or may not have been fixed (someone should go through the patch I guess..)
Comment 5 Levente Farkas 2016-04-11 17:08:13 UTC
imho it's still not fixed.
Comment 6 GStreamer system administrator 2018-11-03 11:18:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/41.