Add support for fake modes on laptop screens which only have one

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1196239

xrandr output:
Screen 0: minimum 320 x 320, current 1366 x 768, maximum 8192 x 8192
XMIR-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   XMIR mode of death 60.0*+

If you look at the screenshot you can see that no screen is detected: "unknown display", in Saucy without MIR I get "built-in display".

This is being fixed as part of the multi-monitor support.

This is critical for those testing on high-DPI screens since unity and the toolkits don't support "retina dislplays", lowering the resolution is the only option to make it usable.

Yep, this is still a problem...

Using XMir my options are limited:

XMIR-0 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 280mm x 160mm
   1366x768 59.8*+

Compared to native X:

LVDS1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm
   1366x768 60.0*+
   1360x768 59.8 60.0
   1024x768 60.0
   800x600 60.3 56.2
   640x480 59.9

This should be improved by https://github.com/RAOF/xserver/pull/1 . Note that you will still probably get more modes under native X, since native X adds some standard modes not advertised by the hardware, which Mir currently doesn't.

Alexandros - was this fixed in Mir - do you know what revision?

Updated today and verified nothing was fixed.

Speaking to RAOF, he pointed out that this is kind of an intentional feature and not a bug. Because laptop displays typically only support one resolution. The support for other resolutions under legacy X was apparently faked through hardware scaling etc. Not as a native display mode.

You can see the native display modes supported here:

$ cat /sys/class/drm/card0-LVDS-1/modes
1366x768

As such, this bug is a feature request. Not so much a bug.

I don't think being a feature request should affect the important of the issue. I think it is still critical as XMir will be useless on a lot of laptops (especially HiDPI) in 13.10 without this feature. It is impossible to use Ubuntu 13.10 right now on a HiDPI screen without reducing the resolution by at least half.

I agree there's a good case for implementing fake modes for scaling in HiDPI environments. But it's an enhancement, and not a critical one.

Also note that Unity8 scales to arbitrary resolutions so you will never need to set a low resolution mode with that.

Daniel, it makes sense now that XMir won't be default in 13.10. This should have been of critical importance if 13.10 was to have XMir by default.

Chris was talking about doing this in Mir only just this week or so. So it's a Mir task really.

this feature becomes quite critical to use a unity8 desktop, as it's unusable now on a high res screen unless you have amazing vision :)

I've been thinking about this - and we will implement it eventually - but I don't think the readability of Unity8 desktop should be the motivator. Rather, Unity8 desktop scaling should be solved with a configurable scale factor that just makes text (and widgets proportionally) larger without moving away from the screen's best native resolution.

That was always the plan anyway and Unity8 probably has a scaling feature buried inside already. We just need to find out the command (or better get a GUI) for configuring the scale.

Upping the priority since this is needed for Ubuntu personal.

Implementing this will degrade visual quality to some degree. And the alternative I mentioned above won't. We will indeed implement this still, but how is it a high priority compared to just correctly scaling Unity8 and using the native/preferred display resolution for maximum quality?

So, migrating discussion from a bug marked as duplicate:

OK, there's a design discussion to be had here.

In these cases, mirout is correct - your display has exactly one mode it can be driven at. X adds a whole bunch of fake “standard” modes, but they're just that - fake. Selecting one of the fake modes does not change the video mode; instead, it scales the rendering up to the monitor's mode.

What is the user requirement here?

I'd prefer the Mir API to accurately reflect the capabilities of the system, but one of those capabilities is that we can scale content. If the user-requirement is “I'd like everything on my screen to look bigger”, we can do that.

Indeed, this seems to be the Apple approach - https://support.apple.com/en-au/HT202471 - there's the “optimal resolution” button, and then the “make everything larger or smaller” option.

(Note that the user requirement *cannot* be “I'd like to change the display mode”, because Unity 7 doesn't change the display mode in these cases ☺)

Sounds roughly like what I said in the previous comments.

I agree Mir should not be providing fake modes just to address scaling. Scaling should be done in the shell but using the real native mode of the display for maximum visual quality.

However... some shells might not scale adequately and/or some users will have strange preferences and supporting fake modes is just a nice-to-have feature for those cases. Unity8 does not fall into this category so this bug should not be considered high priority IMHO.

Just add a slider in Unity8's settings to adjust the scale, and implement it correctly :)

This is also an issue when we have cloned displays.
We need to be able to scale down to a fake mode. My laptop screen only runs at 1080p and if I have an external monitor plugged in with a lower resolution (eg 720), the only valid resolution will be the lower one.

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

I was just including my example as another plus point for fake modes ("scale" in this case didn't mean "output scaling".
If we had the fake modes then output scaling wouldn't really be required in this case, as we would have a set of mutually inclusive modes to chose from.

Absolutely. I was already thinking that but thanks for pointing it out.

Although the implementations may turn out to be directly related we're keeping separate bugs in case they turn out to not be related, and because implementing bug 1639226 it seems is more important than resolving this one by itself (see above comments).

Just catching up on the comments here..

To answer the question of what is the user requirement, I believe the answer is "I'd like everything on my screen to look bigger/smaller". The system settings for Displays will have a Scale slider (which currently is hidden until the capability exists).

Where is the bug/work item captured to implement Scaling in the shell? If this bug is a wishlist, the other surely needs to be High priority.

Bill,

Please log a new bug for the scale slider (if you can't find one). It will need both 'ubuntu-system-settings' and 'Mir' tasks. Possibly also Unity8/qtmir tasks?

Changing the scale does not change the actual size of the pixels (because we want everything to be sharp still) so that's unrelated to this bug or the other bug mentioned here. Still, very important to the U8 desktop.

Triaged but very low priority. Mir and Unity8 will have better options for scaling than "fake modes" in future.

I think the priority is incorrect, and hopefully not based on the scaling comment, which I think is maybe one use case, but not the most important one:

“My laptop's graphics card|driver is slow|bad. I want to play game X, but at 1920x1080 I get an average of 3 frames per seconds—even with the lowest quality settings.”

Isn't one solution to limit the amount of pixels being rendered? I think this is critical for gaming, as I've used this _a lot_ in the past and current.

> “My laptop's graphics card|driver is slow|bad. I want to play game X, but at 1920x1080 I get an average of 3 frames per seconds—even with the lowest quality settings.”

I can argue that the same can be said for e.g. youtube videos.

Excellent point. However I did not explain myself in that we do still plan on providing users with the means to set an arbitrary fake resolution. Whether or not we add common fake resolutions like 1024x768 to the modes list is all this bug needs to be about.

I would like to say such fake resolutions should not appear in the modes list, since there are countless possible fake resolutions and it would also be nice to distinguish hardware modes from faked modes. However I am aware of existing cases where games like to enumerate and select from a fixed list of modes. So maybe we will have to do this sooner.

Bug filed to track scaling support:
https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1645372

Syncing task from Mir.