| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | Muzer has quit IRC (Ping timeout: 264 seconds) | [00:52] |
| ........................... (idle for 2h13mn) | ||
| neg | sailus: 96d27cb3b108b26d ("v4l2-async: Use endpoint node, not device node, for fwnode match") breaks R-Car Gen2 while the whole series works for R-Car Gen3 | [03:05] |
| .... (idle for 18mn) | ||
| sailus: Offending dts is arch/arm/boot/dts/r8a7791-koelsch.dts
sailus: adv7604 (compatible = "adi,adv7612") register itself as '/i2c-13/hdmi-in@4c/ports/port@0/endpoint' while rcar-vin looks for '/i2c-13/hdmi-in@4c/ports/port@2/endpoint' -> v4l-async fails | [03:23] | |
| I love the idea of matching on endpoints, but I fear to solve it a subdev would need to register all endpoints described. v4l-async would need to allow a subdev to be bound to more then one consumer and the v4l2_dev pointer would need to be removed from the subdev. I once tried to work on that but got stuck on event propagation, I found not clear way how to solve that :-(
On the upside, if the event problem could be solved while taking the MC graph into account two things which bug me would be solved in one go ;-) | [03:33] | |
| ............ (idle for 58mn) | ||
| tfiga | pinchartl: kbingham: did we have any follow up on using cached buffers for UVC?
(URB buffers) | [04:34] |
| ..................... (idle for 1h44mn) | ||
| *** | ntrrgc has quit IRC (Ping timeout: 252 seconds)
dagmcr has quit IRC (Ping timeout: 252 seconds) | [06:18] |
| .............. (idle for 1h6mn) | ||
| pinchartl | tfiga: I'd say I'll let Kieran have a look, but I suppose I should as well ? :-) | [07:28] |
| tfiga | pinchartl: up to you guys to figure out :)
I think we had 2 ideas: 1) use buffers with cached mapping, 2) copy the packet headers in bulk to some temporary buffer before doing a lot of random accesses to it and for 1) we had a) just use kmalloc() and do all the map and sync manually, 2) have the USB host subsystem give us a way to request cached buffers and it would handle everything for us oops, s/2)/b)/ | [07:40] |
| ..... (idle for 20mn) | ||
| LazyGrizzly | ping pinchartl | [08:02] |
| pinchartl | LazyGrizzly: pong (but mostly AFK for the next hour) | [08:11] |
| LazyGrizzly | no worries I wanted to make sure SGRBG12SP and friends where OK. You had concerns about the naming 'simple packed' but i am unsure on what alternatives there are | [08:15] |
| pinchartl | LazyGrizzly: remind me, did I request a new version ? | [08:21] |
| LazyGrizzly | pinchartl: https://www.mail-archive.com/linux-media@vger.kernel.org/msg146763.html
quote: I don't think there are any way simpler than the SBGGR12P family. I wonder if we could find better descriptive name, both for this comment and for the format name in uvc_fmts[]. | [08:25] |
| pinchartl | it's the name "simple packed" that bothers me
it's not simpler than the V4L2_PIX_FMT_SBGGR12P family it's just different | [08:28] |
| .... (idle for 18mn) | ||
| hverkuil | tfiga: posted patch to always reacquire memory for USERPTR buffers. Please review and test! | [08:46] |
| LazyGrizzly | pinchartl: would 'straight packed' be better? the pixels are simply put straight after one another, i am unsure what could be more fitting. | [08:47] |
| pinchartl | hverkuil: ^^ any comment on the naming ? | [08:51] |
| sailus | LazyGrizzly, pinchartl: My suggestion was to name it according to the hardware that supports the format.
Even if there could be other uses for it which we only learn about in the future, that's all right. | [08:52] |
| tfiga | hverkuil: thanks! will try it on Monday
hverkuil: also thanks for posting v4. let me try to review it early next week | [08:53] |
| sailus | To be clear, I'm not happy with the proposed name. | [08:54] |
| pinchartl | LazyGrizzly: is it hardware-specific ? | [08:56] |
| bbrezillon | pH5: Hi
do you think you'll be able to send a new version of the hantro series soon? both ezequielg and I are basing our changes on top, so that'd be great to have at least the first 7 patches merged | [09:04] |
| LazyGrizzly | pinchartl: sailus: it is not hardware specific.
It is the bayer 12-bit packed format that is used by devices that adhere to the USB3Vision protocol. They all should follow format definitions mentioned in this https://www.emva.org/wp-content/uploads/GenICam_PFNC_2_3.pdf . Sadly they don't mention by12 packed explicitly. | [09:06] |
| hverkuil | tfiga: regarding v4 of the codec spec: I think the decoder spec is basically ready, but for the encoder there are a number of open issues. I proposed solutions, but I'm not happy with it and will come up with alternative proposals once I have a bit more time to think about it. | [09:20] |
| tfiga | hverkuil: agreed
perhaps we could merge just the decoder first? | [09:22] |
| hverkuil | pinchartl: LazyGrizzly: how about "Linear Packed", i.e. SRGGB12LP | [09:23] |
| LazyGrizzly | fine by me | [09:23] |
| hverkuil | tfiga: yes, that was my plan. I need Reviewed-by tags from at least you and ndufresne before I can merge anything. | [09:24] |
| pinchartl | headless: I prefer that over simple, yes
LazyGrizzly: I noticed that the spec doesn't document the format, yes. is there another document that would describe it in details ? if not, how did you figure out the layout ? | [09:34] |
| LazyGrizzly | pinchartl: i asked the firmware developer of some usb3vision cameras | [09:36] |
| .... (idle for 18mn) | ||
| sailus | If the format is specific to USB3Vision devices, then you could also call it such.
That said, I'm fine with "Linear Packed" naming as well. It describes the name reasonably well and there is a real chance it could be used by non-USB3Vision devices. | [09:54] |
| LazyGrizzly | pinchartl: unless there are any other objections i'd proceed with renaming everthing to 'linear packed' and modifying the patches | [09:58] |
| pinchartl | LazyGrizzly: are you aware of multiple devices from multiple vendors using the same format, or is it a single device (or single vendor) ? | [10:00] |
| LazyGrizzly | pinchartl: at this point i am not sure how other companies handle usb3vision. theimagingsource.com has multiple usb3 cameras that offer this format. i am only working with those so ....
If you have doubts i can PM you the email of the firmware developer | [10:08] |
| pinchartl | LazyGrizzly: could you ask the firmware developer where they have found the exact description of the format ? | [10:11] |
| kbingham | tfiga, pinchartl, I remember we did a big analysis with keiichiw and the results are at "https://docs.google.com/spreadsheets/d/1uPdbdVcebO9OQ0LQ8hR2LGIEySWgSnGwwhzv7LPXAlU/edit?usp=sharing" - So I think it just needs a decision on the best of those and then apply appropriate patches :)
(and probably then do a whole load more testing. ) | [10:14] |
| LazyGrizzly | pinchartl: from what he told me he visited seminars and transferred the descriptions for the mono12 packed format in the pdf i linked to the bayer formats | [10:19] |
| ....... (idle for 30mn) | ||
| tfiga | kbingham: I think all the options are relatively close to each other
IMHO it's more about whether to handle it ad hoc or in a more structured fashion kbingham: I also noticed something weird with the throughput value doesn't it mean the actually amount of data being sent by the camera itself rather than a benchmark result? if so, it should be the same for all the setups to be comparable (maybe +/- the cases of a lot of errors, as the data might have been dropped?) | [10:49] |
| pinchartl | LazyGrizzly: so it's likely custom-made. I wonder if we should call it SGRBG12_TIS | [10:58] |
| tfiga | kbingham: my subjective opinion is that we should go with kmalloc, persistent mapping and sync before/after each packet (i.e. option F)
then maybe some time in the future someone figures out how to move this to the USB framework | [11:02] |
| ...... (idle for 26mn) | ||
| paulk-leonov | mjourdan: hey there -- do you happen to know whether the amlogic VPU firmware actually does something useful or not?
it would be great to get rid of it if not, or liberate it if it's really needed :) but sadly the current situation is a real shame... mjourdan: unrelated: are there amlogic boards that don't enforce signature verifications on the first bootloader (thus making the SoC usable in the free world)? | [11:29] |
| mjourdan | paulk-leonov: I'm guessing that question is related to your email 'Hardware-accelerated video decoders used through a firmware instead of hardware registers' ? :) | [11:32] |
| paulk-leonov | mjourdan: definitely :)
I'd like to have a clear idea of what the situation is like on common platforms so we can have a chance to solve the issue for good | [11:32] |
| mjourdan | My guess is that the firmware does bitstream parsing and coordinating the underlying decoding blocks. Whether or not this can be bypassed by only doing work from the CPU, I don't know.
paulk-leonov: There are plenty of dev boards with amlogic SoCs ("Le Potato", "La frite", "Odroid-C2", "Odroid-N2", "Khadas VIM2", "Khadas VIM3").. Even on some retail products you can hook to the serial and push your own u-boot/kernel without secure boot (like the X96 Max). ah sorry, you meant the first bootloader I'm not sure actually if the ATF is signed on those paulk-leonov: I don't know what arch the firmware is compiled into. And regarding the vdec, even though we have access to docs & support, amlogic remains silent regarding the vdec. I wish we could make a stateless driver for it (if even possible) but at this point it's way too much work | [11:34] |
| paulk-leonov | mjourdan: sure, I understand that amlogic is not interested in this at all
so the effort will probably come from the community mjourdan: yeah I mean first stage loader, I'm not that very interested in the ability to chainload mjourdan: do you have JTAG available though? sometimes JTAG can be used to bypass "secure boot" mechanisms] | [11:43] |
| tfiga | paulk-leonov: I can assure you that some vendors would prefer using firmware even for statless decoding :(
just to cover the register layout | [11:51] |
| paulk-leonov | tfiga: that's an issue we need to worry about IMO :)
this nonsense has been going on for long enough | [11:52] |
| tfiga | paulk-leonov: I'm not sure if we have anything to force them
they would be more than happy not to upstream their code | [11:52] |
| paulk-leonov | well, we can at least start by talking about the issue, which can induce RE efforts
I think the resolution is more technical than political at this point since indeed, they will most likely not change their minds on the other hand reversing a tiny firmware that just does parsing + writing to registers should be doable in most cases | [11:53] |
| tfiga | paulk-leonov: you can see the mtk-vcodec driver with some patches getting the stateless mode on newer SoCs | [11:54] |
| paulk-leonov | but still through the firmware I guess? | [11:54] |
| tfiga | yep | [11:54] |
| paulk-leonov | hehe
well we should just trace the firmware and just stop using it | [11:54] |
| tfiga | :) | [11:55] |
| pinchartl | paulk-leonov: wouldn't it be best if we could write an open-source firmware to offload some operations from the main CPU ? :-) | [11:56] |
| paulk-leonov | pinchartl: not sure that's the best thing to do in terms of latency/perdf
perf* | [11:57] |
| tfiga | we're trying to reduce firmware in our projects, but often it's impossible to eliminate it completely only for such reasons ;/ | [11:57] |
| paulk-leonov | pinchartl: but yeah it would be interesting to know precisely and potentially go with a free firmware if that has advantages
tfiga: yup, MT8173 has basically that VPU firmware, the SPM PCM firmwares and that's it (well, and GPU stuff obviously) | [11:57] |
| LazyGrizzly | pinchartl: i've asked the firmware developer to contact you. he knows the details better than i do and if userspace fourccs should be device/vendor/protocol specific | [11:58] |
| tfiga | paulk-leonov: MT8183 is more "interesting" as it has one coprocessor that runs firmware for everything | [11:59] |
| paulk-leonov | tfiga: ah, didn't know that! | [11:59] |
| tfiga | we had quite a pain with that ;/ | [11:59] |
| paulk-leonov | is that MCSI? | [12:00] |
| pinchartl | paulk-leonov: for codecs it may be less of an issue, but for camera ISPs the real time constraints are stronger | [12:00] |
| tfiga | still working on something relatively clean and that could also work for upstream (linux-firmware) | [12:00] |
| pinchartl | LazyGrizzly: thank you | [12:00] |
| tfiga | paulk-leonov: not sure what MCSI is | [12:00] |
| paulk-leonov | okay, was just looking at https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/mcsi/mcsi.c and it looked like it could be related
pinchartl: yeah maybe, but for decoding we're probably better off with e.g. ffmpeg doing bitstream parsing in parallel on the ARM cores | [12:01] |
| tfiga | to be fully precise, there are also few very tiny coprocessors for power and security | [12:01] |
| paulk-leonov | instead of parsing on the coprocessor that runs at a few hundred MHz
tfiga: ah so there's probably still a SPM PCM then :) | [12:02] |
| tfiga | could be
I guess in the end it's actually not so different from VPU | [12:02] |
| mjourdan | paulk-leonov: No explicit JTAG that I can see at least | [12:03] |
| paulk-leonov | VPU is a MD32 core and yeah Mediatek tends to reuse that for various things
mjourdan: noted, thanks | [12:03] |
| tfiga | the big one handles video codecs, ISPs and some video processor
and what not :) | [12:03] |
| paulk-leonov | the SPM PCM is a custom ISA, but I mostly reversed it at this point: https://www.paulk.fr/media/2018-thsf/2018-thsf-mt8173-pcm.pdf
tfiga: I just read that MT8183 is *not* a PowerVR? | [12:04] |
| tfiga | paulk-leonov: nope, it's a Mali | [12:14] |
| paulk-leonov | amazing :) | [12:14] |
| *** | LazyGrizzly has left | [12:18] |
| tensa has quit IRC (Quit: Ping timeout (120 seconds)) | [12:27] | |
| ............ (idle for 55mn) | ||
| freyr69 | Hi there. I have a no-name SDI capture card exposing a v4l2 interface. The hardware itself could auto-detect video format
Yet driver send no related event I'm not familiar with V4L2 So, does V4L2 interface support dynamic format change and how? https://www.linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-query-dv-timings.html this page says that there should be a V4L2_EVENT_SOURCE_CHANGE event Yet I've never seen an application that supports it | [13:22] |
| .... (idle for 19mn) | ||
| hverkuil | freyr69: yes, the driver should send the SOURCE_CHANGE event and support the DV Timings ioctls.
v4l2-ctl support this. Also qv4l2. You don't see this typically in other applications since HDMI receivers are almost never found on your typical cheap SBC. | [13:43] |
| freyr69 | hverkuil: are there any examples of players or somethings like that supporting that? | [13:48] |
| hverkuil | v4l2-ctl support this. Also qv4l2.
I don't know if it has made its way into gstreamer or ffmpeg. | [13:48] |
| freyr69 | Isn't it a simple ioctl wrapper?
neither ffmpeg nor gstreamer nor mpv support it | [13:48] |
| hverkuil | More a reference application on how to stream video. | [13:49] |
| freyr69 | I'm thinking about implementing a gstreamer support
is it a stable interface? | [13:49] |
| hverkuil | freyr69: that would be nice. Look at v4l2-ctl. | [13:49] |
| freyr69 | what is it used for, only digital capture cards? | [13:49] |
| hverkuil | Yes, we (Cisco) use it in our video telepresence systems for years.
Digital Video input, basically anything that's not a sensor or composite/S-Video. | [13:49] |
| freyr69 | Do I understand it correct: on SOURCE_CHANGE I should reset timing and then reset format?
correctly* | [13:51] |
| hverkuil | The source change event tells you something changed. Either a signal went away, changed, or a new signal appeared.
You use DV_QUERY_TIMINGS to obtain the new timings, then call S_DV_TIMINGS to configure the receiver and then you can start streaming. | [13:52] |
| freyr69 | I see, thanks | [13:53] |
| hverkuil | See v4l2-ctl-streaming.c, streaming_set_cap().
It's not quite perfect: the initial wait for a valid signal just polls. Instead it really should just wait for a SOURCE_CHANGE event. | [13:54] |
| ...... (idle for 26mn) | ||
| freyr69: what SDI card is it? Is the driver source available somewhere?
freyr69: if it is an SDI to USB device, then the USB side probably advertises it as a webcam. In that case you're out of luck. From linux it just looks like a regular webcam. | [14:21] | |
| ..... (idle for 24mn) | ||
| *** | benjiG has left | [14:48] |
| prabhakarlad has left | [14:58] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |