GNOME Bugzilla – Bug 690646
ximagesrc: Cursor offset with ximagesrc and xid
Last modified: 2014-09-16 13:29:16 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.
Still present in 1.0.5 version.
I still see this issue on Ubuntu 12.04 LTS. A chance to get this fixed? Thanks, Jörg
If anyone has a simple way to reproduce this, I have tried and wasn't able to.
Using kazan on Ubuntu 12.04 LTS with GNOME desktop this should be reproducible: add-apt-repository http://ppa.launchpad.net/kazam-team/stable-series/ubuntu Package: kazam Status: install ok installed Priority: optional Section: video Installed-Size: 2425 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> 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. Homepage: https://launchpad.net/kazam Downstream bug on Kazam Launchpad: https://bugs.launchpad.net/kazam/+bug/1092339
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.
On my Ubuntu 12.04 I am using this ppa for gstreamer plugins: $ apt-cache policy gstreamer1.0-plugins-good 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 http://ppa.launchpad.net/kazam-team/stable-series/ubuntu/ precise/main amd64 Packages 100 /var/lib/dpkg/status Running gst-launch-1.0 ximagesrc ! ximagesink shows a fixed offset of the cursor. Is this already the issue or is it expected. Waiting for instructions...
Steps to reproduce this issue on Ubuntu 12.04 LTS with gstreamer1.0 from Kazam ppa: * http://ppa.launchpad.net/kazam-team/stable-series/ubuntu/ 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).
Please let me know if you need any further details.
NOTE: Xinerama is enabled, ie my two monitors are treated as a large screen with 1680x1950 pixels.
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.
Other reporter from downstream bug also has a dual-screen setup, with the monitors side by side.
Hello, at least I would like to set this bug from UNCONFIRMED to NEW. Thanks, Jörg
Any news? Is anybody working on this issue?
Being back from holiday: Is anybody working on this issue or do you still need more information?
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.
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).
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.
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.
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.
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. Ciao, Antonio
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, Antonio
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
(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. Thanks, Antonio
Yes, exactly that :) Thanks for working on the patch
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 Thanks, Antonio
Shall we backport this to 1.4 ?