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

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

I have merges proposed for u-s-d and u-c-c.
Build logs are at https://launchpad.net/~noskcaj/+archive/build/+build/5648073/+files/buildlog_ubuntu-trusty-amd64.unity-settings-daemon_14.04.0%2B14.04.20140228-0ubuntu2_UPLOADING.txt.gz and https://launchpad.net/~noskcaj/+archive/build/+build/5648067/+files/buildlog_ubuntu-trusty-amd64.unity-control-center_14.04.3%2B14.04.20140226-0ubuntu2_UPLOADING.txt.gz repectively.

gnome-desktop buildlog
https://launchpadlibrarian.net/168292752/buildlog_ubuntu-trusty-amd64.gnome-desktop3_3.10.1-0ubuntu1~trusty2_UPLOADING.txt.gz

displayconfig buildlog
https://launchpadlibrarian.net/168120073/buildlog_ubuntu-trusty-amd64.displayconfig_3.10.4-0ubuntu1~trusty1_UPLOADING.txt.gz

logs for the other packages should be at https://launchpad.net/~noskcaj/+archive/build

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?

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

(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)

- 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.

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)

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.

@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.

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

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.

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

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, Thanks, but please attach a debdiff, I can't review that right now with internet issues

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 :)

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)

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