Sebastian Krzyszkowiak @dos@librem.one

@maxleibman This is actually unironically one of the rare use cases where it does make some sense, especially when you keep waiting for your PDF reader to search through thousands pages of reference manual just to find out that you need to come up with yet another synonym as a search phrase.

Well, at least theoretically. Most AI integrations I've seen so far looked like they were put together with sticks and mud, probably written by that AI itself 😂

@pavel Doing it via GStreamer makes buffer queue management easier, but of course it can be done either way. With SDL you get GL context already, so you just do it the way I showed you some time ago. You skip the context creation part and you're done.

@pavel Of course. The driver doesn't handle that right now, but it's just some straightforward plumbing. Good entry level task.

@pavel There's plenty of apps that embed GStreamer's output to look at, and you can even skip it completely and simply import the V4L buffer into SDL's GL context and don't create your own one at all. This is just gluing things together at this point.

@pavel @datenwolf @dcz @martijnbraam @NekoCWD By the way, the actual framerate limits (verified to work) are 120 FPS @ 1052x780, 60 FPS at 2104x1560 and 20 FPS (8-bit) or 15 FPS (10-bit) at 4208x3120. Full res could go up to 30 FPS, but only once we get 4 lane configuration to work.

I can even produce 120 FPS video, although it doesn't skip frames only once downscaled to 127x93 right now 😂

8-bit vs 10-bit #librem5 #shotonlibrem5

@pavel @datenwolf @dcz @martijnbraam @NekoCWD I'm just using waylandsink at this point, but it could be passed anywhere else. That's literally the least interesting part of the thing 😂

@lord @datenwolf @dcz @martijnbraam @NekoCWD @pavel Specialized hardware. Phones usually don't have to do image processing nor video encoding on CPU or GPU at all, they have hardware ISP and encoders. L5 does not.

On other hardware there's also a matter of whether there's driver and software support for it, so Android may be able to use that, but pmOS - not necessarily.

@pavel @datenwolf @dcz @martijnbraam @NekoCWD I'd expect moving binning to a separate pre-pass to make it faster, we'll see.
Also, my stats are center-weighted. Millipixels annoyed me with its reluctance to overexpose the sky 😄

@pavel @datenwolf @dcz @martijnbraam @NekoCWD It's 526x390, but properly binned (each channel's sample consists of 4 raw pixels averaged), which reduces noise. The shader got heavy though, does only ~35 FPS at this res - but there should be room for optimization. I've been more concerned with its correctness than performance so far.

Stats counting on the CPU with NEON is fast enough for full frame with some subsampling.

I'm giving it some finishing touches and will then publish it of course 😁

Note that the picture is shifted down-left a bit because the driver was misconfiguring the output parameters to include dummy pixels - fixed that too, along with several out-of-range clocks 👻

I think both left- and right-masked PDAF pixels are accessible in 1:2 mode with binning disabled, though I haven't done the math yet to be 100% sure. Enabling/disabling it on demand will be somewhat clunky though. I can also read calibration data from OTP, but AFAIK there are no kernel APIs to expose that to userspace :(
https://source.puri.sm/Librem5/linux/-/issues/411#note_285719

BTW. Recording 30 minutes with screen off ate about 15% of battery, so 3 hours of recording should be possible.

@pavel @datenwolf @dcz @martijnbraam @NekoCWD I played with it over the last days and I already have 526x390 30 FPS encoding with live viewfinder, perfectly synced audio, color correction, lens shading correction, tone mapping, AWB and AE - consuming about 40% CPU. Still needs chromatic shading correction and AF, and I started experimenting with enabling PDAF.

I can also make the sensor output 60 FPS and RAW10. Patches incoming ;) Still only 2 MIPI lanes though, so no 13MP 30FPS yet.

@asegPL Żeby jakikolwiek system się dało tak zainstalować przy EFI, musiałby siedzieć na FAT32.

@1peter10 @agx @postmarketOS @yoasif @phosh I mean, I'm not exactly a social butterfly and we had a pandemic meanwhile, but "ooh it doesn't need swipes, I hate those on my phone" was still something I heard surprising number of times when I showed my phone to people in those early days 😂 I honestly didn't expect these reactions.

@1peter10 @agx @postmarketOS @yoasif @phosh I've seen many people praise the early Phosh interface for everything being an obvious tap away and that there's no need for performing swipes to use it. At the same time lots of people (perhaps more) complained that they couldn't swipe 🫩
Swipes solve some issues and we're in much better place now than we were without them, but I think it may be worth contemplating on how to bring back the possibility of swipeless operation, even if behind an a11y flag

@cas @ireneista When it comes to L5, touchscreen in u-boot is just a motivated hacker away. Touch and panel are very easy to drive, and there's a working display controller driver for imx8mq Reform out there already, so it's mostly about connecting the pieces together.

uint8x16_t vector1 = ((uint8x16_t){1} > (uint8x16_t){0}) >> 7;
printf("%d\n", vector1[0]); // 1 in clang, 255 in gcc

uint8x16_t vector2 = (uint8x16_t){1} > (uint8x16_t){0};
vector2 = vector2 >> 7;
printf("%d\n", vector2[0]); // 1 in both gcc and clang

🤔