Quackdoc

This is not traditional VRR how we think of it. VRR how we think of it is changing the "frame rate" of the monitor to better suit the frame pacing of the received frames, this is not whats happening here. This is how things like freesync works. It takes your device framerate, say 60fps, and slows it down to better match the frame pacing of the content, say 48fps. Now the monitor doesn't physically change states or anything, it just allows flexible updating to match the frame pacing.

You don;t get this with this adaptive refresh rate method

Here you are effectively getting a noop every refresh cycle it doesn't need. It's still good, but not as good as what most people think of as VRR (Freesync/vesa adaptivesync, gsync etc.). You are limited to the steps your display can output. For this to be useful you require a high refreshrate display like 120hz because each application needs to align with a frame refresh.

IE. say you have a 24fps video, the display won't change it's frame pacing, but rather you get a noop every 4 frames and a refresh, (24 * 5). Now assume you have a 90hz display, 24fps has no solid divisor in 90fps, so you have to either wait for sync, or get tearing. The first one leads to judder (which can probably be mitigated using offset sync waits?) the second one is well, tearing.

says "true variable refresh rate" support, is not true variable refresh rate support...

Well thats click bait and a half

I'll try it out for sure. Last time what tried river it was fairly basic. So if it's come a long way that's quite exciting.

Click baity title aside. This is actually pretty much pretty true. What the vast majority of people want when they're writing their own composers seems to be specifically the custom window management aspects.

And it is true that even with something like Wlroots or a Smithay, it is a lot of works right your own composer and have it be "competitive". And he is right. There are a lot of composers out there that are just not usable for anything more than the basics. And there are tons more which are just toys that have been abandoned that aren't really usable. That being said we saw a lot of that with window managers, But yes, writing a compositor is a lot more then writing a window manager.

I personally don't use hyperland, but I can see the point he's trying to make, and I think it's a rather good point. I think if we had more compositors that focused on having a scriptable window management, then that would be for the better.

I don't really see this as toxic either. I mean, if it's toxic to call a composite or trash in one way or another, then I would argue that 90% of the Linux community is far more toxic than he is. It's just a matter of truth. Wayland is a big complicated thing with a lot of protocols and some of it is poorly documented.

And of course, this is him shilling his own composter. It's his own composter, and this is the blog about him making his own composter. Of course he's gonna put a post on it, shilling his own compositor.

That being said, As I said earlier, I would like to see a more scriptable take for things like window management. I don't think hyprland has to be unique in this aspect, but as it stands, it most definitely is.

pardon my weird language, its hard to use STT.

this is a massive issue even on my tablet too, but many toolkits have this issue

None of them are really great, Im hoping cosmic in the future will be, as it stands.

"Touch primary" DEs (IE. Phone, tablet with no keyboard or detachable etc.) I think are the way to go.

Plasma mobile is king 100% nothing gets remotely close right now.

Phosh I found far too buggy, and the apps are far too limiting. Things like squeekboard for instance don't scale properly, I had issues running chromium browsers on it too.

Ubuntu touch uses lomiri which im sure is great, I havent had luck running lomiri on any "common generic PC" linux distros. I did try getting it running on arch but found too many issues.

swmo is nice in theory, but it's missing a lot of the ergonomics.

Plasma mobile is missing a lot. It has some not great design choices I find, however it by far has the best app ecosystem in terms of actual app quality, as well as actually working fine on tablets and phones alike.

For touch secondary experiences I find KDE and Gnome to be just about as you would expect, Both are fine and mostly navigatable on touch only stuff, I would say KDE is often a lot better in terms of responsiveness, Gnome I can find bugs out as @that_[email protected] said. That being said, In portait mode, KDE is down right terrible some times as many KDE desktop apps have zero support for portrait aspect ratios, and you are relying on scaling being "low" enough that the app can fit fine anyways.

as for some stuff you can look forwards to in the future, We are starting to see stuff like catacomb which is designed for phones. I also had some actually great luck with Niri but it's mostly just buggy, and you still need something to manually launch keyboards.

In terms of applications, I have absurdly high hopes for cosmic apps. Each one I have used this far has a "tiling first" design policy, which translates pretty much 1:1 with being flexible for a phone it turns out, While cosmic apps have really poor touch support, if you install them and pretend your mouse is a finger, you will find that each one is almost perfect in a phone form factor.

EDIT: I wish I could say linux touch was in a good spot but realistically it's not. I personally recommend just installing something like Bliss or using waydroid as the primary experience. I am very active in the bliss community because in large part tablets and touch support. Android is still far better then linux is in general, even if a little less flexible, you can have a fully foss install like what I have personally.

ah my bad, I had thought I made it clear, I mean the greater android x86, Blisslabs projects like Bliss OS and waydroid, other projects like WSL2, tho that is dead... some chromeOS stuff too.

It's less secure, but the host<->guest seperation is there.

what does Ubuntu touch have to do with this? I explicitly refered to the greater ax86 ecosystem.

It's still really basic, but has loads of potential, Unforunately it has a hard requirement on GTK, otherwise there are a few things that would have been nice for greater AX86 in general, for instance they have mediacodec->vaapi support, something ax86 has... struggled with in the past. but we can't use it since we can't use gtk.

it's worth noting that no actual security problems have been presented that haven't been dealt with, Sandboxing is available on any distro assuming the tools are made availible. Waydroid supports both apparmor and selinux, please report any security issues and tag the maintainers when doing so.

EDIT: you do need to set apparmor into enforce mode manually though.

correct on both accounts.