Posts
5603
Following
351
Followers
551
.
@jani @dennyhenke @miiko and a small supporting tool i did for opening html emails: https://crates.io/crates/mailweb
0
0
1

Jarkko Sakkinen

Edited 3 months ago
Created beginnings of TPM 2.0 emulator integrated directly to QEMU based on Infineon SLB9672. It requires compilation with optionally enabled Rust shenanigans.

Right now it processes only self-test, reading of capabilities and stuff like that but is bound and wired to qemu. I.e. can do "-tpmdev vtpm,id=tpm0".

Not out anytime soon but will be out in foreseeable future :-)

#qemu #tpm #emulator
3
4
10
@dennyhenke @jani @miiko Inbox privacy is irrelevant tbh :-) If you want privacy in that context, sign/encrypt your email.

Inbox encryption does not seal SMTP.
0
0
0

Jarkko Sakkinen

lrzsz2 0.3.2 and zmodem2 0.4.8 with (finally) working batch transfers. #zmodem #rustlang #tty
0
1
2

Jarkko Sakkinen

Edited 3 months ago
Speaking of swcam R&D benefits.

I talked about drones at LKML but you don't have to go that far in order to find useful places to improve QA using a software-define camera.

E.g., one could use it to improve tests of libcamera, pipewire and gstreamer ;-)

EDIT: and it could be utilized with WSL2 to provide video source for the VM environment.
0
0
2
@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
@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
@jani NP, it was anyway good learnings. There are worse ways to waste your week :-) It was my own choice.
1
0
1

Jarkko Sakkinen

Edited 3 months ago
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 Sakkinen

drafted my first ever himmelblau idm patch for dynamic user credential resolution :-) will take a while before any prs result.
0
0
0

Jarkko Sakkinen

-MODULE_DESCRIPTION("V4L2 virtual camera driver");+MODULE_DESCRIPTION("V4L2 software camera driver");

a cosmetic change but describes better the scope and purpose. I.e. vcam -> swcam
0
0
0

Jarkko Sakkinen

Edited 3 months ago
the next item in my backlog (i have a project to do something to every item in my personal backlog) are container objects. expected outcome is similar as for vcam initially i.e. "fuck no".

but since these are totally sidechannel things and nothing i take too personally i can still work on these topics if nothing else for my own entertainment :-) two years in a review cycle - i have zero problems with that.

i do give up on patch sets even if i've made myself a fool promoting them every single time when objective facts fight against them that i can understand with my limited brain capacity. up until that i go against the wind :-)
0
0
1

Jarkko Sakkinen

It is good to remark libcamerify from libcamera-tools is LD_PRELOAD based solution for "virtual camera", not ubiquitos solution really. It is also across the board much more stressing and higher latency solution for system than a well-designed loopback device.
0
0
0

Jarkko Sakkinen

Edited 3 months ago
Given that it seems a stretch to insure maintainers that people actually need this feature, I'm looking into https://docs.rs/hylarana/0.3.0/hylarana/. I try to understand how much effort it would take to implement a PoC service for video streaming from phone.
0
0
0
@pinkforest oh, not on purpose :D a genuine human made typo
1
0
0
And despite perhaps a bit ugly/dirty approach this is also very macro and generator friendly way to go (e.g. with Rust I think this can be fluently supported via syntax tree macros).
0
0
0
And I think I cap in the driver size states to 128 i.e. exactly 4KiB. It's like the driver definition blob sort of.
1
0
0
Show older