dcz_self
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.
Still, an anglocentric bubble diminishes internationalization, and I disagree that it's a good thing.
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.
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: [email protected]
Mastodon: https://fosstodon.org/@dcz
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 :)
> $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).
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.
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/
Too many projects, not enough time. Brutalist design, no JS :)
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.
Given that it contains hardware, I don't expect to make any profit ;)
https://dcz_self.gitlab.io/posts/jazda_rust/
Pictures of the less-desired rust included.
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?
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).
Can anyone recommend an EU-based server provider that could be used as a tunnel?
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.
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
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 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.
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).