[Merged by Bors] - Allow configuration to assign applications to outputs

[AlanGriffiths]

Uses https://github.com/MirServer/mir/pull/2853 to associate surface titles with outputs and move those apps to those outputs

WIP as:

1. it won't build on edge without the Mir PR landing; and,
2. there's more to be done to support other ways to map apps to outputs

[AlanGriffiths]

When testing remember that this needs to be built against ppa:mir-team/dev and that the default layout is overlapping screens. Try something like:

ubuntu-frame --x11-output 800x600:800x600 --output-for-app=OUT-2:Cog --output-for-app=OUT-1:Kodi --display-layout side_by_side

[AlanGriffiths]

IMO we need this as part of the display configuration, as you could arguably have different apps mapped to different displays in different layouts.

That implies adding new miral APIs that allow Frame's window manager to interrogate the .display configuration. I'm not sure what that would look like, but it wouldn't be trivial.

(It seems wrong to consider wiring something as Frame specific as this into the mir libraries. Or for Frame to parse the file for itself.)

We also need more ways to match apps, as this won't allow you to run multiple WPEs mapped to different screens.

There is existing code in Frame to use apparmor to identify other snaps, we could add that as an additional matching option?

[AlanGriffiths]

you could arguably have different apps mapped to different displays in different layouts.

We could optionally include the layout name in the mapping string?

[Saviq]

IMO we need this as part of the display configuration, as you could arguably have different apps mapped to different displays in different layouts.

That implies adding new miral APIs that allow Frame's window manager to interrogate the .display configuration. I'm not sure what that would look like, but it wouldn't be trivial.

(It seems wrong to consider wiring something as Frame specific as this into the mir libraries. Or for Frame to parse the file for itself.)

Frame could specialize the parsing, maybe registering with a key and receiving callbacks when that is encountered in the config? Or subclassing StaticDisplayConfiguration?

We could optionally include the layout name in the mapping string?

I'm looking after the user experience of this - this way we could change display config dynamically, but not apps that map to displays… this really fits into the display file, we should try and find a way for it to go there.

We also need more ways to match apps, as this won't allow you to run multiple WPEs mapped to different screens.

There is existing code in Frame to use apparmor to identify other snaps, we could add that as an additional matching option?

Yes, that was one of the options I was thinking of. Having a way for Frame to dynamically set the parsing up as suggested above would also separate this snap-specific handling from Mir itself.

[AlanGriffiths]

OK, another approach with display:

  side_by_side:
    cards:
    # a list of cards (currently matched by card-id)

    - card-id: 0
      OUT-1:
        # This output supports the following modes: 800x600@60.0
        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled  # {enabled, disabled}, defaults to enabled
        mode: 800x600@60.0      # Defaults to preferred mode
        position: [0, 0]        # Defaults to [0, 0]
        orientation: normal     # {normal, left, right, inverted}, defaults to normal
        scale: 1
        group: 0        # Outputs with the same non-zero value are treated as a single display
        surface-title: Cog

      OUT-2:
        surface-title: Kodi
        # This output supports the following modes: 800x600@60.0
        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled  # {enabled, disabled}, defaults to enabled
        mode: 800x600@60.0      # Defaults to preferred mode
        position: [800, 0]      # Defaults to [0, 0]
        orientation: normal     # {normal, left, right, inverted}, defaults to normal
        scale: 1
        group: 0        # Outputs with the same non-zero value are treated as a single display

[Saviq]

OK, another approach with display:

Looking better, and working! I'll sleep on the surface-title key, maybe simpler app-title, or window-title, though I know it's not strictly correct? Don't want to need to teach people what surfaces are :)

We may want to log the surface titles encountered so those are visible on device?

[AlanGriffiths]

When I stop and start gedit, that places it correctly, but not when modifying frame.display-layout.

I've not tracked down the change, but this doesn't get placed because the surface title has become "Untitled Document 1 - gedit", not "gedit"

[bors[bot]]

Pull request successfully merged into main.

Build succeeded:

• Snap