| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | Tex_Nick has left "In Linux, We Trust" | [01:23] |
| ...................................... (idle for 3h8mn) | ||
| Satyricon has quit IRC (Ping timeout: 276 seconds) | [04:31] | |
| .................... (idle for 1h37mn) | ||
| sailus has quit IRC (*.net *.split)
arnd has quit IRC (*.net *.split) | [06:08] | |
| .................................. (idle for 2h47mn) | ||
| nohous | 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 | [08:55] |
| hverkuil | 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. | [09:00] |
| nohous | hverkuil: well, these are fourccs coming from quicktime | [09:02] |
| hverkuil | 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. | [09:04] |
| nohous | 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? | [09:05] |
| hverkuil | 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)? | [09:05] |
| nohous | right
let me show you picture http://i.imgur.com/cUSNSOw.png densely packed: C.2, padded format: C.3 | [09:06] |
| hverkuil | Hmm, Y10BPACK is exactly that. | [09:08] |
| nohous | 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 | [09:08] |
| hverkuil | 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. | [09:10] |
| nohous | hverkuil: ok, great. I guess the names don't have to be absolutely descriptive since formats are detailed in documentation | [09:12] |
| hverkuil | Hmm, make that 10BPAD32.
Right. | [09:12] |
| nohous | the "default" endianness is little in v4l2, right? | [09:14] |
| hverkuil | y | [09:15] |
| nohous | i'll do YUYV_422_10BPAD32 and YUYV_444_10BPAD32 | [09:16] |
| 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) | [09:21] | |
| hverkuil | 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. | [09:32] |
| nohous | ok | [09:33] |
| hverkuil | 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. | [09:36] |
| nohous | 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) | [09:37] |
| hverkuil | Right. | [09:38] |
| nohous | 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 | [09:40] |
| hverkuil | 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. | [09:42] |
| nohous | 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 | [09:43] |
| hverkuil | It shouldn't be a problem. 3.8 has the support you need AFAICT. | [09:44] |
| ................ (idle for 1h18mn) | ||
| mchehab | 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 | [11:02] |
| ....... (idle for 30mn) | ||
| hverkuil | mchehab: fixed smatch. I was missing a libelf-dev package for some reason. Probably fallout from an upgrade I did yesterday. | [11:32] |
| mchehab | 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 | [11:32] |
| ..... (idle for 20mn) | ||
| hverkuil | I'll let it run tonight and check the results tomorrow. | [11:53] |
| .................................. (idle for 2h45mn) | ||
| *** | awalls has left | [14:38] |
| ................. (idle for 1h24mn) | ||
| sailus_ | mchehab: Obrigado! | [16:02] |
| mchehab | de nada! | [16:03] |
| ..... (idle for 22mn) | ||
| pinchartl | looks like ELC-E will take place one week later than initially planned | [16:25] |
| ..... (idle for 22mn) | ||
| broonie | pinchartl: Was there an announcement about that yet?
hverkuil: AFAICT it's some changes in the kernel build, same thing has bitten kernelci.org. | [16:47] |
| pinchartl | broonie: there was one in the ELC speakers e-mail that was sent today
Tim mentioned he would publish an official notification next week | [16:52] |
| broonie | Ah, I got an attendee e-mail today but it was the usual LF unreadable HTML only on my text mail client.
broonie wants to book travel! | [16:52] |
| larsc | 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 (?)" | [16:53] |
| .................. (idle for 1h25mn) | ||
| pinchartl | 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 | [18:24] |
| .......................................... (idle for 3h29mn) | ||
| headless | pinchartl: I'm prepping the TCON support for posting
hi | [21:54] |
| pinchartl | headless: oh ?
will I like it ? :-) | [21:58] |
| headless | pinchartl: we'll see
the origina code was even tested (but I don't have the test target for my version) original prosit | [22:01] |
| ........... (idle for 54mn) | ||
| nite | [22:56] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
