1. HEADLINE: A way to have different scaling for external monitors hooked up to my HiDPI laptop.
Currently I need can only set a single scaling factor, so I need to ajust my laptop screen resolution to match scaling of the external monitor. If that's not possible, a way to automatically set resolution and scale for both screens once you hook one up would already save me a lot of manual switching and restarting lightDM!
2. HEADLINE: "Native" multitouch gestures like 3-finger swipe to change workspace.
There are some programs that can do this already like xSwipe and Fusuma, but I expect this integrated with a nice and easy menu.
3. HEADLINE: Better battery management.
Battery performance under Ubuntu is often much worse in Ubuntu than Windows. TLP helps, but it's not enough.
Dev: Sure, here you go.
User: But why is it so small on my new shiny tablet high density screen?
Dev: (SHit it worked okay for me) Okay now it detects the density and scale..
User: But when I move the window to my old good lcd screen it becomes way too big!
Dev: Okay let's see if I can dynamically adapt to a new monitor density, it's just one scale factor.
User: But when I put it on my big tv flat screen it is too small!!
Dev: (Oh shit you gotta be kidding me, the pixels are actually a viewing distance relative unit??!)
DPI scaling between monitors work exactly as you'd expect. Windows stay the same size when moving between high-DPI and regular monitors.
These two problems are two of the biggest reasons I don't use Ubuntu (or any Linux) desktop (I use a macbook with a headless Ubuntu Server box and, when necessary, X11 forwarding over ssh).
I have to log out when I plug/unplug or the windows will end up blurry or the wrong size.
I know they have a bad track record of not listening, but I think things might be different now, they seem to be a bit more receptive to feedback, particularly with the beta updates.
Or maybe I'm remembering the prerelease "hai where r the bugz halp" back when Win10 was not yet RTM...
(Admittedly, "points" are still likely a good measurement for print. Perhaps one can work backwards and fudge point as a measure of angle if you consider 12 point font at a typical viewing distance.)
I assume the real hard piece is figuring out the distance the display is going to be viewed at. Some definite defaults exist (phones are typically about the same distance away, same with desktop monitors) but unique situations certainly can exist. (I'm also assuming that the monitor can report it's physical size and resolution; combined w/ viewing distance, it should be possible to calculate FoV.) If you did this, you should be able to mostly seemlessly split a window between two displays, and have it be equal "size" in the FoV. (of course, some displays have borders, so that fudges it a bit.)
That is a good starting point for calculating the default "optimal UI scaling", but there are going to be adjustments needed for the FoV of the whole screen area (not per pixel) too.
With large screens, for example 24-30" on your desk, just the per-pixel FoV measure will probably be good enough. You have plenty of "space" for windows and content, and want to get the optimal scaling.
But once you get to very small screens like phones, there is a tradeoff between keeping font and UI sizes comfortable, and being able to actually fit enough content on the screen without endless scrolling. I am willing to strain my eyes with smaller font sizes on my phone than on my laptop, just so that I can see more than 5 sentences of text at the same time.
This is at the Operating System level, not like some random one-off application.
For me, the one feature I miss the most is a checkbox option for "Native Scrolling"; Did this really need to be removed?
And the vector-based competition to X (e.g. NeWS, Display Postscript) would have done better.
This would be awesome. Even when both the laptop and the external screen are 1080p, different scaling could be helpful if you want to use a dual monitor setup effectively.
Unfortunately, it's a tough nut to crack given current desktop behavior. For example, you can have a window that straddles both monitors. What should the scaling be? You need to switch at some point as you're moving a window back and forth - when? So it's a challenge, but solving it would be so worth it!
Plugging two 4K monitors into my laptop (which has a native 1080p display) is an awful experience when booted into Ubuntu. You either have to set the DPI to make the laptop display unusable or set it to make the 4K monitors look like $hit.
Plus... you know... games.
Multi-DPI is kind of a hack in general though and is likely to cause issues unless applications have been tested for it very thoroughly, it causes serious issues on major frameworks like Electron and Qt - though both of their support for it is improving slowly. If you want things to work smoothly for now, try to stick to 1 DPI setting.
It's not windows fault the apps don't take advantage of DPI.
You can also disable dpi scaling for individual apps.
It's "not Windows fault", sure but it certainly makes it a worse experience than other platforms like OSX where multi-DPI is much more commonly supported.
I mean, I get it, same issue as Vista for Microsoft - people expect 100% backwards compatibility, but it turns out that terrible design decisions made many years ago tend to mean you need to break compatibility. Just like UAC, resolution scaling will be an issue that becomes less painful in Windows over time. Right now it's not great, however.
Just most apps chose to ignore it, the developers took the 'anyone uses 96 dpi anyway' attitude and at the end of 90's most applications started to suck at 120 dpi.
I guess people got lazy, as you say.
No point in spending time on logical pixels if it makes almost no relevant difference...
If you're making a decision about whether to make a purchase, don't make it unless you're prepared to do it all at once. Stick to ~100 DPI until you can make a commitment to go all at once.
That has not been my experience here at all. There is a rather active, and sometimes vocal, Windows fan base around here. Misconceptions about the current state of desktop Linux are commonly seen as it seems most people around here only use either Mac or Windows.
I mostly use mac at work, mostly windows at home, and a bit of linux for servers, and my htpc (most of my casual browsing at home)... Each experience is fairly different. And they all have pluses and minuses. That said, more often than not, I prefer the Windows UI desktop/menu, but osx & unity app integration and linux/bash shell environment. I wish that Ubuntu/unity would integrate more of the menu/taskbar features found in windows. (And bring back natural scrolling checkbox)
OS X, years ago when the first retina MBP was released, did everything right. It was seamless from monitor to monitor, scaling done well.
Windows 10, now: OK, ish. Most applications scale badly with blurry text because it's just literally scaling the image afterwards. Newer applications are fine. The actual scaling isn't great - having a window half on one monitor and half on the other leads it to 'picking one' and looking weird on the other.
KDE, now: Pretty good. Correct scaling once you set it up. The autodetection can be dodgy, and the DPI scaling for text isn't linked to the rendering scaling for windows, for some reason. The GUI still only gives you a single scaling option for all monitors, but the autodetection can do different for each monitor, and environment variables can be set to solve it manually. The actual scaling is perfect for the vast majority of things. Things scale correctly and no blurriness. The only application that doesn't handle scaling is Unity3D, so everything is tiny (no fallback to raw image scaling).
In general, it's what you'd expect for interace stuff across the platforms - Linux does it right, but the interfaces around it are bad, Windows does it fine for new stuff, old stuff (which is most stuff) sucks, but the interfaces are OK for doing it, and OS X gets it all right.
Edit: Just to be clear, it's only the Unity3D editor that doesn't do scaling, the actual games work fine, as you'd expect they just get the full space and the game chooses how to render to it. To be fair to Unity about the editor, they support scaling on OS X, and the Linux build is still a beta. It is annoying though.
sudo apt install pavucontrol
It lets you configure some neat tricks. For example, you can setup an audio device that forwards to another computer running PulseAudio, an RTP receiver, and a few other similar protocols then set say, Spotify to output to that device. So if you have some network-enabled audio receiver somewhere in your house/office/whatever you can send audio from your Linux workstation to it.
You can of course also pass that audio through various filters/plugins to mess with the sound before it goes out to the remote receiver. For example, equalize it, noise removal, etc. PulseAudio supports LADSPA plugins so if you wanted to you could setup a little Raspberry Pi audio receiver at your front door and yell at solicitors in a robotic voice from your desktop. All with a bit of PulseAudio configuration fiddling =)
I remember trying it on whatever Windows computers were in the lab just to make sure I wasn't crazy and that this wasn't there all along, and sure enough, they kept the same volume no matter whether the headphones were plugged in or not.
One of the first PulseAudio victories I remember, at a time when I vaguely recall that it was a newcomer and people were really pissed at PulseAudio's bugs and recommending just straight ALSA instead.
Actually, this is especially true when both are 1080p, because laptop screens are never as big as desktop monitors, and we also tend to use them closer. I have this exact problem right now but I think I've just adjusted my eyes over time to squinting at 1080p at 14", or perhaps I turned on some display scaling and forgot about it.
> For example, you can have a window that straddles both monitors. What should the scaling be?
Intuitively, I feel like you should use the physical DPI of both screens to make sure that the window has the same physical dimensions on both. But that'd probably lead to weird scaling factors like 1.17 instead of nice round ones, and thus fuzzy scaling, so it probably couldn't quite work. I guess perhaps you'd just snap each display's DPI to the closest predefined value (eg. .25 increments which I think most systems use these days). Then you'd get a similar-sized part on both sides of the boundary.
But yeah, I think overall if you actually use physical DPI for scaling everything should work out close to nicely.
With "Displays have separate spaces" turned off (so windows can be present on more than one monitor at a time), it looks like windows take their DPI setting from whichever monitor the majority of the window is on-- with my current two-monitor setup, the DPI transition happens at the halfway point of a window, regardless of where the mouse is as I'm dragging.
Another approach would be to let the application render at higher DPI and the compositor would downsample the portion on the lower DPI display.
I even had to do this with Chrome . It's crazy how obscure this was when I was setting things up. Other apps, like Gimp, still look like shit because I can't find a way to do the same thing; their GUI just rends at a tiny scale and is difficult to use.
Actually Linux/Xorg generally support this out of the box, it is just the higher-level software that would need to make use of it. You can try it youself:
xrandr --output <output-name> --scale 2x2
the result should be the given monitor will appear to have twice the resolution, so if applications believe they are running on a high-DPI display, they will look fine on the external monitor as well.
However due to lack of support and awareness in desktops doing just this might leave you with an unsatisfactory configuration, e.g. part of the desktop erroneously shown on both monitors - you might need to use further xrandr commands to setup the regions that each monitor displays.
I use the same approach to solve this issue on a Windows 7 system I am using, it is just slightly more involved (I need to setup a custom resolution in the Nvidia control panel).
So quality will be there.
For normal/low-DPI screens instead, you'd scale everything down, so you'd lose some memory CPU power, but you'd still get the quality result.
I have a Macbook Pro with retina and stopped using linux simply because I couldn't get a good resolution on my laptop and monitors. And then when traveling (flights etc), ubuntu chewed through battery probably 3 to 4x as fast as OSX so I wasn't good for that either. As a result, I have been on OSX for a couple years now but would love to be back on ubuntu some day.
Autdetection would Be nice, but just being able to set the scaling option in one place and having it apply not only to my desktop but the login manager as well would be very useful.
Also, afaik there is no documentation on changing the scaling factor in the login manager, or at least not in the official docs.
I would not buy a standard resolution monitor at this point, so having simple support for it in Linux is very important to me.
I'm mostly replying at the point 1., as it's closed to what I do...
I know we should offer an UI for that, but waiting for that you can just workaround this.
Well, as said unity supports scaling, although it's not possible to scale toolkits per monitor.
However... There's actually a good workaround for this, that works fine for multiple monitors.
The idea is that you scale everything up to 2x / or your maximum scaling (including window contents), then you scale the non-HiDPI monitors down using xrandr --scale
For example, if you want to use normal resolution there, you just have to do something like:
xrandr --output <OUTPUT> --scale 2x2
In this way it will be scaled down, and everything will be readable and almost 1x1.
You can test this in normal resolution monitor as well, and you'll see things should be pretty good.
I should find some time to implement this directly inside UCC / USD, so that users will get this for free...
Notice that there's also a bug in X causing some mouse trapping, so you'd probably also need X to be patched as explained in this bug: https://pad.lv/1580123 (we'd like to include this upstream, but we're waiting for X upstream approval for that)
Including the ability to configure what gestures you want in a GUI interface!