dcz_self

Passing data from camera to OpenGL broke my mind. The code is still far from what I'd call nice, but feel free to steal anything you want!

Once I verify that debayering still works (I originally tested it years ago), GPU progress will mean calculating various statistics - the color balance, brightness, contrast for focusing, histograms, etc. Then feed them to control algorithms to adjust the camera controls.

There are two main differences.

First, libobscura doesn't yet fully support even UVC webcams,

and second, related to the quote, is that you will not run into segfault with libobscura no matter how hard you try.

When using libcamera, the task of memory management is on you, with the usual consequences.

There are more smaller differences. Image processing in libobscura is on the GPU from day 1. Contributing to the project is through codeberg, not a mailing list. The internal architecture differs, although that's not too visible.

Future goals may end up diverging, too. I'm thinking of a completely different approach to configuring devices and a different governance structure.

I guess my initial reaction was wrong: not having code in non-English languages doesn't accurately represent developer sentiments. There's a lot of translation efforts in open source, but again, this is not a good proxy for the sentiment because we don't know how many translators (who care about non-English) set project direction and design protocols.

Still, an anglocentric bubble diminishes internationalization, and I disagree that it's a good thing.

Why is that a good thing? I get the idea that a common language is beneficial, but the flip side is the knowledge and effort of the people who know another language. That's lost due to never being opened (I guess that's more of an indictment of the open source community being not interlinguistic).

Oh wow, the beginning of a new era.

Hear, hear.

I hit all those Wayland issues while working on Squeekboard. https://gitlab.gnome.org/World/Phosh/squeekboard

Similarly, how do you create an on-screen keyboard that can inject keypresses for characters not available in the current layout?

I switched the keyboard layout on the fly, on key press, if needed. That works... mostly. Chromium and Chromium-based apps know better what layout I am using, so they will misinterpret some inputs despite having a key map already. And then you realize that you can't use a physical keyboard at the same time, because key maps go out of sync while keys are pressed on both. I talked to a Wayland dev about having separate keyboards with separate layouts, but the answer was basically "it's an incompatible change, and it's too late to fix this" (it was in an issue tracker, but no link). So the only way to have a non-input-method on-screen keyboard is to limit yourself artificially to the current layout. Which, of course, is an oft requested feature I will never implement.

A better idea would be to allow to send arbitrary Unicode strings and maybe integrate regular input and IME input (input system for typing Asian characters).

Isn't Mac OS do something like that? I agree this is the way to go. But the stumbling block is - again - that applications like Chromium won't implement this. I created the text-input-v3 protocol some 4 years ago, and it's still basically only used in GNOME.

But with new funding from NLNet I'm gathering a special ops team to push input methods again this year :)

most developers use only ASCII and do not have experience using multiple layouts.

I'm getting that impression as well after discussing the topic of internationalization on Mastodon: using languages other than English is undervalued by open source devs. I mean, how often do you find variables named in Spanish or Russian in open source software? It's a very anglocentric bubble.

I force feed people and computers with Open Source. I think I'm good at it.

Location: Germany

Remote: preferred

Willing to relocate: unlikely

Technologies: Linux, Rust, Libre Software, Open Hardware, exchanging ideas with humans

Résumé: https://dorotac.eu

Email: hnstarfish@dorotac.eu

Mastodon: https://fosstodon.org/@dcz

https://jazda.org

A bicycle computer. Hackable. Open source software. Off the shelf hardware.

ARM microcontroller, 100% Rust, Bluetooth (not yet).

I have had a bike computer nearly 3 decades ago, but the dream to have the distance counter reset automatically has remained unfulfilled. I could either get a fixed-function calculator or 100% closed overpowered gadget. Why can't I have some fun myself?!?

Thankfully, now we have cheap, reverse-engineered smart watches. I found a pretty decent, sunlight-readable one, and now I'm hacking away!

The big TODO is speeding up development by switching from TockOS to RTIC, and implementing a minimal Bluetooth Low Enegy stack.

Currently on hiatus because it's bike season and I'd rather spend my time outside :)

Thanks for the report. I don't have access to Safari, so there isn't much I can do right now :/

Which lines do you mean? This source code part?

$1 = alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x5555555abaa0}, _marker: core::marker::PhantomData<u8>}, cap: 3, alloc: alloc::alloc::Global}, len: 3}}

