Ubuntu
gnome-control-center package

Monitor image not clickable in display settings after the first time

Bug #1043769 reported by Ugo Riboni on 2012-08-30

This bug affects 7 people

	Status	Importance	Assigned to
cairo	Fix Released	Medium	freedesktop-bugs #54732
gnome-control-center	Fix Released	High	gnome-bugs #681475
cairo (Ubuntu)	Fix Released	Low	Unassigned
Quantal	Won't Fix	Low	Unassigned
gnome-control-center (Ubuntu)	Fix Released	Low	Unassigned
Quantal	Won't Fix	Low	Unassigned

Bug Description

[Impact]

Users with multiple displays are unable to change display settings (arrange displays, change resolutions, change the primary display, etc.) with 'gnome-control-center display' unless they happen to know to switch focus to another window and switch back again between every mouse click.

[Test Case]

1. Have a multi monitor setup with 2 (or more) monitors
2. Open the display settings applet in the control center
3. Click on the monitor that is not currently selected
4. Try to select the originally selected monitor by clicking on it

[Regression Potential]

The patches in the attached debdiffs are from the upstream git repositories and are in the latest upstream releases. Raring has been using these upstream releases for some time now; any regressions likely would have showed up in Raring.

That being said, the cairo change is potentially risky, as it alters some low-level behaviors and many packages depend on cairo. The changes to gnome-control-center are limited to the Displays panel; any regressions should only affect that panel (and that panel is already severely broken with multiple displays).

[Original Bug Report]

Steps to reproduce:

* Have a multi monitor setup with 2 monitors
* Open the display settings applet in the control center
* Click on the monitor that is not currently selected
* Click on the monitor that was initially selected

Expected result:
* The second click should select again the clicked monitor

Actual result:
* The second click fails to select the clicked monitor, selection remains where it is

If you focus another application and focus back to the display settings window, then you can move the selection again for one single time, then the bug appears again until you switch focus again.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gnome-control-center 1:3.4.2-0ubuntu13
ProcVersionSignature: Ubuntu 3.5.0-13.13-generic 3.5.3
Uname: Linux 3.5.0-13-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.5.1-0ubuntu3
Architecture: i386
Date: Thu Aug 30 13:14:48 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
ProcEnviron:
TERM=xterm
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: gnome-control-center
UpgradeStatus: Upgraded to quantal on 2012-08-29 (0 days ago)
usr_lib_gnome-control-center:
activity-log-manager-control-center 0.9.4-0ubuntu3
deja-dup 23.90-0ubuntu1
gnome-control-center-signon 0.0.13-0ubuntu1
indicator-datetime 12.10.0-0ubuntu1

See original description

Tags:

Revision history for this message

Ugo Riboni (uriboni) wrote on 2012-08-30:

Dependencies.txt Edit (12.0 KiB, text/plain; charset="utf-8")

Revision history for this message

In freedesktop.org Bugzilla #54732, BenjaminBerg (benjamin-sipsolutions) wrote on 2012-09-10:

#10

When the user calls into cairo_copy_path, cairo will convert the path to user coordinates using "cairo_device_to_user". However, the path is stored in *backend* coordinates (converted using the function _cairo_gstate_user_to_backend).

This means that the result of cairo_copy_path is shifted by the device offset of the target device.

https://bugzilla.gnome.org/show_bug.cgi?id=681475 is an example where this causes troubles.

Revision history for this message

In freedesktop.org Bugzilla #54732, Chris Wilson (ickle) wrote on 2012-09-10:

#11

commit f34b87f6d76cbea93acd4a8c73c8c6a6b412a302
Author: Chris Wilson <email address hidden>
Date: Mon Sep 10 15:09:18 2012 +0100

path: Convert from backend coordinates back into user coordinates

    Fixes regression from commit 83bfd85a1378e61b8bdc3f554f5e07900311f61f
    Author: Chris Wilson <email address hidden>
    Date: Fri Apr 23 19:45:26 2010 +0100

Implement cairo_backend_t

    As there exists no public API to perform the operation we needed, and we
    failed to create one, the constructed path failed to correctly remove
    the device offset.

Fixes copy-path under device translation.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54732
    Reported-by: Benjamin Berg <email address hidden>
    Signed-off-by: Chris Wilson <email address hidden>

Revision history for this message

In freedesktop.org Bugzilla #54732, Dominik-rottsches (dominik-rottsches) wrote on 2012-09-10:

#12

*** Bug 54446 has been marked as a duplicate of this bug. ***

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-09-12:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-control-center (Ubuntu):
status:	New → Confirmed

Revision history for this message

Adam Niedling (krychek) wrote on 2012-11-01:

I'm also affected by this bug. This has never been an issue before 12.10. Thanks for the workaround!

Revision history for this message

Alexander Adam (7ql6) wrote on 2012-11-25:

I have the same problem in x64 Ubuntu and Gnome.
Since 12.10 display management absolutely doesn't work for me on new user accounts.
Displays are rarely selectable and switching to some unspectacular configurations lead to graphical errors, black screen or logouts.

I use an ASUS Zenbook UX31A with DELL U2711 via HDMI.

Revision history for this message

Lonnie Lee Best (launchpad-startport) wrote on 2012-12-12:

