The point that some people have tried to make is that HiDPI isn’t even necessarily the enemy here rather fractional scaling is. 2256 x 1504 is too low of a resolution for 2x scaling and too high of a resolution for 1x scaling that’s just a fact. I’m sure that there is a reason why they went with this resolution but it’s definitely not ideal. Bear in mind that in 2020 because of COVID it was really hard to source screens for a while so that could have swayed their decision one way or the other. If you want a LoDPI display for better battery life then sure hopefully Framework will source a 1920x1280 screen for you but if you want a HiDPI display that just works out of the box then instead hope that they source a 3000x2000 screen that will look good at a 2x scale.
All of that said, Gnome running on Wayland at 1.5 x scaling on the Framework as is isn’t so bad that you notice anything. It’s always interesting to me to see what the different dealbreakers are for people. For me any blur caused by fractional scaling which I can’t even notice when I’m using the Framework didn’t come close to tipping the scales on whether I should get this laptop or not.
^ Yeah - I don’t ever want to go back to LoDPI (though if some people prefer that it’d be cool to have the option). I love the screen on the Framework just wish the software handled it better (not a Framework problem).
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
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.
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).
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.