@Julian_Joaquin I could never get that solution to work properly. It works just fine whenever I do after boot and login and then setting it manually. However, as soon as I add it to my .xprofile and having it run on startup completely breaks the display where there’s massive flickering, each line on the display is misaligned, the top of the display are repeated on the bottom, image sliding left and right rapidly, etc and no matter what, there’s no way to fix it other than entering another tty, commenting out the two lines, and then rebooting.
I’m running on Solus Linux if that explains anything at all.
I’ve settled with slightly modifying my scaling the output solution to adding a new mode with the resolution of 2820x1880
(Non-integer) scaling is actually really hard. You basically have only three options:
Resize everything post-raster. Easily doable in the widget toolkit or even the window manager, but looks ugly. This is what your web browser does.
Actually provide raster graphics (and in some cases, raster programming) for a reasonable set of resolutions. Hopefully I don’t need to explain why this is a huge amount of work.
Use vector graphics for everything. Requires code changes to your application, and requires those assets to exist. While that’s more common these days, it’s not guaranteed. Also, graphics designed to align to pixel boundaries will look bad at non-integer scaling factors. This is why most text looks good at any resolution; most fonts have been vector for a long time, and a lot of effort has been expended making them look good at any size over the course of decades.
You can, of course, mix and match these, using different approaches for different UI elements, but ultimately the only solution is “vector everything” and either (a) high enough resolution that you’re either never trying to use fractional pixels for anything, or don’t notice the scaling artifacts when things miss pixel boundaries, and/or (b) kerning for graphics as well as text.
Computer Science major here, so… I get it, but aren’t most desktop UI elements CSS-based (making adaptive scaling much easier), or is that only theming that’s done that way, or am I just a young padawan with much to learn?
It depends. Qt widgets aren’t, and that’s still a good chunk of stuff I use. GTK I think sort-of is. I have no idea what Windows uses.
Also, that doesn’t solve the problem anyway when your CSS is designed in pixels; you end up with what are supposed to be nice, crisp lines some integer number of pixels thick (usually 1px) turned into blurry messes. And none of this does anything for icons. Even if those are vector, if they’ve been designed with lines neatly aligned to a pixel grid, non-integer scaling throws that all off and you’re back to blurry messes.
I honestly don’t see that non-integer scaling will ever be as good as integer scaling, period. It would be a lot better if SVG gained kerning.
(BTW, also a CS major, and been writing Qt applications for 10+ years. If you’ve ever used the Oxygen widget style on KDE, I wrote some of that.)
I just tested PIN unlock successfully on Brunch (v93) and ChromeOS (v92) that I installed via the brunch-toolkit. I had to remove a pnvm module from /lib/firmware to get the wireless working (and BT is still not happy), but after going to Settings and searching PIN and enabling the Password/PIN (default is password only), I was able to lock and get prompted for the PIN and unlocked by entering it.
Now reboot It will ask you for your account password. PIN unlock is handy but if I have to reboot at work then that means I have to lug my password and yubikey with me which I don’t want to do.
This is actually part of Chrome’s security model, the same “reboot requires password” policy applies to the fingerprint reader. Your data is encrypted locally on the Chromebook with secret that is partially comprised of your password, the PIN doesn’t satisfy the role of your password in this case. I’ve found that with a password of 12-16 characters I was able to Not sure why your Yubikey comes into the equation unless your account is set up to force 2FA even for ChromeOS logins (haven’t actually seen this in practice yet).
When you need to use your password
You must use your password for the following cases:
Your Chromebook restarted.
Your fingerprint sensor doesn’t recognize your fingerprint after a few unsuccessful attempts.
If it is that big of a hassle, enable Smart Unlock and pair your Chromebook with a phone with a fingerprint reader or face unlock and you can just touch your phone (or look at it) to unlock it and within seconds allow you to hit Enter on the Chromebook (or touching the display picture on a touchscreen) to log in. I use this on my “real” Chromebooks and I’m excited to test it out under Brunch as soon as I get the AX210 Bluetooth issues sorted (hopefully without needing to wait for the next LTS kernel for ChromeOS).
I had the same exact issue when I placed the script in .xprofile. For lack of my own understanding, the script executes at a specific time that causes the screen to just glitch out like that. I found that running the script at the time when other applications autostart seems to work. As I mentioned previously, a .desktop entry under /etc/xdg/autostart/ pointing to your script should do the trick.
All of my Chromebooks let me login/unlock with a PIN after Shut Down, Reboot, Upgrade, etc. That’s the behavior I wanted on my Framework but could not duplicate. I use Yubikey for 2fa (google implemented this well on multiple products) and I do not use fingerprint biometrics.
I can’t remember where I found this suggestion (reddit?), but on Pop OS I’ve been happy running at native resolution + Large Text (from the accessibility options). I have the accessibility menu always showing in the toolbar and I just disable Large Text when it’s docked (dual 27" QHD).
Long-time follow-up to this issue, I’ve stumbled into this exact problem by accident and was able to reproduce it. Scared the hell out of me and my colleagues when we saw the screen flicker like that.
It seems that whenever a new mode is added to the output display for the first time since boot the screen, for lack of better terms, glitches out erratically. This mainly occurs whenever xrandr --addmode or --mode is executed for the first time.
This is reproducible by executing the two aforementioned lines in either .xprofile, .xsessionrc, or in a .desktop entry under /etc/xdg/autostart.
I was able to find a work around by changing the mode at least twice before using our custom mode. Something like this works:
xrandr --output eDP-1 --mode 3000x2000_60.00
xrandr --output eDP-1 --mode 2256x1504 # It doesn't matter what mode here
xrandr --output eDP-1 --mode 3000x2000_60.00
I don’t have the slightest clue why this works, it just does. And quite frankly, I don’t understand X11 enough to sift through the documentation. It would be great if someone could explain this behaviour.
Working on Fedora 35 with Gnome 41(Wayland), inspired by people starting with 100% and working with text scaling or accessibility options, I went from the opposite direction starting at 200% and scaling text down and found a sweet spot for myself at around 90%. This works a lot better than I thought it would and applies across all applications.
Not perfect, but better than default 200% or the inconsistencies with fractional scaling to my eyes.
linux on hidpi isn’t still the best experience, it would be good if it defaulted to something “sane” allowing people to then do tweaks, but maybe i’m not sane either. anyway, on gnome 40 + wayland on my 2014 13" retina macbook pro (2560x1600) i use 1.5x display scaling and 1.25x font scaling. some apps (e.g. telegram) require further tweaking.
to be honest, this sucks and i wish i didn’t have to do any of this, but hey, at least i’m not editing text files so there’s that.
edit: to be clear, hidpi displays aren’t the problem, software is. asking for a lower res screen just because hidpi kind of sucks makes no sense.
For those trying to get a custom screen resolution working on ubuntu 21.04, the xrandr instructions won’t work. Instead you can follow the instructions here.
Basically:
Edit GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub file to have video=eDP-1:1920x1280@60 (eg. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep video=eDP-1:1920x1280@60")
Run sudo update-grub
Restart
I also used the Tweaks app to adjust the scaling factor on fonts to 1.3.
Edit: After playing around with this a bit more, I found that 1620x1080 is the best resolution for my situation. I am using a secondary ultrawide with a 3440x1440 resolution and both monitors look good without any scaling.
When originally considering purchasing the Framework, the HiDPI display was one of the only things that made me wary. I’d had a couple of bad experiences installing Linux on others’ HiDPI computers in the past (5+ years ago), and didn’t exactly want to delve into the world of configuring each and every application again.
However, I ended up buying the machine for the plethora of other advantages, shirking my uneasiness with HiDPI displays temporarily. This turned out to be a good decision: I think I’ve got it all sorted now.
For other users that might like the same scaling preferences as I, I eventually settled on:
Setting Xft.dpi: 208.57 in ~/.Xresources. This fractional value obviously isn’t evaluated that way, and ends up at the close-to-correct 201. This setting alone scales GTK3 applications (Firefox and PavuControl, which I use regularly) very nicely.
To get i3status looking right, I changed its font by editing ~/.config/i3/config and changing the font line to:
font pango:monospace 10
Now my terminal, st, doesn’t adhere to differing DPIs. I eventually ended up setting the font in config.h to be:
it looks like GNOME is dominant in this thread. But, don’t forget KDE also support HiDPI as well and it will be more popular in 2022 thanks to the Valve.
I just read an interesting article about dpi in X11, Qt, GTK, Wayland, etc. Not sure how current the information in it truly is, but it does explain the nature of the problem, especially with individual applications not caring about system DPI information…
I run Wayland Gnome on Ubuntu 21.10 and simply enable large text in the Accessibility control panel and the UI is perfect. Apps respect it across the board. Nothing blurry, nothing too small, terminal apps look wonderful, brave renders perfecty, video is sharp af. I don’t understand the need to fractional scale the linux ui when you can simply up the font size(s). I am an old fart and can see everything with this setup perfectly, and it’s way sharper than windows 11 at 150% on the same display. /shrugs.