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 690646 - ximagesrc: Cursor offset with ximagesrc and xid
ximagesrc: Cursor offset with ximagesrc and xid
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2012-12-22 18:45 UTC by David Klasinc
Modified: 2014-09-16 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Video of mouse cursor. (707.67 KB, video/mp4)
2012-12-22 18:45 UTC, David Klasinc
ximagesrc show-pointer fixes (9.11 KB, patch)
2014-09-05 11:37 UTC, Antonio Ospite
needs-work Details | Review
ximagesrc show-pointer fixes V2 (9.16 KB, patch)
2014-09-15 11:09 UTC, Antonio Ospite
committed Details | Review

Description David Klasinc 2012-12-22 18:45:19 UTC
Created attachment 232129 [details]
Video of mouse cursor.

When show-pointer is set to true and xid of a window is passed to ximagesrc cursor in the captured video will be offset by a fixed number of pixels. I attached a sample video.

Video was recorded with Kazam screen caster which is using ximagesrc for capturing.

When menu in program is selected, mouse cursor is in the wrong place.
Comment 1 David Klasinc 2013-03-07 14:53:16 UTC
Still present in 1.0.5 version.
Comment 2 Joerg.Thoennes 2013-07-24 13:15:41 UTC
I still see this issue on Ubuntu 12.04 LTS.

A chance to get this fixed?

Thanks, Jörg
Comment 3 Tim-Philipp Müller 2013-07-24 13:33:55 UTC
If anyone has a simple way to reproduce this, I have tried and wasn't able to.
Comment 4 Joerg.Thoennes 2013-07-24 13:43:13 UTC
Using kazan on Ubuntu 12.04 LTS with GNOME desktop this should be reproducible:


Package: kazam
Status: install ok installed
Priority: optional
Section: video
Installed-Size: 2425
Maintainer: Ubuntu Developers <>
Architecture: all
Version: 1.4.3-0ubuntu2
Depends: python3 (>= 3.2), python3-gi, python3-gi-cairo, python3-dbus, python3-cairo, gstreamer1.0-pulseaudio, gstreamer1.0-plugins-base, gstreamer1.0-plugins-good, gstreamer1.0-plugins-ugly, gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0, gir1.2-keybinder-3.0, gir1.2-appindicator3-0.1, gir1.2-wnck-3.0, python3-xdg
Recommends: gstreamer1.0-libav
Description: Easy to use screencast and screenshot application.
  The application provides well designed and easy to use interface.
  Kazam can record desktop video and multiple audio streams simultaneously
  with control over audio levels, and screen region being captured. Support
  for H264 and VP8 codecs is built in.
  Kazam can also capture still screenshots.

Downstream bug on Kazam Launchpad:
Comment 5 Joerg.Thoennes 2013-07-30 08:53:31 UTC
Kazam developer provided outline to reproduce this:

> Just use gst-launch with ximagesrc and an xid of a valid window should be provided and piped to some encoder and written in a file.

He will provide an appropriate example as soon as he is back from vacation.
Comment 6 Joerg.Thoennes 2013-07-30 09:21:19 UTC
On my Ubuntu 12.04 I am using this ppa for gstreamer plugins:

$ apt-cache policy gstreamer1.0-plugins-good
  Installed: 1.0.5-1ubuntu1~ubuntu12.04.1~ppa4
  Candidate: 1.0.5-1ubuntu1~ubuntu12.04.1~ppa4
  Version table:
 *** 1.0.5-1ubuntu1~ubuntu12.04.1~ppa4 0
        500 precise/main amd64 Packages
        100 /var/lib/dpkg/status


gst-launch-1.0 ximagesrc ! ximagesink

shows a fixed offset of the cursor. Is this already the issue or is it

Waiting for instructions...
Comment 7 Joerg.Thoennes 2013-07-30 10:52:36 UTC
Steps to reproduce this issue on Ubuntu 12.04 LTS
with gstreamer1.0 from Kazam ppa:

NVIDIA X Server Settings / X Server Display Configuration shows:
- on top:    1680x1050 external monitor (Lenovo ThinkVision monitor)
- on bottom: 1600x900laptop monitor     (Lenovo Thinkpad T520)

The issue can be reproduced in the top monitor with the larger resolution (1680x1050):
* Open terminal
* Move it to the upper monitor
* Run: gst-launch-1.0 ximagesrc ! ximagesink

Expected behaviour:
* GStreamer mouse follows real mouse (with slight offset).
Actual behaviour:
* GStream mouse stays at top of monitor and follows real mouse only horizontally.
  (No vertical motion noticed).
Comment 8 Joerg.Thoennes 2013-07-30 10:53:16 UTC
Please let me know if you need any further details.
Comment 9 Joerg.Thoennes 2013-07-30 10:56:28 UTC
NOTE: Xinerama is enabled, ie my two monitors are treated as a large screen
with 1680x1950 pixels.
Comment 10 Joerg.Thoennes 2013-07-30 11:04:38 UTC
More system details:
* Operating System: Linux-x86_64
* NVIDIA Driver Version: 304.88
* X Server Vendor Version: 1.11.3 (11103000)

I expect this can be also reproduced for other system configurations.
Comment 11 Joerg.Thoennes 2013-07-31 12:28:06 UTC
Other reporter from downstream bug also has a dual-screen setup, with the monitors side by side.
Comment 12 Joerg.Thoennes 2013-08-05 10:23:09 UTC

