Sebastian Krzyszkowiak @dos@librem.one

@Utgardloki@norden.social @bart @nitrokey (haven't read the updated version of the rest yet, but in the past other paragraphs weren't much better)

@Utgardloki@norden.social @bart @nitrokey

I'm afraid there is *no single factual information* in the following paragraph:

> PureOS also uses linux-libre. This will prevent the user from loading any proprietary firmware updates which just so happens to be almost all of them. The Librem 5 prevents the user from updating new firmware even with an alternative kernel which forces the user to use outdated and insecure firmware with known vulnerabilities.

@js@mstdn.io @letterus @agx BTW. The first iPhone had a screen with resolution even lower than that (320x480) and with comparable DPI.

@js@mstdn.io @letterus @agx How many FPS the compositor can draw is irrelevant. How would you distinguish between a wl_shm backed surface that legitimately updates ten times per second and a client that struggles to render and ends up with 10 FPS?

@js@mstdn.io @letterus @agx Reasonably sized text on 360x720 at 5" is hardly illegible. Just run any XWayland app where such scaling happens already and see for yourself.

Nevertheless, the compositor has no contextual knowledge on what's being displayed. Every client would have to implement that by themselves.

@carlosgonz@mastodon.social Because I still haven't finished producing music that we have prepared for it :P

@js@mstdn.io @letterus @agx Nope. It would be kinda like changing your screen's resolution to a lower value.

But at least one could already play stuff like Animatch or Neverball at full res on the phone with no glaring issues.

Today, while still not ready to become the default (almost!), SDL got bunch of those missing parts filled in - mostly by Ethan Lee. I've managed to find and fix some bugs this time as well. So, grab SDL 2.0.16, test and enjoy its refreshed Wayland backend while it's hot!

More info on the Wayland backend state (by Ethan): https://icculus.org/finger/flibitijibibo

Back in 2018, putting SDL's Wayland backend into shape was part of my first project done for @purism. Before that you couldn't really use it without expecting it to crash; it was outdated and lacked support for basic stuff like high DPI screens. Got it to work well enough for basic use-cases back then (even fixing some compositor bugs in the process), but it was still pretty bare bones with tons of features missing and the rest held by duct tape.

@patrick @letterus @agx That would be something for system integrators/distro maintainers to decide and apply though, no need to have upstream phoc guessing user intention and hardware performance.

@patrick @letterus @agx Such workaround would be opt-in anyway (unless a distro maintainer opts-in for you of course ;))

@letterus @agx Some people may strongly prefer snappiness over sharpness, so why not give them a choice? :)

@letterus @agx One more thing: a possible feature that could be added to phoc to make platforms like PinePhone faster even with software rendering is to render everything in smaller resolution and then upscale while displaying. This will of course make everything blurry or pixelated, but should make it very snappy even with underpowered hardware.

@letterus @agx Possibly. GTK4's GPU rendering isn't well optimized for mobile platforms, but it already got pretty usable in GTK 4.2. There will still be some work needed in order to keep slow GPU-rendered clients from making the whole compositor slow (like https://github.com/swaywm/wlroots/issues/3026), so there's no single silver bullet, but we'll get there eventually ;)

@letterus @agx Most of apps you're likely to run under phosh (and also phosh itself) is still based on GTK3, and GTK3 is purely software rendered - PinePhone's slow memory bandwidth is a huge bottleneck there. It is noticeably snappier on the Librem 5 since its RAM is significantly faster.

One thing to check is whether arm64 optimizations are enabled in pixman build used by your distro, there is a patch that's not merged upstream that can make it a bit faster overall.

@gamey @maximiliano No way, Megapixels reaches directly to V4L2 media request API, which is as low-level as it gets (maybe aside of reimplementing the drivers in user space)

@maximiliano > ASHPD

I *knew* that this acronym feels weirdly familiar, but I'm a bit ashamed that I didn't realize why until I read the README.

@chrichri I wish! I have no idea how to build it with F-Droid's build system (it's a cmake project that embeds gradle). It is in my own repo though: https://dosowisko.net/fdroid/repo/