The has properly detected chargers using BC1.2, Type-C and PD signaling for years now, but it struggled with sources that couldn't actually provide the advertised current (which could happen with buggy chargers/docks, broken or poorly made cables etc.). It would attempt to draw power, drop below voltage threshold, disconnect, and then do it all again once the voltage went back up to a good level in an endless loop. Good news: this behavior is about to be gone ๐Ÿ˜

NXP has published their 6.18-based kernel tree and while browsing it I have noticed that they apparently found a way to support custom horizontal strides with mxsfb (by using some undocumented leftover IP for EPDC panels that imx8mq doesn't support). This may be interesting as it potentially opens a way to use linear PE in with the 's internal screen, so the GPU could render directly to the scanout surface without having to resolve its tiled buffer to linear afterwards.

It's funny how this phone keeps feeling faster as it gets older.

Looks like GTK is starting to get its renderer inefficiencies sorted out, as updating Flatpak runtimes has made Tuba smoother than ever ๐Ÿ˜„

I couldn't make any sense out of these logs so I yielded to a developer higher in seniority who is now carefully analyzing the issue.

Call me a Time Lord, cause lately whenever I dig into something in the kernel I end up fixing clocks being all over the place ๐Ÿ• ๐Ÿ•œ ๐Ÿ•ข ๐Ÿ•–

So I finally understand why 4-lane MIPI CSI-2 doesn't work with the 's big cam.

Turns out it's not going to work - but I now at least understand why ๐Ÿ˜‚

(this limits streaming at full res to about 16 FPS 10-bit and 20 FPS 8-bit instead of the sensor's 30 FPS, but you won't really be able to process it at this speed anyway so it's not a big loss; lower res can still work with higher framerates; with the current driver up to 120 FPS but it could go even higher)

I'm happy to report that I've successfully managed to turn my WTFs and OMGs into working touch PointerEvents, and even got to spot and fix some minor bugs on the way. Once I manage to go through the submission and review process as well it should considerably improve the handling of touchscreens on websites in GNOME Web.

Show thread

So PureOS 11 (crimson) on Librem 5 has become daily driveable, as evidenced by me upgrading the system of my daily driver to it and not having much to complain about. From oldoldstable to oldstable - heading towards modernity one step at a time ๐Ÿ˜‚

FWIW, don't mind the stripes on the bottom or right edge on some of these photos. It was just me poorly rotating and noticing too late ๐Ÿ˜›

Show thread

And the great thing is that you can take your past photos and re-develop them again with whatever code you have available now. No need to be picky, it's fast enough to just go through them all.

Show thread

There are still some crucial things missing, such as profiled denoising or proper highlight recovery, but since the performance budget for a still photo is much higher than for a 30 FPS video, there's plenty of room to add more stuff - and most of these 2 seconds are spent reading DNG and saving JPG anyway.

Show thread

Unlike Glowup, which takes about 30 seconds and lots of RAM to process, this is still just as fast - the photo is developed within 2 seconds from shooting.

Show thread

To pass some time in a train yesterday, I've copy'n'pasted my recent GPU ISP into Millipixels' postprocessing code to see how it compares with what was already there. Before/after:

By the way, with just a one-line change (commenting out mp4mux/filesink, uncommenting flvmux/rtmpsink and adjusting the URL) you can stream online rather than to a local file ๐Ÿ˜Ž

(fwiw this screenshot is from before autofocus, white balance and most of image processing stuff was there)

Show thread

I have published the snippet of code that implements a GPU-based ISP with bunch of corrections and encodes video in real time on the Librem 5. Feel free to take parts of it and use in your apps and frameworks... or record your cats ๐Ÿ˜ผ

source.puri.sm/-/snippets/1223

Show more
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml