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.
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).
> 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.
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 :)
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).
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).
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.