<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: eelstrebor has quit IRC (Quit: Ex-Chat)
<br> camus1 has joined #linux-media
<br> svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1921 has joined #linux-media
<br> lyakh_ has joined #linux-media
<br> lyakh__ has quit IRC (Ping timeout: 480 seconds)
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1921 has quit IRC (Read error: Connection reset by peer)
<br> xiaer1921 has joined #linux-media
<br> xiaer1921 has quit IRC (Read error: Connection reset by peer)
<br> cphealy has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has joined #linux-media
<br> eelstrebor has quit IRC ()
<br> fleebs has quit IRC (Ping timeout: 480 seconds)
<br> sailorek1234 has joined #linux-media
wens: <u>ndufresne</u>: any pointers would be much appreciated. The Chromium bug entry has little background context on this.
***: lyakh_ is now known as lyakh
<br> jm_h has joined #linux-media
<br> GBenji has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
<br> svarbanov has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> BrianG61UK has quit IRC (Read error: Connection reset by peer)
<br> svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> svarbanov has joined #linux-media
andrzej_p: <u>hverkuil</u>: thanks for taking care of vp9 series!
***: ao2 has joined #linux-media
hverkuil: <u>pinchartl</u>: is anyone maintaining libwebcam/uvcdynctrl? If so, where is it maintained?
pinchartl: not to my knowledge
hverkuil: <u>pinchartl</u>: OK, then I don't need to care about that. v4l2-compliance fails if logitech controls are added via uvcdynctrl, but if nobody maintains it and it is not in the debian package list anymore, then I won't attempt to fix that.
***: svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> svarbanov has joined #linux-media
<br> Moarc_ has quit IRC (Read error: Connection reset by peer)
<br> Moarc has joined #linux-media
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
ndufresne: <u>wens</u>: at the very basic, it starts from the intention, which has been documented here, https://www.kernel.org/doc/html/latest/driver-api/media/v4l2-videobuf2.html
<br> "offset in the plane to the start of data; usually 0, unless there is a header in front of the data."
<br> So fundamentally, using it for skipping over previous planes in the same buffer is a "repurpose"
<br> And both purpose seems rather incompatible, since if it was about a header, and the reason it is included in bytesused fwiw, then the importer may get miss-guided into thinking there is head data in there
<br> That being said, the data_offset is not usable, as even if you have two driver that expose the same data_offset size, no one can know if the importer will skip or read, and if it reads it, no one can know if the header it expect is compatible with the header produced by the exporter
<br> This is an ancient and weak API, I believe everyone agrees
<br> Now, if we assume we accept the repurpose, that basically means that we decide that none of the Output (or m2m output) devices are allowed to assume there is a header (the original intent) in the 0-data_offset portion of the buffer or plane
<br> From import/export point of view, we are still with a very week API, since while you now can import single allocation into Output devices, you can write into single allocation from Capture devices that implements multi allocation only (even though this is in practice compatible)
<br> This is due to the spec part, which is ABI and cannot be changed: "Offset in bytes to video data in the plane. Drivers must set this field when type refers to a capture stream, applications when it refers to an output stream."
<br> A capture driver is not allowed to read user provided data_offset
<br> <u>hverkuil</u>: I believe this is as exact as it can be on the situation, opting for a slight ABI break (considering no Output drivers uses that other then to skip), will partially delay the need for v4l2_buffer_ext I suppose, but does not really solve the core of the API issue
pinchartl: <u>ndufresne</u>: I'd really like to see proper data_offset support (with the same semantics as DRM/KMS) in V4L2
ndufresne: <u>pinchartl</u>: you haven't follow or commented on any of the v4l2_buffer_ext work
pinchartl: we've spent weeks fixing bugs in libcamera because of this :-S
<br> I know, I was hoping it would get merged without me needing to get involved :-)
***: eelstrebor has joined #linux-media
ndufresne: hehe, that's how I'm fixing uvc gadget, and it seems to work very well ;-P
pinchartl: in some cases it works fine, so it's worth a try :-)
<br> is v4l2_buffer_ext still being worked on ?
ndufresne: thing is that we decided to pull DRM modifiers, but that is pulling a string since now we also need a new ENUM_FMT
<br> which cascade into enum frame itnerval stuff (Which takes format as parameter)
pinchartl: I wonder if we should also take this as an opportunity to remove the bayer patterns from the pixel formats
ndufresne: I don't think anyone is working on it, Helene left kernel development
pinchartl: (that is, s/S[RGB]{4}/RAW/)
ndufresne: <u>pinchartl</u>: do they cause problem ?
pinchartl: combinatorial explosion of formats
ndufresne: so more like RAW + MOD ?
pinchartl: I'd pass the pattern out of band
<br> in a camera pipeline, the pattern usually matters only in the sensor and in the ISP
<br> nowhere in-between
ndufresne: we use to do that in gst for RGB, but that turned out to be really expensive when negotiation hundreds of nodes
pinchartl: so querying the pattern from the sensor (through a V4L2 control ?) and setting it on the ISP subdev (through a V4L2 control ?) could be better than propagating it through the pipeline
ndufresne: perhaps for cam there is only 1 layer of bayer, so nobody cares
***: eelstrebor has quit IRC ()
ndufresne: this imho looks like a major break ...
***: sailorek1234 has quit IRC ()
pinchartl: if you wanted to add SRGBW support today, you'd have to add quite a few pixel formats and media bus codes (8, 10, 12, 14 bits, with or without DPCM compression and/or aLaw/µLaw)
<br> and then mass-patch lots of subdev drivers that just pass the raw data through to support those formats
<br> every CSI-2 receiver driver would need to be patched to map the new mbus code to the new pixel format
<br> when nothing cares about it at the hardware level
ndufresne: well, there is more then one solution to avoiding to have to patch drivers that can passthrough stuff
pinchartl: I don't think it was a good design
ndufresne: as an example, internal to the kernel, there could be a static database of "raw formats"
<br> and that could genericlaly be handled instead of large switch cases
pinchartl: that could help, but but not handle everything, as mapping between mbus code and pixel format is device-specific
ndufresne: right
pinchartl: some devices can capture RAW10 in a packed format, some will always expand it to 16bpp, some will have multiple options
***: xiaer1921 has quit IRC (Remote host closed the connection)
ndufresne: basically you regret being too explicit in the formats
pinchartl: if we could redesign it, handling the CFA pattern out of band would be best. I'm not sure if that can be achieved now, or if we should aim for an option that wouldn't be as good, but would be easier to handle in a backward-compatible way
<br> yes
ndufresne: (thought, that ensure you a job with libcamera lol)
pinchartl: for bayer formats at least
***: xiaer1921 has joined #linux-media
ndufresne: I bet in many placed when configuring the MC, code will just blindly copy the format and paste it on the next node ...
pinchartl: I don't regret yet getting involved with cameras, I hope I won't get there :-)
ndufresne: I think some experimentation would be needed, if the pattern is out-of-band, you could introduce a new format and leave the old one alone
<br> The documentation of the format is "for further details go read controls X after YZ have been done)
pinchartl: it may be possible, yes. I hope someone else will do the work :-)
ndufresne: The definition of the needed state is always the tricky bit, consider the format enumation for CODEC, this is far from trivial, you really need to follow the procedure to avoid undefined territy that may work for 1 driver but not the other
pinchartl: for sensors, the pattern varies with cropping. if you move the crop rectangle by one pixel, the pattern changes. same for mirroring or flipping. that's another reason why out-of-band pattern handling would be easier
hverkuil: the work on v4l2_format_ext etc. is stalled, sadly. Lack of time and people, really. I've thought of working on this, but I never seem to get to the point where I have the time, there is always something more urgent that needs my attention :-(
***: dongo has joined #linux-media
<br> dongo has quit IRC (Quit: Leaving)
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> sailorek1234 has joined #linux-media
<br> cphealy has joined #linux-media
<br> svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> sailorek1234 has quit IRC ()
<br> eballetbo has quit IRC (Remote host closed the connection)
<br> dagmcr has quit IRC (Remote host closed the connection)
<br> feklee has quit IRC (Read error: Connection reset by peer)
<br> ribalda has quit IRC (Read error: Connection reset by peer)
<br> arnd_ has quit IRC (Remote host closed the connection)
<br> tfiga has quit IRC (Remote host closed the connection)
<br> pratyush has quit IRC (Remote host closed the connection)
<br> paulk1 has joined #linux-media
<br> paulk has quit IRC (Ping timeout: 480 seconds)
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> ribalda has joined #linux-media
<br> pratyush has joined #linux-media
<br> arnd_ has joined #linux-media
<br> feklee has joined #linux-media
<br> dagmcr has joined #linux-media
<br> eballetbo has joined #linux-media
<br> tfiga has joined #linux-media
<br> GBenji has left
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> gouchi has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> gouchi has quit IRC (Remote host closed the connection)
<br> montjoie has quit IRC (Ping timeout: 480 seconds)
<br> Moarc has quit IRC (Quit: i znowu NADMUCHAÅ BALONA)
<br> Moarc has joined #linux-media
<br> montjoie has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> camus1 has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
<br> jm_h has quit IRC (Remote host closed the connection)
<br> paulk1 has quit IRC (Ping timeout: 480 seconds)
<br> ao2 has quit IRC (Quit: Leaving)
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Read error: Connection reset by peer)
<br> svarbanov has joined #linux-media
<br> djrscally has quit IRC (Quit: Konversation terminated!)