Mir

A scaled (not panned or clipped) mirror/clone mode is desired

Bug #1639226 reported by Gerry Boland on 2016-11-04
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
High
Daniel van Vugt

Bug Description

Unity8 wants the ability to configure the displays to clone mode.

That is, unity8 has a single surface, which then USC composites on all displays - scaling the surface so that unity8 is fullscreen (or with minimal black borders) on all displays.

Currently all Unity8 can do is configure all displays to view position (0,0), so that all displays render the surface at that position. But for displays of differing resolution, that surface can be clipped/bordered. This is not ideal.

Related branches

Gerry Boland (gerboland) on 2016-11-04
summary: - Mirror mode desired
+ Mirror/clone mode desired

A couple of things:
  (1) The title suggests Mir doesn't have a clone mode, but it does and has done for years.
  (2) The suggested solution of scaling is probably significantly more work (and possibly less desirable) than another solution I was thinking about...

We could simply solve the clipping bug on displays of lower resolution by panning that display to follow the hardware cursor when it touches the edge of the screen. That's how Xorg has handled it traditionally and it's rather nice. Only problem is the prerequisite to that is for Unity8 to start using USC's hardware cursor. Panning has the extra advantage of us being able to do it without having to GL re-composite the smaller display (hence I figured that will be more work).

tags: added: enhancement multimonitor
summary: - Mirror/clone mode desired
+ A scaled (not panned or clipped) mirror/clone mode is desired
Changed in mir:
importance: Undecided → Medium
status: New → Triaged
Gerry Boland (gerboland) wrote :

> (1) The title suggests Mir doesn't have a clone mode, but it does and
> has done for years.
My definition of clone/mirror apparently does not match yours - and I'll argue that without scaling, clone mode is not useful.

> (2) The suggested solution of scaling is probably significantly more
> work (and possibly less desirable) than another solution I was thinking
> about...
What I have asked for is what design has requested.

Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
Nick Dedekind (nick-dedekind) wrote :

I think we need to at least duplicate what X does. It seems to choose the highest common resolution. But then xrandr is spitting out a bunch more modes than mir is picking up for internal displays, so perhaps it's actually scaling?

Daniel van Vugt (vanvugt) wrote :

Nick,
You've got your bugs mixed up. That comment belongs in bug 1196239 and the comment in that bug belongs here.

Daniel van Vugt (vanvugt) wrote :

OK, I've got a basic plan for this...

Give outputs A and B of arbitrary differing resolutions, if you want to clone A to B then B will simply display a potentially scaled and letterboxed image of A. To achieve this you would simply set B's logical position and logical size to that of A.

In Xorg you can already do something like that:
   xrandr --output B -pos (A.X)x(A.Y) --scale-from (A.WIDTH)x(A.HEIGHT)

So then you have arbitrary cloning of any display to any display even if they have different physical resolutions.

What's missing in Mir right now is the API for setting the arbitrary logical size for an output. Although our default GL renderer already supports arbitrary logical sizes it might still be missing letterbox support to avoid distortion.

Gerry Boland (gerboland) wrote :

I was thinking of a simpler setup, having 2 displays, you could just configure DisplayB to clone DisplayA, and Mir would handle the scaling/letterboxing...

Your proposal is more flexible than that, but I don't see the value in that flexibility. For what would I use your proposal that is not clone-related?

Daniel van Vugt (vanvugt) wrote :

It's the same thing really. Indeed we should provide simpler helper functions for "clone A onto B". I was really just describing the underlying implementation.

Gerry Boland (gerboland) wrote :

Any progress on this?

Changed in mir:
importance: Medium → High
Daniel van Vugt (vanvugt) wrote :

It's on my queue of work, immediately behind finishing (proposing) the first part of client-side vsync to solve our the latency problems in time for Mir 0.26.

Changed in mir:
milestone: none → 1.0.0
Changed in mir:
status: Triaged → In Progress
Mir CI Bot (mir-ci-bot) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Daniel van Vugt (vanvugt) wrote :

Still attacking this bug from multiple angles, and some angles require multiple branches. So you'll see a bunch of branches attached to the bug before it's resolved.

Mir CI Bot (mir-ci-bot) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-02-16
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-02-17
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-03-22
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Changed in mir:
milestone: 0.27.0 → 0.28.0
Mir CI Bot (mir-ci-bot) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-04-04
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-04-04
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-04-13
Changed in mir:
status: In Progress → Fix Committed
Daniel van Vugt (vanvugt) wrote :

See above. 10 branches landed and at least 2 or 3 more required before this feature is complete. But it's getting very close.

I might decide to declare it complete without finishing up hardware cursor support to work with it. Not sure yet.

Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Mir CI Bot (mir-ci-bot) on 2017-05-17
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
milestone: 0.28.0 → 0.27.0
Daniel van Vugt (vanvugt) wrote :

The feature only exists mostly complete in the 0.28 series (lp:mir).

  http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/4171

It's missing in lp:mir/0.27

Changed in mir:
milestone: 0.27.0 → 0.28.0
Changed in mir:
milestone: 0.28.0 → 0.27.0
Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers