hverkuil: any ideas for new pixel formats naming?  I need to define macros for fourccs V210, V410, YUV2 (that one's actually the same as YUYV), 2VYU, V308, V408, V216
hverkuil: and also something for densely-packed 10b a 12b YUV 4:2:2, YUV 4:4:4, RGB, RGBA
what i have for the former is like V4L2_PIX_FMT_V308
The name of the define is generally something that is more-or-less descriptive, which V308 is clearly not. At least, I don't know what it means. The fourcc is up to you: if these are already defined somewhere for these formats, and they are not yet used in videodev2.h, then just reuse those.
hverkuil: well, these are fourccs coming from quicktime
For the 10 and 12 bit versions I would do something like V4L2_PIX_FMT_YUYV_10BPACK/12BPACK (without the PACK these would take 16 bits per pixel). This more-or-less conforms to existing defines like FMT_Y10 and Y10BPACK.
yes, that seems nice, but how to distinguish between formats where 3 10b components are packed in 32bits with 2 bits of padding vs. densely-packed 10 b formats?
We don't really have guidelines for the actual fourcc. The only exception is that big-endian variants are signaled by setting bit 31 (if memory serves).
So densely packed would have 4 pixels per 40 bits (or 5 bytes)?
right
let me show you picture
http://i.imgur.com/cUSNSOw.png
densely packed: C.2, padded format: C.3
Hmm, Y10BPACK is exactly that.
this scheme is also agnostic with respect to actual component count per pixel btw, so C.3/C.2 can be used for 4:2:2, 4:4:4, 4:4:4:4, 4:2:2:4....
it is, but we need to define versions of Y10BPACK and the C.3 for YUV422/YUV444/RGB444/RGBA4444/YUVA4224
YUYV_10B vs YUYV_10BPAD vs YUYV_10BPACK
10B: use 16 bits per component, 10BPAD: pack in 32 bits with padding, 10BPACK: pack without padding.
hverkuil: ok, great. I guess the names don't have to be absolutely descriptive since formats are detailed in documentation
Hmm, make that 10BPAD32.
Right.
the "default" endianness is little in v4l2, right?
y
i'll do YUYV_422_10BPAD32 and YUYV_444_10BPAD32
argh, with v210 to packing goes on the msbs of uint32_t, whereas in v410 it goes to lsbs
so V4L2_PIX_FMT_UYV422_10BPAD32M for MSB padding and V4L2_PIX_FMT_UYV422_10BPAD32L for LSB padding (both are little endian)
How about PAD32HI and PAD32LO? That is conform what is used in include/uapi/linux/media-bus-format.h
.
(media bus formats describe how data passed from one HW block to another, they don't describe the memory layout)
But they also need to specific where the padding goes, so let's use the same naming.
ok
I would use V4L2_PIX_FMT_YUYV_10BPAD32HI. The 422 is unnecessary since YUYV is implicitly 422. Stick to the names given for the existing 8 bit variants and just add the suffix.
hverkuil, ok, so for 422 formats i'll use four characters for component order (YUYV), whereas for 444 i'll use only chars (e.g. YUV)
Right.
btw, is i it a good idea to split the driver into multiple subdevs? one argument is that we're going to have multiple rx / tx channels with possibility for channel aggregation and another is that i could split the sdi pipeline and memory pipeline
sdi rx provides some data format which could be exposed via one output pad and memory pixel packer would have an input pad with its own format
That's a design decision you are best placed to make. It tends to depend on how independent from one another these blocks are.
A good first approximation is to go with the high-level block diagram: if it is a separate block, then it should probably be a separate driver.
ok, i'll have to think this through since we need to support kernels as old as 3.8 and i am not sure in what  state is media-bus api there
It shouldn't be a problem. 3.8 has the support you need AFAICT.
hverkuil: just fixed the build issues with media_build, but it seems that there's a problem on your scripts/environment when calling smatch... from your logs:
smatch: ERRORS collect2: error: ld returned 1 exit status elf.h:22:18: fatal error: gelf.h: No such file or directory elf.h:22:18: fatal error: gelf.h: No such file or directory elf.h:22:18: fatal error: gelf.h: No such file or directory arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
mchehab: fixed smatch. I was missing a libelf-dev package for some reason. Probably fallout from an upgrade I did yesterday.
yeah, sometimes upgrades don't go that well ;)
anyway, it won't hurt if you could manually run the script to double check if everything is building well
I tested building here only with Kernel 4.4.6
I'll let it run tonight and check the results tomorrow.
mchehab: Obrigado!
de nada!
looks like ELC-E will take place one week later than initially planned
pinchartl: Was there an announcement about that yet?
hverkuil: AFAICT it's some changes in the kernel build, same thing has bitten kernelci.org.
broonie: there was one in the ELC speakers e-mail that was sent today
Tim mentioned he would publish an official notification next week
Ah, I got an attendee e-mail today but it was the usual LF unreadable HTML only on my text mail client.
the speaker mail is readable in plain-text only
actually it is much more legible than the html version
I was thinking about submiting a talk fo ELC-E: "The future of audio on Linux - The end of an golden age (?)"
larsc: please do
and feel free to blame Intel in that Intel-sponsored conference :-)
they seem to rapidly lose the little common sense they still had
pinchartl: I'm prepping the TCON support for posting
hi
headless: oh ?
will I like it ? :-)
pinchartl: we'll see
the origina code was even tested (but I don't have the test target for my version)
original
prosit
nite