Mir

Display mode changes made directly to the system compositor are not reflected in the nested Mir server

Bug #1669034 reported by Gerry Boland
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Invalid
Undecided
Unassigned
Mir
Invalid
High
Unassigned

Bug Description

I need a second pair of eyes on this.

I'm running unity8 on my AMD laptop. It comes up at whatever resolution Mir decides, probably based on what the driver recommends.

I want to change the resolution, so use the mirout tool to do so:

⮀ sudo MIR_SOCKET=/run/mir_socket mirout
Connected to server: <default>
Max 2 simultaneous outputs
Output 38: eDP, connected, "CMN 5264", 1366x768+0+0, enabled, on, 310mm x 170mm (13.9"), normal, 1.00x, HRGB, monitor
    1366x768 60.00*+
    1280x720 59.85
    1152x768 59.78
    1024x768 59.92
     800x600 59.86
     848x480 59.65
     720x480 59.70
     640x480 59.37
Output 40: HDMI-A, disconnected
Output 42: VGA, disconnected
⮀ sudo MIR_SOCKET=/run/mir_socket mirout mode 640x480
⮀ sudo MIR_SOCKET=/run/mir_socket mirout
Connected to server: <default>
Max 2 simultaneous outputs
Output 38: eDP, connected, "CMN 5264", 640x480+0+0, enabled, on, 310mm x 170mm (13.9"), normal, 1.00x, HRGB, monitor
    1366x768 60.00 +
    1280x720 59.85
    1152x768 59.78
    1024x768 59.92
     800x600 59.86
     848x480 59.65
     720x480 59.70
     640x480 59.37*
Output 40: HDMI-A, disconnected
Output 42: VGA, disconnected

So it seems to work. But unity8 appears unchanged on the display. Looking into its log I see prints only from Mir:

[2017-03-01 16:02:34.550711] mirserver: New display configuration:
[2017-03-01 16:02:34.550781] mirserver: Output 38: eDP connected, used
[2017-03-01 16:02:34.550799] mirserver: EDID manufacturer: CMN
[2017-03-01 16:02:34.550814] mirserver: EDID product code: 5264
[2017-03-01 16:02:34.550840] mirserver: Physical size 13.9" 310x170mm
[2017-03-01 16:02:34.550854] mirserver: Power is on
[2017-03-01 16:02:34.550871] mirserver: Current mode 1366x768 60.00Hz
[2017-03-01 16:02:34.550888] mirserver: Preferred mode 1366x768 60.00Hz
[2017-03-01 16:02:34.550902] mirserver: Orientation normal
[2017-03-01 16:02:34.550915] mirserver: Logical size 1366x768
[2017-03-01 16:02:34.550928] mirserver: Logical position +0+0
[2017-03-01 16:02:34.550946] mirserver: Output 40: HDMI-A disconnected
[2017-03-01 16:02:34.550964] mirserver: Output 42: VGA disconnected
[2017-03-01 16:02:34.550982] mirserver: New base display configuration:
[2017-03-01 16:02:34.551002] mirserver: Output 38: eDP connected, used
[2017-03-01 16:02:34.551017] mirserver: EDID manufacturer: CMN
[2017-03-01 16:02:34.551030] mirserver: EDID product code: 5264
[2017-03-01 16:02:34.551046] mirserver: Physical size 13.9" 310x170mm
[2017-03-01 16:02:34.551059] mirserver: Power is on
[2017-03-01 16:02:34.551075] mirserver: Current mode 1366x768 60.00Hz
[2017-03-01 16:02:34.551091] mirserver: Preferred mode 1366x768 60.00Hz
[2017-03-01 16:02:34.551104] mirserver: Orientation normal
[2017-03-01 16:02:34.551118] mirserver: Logical size 1366x768
[2017-03-01 16:02:34.551131] mirserver: Logical position +0+0
[2017-03-01 16:02:34.551147] mirserver: Output 40: HDMI-A disconnected
[2017-03-01 16:02:34.551164] mirserver: Output 42: VGA disconnected

Which only mentions the old resolution. And so unity8 has nothing to do.

Can someone else check this and see?

(note: mirout fails when talking to the nested server directly, think a mir bug there)

Revision history for this message
Gerry Boland (gerboland) wrote :

Indents lost: here are logs again: http://pastebin.ubuntu.com/24090932/

Revision history for this message
Dave Morley (davmor2) wrote :

Confirming this issue in kvm. For me I tried to set 1920X1080

davmor2@davmor2-kvm:~$ mirout /run/mir_socket mode 1920x1080
davmor2@davmor2-kvm:~$ mirout /run/mir_socket
Connected to server: /run/mir_socket
Max 4 simultaneous outputs
Output 30: Virtual, connected, 1920x1080+0+0, enabled, on, 0mm x 0mm (0.0"), normal, 1.00x, unknown, monitor
    1024x768 59.94 +
    1920x1200 59.95
    1920x1080 59.99*
    1600x1200 59.95
    1680x1050 59.99
    1400x1050 59.99
    1280x1024 59.94
    1440x900 59.99
    1280x960 59.99
    1280x854 59.95
    1280x800 59.95
    1280x720 59.97
    1152x768 59.94
     800x600 59.95
     848x480 59.93
     720x480 59.93
     640x480 59.93
Output 34: Virtual, disconnected
Output 38: Virtual, disconnected
Output 42: Virtual, disconnected
davmor2@davmor2-kvm:~$

Changed in mir:
status: New → Confirmed
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

Right after setting the current mode and usc applying it I do see a configure_display() request originating from unity8 - there the resolution is again is requested to be 1024x768.

I do not think this is a bug..

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I was wondering for a while how you got 'mirout' to not crash. Because it will crash if you point it at a nested server (bug 1661163).

But then I was able to reproduce the problem. It's that mode changes directed at the system compositor are not communicated to the nested server's display configuration.

However mode changes initiated through the nested server's socket are correctly reflected in both servers.

Architecturally we may want to direct mode changes to the Unity8 socket and not the USC socket. If you do that then it should work (although mirout itself may crash - bug 1661163).

summary: - Check resolution changes are being propagated to the nested server
+ Display mode changes made directly to the system server are not
+ reflected in the nested server
Changed in mir:
importance: Undecided → High
status: Confirmed → Triaged
milestone: none → 1.0.0
tags: added: multimonitor nested
summary: - Display mode changes made directly to the system server are not
- reflected in the nested server
+ Display mode changes made directly to the system compositor are not
+ reflected in the nested Mir server
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

Looking at qtmirs code this happens because qtmir wrapps the default display configuration policies of mir. All of them will pick preferred mode over any current mode.

Changed in qtmir:
status: New → Triaged
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

Adding qtmir to the bug ticket - we could change qtmir to also look at the current mode before passing the config to the wrapped policies.. Or we could change the mir implementations or change favor any already selected modes.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I reproduced the bug using just nested Mir demo servers. That makes me think we may only need to fix Mir.

tags: added: unity8-desktop
Michał Sawicz (saviq)
affects: qtmir → qtmir (Ubuntu)
Changed in mir:
milestone: 0.27.0 → 0.28.0
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :
Download full text (3.9 KiB)

You can see this behaviour running Mir on Mir on the desktop. Run the following in three terminals:

$ mir_demo_server --window-manager system-compositor --file /tmp/usc-socket
$ mir_demo_server --host /tmp/usc-socket --launch mir_demo_client_egltriangle
$ mirout /tmp/usc-socket rotate inverted

From the "system-compositor" console we see:

[2017-08-22 10:03:26.875363] mirserver: New display configuration:
[2017-08-22 10:03:26.875375] mirserver: Output 1: unknown connected, used
[2017-08-22 10:03:26.875386] mirserver: Physical size 15.0" 317x211mm
[2017-08-22 10:03:26.875392] mirserver: Power is on
[2017-08-22 10:03:26.875398] mirserver: Current mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875404] mirserver: Preferred mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875410] mirserver: Orientation inverted
[2017-08-22 10:03:26.875416] mirserver: Logical size 1200x800
[2017-08-22 10:03:26.875421] mirserver: Logical position +0+0
[2017-08-22 10:03:26.875430] mirserver: New base display configuration:
[2017-08-22 10:03:26.875437] mirserver: Output 1: unknown connected, used
[2017-08-22 10:03:26.875443] mirserver: Physical size 15.0" 317x211mm
[2017-08-22 10:03:26.875449] mirserver: Power is on
[2017-08-22 10:03:26.875455] mirserver: Current mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875461] mirserver: Preferred mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875466] mirserver: Orientation inverted
[2017-08-22 10:03:26.875472] mirserver: Logical size 1200x800
[2017-08-22 10:03:26.875477] mirserver: Logical position +0+0

