[nhaehnle]

> 1. HEADLINE: A way to have different scaling for external monitors hooked up to my HiDPI laptop.

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!

[planteen]

Widows 10 handles different scaling (zoom) between monitors far better than any Linux distro I have used. A window keeps the zoom of where it came from until it is entirely on the new monitor. Works pretty well.

[skrowl]

While I get that it's uncool to like Windows on HN, I really like Windows 10. With WSL, all of the CLI tools I need for development are here along with better hardware support (including suspend / resume, high DPI monitor support, latest GPU drivers / etc).

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.

[problems]

Windows isn't the best at multi-DPI in general though either. Only recently did Firefox on Windows get multi-DPI support - not sure if Chrome does yet because I gave up on it and went to dual 4K because the scaling was easier. If you want to see really good multi-DPI support, OSX is really good at it with most apps supporting it out of the box.

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.

[calferreira]

I think you're confusing Windows DPI scaling availability vs lack of support from the apps you use.

It's not windows fault the apps don't take advantage of DPI. You can also disable dpi scaling for individual apps.

[problems]

You're right, but even many builtin Microsoft apps - while they supported DPI scaling - did not support multi-DPI switching and rather than scaling properly just scaled pixels and looked blurry.

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.

[hackmiester]

I would much prefer the Windows behavior to what I see on Linux. Right now, if I open an app that doesn't support high DPI, it is just unusable because it is so tiny.

[rayiner]

It's worth considering whether there is some flaw with windows multi dpi scaling such that apps don't use it. Firefox and Chrome have scaled properly on Mac for years now, while even Windows 10 ships with first party apps that don't scale right. (E.g. device manager.)

[AndrewGaspar]

For sure that this has been an issue in the past with Windows. UWP helps make muli-DPI work by default in new applications.

[Latty]

I mean, you say that, but on KDE, for example, every application except one on my system works with DPI scaling (the odd one out is Unity3D) - that's because at the QT level DPI scaling is built-in, so the toolkit supports it and the applications get it for free. Clearly this wasn't the case for the older Windows UI stuff, where they are literally just scaling the image of the window up (which means horrible looking text).

[vetinari]

Actually, the really old windows stuff did support scaling - the 'Large fonts (120%)' option was there almost forever. I remember that original Delphi, circa 1995, supported it.

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.

[freeone3000]

Anything running its own renderer doesn't get to benefit from component scaling since they don't use components.

[lighthazard]

The problem isn't just scaling between two different resolutions, it's the inconsistencies (yes, apps don't take advantage but that's not the only issue). For example, if I want 200% 4k (my monitor) and 100% 1080p (my 2 side monitors), I have to choose between ultra-tiny text on my 4k with regular text or blurry text on my 1080ps.

http://i.imgur.com/o1S8ZUt.png

[tbyehl]

Is that Windows 10? On my Windows 10 Ent desktop I'm able to set the scale factor of each display independently.

http://imgur.com/a/5378F

[nailer]

This month's Windows update fixes DPI scaling for old toolkits.

[planteen]

Yes, it's true that there are issues. It seems like most Microsoft apps handle multi-DPI well. By comparison, on Fedora 25 (the latest release), the only program I have found that handles multi-DPI is Terminal. Firefox doesn't do it.

[problems]

Yeah, Windows support is better than Linux for it, but it's still pretty iffy. While IE and a few other things do, even stuff like Windows Explorer and OneNote doesn't handle multi-DPI well or even just runtime DPI changes in general, I'll RDP my box from a 100 DPI system and have my session screwed up when I come back to my system.

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.

[Zeklandia]

Chrome hast had DPI scaling since 2015 on Windows. I remember having to report lots of initial bugs. Now it works fine.

[problems]

DPI scaling yes, but not multi-DPI, when dragging from a 100 DPI monitor to a 300 DPI one text should remain sharp and not blurred by scaling pixels. Or even vice versa.

[8xde0wcNwpslOw]

>While I get that it's uncool to like Windows on HN

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.

[tracker1]

Agreed, while I see some MS/Windows hate... some of it technical, some political, and a mix of founded/fud... There's been a fair amount of counter to that.

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)

[freeone3000]

Microsoft integrated Ubuntu instead.

[Latty]

My experience (currently running two 27" panels at 3840x2160 and one 27" panel at 2560x1440 in KDE for most stuff, Windows for gaming, and previously had one of the first edition retina MBPs with external non-retina displays):

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.

[cookiecaper]

I use this on Windows 10: http://windows10_dpi_blurry_fix.xpexplorer.com/ and it works fine. If you have blurry text, disable DPI scaling in that app (right-click -> Properties -> Compatibility -> Disable DPI scaling) and this will take over and make it usable. There are a couple of applications that act wrong no matter what (Battle.net for example), but most of the time this fixes it well enough.

[Latty]

I only use Windows 10 for gaming, so fortunately I don't really need to worry. Useful for those who use Windows all the time, though.

[j_s]

Windows also gets my vote when it comes to the per-app volume mixer controls which have been awesome since Windows Vista.

https://blogs.msdn.microsoft.com/larryosterman/2005/12/15/vo...

[riskable]

PulseAudio provides this feature and actually provides more features and functionality than Windows. Ubuntu's default mixer isn't the greatest so I recommend this instead:

    sudo apt install pavucontrol

You can then find it in the application menu labeled, "PulseAudio Volume Control". It lets you set the volume for individual applications (and with Chrome, individual tabs!) and also pick which output/input device will be used.

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 =)

[drostie]

I still remember the first time I was in a computer lab and I leaned too far away from my computer and my headphones that were blaring music popped out... and the whole room WASN'T subjected to the same loud music. And I opened up the Kubuntu audio controls and plugged in my headphones and the volume slider suddenly jumped up, then I unplugged again and it muted again. "Woah."

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.

[icebraining]

+1, PA + pavucontrol are very flexible. You don't even need weird protocols to send your audio to another computer, I just used its tunnel module (enable it in the receiver, then configure its IP on the sender) to send my browser's audio output to my home server, which has a decent stereo attached. The latency is quite good too, the delay even over wifi is barely noticeable.

[JetSpiegel]

There's also pulseaudio-dlna[0]. It works as advertised.

[0] https://github.com/masmu/pulseaudio-dlna

[j_s]

Thanks for the heads-up! This is one thing I miss mightily on my Mac.

[randkyp]

This feature comes by default with PulseAudio, maybe Ubuntu doesn't expose it well enough in their audio settings. I think Gnome Settings has it, KDE definitely does.

[vetinari]

Pulse Audio solves the same thing for Linux.

[zerocrates]

I get correct auto scaling-switching like this on Gnome 3 with Wayland, but only for a subset of programs (basically those that are fairly vanilla GTK+3), and at the cost of weird bugs with Wayland and program support thereof that still crop up fairly regularly.

[godelski]

I've always resorted to xrander and can get the screen looking pretty good. Though I really think something like this should just work.

[benwaffle]

Weston does multi-DPI really well. When you drag a window between monitors, the half on the HiDPI monitor is scaled and the half on the LoDPI monitor is unscaled. So it looks perfect without windows growing or shrinking when you move them to another monitor like GNOME on wayland.

[0x6c6f6c]

I'd love to read more about how this was done, if you have a link perhaps.

[pvinis]

macOS handles that edge case. It just displays the window in only one screen. The one with the biggest area of the window shown. There is no need to be held back by cases like this.

[gcr]

If you zoom in, you can sort of force parts of one monitor to be shown on the other monitor. You can see how everything's upscaled/downscaled from there.

[ibrahima]

> 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.

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.

[akx]

FWIW, macOS changes a window's DPI mode when the cursor that is moving the window passes over from to one screen to another. Just tried that out. :D

[JonathonW]

That's what happens when "Displays have separate spaces" turned on. (With that setting on, windows are only present on one monitor at a time, and, when dragging a window, that transition happens when the mouse cursor moves between displays.)

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.

[randallsquared]

Leaving aside the implementation difficulty, the answer to "what should the scaling be" seems obvious? Use the monitor scaling for the part shown on that monitor. The switch should happen on a monitor level, not on a window level.

[vetinari]

The painting happens on window level, that's why it handled there. Application paints the window whenever it receives event "paint me" for it and it cannot paint different portions of a window at different DPI - from the applications POV, it is a single canvas. Another thing is, that the window resize and dpi change are separate events, so you cannot really call it twice in a row with different DPI and expect the app not getting confused.

Another approach would be to let the application render at higher DPI and the compositor would downsample the portion on the lower DPI display.

[gcr]

OSX handles this by upsampling/downsampling the parts of windows that are drawn on the other screen.

[willvarfar]

This isn't just external monitors! MBP with "retina" screens are also unusable for Ubuntu :(