Shell doesn't know when base display config has changed

We need this in Unity8 to implement display state saving across reboots

Here is the workflow we require for unity8 display configuration.

1) unity8 starts and loads saved config from disk (default if not present)
2) settings app starts.
3) unity8 gets set_base_config_is_allowed and returns true
4) user selects a resolution/option/etc and settings app calls set_base_config
5) unity8 overloads the server call to set_base_config (not sure if it can do this?) and applies the change.
6) settings app goes "Are you sure you want to keep this config?"
7.1) user selects "no"
7.2) settings app calls restore_base_config
7.3) unity8 overloads the server call and loads config from disk
OR
8.1) user selects "yes"
8.2) settings app calls save_base_config
8.3) unity8 overloads the server call and saves config to disk

Sorry, that was a bit wrong.

1) unity8 starts and loads saved config from disk (default if not present)
2) settings app starts.
3) unity8 gets set_base_config_is_allowed and returns true
4) user selects a resolution/option/etc and settings app calls mir_connection_preview_base_display_configuration
5) settings app goes "Are you sure you want to keep this config?"
6.1) user selects "no"
6.2) settings app calls mir_connection_cancel_base_display_configuration_preview
OR
8.1) user selects "yes"
8.2) settings app calls mir_connection_confirm_base_display_configuration
8.3) unity8 gets notified of the change to the base config and saves to disk.

A couple of years ago we had a similar discussion about how to persist display configurations. Following that I was tasked with implementing mir_blob_from_display_configuration(), mir_blob_to_display_configuration() et alia. That's a client API for persisting display configurations.

Now, you're talking about persisting them in Unity8. Are you expecting an additional server API?

If you're happy creating an internal connection to use the client API then I think Mir already has everything you're asking for:
1. Clients are notified of config changes (which if it never applies a session config must be base config changes); and
2. there's mechanisms for serializing them and applying them.

I can wrap this implementation up as a MirAL helper class.

The MirBlob is perfect for serializing the display config to disk. But yes we want to utilize that within unity8, not from a client.

I would be happy to have a MirAL api for this

After some discussion on IRC it appears that an additional usecase is hardware changes:

1) unity8 starts and loads saved config from disk (default if not present)
2) an additional screen is plugged in
3) Unity8 is notified of the h/w change and selects a saved config from disk (default if not present)
4) The selected config is applied.

Current "strawman" implementation idea:

1. run an "internal client" in qtmir/miral
2. use mir_connection_set_display_config_change_callback() to monitor display configuration changes.
3. this can use the client API mir_connection_set_base_display_config() to apply a saved configuration

Pros: simple to implement using established libmirclient API
Cons: can't react to (e.g. h/w) changes before a new config has been applied

Is this worth doing as a first cut implementation?

@ Is this worth doing as a first cut implementation?

Probably not.

It looks as though the MirDisplayConfiguration based APIs are partially deprecated (there's missing functionality in the MirDisplayConfig APIs which would inhibit full deprecation).

It may be worth noting that the "nested" server configuration does something very like what has been suggested in comment #7 using the MirDisplayConfiguration based APIs. (There may be value in reworking that in parallel.)

After some discussions on IRC trying to progress in QtMir before migrating the result to MirAL

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.26.0

This bug was fixed in the package mir - 0.26.0+17.04.20170126.3-0ubuntu1

---------------
mir (0.26.0+17.04.20170126.3-0ubuntu1) zesty; urgency=medium

  [ Daniel van Vugt ]
  * New upstream release 0.26.0 (https://launchpad.net/mir/+milestone/0.26.0)
    - ABI summary:
      . mirclient ABI unchanged at 9
      . mirserver ABI bumped to 43
      . mircommon ABI unchanged at 7
      . mirplatform ABI unchanged at 14
      . mirprotobuf ABI unchanged at 3
      . mirplatformgraphics ABI unchanged at 11
      . mirclientplatform ABI unchanged at 5
      . mirinputplatform ABI unchanged at 6
      . mircore ABI unchanged at 1
    - Enhancements:
      . New/improved toolkit APIs: MirInputConfig and related functions,
        MirWindow and related functions, DisplayConfig and related functions,
        MirScreencastSpec and related functions,
      . Support for configuring input configuration
      . Introduce toolkit extension mechanism for platform specific APIs.
      . Toolkit extensions for: mesa_drm_auth, set_gbm_device and
        window_coordinate_translation
      . Screencasting to a specific MirBuffer.
      . Add DisplayConfigurationController::base_configuration() so downstreams
        can get the base configuration. (Weirdly they can already set it.).
      . x11 platform: allow adjustable scale parameter.
      . Added EDID support: client API, server logging and in mirout.
      . mirout: Add newer attributes only available in the new display
        config API: scaling factor, subpixel arrangement and form factor.
      . mirout: Log the orientation and logical size of each output too.
      . Replace the mir::Server-overridable Reports with Observers.
      . Add xkbcommon to mirclient.pc Requires.private.
      . Deprecate legacy toolkit APIs that will be removed in Mir 1.0
      . Introduced 'client-side vsync', which dramatically reduces latency
        from the client to the screen (particularly for nested servers like
        Unity8).
    - Bugs fixed:
      . [performance] Restore support for better-than-triple buffering by
        default. (LP: #1240909)
      . Frame rate is artificially low on Diamondville Intel Atom systems due
        to aggressive power management (LP: #1388490)
      . [testsfail] failure in CI in
        AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping
        (LP: #1394369)
      . [trusted prompt sessions] Can't open two prompt sessions at the same
        time (LP: #1494197)
      . Changing scale, formFactor or DPI in display configuration causes
        renderer teardown/recreate unnecessarily (LP: #1556142)
      . [testsfail] ApplicationNotRespondingDetection.failure_to_pong_is_
        noticed (LP: #1570327)
      . CI failure in TestClientInput.receives_one_touch_event_per_frame
        (LP: #1570698)
      . Mir-on-X mouse input is jerky/stuttery compared to Mir-on-KMS
        (LP: #1576600)
      . [regression] Two fingers in mir_proving_server now resizes/moves app
        windows (two finger apps unusable) (LP: #1586311)
      . Pointer/cursor input lag in unity8 session (LP: #1591328)
      . PointerConfinement.test_we_update_our_confined_region_on_a_resize
      ...