Sebastian Krzyszkowiak @dos@librem.one

Change of the Guard #shotonlibrem5

@chrichri There's a "sharpen" module enabled in darktable, so I guess the former. The rest are: haze removal, exposure, graduated density, filmic rgb, shadows and highlights, local contrast and velvia.

@chrichri The left one is dcraw, which only does some pretty basic processing. The right one is darktable after enabling bunch of modules (just went through them quickly, haven't really touched any sliders :))

Same raw photo developed in two different ways. #shotonlibrem5

#shotonlibrem5

@dailylinuxmobile@fosstodon.org @kop316 @manjarolinux@botsin.space Distros should wait until relevant MRs are finished and merged, and then simply pull a new upstream Chatty version in with all its dependencies.

@kop316 @linmob @PINE64 @purism Manjaro does that often without making this explicit, and we then get plenty of invalid bug reports upstream :( There's usually a good reason why stuff that isn't merged yet isn't merged yet. It's fine to have a distro that includes experimental stuff around for those bravest, but I'd like to see Manjaro clearly state which things they pull in are still unfinished so users are well aware of what to expect.

Being used to working with no ready-made engine this gives me very ambivalent feelings:
1. Yaaay, I can do this without fully understanding how it works underneath! Prototyping is so quick!
2. Oh no, I don't fully understand how it works underneath! Debugging is so hard!

Not really participating in #stopwaitingforgodot jam, but took this opportunity to go back to my old "park revitalization" prototype in #GodotEngine and learn how to use viewports in order to add splitscreen multiplayer :) #gamedev #indiedev #gamejam

@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.