[FFe] Implement DisplayConfig dbus interface and transition to gnome-desktop 3.10

Bug #1228765 reported by Tim Lunn on 2013-09-22
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu GNOME
High
Unassigned
Unity
Invalid
Medium
Unassigned
gnome-desktop3 (Ubuntu)
Wishlist
Unassigned
gnome-settings-daemon (Ubuntu)
Wishlist
Unassigned
unity (Ubuntu)
Medium
Unassigned
unity-control-center (Ubuntu)
Low
Jackson Doak
unity-settings-daemon (Ubuntu)
Undecided
Jackson Doak

Bug Description

Ubuntu GNOME would like to transition for gnome-settings-daemon/gnome-control-center 3.10. This however requires a transition to gnome-desktop 3-10. I have been working on this for quite some time however this work was essentially blocked waiting on the unity- forks for settings daemon and control center. These were only finalised the day before feature freeze.

Right now there are quite a few features that are not available for configuration in g-c-c given it is so old. We are also hitting some odd bugs with mutter using its own display config separate to what gnome-settings-daemon is doing with xrandr.

For GNOME 3.10, all the display configuration/xrandr code has been moved into Mutter as dbus interface. The Main reason for this move was to abstract away the display server (x11/wayland). Apart from these changes there were no significant changes in the API.

This affects gnome-desktop3 and gnome-settings-daemon. In particular the changes in gnome-desktop would create a gigantic mess if we tried to revert these changes for Unity only. As such have forked the display config code from mutter and ported *-settings-daemon and *-control-center to the new api. The code itself is fairly self contained, so apart from the resulting duplication of code, it shouldnt really be much of an issue.

We have tested this via a ppa, however it was hard to get extensive testing, due to the amount of archive churn in the affected packages. I am pretty confident there are no much regressions and I will commit to fixing any issues to do appear.

Essentially this transition will involve:
new displayconfig package: This is the relevant code forked from mutter 3.10.4 (with a couple of fixes from 3.11 backported), wrapped up in a daemon. This gets autostarted when required by g/u-s-d (although dbus activation may be broken in flashback session)
my upstream branch is at https://github.com/darkxst/displayconfig (I had trouble working out how to import a git branch into bzr, but I imagine it should live in bzr once approved)

gnome/unity-settings-daemon, have backported patches to adapt to the new API.
Likewise for gnome/unity-control-center.
All other rdepends just require a no-change rebuild to adapt to the new soname.

Assuming this gets a approved, subsequent FFe's for gnome-settings-daemon and gnome-control-center 3.10 will follow.