at least I would like to set this bug from UNCONFIRMED to NEW.

Thanks, Jörg
Comment 13 Joerg.Thoennes 2013-08-14 14:56:13 UTC
Any news? Is anybody working on this issue?
Comment 14 Joerg.Thoennes 2013-09-03 10:10:36 UTC
Being back from holiday: Is anybody working on this issue or do you still need more information?
Comment 15 Tim-Philipp Müller 2013-09-03 10:18:12 UTC
I don't think anyone is working on it. It seems like one needs Ubuntu and/or a dual screen setup and/or certain drivers to reproduce this.
Comment 16 Joerg.Thoennes 2013-09-18 08:43:04 UTC
I really wonder whether nobody of the developers owns a second monitor...

There are a couple of strange issues related to dual screen setup, especially if the screens stacked above each other (laptop + normal monitor).
Comment 17 Alexander Bessman 2013-09-27 17:12:14 UTC
Steps to reproduce this issue on a single monitor setup with Ubuntu 13.04 and Mesa 9.2.0:

* Open any window, and move it close to the bottom of the screen (this makes the bug more apparent)
* Get the window's XID with xwininfo
* run:  gst-launch-1.0 ximagesrc xid=$WINDOW_XID ! ximagesink
* Bring the window to focus and move the mouse cursor across it slowly in some pattern

Expected behavior:
* The position of the GStreamer mouse relative to the window should be the same as the real mouse.

Actual behavior:
* GStreamer mouse is offset vertically by a number of pixels corresponding to the distance of the window from the top of the screen.
Comment 18 Tim-Philipp Müller 2013-09-27 22:33:03 UTC
Thanks, I can reproduce some problem now (in gnome-shell), but I don't know if it's the same.

Using xeyes I found that even if I use show-pointer=true, the ximagesink window didn't actually ever show the pointer when it was in the xeyes window. It did show a pointer when I was operating in the top left corner of the screen, as if the xeyes window was actually at the top left of the screen. So more than offset by a few pixels in my case.

Also, the ximagesink background wasn't right, showed some other/cached/nonsense background.
Comment 19 Alexander Bessman 2013-09-28 06:40:37 UTC
That's the same bug. When I wrote "by a number of pixels", I didn't mean to imply that that number was small.

Using xeyes, I can confirm the weird background problem too.
Comment 20 Antonio Ospite 2014-09-04 16:40:54 UTC
Hi, I confirm the issue, I started looking at the ximagesrc code and it looks like the window geometry is not fully taken into account, in particular the window position seems to be ignored.

If I don't set the xid property and set startx,starty and endx,endy manually starting from the info from xwininfo the pointer is shown correctly.

Given this data:

xwininfo: Window id: 0x380000b "xeyes"

  Absolute upper-left X:  1032
  Absolute upper-left Y:  774
  Width: 140
  Height: 100

The following command line works fine with either use-damage set to true or false:

gst-launch-1.0 ximagesrc startx=1032 starty=774 endx=$((1032 + 140 - 1)) endy=$((774 + 100 - 1)) use-damage=true ! videoconvert ! autovideosink

I am not sure if I can find the time to come up with a fix myself, I still have a lot to learn about X.

Comment 21 Antonio Ospite 2014-09-05 11:37:57 UTC
Created attachment 285482 [details] [review]
ximagesrc show-pointer fixes

Hi, it looks like this is really about the window position.

Please find attached some tentative fixes for this issue, they are on top of the 1.4 branch.

The third commit in the set also fixes a nasty behavior in multi-screen setups.
I can provide more info to replicate it with a virtual X screen if someone want to see it.

To better see the improvements try also one patch at time, the xeyes test is more than OK.

The changes need to be tested and reviewed, but they should be a good starting point.

Ciao ciao,
Comment 22 Sebastian Dröge (slomo) 2014-09-12 14:12:12 UTC
Review of attachment 285482 [details] [review]:

::: sys/ximage/gstximagesrc.c
@@ +214,3 @@
+    if (coord_translated) {
+      s->x = x;
+      s->y = y;

These should probably be reset to 0 otherwise
Comment 23 Antonio Ospite 2014-09-15 09:09:01 UTC
(In reply to comment #22)
> Review of attachment 285482 [details] [review]:
> ::: sys/ximage/gstximagesrc.c
> @@ +214,3 @@
> +    if (coord_translated) {
> +      s->x = x;
> +      s->y = y;
> These should probably be reset to 0 otherwise

OK, I'll do that.

Just to be sure, this is necessary because the object is zeroed only once on element creation, but the element can survive a start/stop cycle (and/or get_caps can be called multiple times?), so we can't rely on the initial zeroing, right?

I am still getting my head around GStreamer.

Comment 24 Sebastian Dröge (slomo) 2014-09-15 09:58:22 UTC
Yes, exactly that :) Thanks for working on the patch
Comment 25 Antonio Ospite 2014-09-15 11:09:39 UTC
Created attachment 286192 [details] [review]
ximagesrc show-pointer fixes V2

OK, patchset updated with only this change in the first commit:

  - reset s->x and s->y to zero when coordinate translation fails

Comment 26 Nicolas Dufresne (ndufresne) 2014-09-16 13:29:16 UTC
Shall we backport this to 1.4 ?