For anyone who is too small-brained to develop #libcamera, I started an unofficial Matrix channel to discuss the need for ergonomic alternative:
#libobscura:chatwave.org
https://matrix.to/#/#libobscura:chatwave.org
#v4l2 #linux #driver #kernel #ergonomy #graphics #camera #video
@pavel @martijnbraam "Don't" - I take issue with that approach. Since when is experimenting bad? Libmegapixels that you mention yourself is the prime example of being an experiment that can teach something.
@pavel @martijnbraam I only aim to gather those already excluded from libcamera - that's adding resources rather than splitting it.
libmegapixels might end up being the alternative. Again: a third effort is not the goal.
@dcz Could you elaborate on what you mean by an "ergonomic alternative"?
also cc @libcamera , i forget the exact people working on libcamera but the probably wanna be aware of this discussion and your percieved issue with their project.
@krafter @libcamera A short, subjective sample: difficult to understand architecture because every object contains a reference to every other object. The APIs are way too stateful. Also, passing raw pointers everywhere caused me segfaults that I wasted days on without progress. Authors say that C++ is the reason, but also I don't think they are open to replacing C++ in the mid-short term.
I think they are aware of my issues, but I haven't been able to influence them in any real way.
@dcz well there are many talented people working on libcamera, and I'm sure they did things that way for a reason. It seems to me that they might need better documentation on their software architecture, or you need to study it more closely.
I such an emerging space as linux mobile, fragmentation like this is the VERY LAST thing we need. The whole point of libcamera is to have ONE api for applications to use cameras. I repeat: Fragmentation is the very last thing we need in this space.
@krafter Oh, they are smart people. But to me, they are too smart. I can't really take part in their work, despite trying.
We already have fragmentation for this reason, see libmegapixels. And it's fragmentation coming from unfulfilled needs. libcamera has trouble progressing (see the config API issues and the stading lack of a C ABI).
IMO if libcamera doesn't improve quickly, mobile cameras will just keep falling behind Android. And I don't see improvement without a change in philosophy.
@libcamera @krafter Oh, I didn't realize there was one, and I had a free day.
Shame I didn't manage to find anyone at FOSDEM either.
@pavel @krafter A situation can get better if the original place is difficult to use.
Back when I was writing my thesis, I used a library which included userspace drivers. It was hard to write those drivers, and it angered me, so I threw away the entire system. The maintainer accepted it (bless them) and in a couple of months the entire ecosystem was covered.
Linux camera ecosystem is not big. Libcamera is harder than kernel (I'm the proof). Libmegapixels looks good with simple drivers.
@dcz is this the usual Linux Mobile thing where you refuse to understand something, so you write a poor wrapper around it and then abandon it after 2 months for it to then be misunderstood as the way forward and a competing solution to the thing you're wrapping by your users for the next 3 years
@CounterPillow as someone who has had some lengthy discussions with both the libcamera devs (who are pretty cool) and with @dcz (who is also pretty cool) i gotta ask what the heck is up with this comment. genuinely like ???