| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| freefolk[m] | I'm interested in getting a tv tuner for the mini-pci-e slot. I'm reading https://www.linuxtv.org/wiki/index.php/Sundtek and it looks like the "Sundtek MediaTV Pro II ATSC" is the only linux-supported mini-PCIe option?
The card looks like it has an antenna connector similar to a wifi card, so do I just connect one of my laptop's internal antenna cables to it? Also, does this mini-PCIe card use USB signaling or PCIe signalling? | [00:12] |
| * I'm interested in getting a tv tuner for the mini-pci-e slot. I'm reading https://www.linuxtv.org/wiki/index.php/ATSC_PCIe_cards and it looks like the "Sundtek MediaTV Pro II ATSC" is the only linux-supported mini-PCIe option?
* I'm interested in getting a tv tuner for the mini-pci-e slot in my laptop. I'm reading https://www.linuxtv.org/wiki/index.php/ATSC_PCIe_cards and it looks like the "Sundtek MediaTV Pro II ATSC" is the only linux-supported mini-PCIe option? * Also, is this mini-PCIe communicate via PCIe or via USB? | [00:21] | |
| * Also, does this mini-PCIe communicate via PCIe or via USB? | [00:30] | |
| ................................................................... (idle for 5h33mn) | ||
| hverkuil | ezequielg: sounds like a good plan. Did you have time to look some more into MVC? | [06:03] |
| ................................................................ (idle for 5h15mn) | ||
| pinchartl | hverkuil: ping | [11:18] |
| hverkuil | pinchartl: pong | [11:26] |
| pinchartl | hverkuil: how would you name a 10bit NV12 pixel format ?
(considering it packs 3 pixels in 4 bytes, with 2 bits of padding) | [11:30] |
| sorry for asking harsh questions out of the blue :-) | [11:35] | |
| hverkuil | V4L2_PIX_FMT_NV12_10 ?
(slow reply since I'm in another meeting) | [11:35] |
| pinchartl | no worries
there will be NV12_12 too | [11:35] |
| hverkuil | or perhaps _D10 (d=bit depth) | [11:36] |
| pinchartl | I suppose I can ignore for now the fact that different packing schemes could exist ?
someone could store the same data with 2 bytes per pixel instead of packing 3 pixels in 4 bytes or pack 12 pixels in 15 bytes to avoid the padding bits, although that's unlikely, as hardware won't like 15 bytes DMA transfers | [11:36] |
| hverkuil | you might want to look at media-bus-format.h for some ideas. | [11:38] |
| pinchartl | should I try to establish a new naming scheme for YUV formats with more than 8 bits per pixels ?
or try to stay as close as possible to what we have, with ad-hoc names ? | [11:38] |
| hverkuil | I think a new naming scheme will be beneficial. You need that for 10 and 12 bit formats. | [11:41] |
| pinchartl | ok. I'll try to come up with something not too brain-dead
I expect lots of bikeshedding though :-) | [11:42] |
| hverkuil | I don't think you should try to capture all the weird and wonderful ways that pixels can be formatted, just something that will cover the more logical options. | [11:43] |
| pinchartl | on a side note, I'll also submit 20bit bayer formats. sensor developers are crazy... | [11:43] |
| hverkuil | :-) | [11:43] |
| pinchartl | (seems the CCS spec supports up to 24 bits...)
10-, 12- and 16-bit RGB is also interesting | [11:43] |
| hverkuil | I'm very, very surprised that nobody submitted 10 bit RGB yet.
I'd expected that years ago. | [11:44] |
| pinchartl | (I mean 10, 12 and 16 bits per component, not in total)
would you name is XRGB30 (to mimick RGB24) or XRGB2101010 (to mimick RGB555, and also DRM) ? s/is/it/ | [11:44] |
| hverkuil | I'd go with the latter. The current name conventions are very 8-bit oriented, and do not scale well for these more complex formats. Also, if drm already has a fourcc that is reasonable, then it would be good to use that in V4L2 as well. | [11:47] |
| pinchartl | for some formats they do
and some of them use a numerical value that is already taken by something else in V4L2 :-( | [11:47] |
| hverkuil | We can keep the same symbolic name (with the V4L2 prefix of course), but with a different fourcc. | [11:49] |
| pinchartl | yes, that's what I was planning to do
shame the numerical value is already taken the order of the components will also need to be discussed. for 8- and 16-bit RGB, we have a naming scheme where we use the order of the components in a 8-bit or 16-bit word. for instance, RGB565 is stored as [RRRRR GGGGGG BBBBB], little endian, and thus [GGGBBBBB] [RRRRRGGG] in memory. for RGB24 and RGB32, we use (mostly) the byte order in memory instead. for 10- and 12- bpc formats, I was thinking of using the order in a little endian word, as the components don't align to byte boundaries and I think I'll do the same for 16-bpc to be consistent this matches what DRM does (they use the same convention for all RGB formats, and thus name ARGB what we name BGRA) | [11:49] |
| hverkuil | As long as it is clearly documented I am fine with it. | [11:51] |
| pinchartl | I'm splitting the RGB formats page in three sections, 8- and 16-bpp, 24- and 32-bpp, and 10+ bpc, to document the naming scheme clearly for each category | [11:52] |
| hverkuil | We never had clear naming rules (in part because HW designers are mad), so having something better for these higher bit depth formats would be welcome. | [11:52] |
| pinchartl | I'm sure it will break as soon as it gets merged, but I'll still try :-)
thanks for your feedback | [11:53] |
| hverkuil | I'm always happy if we can cover 90% or up of the various formats. You can never reach 100%, it is just something you have to accept. | [11:57] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |