I’ve used a 1440p 27” display and found no issues except in the HDR experience which is godawful
I’m too lazy to do the math or look up the PPI compared to the Framework-I think the framework laptop is more dense given it’s high res and smaller size
The windows laptop I use is strictly 1080p and fine as well
You might want to check out the Brunch project.
Thanks! I’ll try that next
Edit- unfortunately brunch + chromeos 93 works this same way - it requires a password not a pin to login.
Scaling is one of these things that, like sleep/hibernate (Linux deep sleep), ought to be a solved problem by now.
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
xrandr --newmode "2820x1880_60.00" 453.75 2820 3044 3352 3876 1880 1883 1893 1948 -hsync +vsync
xrandr --addmode eDP-1 "2820x1880_60.00"
I’ve tried both the cvt and gtf output of 3000 2000 60 but both produced the same result.
(Non-integer) scaling is actually really hard. You basically have only three options:
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.
- You switch to another user on the same device.
- After 48 hours for personal Chromebooks.
- After 12 hours for managed Chromebooks.
Set up & sign in with fingerprint on your Chromebook - Chromebook Help.
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.
Interesting, I haven’t ever enabled PIN since I use Smart Unlock, but I might have to try it on a couple now.
One post I found suggested disabling Guest browsing under Settings> Security> Manage other people might enable PIN unlock on boot.
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).
On my linux desktop, for high dpi, i have this is my ~/.Xresources :
Xft.dpi: 192
If you change this, you just apply this command to add the resources:
$ xrdb ~/.Xresources
Does it work for the framework laptop? I have not received mine yet.
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.