<!-- 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>
***: hiroh has joined #linux-media
<br> eelstrebor has joined #linux-media
<br> hiroh has quit IRC (Remote host closed the connection)
<br> hiroh has joined #linux-media
<br> jarthur has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> eelstrebor has joined #linux-media
<br> eelstrebor has quit IRC ()
<br> jm_h has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
<br> GBenji has joined #linux-media
<br> ao2 has joined #linux-media
mriesch: in a driver for a hdmi/mhl receiver how could the input be specified (either hdmi or mhl)?
<br> an extcon in the device tree?
hverkuil: <u>mriesch</u>: perhaps extending this: Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
<br> <u>mriesch</u>: but if there is just a single input supported by the receiver, that can either be hdmi or mhl, then a property for that driver might be sufficient.
<br> connectors in the devicetree aren't used very often. i2c/tvp5150.c is the main user of it.
***: djrscally has joined #linux-media
mriesch: <u>hverkuil</u>: yes, it is a single input receiver.
<br> the property would be a simple solution. but this property would be driver-specific, right? or is there some kind of superclass for video decoders that could parse this property?
hverkuil: It would be driver specific. There are no MHL receivers inthe kernel today, so this is new.
<br> I am leaning a bit towards a proper mhl connector, but it would definitely be (a lot?) more work.
mriesch: not sure whether mhl is really a thing. i am not using it and therefore my driver cannot support it initially
<br> however, i would like that it is possible to extend it if someone feels like using mhl
***: svarbanov has joined #linux-media
mriesch: <u>hverkuil</u>: could i use hdmi-connector for the start and determine the connector type in my driver by checking the remote-endpoint? if yes, this should be quite generic, right?
***: hiroh has quit IRC (Remote host closed the connection)
hverkuil: That's what I had in mind. Look at tvp5150.c to see how that driver does it.
mriesch: <u>hverkuil</u>: ok, thanks for the pointer. i'll have a look
hverkuil: The problem is that support for hdmi connectors really should be hooked up in the media controller as well, just as was done for e.g. MEDIA_ENT_F_CONN_SVIDEO.
mriesch: btw, from a user space perspective what is a good way to iterate over all digital inputs and e.g. check their signal status or set the edid?
***: camus has joined #linux-media
<br> camus1 has quit IRC (Read error: Connection reset by peer)
hverkuil: Software typically sets the EDID for HDMI (and similar) receivers at boot time (VIDIOC_S_EDID). Digital video (DV) receivers must support the V4L2_EVENT_SOURCE_CHANGE event, and usually userspace will wait for that event, then call VIDIOC_QUERY_DV_TIMINGS to determine the signal status & video timings.
***: Bugies has joined #linux-media
mriesch: <u>hverkuil</u>: as to edid, how should the hdmi receiver behave before VIDIOC_S_EDID is called for the first time?
hverkuil: HPD should be low, so there is never a signal. See how existing HDMI receivers behave.
mriesch: and is there library of some sort? i guess i can iterate over all /dev/video*, but then i need to find the correct subdev to call VIDIOC_S_EDID on, right?
hverkuil: What is the bridge driver you use?
mriesch: <u>hverkuil</u>: an adapted version of the rockchip vip/cif v5 driver, which maxime chevallier posted a year ago
<br> does the bridge driver have to support the ioctls as well?
hverkuil: Is that an MC driver? Or a regular driver? In the latter case the bridge driver has to support the ioctls and pass them on to the subdev driver. In the first case it is the subdev driver that exposes the ioctls.
mriesch: <u>hverkuil</u>: not sure, but it does call media_device_register if this tells anything?
hverkuil: MC-centric (it calls v4l2_device_register_subdev_nodes)
<br> So it is just the subdev that has to support it.
mriesch: alright... then there must have been a mistake on my side. i called v4l2-ctl --set-edid and it told me that /dev/video0 does not support the ioctl. when applied to the subdev it works
hverkuil: by default v4l2-ctl uses /dev/video0. So if you need to select a subdev device node, then you need to provide that with the -d option.
mriesch: <u>hverkuil</u>: yes, with the -d option it works. but then i have to find the correct subdev device node myself, right?
***: pratyush has joined #linux-media
hverkuil: Yes. /dev/mediaX gives you the topology and the subdev nodes. It is more complicated, but that's where libcamera would come in. But I don't know if it supports hdmi receivers yet.
mriesch: right, i suspected that libcamera deals with the very same problem. just wondered whether libcamera is suitable because it is mainly for.. well.. cameras. but i think this discussion can be triggered in a different channel :-)
<br> <u>hverkuil</u>: thanks a lot for your help!
hverkuil: My pleasure. I'm the HDMI expert here, so feel free to ask any questions relating to that.
***: camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> hiroh has joined #linux-media
<br> camus1 has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> camus has quit IRC (Remote host closed the connection)
<br> camus has joined #linux-media
<br> paulk1 has joined #linux-media
paulk1: hi
<br> I'm playing with a pinecube (allwinner v3/s3 + ov5640 on parallel)
<br> and just noticed that media-ctl --set-v4l2 "'ov5640 1-003c':0[fmt:UYVY8_2X8/2592x1944@1/15]" doesn't work
<br> that's because the framerate was previously 1/30
<br> and apparently media-ctl will first set the dimensions and then the framerate
<br> so dimensions get rejected because it's invalid at 1/30 (and only valid at 1/15)
<br> however if I first set to 1/15 with another dimension (say 1920x1080) and then call the same media-ctl arguments, it works
<br> would it make sense for media-ctl to try to set the framerate before the dimensions?
<br> I guess this is a little bit confusing
jmondi: <u>paulk1</u>: I've had the same issue and my take is that the ov5640 driver should drop setting framerate with s_frame_interval() and have it controlled by VBLANK
paulk1: mhh I'm not sure about that
jmondi: in the meantime I'm afraid you will have to set the format twice, one to set the framerate, the second to set the actual format
paulk1: I kind of assumed it was taking place in two separate calls
<br> and the issue was the call order
jmondi: s_frame_interval() is a mis-leading API, which prevents explicit control of blankings
paulk1: it's definitely legit to have s_frame_interval to select between multiple framerates, isn't it?
jmondi: it is from an API standpoint, it creates more pain than gain in my opinion
paulk1: I don't see the benefit of exposing blanking to userspace at all
<br> users are probably far more interested in framerate
hverkuil: <u>jmondi</u>: shouldn't changing the frame size in ov5640 clamp the framerate if needed? What do other sensor drivers do?
jmondi: the discussion about what better API to use it's kind of tangential, as long as it is there and nobody changes it (I'm trying to as we speak :) you're left with a driver that requires two s_fmt() calls
<br> <u>paulk1</u>: I don't think so, userspace should set the blankings, and the framerate changes accordingly
<br> users care about the framerate, but the current 15,30,60 enumeration is a small subset of the possible ones
<br> the API seems to be simpler, but it creates more pain and limits the user possibilities to a few choices
paulk1: about s_fmt calls: I don't think the framerate is part of v4l2_mbus_framefmt, is it?
jmondi: <u>hverkuil</u>: it probably should, changing framerate according to the format should be doable
paulk1: so what happens is 1 call to s_fmt and 1 call to s_frame_interval
jmondi: but I would rather switch to contorl the blankings
pinchartl: <u>jmondi</u>: I agree with you, the .s_frame_interval() operation should not be implemented in most drivers
jmondi: as soon as I fix the exposure calculation I should have patches to do so
paulk1: my point is that it would make more sense to do s_frame_interval before s_fmt than the opposite
pinchartl: *except* for sensor that include an ISP that has direct frame rate control
hverkuil: it honestly sounds more like an overly strict behavior of ov5640. That's separate from the discussion of which API to use.
jmondi: <u>hverkuil</u>: yes, sorry I steer the discussion about the API as I'm looking at that right now :)
<br> <u>paulk1</u>: it is totally legit to set frame interval before the format in media-ctl if it helps
<br> but the issue is in the driver afaict
paulk1: well I also find it legit that ov5640 won't let you set dimensions that cannot be achieved for the set frame interval
pinchartl: I don't think changing the order of operations in media-ctl is a good idea. it may fix this, but could break other use cases
paulk1: ideally this would be atomic
pinchartl: yes, ideally we would have an atomic API :-)
jmondi: <u>paulk1</u>: as Hans said I wouldn't be agains reducing the framerate to accommodate the requested format
paulk1: yes that would be fair too IMO
jmondi: I don't think the API specifies how sensors should behave that
<br> s/sensor/sensor drivers/
<br> s/that//
<br> and I'm done with corrections, sorry :)
***: xiaer1921 has quit IRC (Quit: xiaer1921)
<br> hiroh has quit IRC (Remote host closed the connection)
<br> gouchi has joined #linux-media
<br> gouchi has quit IRC ()
<br> hiroh has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Remote host closed the connection)
<br> lucaceresoli has joined #linux-media
<br> djrscally has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has joined #linux-media
<br> eelstrebor has quit IRC ()
<br> hiroh has quit IRC (Remote host closed the connection)
mriesch: when linking e.g. a sensor subdevice and a bridge device, do i have to ensure that the mbus settings (bus-type, bus-width, ...) are of both endpoints are the same in the device tree?
<br> i assumed it was sufficient to specify the settings in one endpoint, but this does not seem to be the case
***: hiroh has joined #linux-media
hverkuil: <u>mriesch</u>: if I remember correctly they have to be provided on both sides, but they don't need to be identical (although they usually are).
pinchartl: they have to be compatible
<br> if one side has fixed settings then there's no need to specify the settings there
<br> the reason why they're usually specified on both sides in DT instead of being queried from one side by the other at runtime is that there could be hardware on the board that changes, for instance, polarity of signals
mriesch: so there is no check whether the dt settings + capabilities of the devices are compatible?
<br> suppose both devices are capable of bt.656 and parallel, and by mistake one chooses bt.656 here and parallel there?
***: svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
pinchartl: then it won't work
<br> don't do that :-)
mriesch: ok, so brain should be turned on when writing the device tree. noted.
pinchartl: sorry about the strain we put on your brain :-)
mriesch: :-)
<br> <u>pinchartl</u>: i have a hdmi receiver here that offers sampling on both clock edges. can pclk-sample be extended to reflect this?
pinchartl: as in a dual data rate ?
mriesch: e.g. by using 2 in this enum, and then activating both V4L2_MBUS_PCLK_SAMPLE_RISING and V4L2_MBUS_PCLK_SAMPLE_FALLING
<br> it's called double data rate here, but yes, i guess that'd be it
<br> "pixel clock rate halved, clocked with both rising
<br> and falling edges"
***: djrscally has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
<br> pratyush has quit IRC (Quit: Connection closed for inactivity)
<br> BrianG61UK has quit IRC (Read error: Connection reset by peer)
<br> BrianG61UK_ has quit IRC (Read error: Connection reset by peer)
<br> hiroh has quit IRC (Remote host closed the connection)
<br> lucaceresoli has quit IRC (Ping timeout: 480 seconds)
<br> GBenji has left
<br> gouchi has joined #linux-media
<br> eelstrebor has joined #linux-media
<br> darkapex3 has joined #linux-media
<br> darkapex2 has quit IRC (Ping timeout: 480 seconds)
<br> ezequielg_ has joined #linux-media
<br> Ampera_ has joined #linux-media
<br> feklee_ has joined #linux-media
<br> dagmcr_ has joined #linux-media
<br> arnd_ has joined #linux-media
<br> mchehab_ has joined #linux-media
<br> Lightsword_ has joined #linux-media
<br> cyrozap-ZNC has joined #linux-media
<br> b-rad has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> Ampera has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> VelcroPad has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> feklee has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> Lightsword has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> arnd has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> mchehab has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> dagmcr has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> ezequielg has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> cyrozap has quit IRC (synthon.oftc.net reflection.oftc.net)
<br> dagmcr_ is now known as dagmcr
<br> feklee_ is now known as feklee
<br> b-rad has joined #linux-media
<br> VelcroPad has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Remote host closed the connection)
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has quit IRC (Quit: Konversation terminated!)
<br> cisco87 has quit IRC ()
<br> cisco87 has joined #linux-media
mriesch: <u>pinchartl</u>: would using both bits be a reasonable way to describe dual edge sampling?
***: ao2 has quit IRC (Quit: Leaving)
pinchartl: that should probably work, yes
<br> you can submit a patch that does that
<br> <u>sailus</u>: any opinion ?
sailus: <u>pinchartl</u>: Weird stuff.
<br> It's the first time ever I hear anyone doing this on parallel interface. :-)
mriesch: <u>pinchartl</u>: ok i'll submit something for further discussion
sailus: I think it seems like a reasonable way to convey that information.
<br> vsync-active and hsync-active tell the polarity of the blanking.
<br> So is pclk-sample change all that is required?
<br> Or could there be dependencies to other existing properties?
<br> I have to say I'm more familiar with the serial buses.
mriesch: <u>sailus</u>: what exactly do you find weird? ;-)
sailus: Double data rate and parallel bus. :-)
<br> Well, hardware engineers are very innovative so maybe it was unavoidable?
mriesch: we are cheating everywhere we can :-)
sailus: The BT.656 and BT.601 are de-facto standards in this area and the vast majority of devices use these.
pinchartl: <u>sailus</u>: there's worse. I've seen parallel buses (for displays) where the SoC outputs one image on rising edges and another image on falling edges, to multiplex two outputs over one bus
sailus: Wow.
***: cisco87 has quit IRC ()
sailus: I wonder how does that look like in DT.
pinchartl: so you can connect two devices that sample on different edges
<br> I don't know, I haven't tried to implement it :-)
mriesch: <u>sailus</u>: apparently the hdmi receiver in question achieves max. 150 mhz pixel clock, and the dual edge sampling allows then 2160p30
<br> pixel clock on the output side, that is
***: cisco87 has joined #linux-media
mriesch: not with bt.656 though, but with bt.1120
sailus: Ah.
<br> Another option would then be to add this to the types of supported buses.
<br> There could be other parameters that are relevant for that bus.
<br> I think this actually would be a better option.
mriesch: for all i know, the {h,v}sync polarity should not be affected. clearly not in the bt.656/bt.1120 case, where the syncs are integrated in the transmitted data
sailus: Ok, then you simply wouldn't need these properties.
mriesch: sorry,i don't follow: what would you add to the supported buses?
***: eelstrebor has quit IRC (Quit: Ex-Chat)
sailus: BT.1120?
<br> What that "parallel" really is there is BT.601.
<br> It actually should be renamed.
mriesch: ah right. well i thought so too, but it seems bt.1120 is covered by bt.656, the only difference being the bus width
<br> https://elixir.bootlin.com/linux/latest/source/include/media/v4l2-mediabus.h#L100
<br> since the bus width is represented by a property, i would suggest to follow likewise and use a property for dual edge sampling. (the hdmi receiver is able to play all combinations)
***: jm_h has quit IRC (Remote host closed the connection)
<br> gouchi has quit IRC (Remote host closed the connection)
sailus: Does BT.1120 always use DDR?
mriesch: <u>sailus</u>: no not necessarily
sailus: Well then, I guess the property is the way to go then.
<br> I downloaded the spec but took just a brief glance.
<br> But should there be a new bus-type? That I think remains open.
***: jarthur has joined #linux-media
<br> djrscally has joined #linux-media
<br> BrianG61UK has joined #linux-media
<br> jarthur has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has joined #linux-media
<br> hiroh has joined #linux-media