Also, if you are on another WORKSPACE (instead of the default one), you can't even select another monitor AT ALL (even on first try).

Whoever fixes this bug needs to test their fix to see if it works correctly from any workspace AND monitor (not just the default workspace and monitor1) that this control can be launched from.

Keep in mind that this control can be launched from every workspace and from each monitor on each workspace; they all have the little gear icon top-right. I'm getting different behaviors when launched from monitors on workspaces 2 and up.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2012-12-13:

thank you for your bug report, it seems like that could be fixed in GNOME 3.6 in raring if somebody could test the new version

Changed in gnome-control-center (Ubuntu):
importance:	Undecided → Low

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-14:

I believe the following upstream patches will fix this (I have not tried them yet):

http://git.gnome.org/browse/gnome-control-center/commit/?id=c1857b0f9c80434890679ace83865db5d2565fa6
http://git.gnome.org/browse/gnome-control-center/commit/?id=a61f0654b98357283ef68bea6d827aabc0a2779e
http://cgit.freedesktop.org/cairo/commit/?id=f34b87f6d76cbea93acd4a8c73c8c6a6b412a302

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-14:

The cairo bug report is linked because apparently the fix for the gnome-control-center bug exposed a bug in cairo. I'm not sure if quantal already has that cairo fix.

Bug Watch Updater (bug-watch-updater) on 2012-12-14

Changed in gnome-control-center:
importance:	Unknown → High
status:	Unknown → Fix Released

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-14:

The quantal version of cairo does not have the fix referenced above, so I'm marking this bug report as also affecting the cairo package.

Bug Watch Updater (bug-watch-updater) on 2012-12-14

Changed in cairo:
importance:	Unknown → Medium
status:	Unknown → Fix Released

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-14:

#13

Additional cairo patches needed:

http://cgit.freedesktop.org/cairo/commit/?id=df6780442feba5c0c9404353177f24913b58bd32
http://cgit.freedesktop.org/cairo/commit/?id=08e3f4614b688331534d72f46c9c3e9f292d0216

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-15:

#14

debdiff for cairo (quantal) Edit (15.8 KiB, text/plain)

Attached is a debdiff for cairo (against the quantal version) that I believe partially fixes this problem. The other part is a change to gnome-control-center, and I will upload that debdiff shortly.

For cairo, I applied the following patches:
  http://cgit.freedesktop.org/cairo/commit/?id=83759e7d592c5d7b12b2341574fd584fe5e0fb5a
  http://cgit.freedesktop.org/cairo/commit/?id=df6780442feba5c0c9404353177f24913b58bd32
  http://cgit.freedesktop.org/cairo/commit/?id=f34b87f6d76cbea93acd4a8c73c8c6a6b412a302
The above patches are in cairo versions 1.12.4 and later, so raring is not affected.

I uploaded the modified cairo package to my PPA (<https://launchpad.net/~a7x/+archive/bug1043769>) and it has finished building. To install:

    sudo apt-add-repository ppa:a7x/bug1043769
    sudo apt-get update
    sudo apt-get upgrade

Revision history for this message

Richard Hansen (rhansen) wrote on 2012-12-15:

#15

debdiff for gnome-control-center (quantal) Edit (6.0 KiB, text/plain)

And here is the debdiff for gnome-control-center (against the quantal version).

For gnome-control-center, I applied the following patches:
http://git.gnome.org/browse/gnome-control-center/commit/?id=c1857b0f9c80434890679ace83865db5d2565fa6
http://git.gnome.org/browse/gnome-control-center/commit/?id=a61f0654b98357283ef68bea6d827aabc0a2779e
The above patches are in gnome-control-center versions 3.6.0 and later, so raring is not affected.

I uploaded the modified gnome-control-center package to my PPA and it has finished building.

Please try these packages and let me know if they work for you.

Richard Hansen (rhansen) on 2012-12-15

description:

updated

Revision history for this message

Ubuntu Foundations Team Bug Bot (crichton) wrote on 2012-12-16:

#16

The attachment "debdiff for cairo (quantal)" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags:

added: patch

Revision history for this message

Sebastien Bacher (seb128) wrote on 2013-01-10:

#17

Those patches should be in raring, closing the main component and making it affect quantal

Changed in gnome-control-center (Ubuntu):
status:	Confirmed → Fix Released
Changed in cairo (Ubuntu):
status:	New → Fix Released
importance:	Undecided → Low
Changed in cairo (Ubuntu Quantal):
importance:	Undecided → Low
Changed in gnome-control-center (Ubuntu Quantal):
status:	New → Triaged
importance:	Undecided → Low
Changed in cairo (Ubuntu Quantal):
status:	New → Triaged

Revision history for this message

Sebastien Bacher (seb128) wrote on 2013-01-10:

#18

Thanks for the work backporting the fixes, the diffs are non trivial though and as you pointed in the SRU infos cairo is used in lot of places so it always has a potential to create issues ... I'm not convinced that the bug is important enough to go through SRU with those changes

Revision history for this message

Sebastien Bacher (seb128) wrote on 2013-01-10:

#19

Unsubscribing sponsors for the moment, I'm following the gnome-control-center bugs and will read the comments. I will keep thinking a bit about the impact/need to SRU and do the sponsoring if needed so no need to keep the item in the public sponsoring queue

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2014-12-05:

#20

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".