[FFe] Distro patch GNOME hi-dpi support for x11 sessions

Bug #1820850 reported by Sebastien Bacher on 2019-03-19
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Marco Trevisan (Treviño)
mutter (Ubuntu)
Marco Trevisan (Treviño)
xorg-server (Ubuntu)

Bug Description

The first part of our work on better handling of HI-DPI screens got merged upstream in 3.32, but it's for wayland only

Since our default session in Ubuntu is based on xorg we would like to distro patch the x11 equivalent for Disco so our users can benefit from the feature.

Updates packages are up for testing in that ppa

The main change is

The ppa also includes a bugfix and a settings change to allow easy configuration.

Note that the feature is behind an experimental gsettings key and the code has no impact on the rendering for users who don't enable it, which means it shouldn't be too risk. It's available as a opt-in for those who want to test it.
From our testing it works fine and we feel like it's ready to be included. We do plan to get that work merged upstream in the next cycle so it should not be an Ubuntu delta to carry over forever.

Related branches

Changed in gnome-control-center (Ubuntu):
importance: Undecided → High
Will Cooke (willcooke) on 2019-03-19
description: updated
Iain Lane (laney) wrote :

This is a *great* feature that it'd be really cool for Ubuntu to have and I'm very pleased that the team has been working on it, but...

I really don't feel very good about this freeze exception request. It doesn't seem right to me to be adding unmerged, experimental and unfinished features into the release - especially so late on.

It is going to need iteration either before or after the release and that runs a very high risk of either being disruptive to the release (making updates to the altered packages potentially more difficult if they need to be changed for other reasons), taking up time of the release/SRU teams having to review changes, or (if iterations aren't included in disco) the package in the release being behind the latest developments meaning that it ends up not being as useful to people as it could be — known bugs will be fixed in the development branches but not in disco.

A PPA seems like the right place to handle distributing such experimental features to people. Testing things is one thing that PPAs are for, and any publicity that you want to do around this feature could have upgrading via `add-apt-repository` as its first step. Such a PPA could even live under an uploading team like ~ubuntu-desktop to make it seem more official if you wanted.

There's no problem with ubuntu/disco-x-fractional branches being created in the packaging repositories, to make handling the PPA easier.

Sebastien Bacher (seb128) wrote :

> that runs a very high risk of either being disruptive to the release

Hum, my understanding is that it is basically be a no-op unless the gsettings key is set? If so I see the risk for the release being low, 'go enable an experimental gsettings key and restart your session' doesn't sound like a release problem, users opting for experimental options get what they ask for?

> A PPA seems like the right place to handle distributing such experimental features to people.

That doesn't have the same "easy to try" nor PR potential, it also can't be described as part of the release...

Launchpad Janitor (janitor) wrote :

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

Changed in gnome-control-center (Ubuntu):
status: New → Confirmed
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Iain Lane (laney) wrote :

> disruptiveness

I'm talking about in terms of handling updates to the package, making it more cumbersome to handle and taking up the time/energy of reviewers, when a fast-moving experimental unfinished feature would be better maintained without that friction - allowing its developers to make any improvements they want with complete freedom.

> That doesn't have the same "easy to try" nor PR potential, it also can't be described as part of the release...

You'll have to give instructions for how to enable it anyway, and in that case telling people how to enable a PPA is not much of an extra leap. I would think that the main PR value is "look at this cool feature that Ubuntu's engineers have done, and you can watch it getting better with each update", which you can get with a PPA.

Feel free to get a second opinion if you aren't inclined to accept this one.

Łukasz Zemczak (sil2100) wrote :

I have been asked to give a second opinion on this FFe so here I am.

Since I am not part of the Desktop team I'm deferring the decision of whether going with the PPA approach or the archive approach is the most optimal to the Desktop leads. Personally I also feel that using a PPA here might be more dynamic, but on the other hand I would always prefer 'official' bits and features to land in the archive. It's a tricky territory I must say. I guess because of our times with the stable-overlay PPA, I'm a bit shellshook regarding PPAs as 'semi-official delivery mechanisms' - but that's just me.
Anyway, as said, I'm leaving the decision of which one is better from the practical POV to the Desktop team, and so far I've been told that the management decision was made to get it into the archive.

With my release team hat on, to be able to approve this FFe I'd need to be sure that adding this feature so late in the cycle will not introduce regressions, therefore delaying the release. In this case, even though the change is quite big, I think the gsettings key makes this rather safe to land from this POV.

One thing I would not accept is blocking the disco release on this feature in any way. Like, once this 'disabled-by-default' feature lands in the archive but appears to be broken in some way that would delay our delivery of 19.04, to me this warrants an instant-revert instead.

With all this being said and some of the internal discussions I had with the Desktop team, I would like to approve this FFe under the above conditions. Sorry about that Laney - just so you know: your arguments were sane and it took me quite a bit to get convinced the other way around. I'll be taking the blame for it in case anything goes wrong.
Also, please land this ASAP and, at best, make sure this gets into the archive before the beta images are built. In case we notice anything wrong with the Beta images because of this, we can quickly revert and forget about it.

Changed in gnome-shell (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-control-center (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-control-center (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Changed in gnome-shell (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
affects: gnome-shell (Ubuntu) → mutter (Ubuntu)
Changed in mutter (Ubuntu):
assignee: Marco Trevisan (Treviño) (3v1n0) → nobody
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Changed in xorg-server (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mutter - 3.32.0-1ubuntu1

mutter (3.32.0-1ubuntu1) disco; urgency=medium

  * debian/control:
    - Update VCS flags to point to launchpad
    - Update maintainer to ubuntu
  * debian/gbp.conf: update branch to point to ubuntu/master
  * debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
    - X11: Add support for fractional scaling using Randr (LP: #1820850)

 -- Marco Trevisan (Treviño) <email address hidden> Wed, 27 Mar 2019 06:48:11 +0100

Changed in mutter (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:

gnome-control-center (1: disco; urgency=medium

  * debian/patches/display-Don-t-always-set-the-primary-monitor-to-the-first.patch:
    - Make sure the display panel primary monitor matches configured one
  * debian/patches/display-Support-UI-scaled-logical-monitor-mode.patch:
    - Support scaled logical monitors using UI scale as it could happen when
      using the X11 Randr scaling (LP: #1820850)

 -- Marco Trevisan (Treviño) <email address hidden> Wed, 27 Mar 2019 06:10:59 +0100

Changed in gnome-control-center (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.20.4-1ubuntu3

xorg-server (2:1.20.4-1ubuntu3) disco; urgency=medium

  * sync-i965-pciids.diff: Sync with mesa, add support for CML. (LP:
  * dix-ensure-work-queues-are-cleared-on-reset.diff: Fix a race
    condition that might crash the server.
  * reset-transforms-in-closescreen.diff: Fix a crash when resuming a
    scale transformation after closing the screen. (LP: #1820850)

 -- Timo Aaltonen <email address hidden> Wed, 03 Apr 2019 12:03:57 +0300

Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers