The problem with some non-HiDPI aware applications (is that they're very small)

July 22, 2018

I tweeted:

One problem with a HiDPI monitor is the occasional application that absolutely doesn't upscale. For example, the Java that I need to access the KVM-over-IP console of this locked up NFS fileserver.

Our current fileservers are old enough Supermicro machines that their onboard IPMIs only support KVM-over-IP through a Java Web Start application. Today, I needed to use it from home, and I was only a little bit surprised when the resulting virtual console was, well, tiny on my new home HiDPI display.

(I was a bit surprised at how visually tiny it came out, but then I keep being surprised at how small 'half their normal size' has actually been on my new display. And the virtual console wasn't really a giant window to start with on my non-HiDPI work displays, at least in the basic 'text' VGA mode.)

Some modern applications are HiDPI aware, and others at least provide settings for the fonts and font sizes that they use. It's possible that Supermicro's Java program has settings for this (I was in a hurry so I didn't look, although here's Arch's Java information), but I have a sneaking suspicion that it doesn't. For applications like this, the end result is tiny, hard to read or use application windows, either permanently or until I can find how to adjust the application (which may not be worth it if I only use the app occasionally). Since I'm likely to run into this periodically, I should work out a decent general solution to it someday.

In the bright future of Wayland, it will presumably be theoretically possible to have your Wayland compositor automatically scale windows according to your desires, so old non-HiDPI X applications being run in some sort of compatibility mode can just be zoomed up however much you want (since all of this is OpenGL based, and my understanding is that OpenGL has good support for that kind of thing). In the current reality of X Windows (at least, it's my current reality and hopefully future reality), I need a different solution. To date, I know of two.

The easiest option and one that's probably already available, even in basic X environments like mine, is a screen magnifier such as KMag. KMag has the moderate inconvenience that it can't be told to magnify a given (X) window, although you can awkwardly set it to magnify an area of the screen instead of wherever your mouse cursor is. Since I already have KMag installed, this is probably my default choice.

Other than that, the Arch wiki has a section on unsupported apps which led me to run_scaled, a shell script that uses xpra to relatively transparently run programs with forced scaling. Run_scaled is a pretty big hammer and it has some drawbacks, partly because your program is running in a separate X server. I could probably make it work for Java Web Start stuff with some effort, but it's more awkward than just resorting to KMag; I'd need to get my browser to run my javaws cover script instead of the real javaws.

(Fedora is already using its alternatives system to pick who gets to be /usr/bin/javaws, so in theory I could just set my script up as that and then pass things off to the IcedTea version.)

(I initially thought of playing tricks with Xephyr plus xrandr for scaling the 'display' inside Xephyr, but the more I think about it the less sense that approach makes. I think I'd be better off using run_scaled.)

Written on 22 July 2018.
« How we're handling NFS exports for our ZFS on Linux systems
The irritatingly many executable formats of Windows »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 22 03:01:52 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.