Conversation

Jarkko Sakkinen

Edited yesterday
Not posting this any time soon but now I think swcam has a decent uAPI where vidioc configuration is decoupled from producer of the stream. The producer provides a dataset of <pix_format, frame_rate> pairs that constraint the vidioc API upon creation and via SWCAM_IOC_WAIT gets the specs for the currently playing stream, always in the expected space of configurations.

The streaming pipeline itself has remained the same from the get go.

See:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/include/uapi/linux/swcam.h?h=vcam

Just wanted to put this to rebasable and complete state just in case (and I will continue to rebase the branch).
1
0
0

@jarkko Sorry about luring you to enter this particular rabbit hole. 😔

2
0
1

@jani @jarkko +1 . Thanks for trying!
(I did not answer but I did read every email in the threads.)

1
0
1
@jani NP, it was anyway good learnings. There are worse ways to waste your week :-) It was my own choice.
1
0
1
@Aissen @jani At least I think I got it right in the implementation despite apparently existentially wrong ;-)

Next, as a sidekick kernel project I'm going to take a look at dhowell's container object patch set from 2017, which was discarded back then w/o much discussion. I pick the best fights apparently...
1
0
3

@jarkko Cheers, $BEVERAGE is on me the next time.

(Which is a kind of empty promise considering the track record of basically any f2f meetings lately, but I digress.)

1
0
1

@jani @jarkko haha, I had forgotten about this one. You did end fixing it in the end though 🙂

1
0
0

@Aissen @jarkko

I did not. It was an impasse. It's still there and depends on BROKEN. Don't tell anyone. 🤫

0
0
1
@jani I appreciate this but as said I don't *expect* this :-) However, hopefully this happens rather sooner than later!

This episode of life left me sort of speechless in the sense that whenever there is a NACK for a patch that I've made, I pretty much always am informed in enough detail by the maintainers that I'm 100% on the board ditching my own patch.


Now I can dig up these conclusions from the thread(s):

1. Undefined "proprietary driver risk".
2. Pick the versions of libcamera, gstreamer and pipewire plus few hundred megabytes of their dependencies and you're set. Not going to test this theory, one week is enough ;-)
3. We just don't want to do it despite all these objective facts and undeniable security impact, which never can be fully closed by doing random user space libraries.

I'm not really dissapointed, as I cannot be when I do the "right thing" - acceptance is secondary. Now I played my hand correctly and this is the unfortunate outcome :-)
0
0
1