Cursor Position incorrect for windowed capture

Bug #1092339 reported by Peter Oxenham
104
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Kazam Screencaster
Fix Committed
Low
Unassigned
gst-plugins-good
Fix Released
Medium

Bug Description

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

Revision history for this message
Peter Oxenham (peterox28) wrote :
David Klasinc (bigwhale)
Changed in kazam:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
David Klasinc (bigwhale) wrote :

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

Revision history for this message
JThoennes (joerg-thoennes) wrote :

Hello,

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

Thanks, Jörg

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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?

Changed in gst-plugins-good:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Revision history for this message
David Klasinc (bigwhale) wrote :

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.

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Enjoy your vacation!

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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.

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Revision history for this message
JThoennes (joerg-thoennes) wrote :

Peter, what is your monitor setup?

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

Revision history for this message
Peter Oxenham (peterox28) wrote :

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

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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.

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Revision history for this message
JThoennes (joerg-thoennes) wrote :

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

Changed in gst-plugins-good:
status: New → Confirmed
Revision history for this message
JThoennes (joerg-thoennes) wrote :

David, was my example valid to reproduce this issue?

Revision history for this message
Alexander Bessman (bessman) wrote :

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.

Revision history for this message
Lrbabe (lrbabe) wrote :

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.

Revision history for this message
David Klasinc (bigwhale) wrote :

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.

Revision history for this message
David Klasinc (bigwhale) wrote :

Fix was committed to upstream.

Changed in kazam:
status: Confirmed → Fix Committed
Changed in gst-plugins-good:
status: Confirmed → Fix Released
Revision history for this message
Leon (leonbo) wrote :

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.

Revision history for this message
Olof Bjarnason (objarni) wrote :

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.

Revision history for this message
Olof Bjarnason (objarni) wrote :

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

Revision history for this message
Peter Würtz (pwuertz) wrote :

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

Revision history for this message
Vishal Gupta (vishgupta92) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.