On my browser, everything breaks according to the browser's window size (I set white-space: pre-wrap).

You can use QtCreator that way already:

https://dorotac.eu/posts/debugging_rust/

You can view the data structures opaquely even though the functions are written not in Rust, but in Python.

One of the difficulties is that the Rust compiler will emit different debugging info depending on the compiler version. Perhaps I should look into how gdb deals with that (if at all).

Patches welcome.

Start in the middle. It's the most interesting part, too. After all, that's the core of your idea.

I don't know where I heard this, but the idea is so important to me that I saved it on my blog: https://dorotac.eu/posts/in_the_middle/

Thanks! That's the Markdown renderer failing to escape entities properly. Fixed now by switching to markdown-it-py.

https://dorotac.eu

Too many projects, not enough time. Brutalist design, no JS :)

Banking or CC app for mandatory 2FA?

Switched banks.

gvmt Covid mandatory app to travel anywhere?

There wasn't one, thank $DEITY (Germany).

QR code for restaurants?

Never encountered one without a menu yet, but I'd just go to another one.

Places that require an app in general?

Never encountered those, either. There was one on my offline backpacking trip which required digital payment. It was sad, but I had to forfeit.

Still chipping away at the Free Software bike computer: https://jazda.org

Given that it contains hardware, I don't expect to make any profit ;)

A blog post about my work on libcamera I do for the Purism Librem 5 phone touches on this topic:

https://puri.sm/posts/cameras-its-complicated/

Funnily enough, about a month ago I gave a presentation about deliberately putting Rust on my bike.

https://dcz_self.gitlab.io/posts/jazda_rust/

Pictures of the less-desired rust included.

With my Librem 5 developer hat on, I'm surprised that a SPI chip matters at all.

The Librem 5 eMMC contains a hidden "partition", which is preferred by the CPU to boot from over the "data partition" where the OS boot loader resides. It should be possible to put Tow-boot into this hidden area, and the OS stored in the data area will have no say. No separate flash chip needed to have an independent boot loader.

I wonder why the PinePhone needs a separate chip for this purpose. Is the CPU unaware of hidden areas on the eMMC?

I'm not a Rust-only developer, but a general systems programmer, and my foray into embedded is limited to a side project (see my profile), but no, I haven't switched to C/C++. Rust brings too much goodness to give it up.

Rust-embedded is an easy ecosystem to work with (if immature), and if you want more flexibility, Tock OS [0] is trying to cover that space (also immature, but I'm working on it).

[0] https://www.tockos.org/

Based on the comments, telekom.de is doing the same thing. A /56 prefix, changing every day. Blood-boiling.

Can anyone recommend an EU-based server provider that could be used as a tunnel?

That's a valid observation of one of the reasons I won't use git-send-email.

I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs.

Keep reading, there's more criticism on other aspects of the tool.

I can figure out how to send you a patch set via email (see my Linux kernel contributions), but if I can avoid doing that, sure as heck I will. Your project must be really important to me, or I have to get paid.

As for the reason, it's simple: the process of submitting patches sucks. I wrote about it: https://dcz_self.gitlab.io/posts/git-botch-email

I hope so too :) Sadly, Megapixels doesn't seem to be interested in libcamera at the moment.

Plumbing things correctly is complicated :)

Did you do your tests in good lighting?

Did you compare raw sensor output, or post-processed?

Big sensors capture more light and have more bokeh. With enough light, the first doesn't matter, and bokeh is not a thing for QR codes.

If you didn't have enough light, then it's probably the question of how denoising was done, and what details have been guessed by fancy algorithms. Geometrical shapes are easy to guess, but when I look at pictures of landscapes, they typically devolve into a painting after 1000×1000px if taken on a phone.

It's not orthogonal. In fact, it's a very good observation, and even libcamera itself recognizes it by providing v4l2 emulation.

It could be a viable way to get the basic use case of video streaming where special controls are not needed. It's worth considering, although then it makes sense to leverage work already in libcamera to implement the extra layer.

libcamera already has that functionality via LD_PRELOAD

That's because we need a standard, and without libcamera, there is no standard.

It's hard to tell because I don't know what Android phones do exactly. Does it vary by manufacturer? Do we include AI tricks and high speed video encoding?

I think it's going to be a long way to get there, but also the openness of the drivers will let us find our own strengths (I have high hopes for super-high FPS recording).