So the *base* configuration has been inverted, but now the nested session re-applies its session configuration...

[2017-08-22 10:03:26.875746] mirserver: Session nested-mir@:/run/user/1000/mir_socket applied display configuration
[2017-08-22 10:03:26.875757] mirserver: Output 1: unknown connected, used
[2017-08-22 10:03:26.875765] mirserver: Physical size 15.0" 317x211mm
[2017-08-22 10:03:26.875771] mirserver: Power is on
[2017-08-22 10:03:26.875776] mirserver: Current mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875782] mirserver: Preferred mode 1200x800 60.00Hz
[2017-08-22 10:03:26.875794] mirserver: Orientation normal
[2017-08-22 10:03:26.875799] mirserver: Logical size 1200x800
[2017-08-22 10:03:26.875807] mirserver: Logical position +0+0
[2017-08-22 10:03:26.888480] GLRenderer: EGL vendor: Mesa Project
[2017-08-22 10:03:26.888512] GLRenderer: EGL version: 1.4 (DRI2)
[2017-08-22 10:03:26.888518] GLRenderer: EGL client APIs: OpenGL OpenGL_ES
[2017-08-22 10:03:26.888524] GLRenderer: GL vendor: Intel Open Source Technology Center
[2017-08-22 10:03:26.888530] GLRenderer: GL renderer: Mesa DRI Intel(R) Sandybridge Desktop
[2017-08-22 10:03:26.888535] GLRenderer: GL version: OpenGL ES 3.0 Mesa 17.0.7
[2017-08-22 10:03:26.888541] GLRenderer: GLSL version: OpenGL ES GLSL ES 3.00
[2017-08-22 10:03:26.888548] GLRenderer: GL max texture size = 8192
[2017-08-22 10:03:26.888564] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0
[2017-08-22 10:03:26.888673] mirserver: New display configuration:
[2017-08-22 10:...

Read more...

Changed in canonical-devices-system-image:
status: New → Invalid
no longer affects: qtmir (Ubuntu)
Changed in mir:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.