Cursor Position incorrect for windowed capture

[Peter Oxenham]

As you can see from the attached screencast the mouse pointer is positioned incorrectly. It seems to be offset within the window the same distance that the window is offset from the screen.

Kazam: 1.3.99-0ubuntu1
Ubuntu: 12.10
XFCE: 4.10

p.s. I am also experiencing the non-transparent window selection mentioned in https://bugs.launchpad.net/kazam/+bug/1030604

[David Klasinc (bigwhale)]

Hello Peter, thank you for your report. I've checked this and indeed it is a bug. Unfortunately this is (for now) an upstream issue. Kazam is using GStreamer for recording and when ximagesrc is used in window recording mode cursor is offset.

I reported the problem to upstream and I'll close bug this when I get confirmation from upstream.

If you care to track what's going on, here's the bug number in gnome bugzilla.

https://bugzilla.gnome.org/show_bug.cgi?id=690646

[JThoennes (joerg-thoennes)]

Hello,

please could anybody from the Kazan developers comment on this GStreamer bug and ask it to be corrected?

Thanks, Jörg

[JThoennes (joerg-thoennes)]

Note, that I am also commented on this bug.

But if some Kazan developer would comment there, this would be really helpful.

Is there any workaround?

[JThoennes (joerg-thoennes)]

Quoting a comment from the upstream gnome-bug #690646:

> Tim-Philipp Müller [GStreamer developer] 2013-07-24 13:33:55 UTC
> If anyone has a simple way to reproduce this, I have tried and wasn't able to.

Is anybody of the kazam developers willing to provide a reasonably simple example to Tim?

Many thanks, Jörg

[David Klasinc (bigwhale)]

Right now all the Kazam developers are on vacation with a very limited network access. If not sooner, then I can provide the appropriate gst-launch command line to reproduce this bug after Aug 4th when I get back to civilization.

If anyone else is willing to try in the mean time, it shouldn't be too difficult. 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.

[JThoennes (joerg-thoennes)]

Thanks, David, for picking this up. I will be patient until work starts again :-)

Enjoy your vacation!

[JThoennes (joerg-thoennes)]

David, according your hints a started to experiment a bit and installed

    gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good

using Kazam ppa

    http://ppa.launchpad.net/kazam-team/stable-series/ubuntu/ precise/main amd64 Packages

Running

    gst-launch-1.0 ximagesrc ! ximagesink

shows a secondary cursor with a fixed offset, but I am not sure whether this is the issue.

[JThoennes (joerg-thoennes)]

Now I could reproduce this issue using this command line:

    gst-launch-1.0 ximagesrc ! ximagesink

My monitor setup is as follows:

I have a Lenovo Thinkpad T520 and above a secondary monitor (ThinkVision) with a larger screen.
NVIDIA X Server Settings / X Server Display Configuration shows:
- on top: 1680x1050 external monitor
- on bottom: 1600x900laptop monitor

[JThoennes (joerg-thoennes)]

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

[JThoennes (joerg-thoennes)]

Peter, what is your monitor setup?

For me, it seems to reproducible only in the secondary monitor on top with Xinerama enabled.

[Peter Oxenham (peterox28)]

Two monitors side by side. I'm not sure about Xinerama.

[JThoennes (joerg-thoennes)]

Peter, run "xdpyinfo" on the command line. It tells you the dimensions of your screen.
If you have one large screen with the sum of the width of your monitors and the maximum of both height
then you have Xinerama enabled.

You can also check if you can resize/move a window to be visible on both screens.

[JThoennes (joerg-thoennes)]

Other reporter from downstream bug also has a dual-screen setup, with the monitors side by side.

[JThoennes (joerg-thoennes)]

(Ignore my last comment. Was intended for the GNOME bug.)

[JThoennes (joerg-thoennes)]

David, was my example valid to reproduce this issue?

[Alexander Bessman (bessman)]

I figured out a way to reproduce this on a single monitor setup:

* Open a window and move it close to the bottom of the screen
* 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

There will be a significant vertical offset between the real mouse and the recorded mouse. I posted this to the upstream bugtracker too.

[Lrbabe (lrbabe)]

How can this be a low priority bug? A screencast with misplaced cursor is useless, so this bug makes Kazam useless, and we have no workaround.

[David Klasinc (bigwhale)]

The workaround, right now, is to use area or full screen recording and then crop your video accordingly. This bug is the result of a bug in GStreamer and will bi fixed as soon as GStreamer is fixed.

[David Klasinc (bigwhale)]

Fix was committed to upstream.

[Leon (leonbo)]

I'm still having this issue on Ubuntu 14.10

The gnome bugzilla mentions this is fixed in gstreamer1.0-plugins-good 1.5. Ubuntu however is shipping 1.4 (also in 15.04 I believe).

Would it be possible to backport the patch into Ubuntu? The patch doesn't look that big.

[Olof Bjarnason (objarni)]

Confirmed in updated Ubuntu 14.04. Makes screencast worthless, however, I'm glad I read through this whole thread as capturing an area is apparently a workaround! That could be more distint, e.g. close to the top of this issue page describing the workaround in big text. Now I will test if the workaround works.

[Olof Bjarnason (objarni)]

WORKAROUND confirmed: Capture AREA instead of WINDOW and the mouse won't be offset in screencast. :)

[Peter Würtz (pwuertz)]

Still not fixed in 15.04, workaround does the job however.

[Vishal Gupta (vishgupta92)]

Still not fixed............