Stephen M. Webb (bregma) on 2013-09-22
Changed in unity (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in unity:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 7.2.0
Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Changed in gnome-desktop3 (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Tim Lunn (darkxst) wrote :

Tagging as high for Ubuntu GNOME, since this is blocking g-s-d/g-c-c (once they have been forked for ubuntu)

Changed in ubuntu-gnome:
importance: Undecided → High
milestone: none → trusty
status: New → Triaged
Jackson Doak (noskcaj) wrote :
Changed in unity-control-center:
status: New → In Progress
assignee: nobody → Jackson Doak (noskcaj)
Changed in unity-settings-daemon:
assignee: nobody → Jackson Doak (noskcaj)
status: New → In Progress
Tim Lunn (darkxst) wrote :
Tim Lunn (darkxst) on 2014-03-04
summary: - Need to implement DisplayConfig dbus interface within Unity
+ [FFe] Implement DisplayConfig dbus interface and transition to gnome-
+ desktop 3.10
tags: added: patch
Tim Lunn (darkxst) on 2014-03-04
description: updated
description: updated
Sebastien Bacher (seb128) wrote :

Thanks for the work you guys put on this. I'm not part of the release team but from an Ubuntu Desktop/Unity perspective that transition seems risky just before the LTS.

The new version does change quite some APIs, when I looked at it those API were used e.g in gnome-screensaver. Could you include on the FFe the list of API changes in the next version and the reverse depends of those APIs? We need to make sure everything in the archive get ported if we transition.

During the call for testing on the ubuntu-desktop list there was some feedback about existing configurations not being respected on upgrade and unity barrier not working, have those issues been resolved?

Sebastien Bacher (seb128) wrote :

The ffe also lists "unity", should those lines be set to invalid since the current solution feature a new component rather than unity changes?

Sebastien Bacher (seb128) wrote :

(oh, another note, g-c-c 3.10 depends on a new gnome-bluetooth apparently, might might depends on bluez5, I just crossed bug #1267909 which is about that)

Tim Lunn (darkxst) on 2014-03-04
Changed in unity:
status: Triaged → Invalid
Tim Lunn (darkxst) wrote :

- I fixed the issue with configurations not being read from the gnome-settings-daemon monitors.xml config file, I',m not entirely sure what wrote this file, but Laney suggested it was maybe copied across by one of the indicators?
- I couldn't reproduce the pointer barrier issue here on my dual monitor setup. I actually don't believe there is any code dealing with pointer barriers involved here either.
- Right, Unity no longer requires changes with this solution. marked invalid.
- Our build of g-c-c 3.10 has the bluetooth changes reverted, so no need for BlueZ 5 this cycle (will definitely need that for next cycle however).
- I will add a list of the changed API tomorrow, however I don't believe gnome-screensaver is affected by this and certainly built fine when I tested it. Most of the API changes are pretty internal (i.e. limited to g-s-d and g-c-c). The api's that most apps are using (background, thumbnailer, etc) are unaffected.

As a side note, I have spoken with upstream about splitting out all app dependencies from gnome-desktop, at which point it would become feasible to fork gnome-desktop, however this won't happen until atleast 3.14 anyway.

affects: unity-control-center → unity-control-center (Ubuntu)
Changed in unity-control-center (Ubuntu):
importance: Undecided → Low
Tim Lunn (darkxst) wrote :

This is the full list of API changes for gnome-desktop, keep in mind that most of these were moved into display-config (and/or made redundant by those changes). There are no rdepends in the archive that use any of these (apart from g-s-d/g-c-c and u-s-d/u-c-c which already have patches prepared on this FFe)

Removed:
gnome_rr_screen_set_size
gnome_rr_screen_get_timestamps
gnome_rr_screen_set_primary_output
gnome_rr_output_is_connected
gnome_rr_output_get_backlight_min
gnome_rr_output_get_backlight_max
gnome_rr_output_get_size_inches
gnome_rr_crtc_set_config_with_time
gnome_rr_output_get_connector_type
gnome_rr_config_save
gnome_rr_config_apply_from_filename_with_time
gnome_rr_config_apply_with_time
gnome_rr_config_get_backup_filename
gnome_rr_config_get_intended_filename
gnome_rr_config_load_filename
gnome_rr_config_new_stored

Changed:
gnome_rr_output_is_laptop -> gnome_rr_output_is_builtin_display
gnome_rr_output_get_backlight (remove gerror param)
gnome_rr_output_get_ids_from_edid (type changes for some params)
gnome_rr_output_get_width_mm -> gnome_rr_output_get_physical_size
gnome_rr_output_get_height_mm -> gnome_rr_output_get_physical_sizels
gnome_idle_monitor_new_for_device (adds gerror)

Steve Langasek (vorlon) wrote :

Robert, Seb: you may not be on the release team, but I'm not on the Ubuntu Desktop team, which is going to have to absorb the impact of this change on libraries that you're using. Is this something that you're prepared to do, or not? I would like to be able to accomodate the Ubuntu GNOME team here, but I don't want to sign off on this change unless the desktop team has done so first, and AIUI that hasn't happened yet.

Sebastien Bacher (seb128) wrote :

@Steve: thanks for checking. When we discussed it with Robert the consensus was that we find that it's a risky change, and that it has potential to create issues for us.

If that was not blocking the GNOME remix, for some of their work, we would have nacked the request, we would like to try to accomodate everyone though.

In the previous testing round we had some issues, so I would like to give it again some proper testing before giving a +1 or -1.

The archive has been moving since that request was filed, so the testing ppa that was set up is not usable anymore. It would be good if somebody could rebase the changes on the current archive version so we can use the ppa for testing, I don't think I'm going to have the free slots to do the rebasing/local builds myself just to be able to test those changes.

Sebastien Bacher (seb128) wrote :

(note that it should be possible to review/land the new service (that's a new source right?) while the other changes are evaluated)

Tim Lunn (darkxst) wrote :

I rebased the packages, however there seems to be a atleast one new issue, since last testing. I have had a pretty crazy week, but will sort it all out sometime tomorrow.

Stephen M. Webb (bregma) on 2014-03-18
Changed in unity:
milestone: 7.2.0 → none
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-desktop3 (Ubuntu):
status: New → Confirmed
Iain Lane (laney) wrote :

Tim, I'm quite concerned about the impact on this for Trusty. If this wasn't an LTS then I wouldn't mind, but it is...

How badly do you Ubuntu GNOME guys need this for T? I'm of course very keen to accommodate your needs but it needs to be balanced with the impact on other flavours. And the nature of this change (a transition) makes it very hard to revert if that becomes necessary.

If you say it is quite important then I'll try it out again this week.

Jackson Doak (noskcaj) wrote :
Tim Lunn (darkxst) wrote :

Jackson, Thanks, but please attach a debdiff, I can't review that right now with internet issues

Rick Harris (rickfharris) wrote :

Hey all, I'm not sure if I should be posting to this bug or some other tracking type bug, or even as a github issue at https://github.com/darkxst/displayconfig so here goes...correct me if I'm wrong.

I've been trying to get gnome-3.10 on Trusty using Jackson's packages for unity-settings-daemon and unity-control-center along with Tim's displayconfig pulled from his github repo.

Everything is almost there except for the following issues:

1. Clicking 'Apply' in unity-control-center's 'Screen Display' dialog after making a change does not present the confirmation dialog messagebox that states "Do you want to keep these display settings?" with the option to 'Revert', 'Confirm' or 'Cancel'.
As a consequence the timer for this messagebox silently ticks down in the background and the changed settings automatically revert to the previous setting.
Some source digging reveals this messagebox is part of gnome-shell in js/ui/windowManager.js :(

2. In some rare instances, constantly clicking the 'Apply' button does actually get the setting to finally stick without it timing out, but the setting is not saved between desktop sessions.

Let me know if I can do anything more to test, or even if this approach is still being developed as it's been a month since there was any action on this.

Cheers :)

Tim Lunn (darkxst) on 2014-05-08
Changed in ubuntu-gnome:
milestone: trusty → utopic
Iain Lane (laney) wrote :

Alright, I just tried the displayconfig daemon out with u-s-d/u-c-c built from the branches attached here, and gnome-desktop 3.12 from gnome3-staging, as we think it's the best architecture for us, short of Unity implementing the interface itself. There were a few problems

  - Nothing activated the daemon meaning that I had the default resolution and no cursor until I entered g-c-c's display panel (both in the greeter and session)
  - After it activated, the monitors were the wrong way around (left-right swapped)
  - No confirmation dialog of changes
  - Got a crash from g-c-c in libgnome-desktop (bt & Core attached, can supply {d,}debs if you want). Don't know when this happened (possibly related to D-Bus activation)

Iain Lane (laney) wrote :
Tim Lunn (darkxst) on 2014-06-27
tags: added: ubuntugnome-blocker
Changed in unity (Ubuntu):
status: Triaged → Invalid
Changed in unity-settings-daemon (Ubuntu):
status: New → In Progress
assignee: nobody → Jackson Doak (noskcaj)
no longer affects: unity-settings-daemon
Tim Lunn (darkxst) on 2014-09-24
Changed in ubuntu-gnome:
status: Triaged → Invalid
Changed in gnome-desktop3 (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Invalid
Changed in unity-control-center (Ubuntu):
status: In Progress → Invalid
Tim Lunn (darkxst) wrote :

This was fixed via Bug: 1372240
gnome-desktop transition and FFe now being tracked in Bug: 1372346

Tim Lunn (darkxst) on 2014-12-11
Changed in ubuntu-gnome:
milestone: utopic → none
Jackson Doak (noskcaj) on 2014-12-14
Changed in unity-settings-daemon (Ubuntu):
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers