Fractional scaling isn’t even a solved problem on MacOS or Windows as some people have said in this thread. Trying to cut a pixel in half or in quarters just doesn’t work it is a quanta (indivisible). And any solution to sort of round out the fuzziness using anti-aliasing is going to be imperfect and cause artifacts to show up.
I am happy with the fractional scaling under X11 on Plasma, Wayland on Gnome, and the xrandr trick in Pantheon on Elementary they have all looked good enough. But none of them are perfect and it’s unrealistic to think they ever will be.
Under X11, the solution given by cassidyjames from Elementary OS works surprisingly well. I haven’t encountered any screen tearing at all, which feels a little strange for X11, albeit not knowing if my screen refresh rate has been affected.
An issue with implementing this was that placing the script in /etc/profile.d/ wouldn’t work, as the script would be executed before loading the desktop, thus breaking. A workaround would be to create a .desktop entry in /etc/xdg/autostart/ that executes the script as if it were an application.
@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.
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.