[08:59] <hverkuil> mchehab: can you look at the m32r error in the daily build? http://www.xs4all.nl/~hverkuil/logs/Friday.log
[08:59] <hverkuil> drivers/media/tuners/tuner-simple.o: In function `v4l2_mc_pci_media_device_init':
[08:59] <hverkuil> /home/hans/work/build/media-git/include/media/v4l2-mc.h:134: multiple definition of `v4l2_mc_pci_media_device_init'
[08:59] <hverkuil> drivers/media/tuners/tuner-xc2028.o:/home/hans/work/build/media-git/include/media/v4l2-mc.h:134: first defined here
[09:01] <mchehab> hverkuil: ok, I will
[09:02] <hverkuil> I got the same report from krobot mails.
[09:02] <mchehab> yes, I saw. I guess I fixed it locally already
[09:02] <mchehab> but didn't push yet
[09:02] <mchehab> (as there are other patches on my branch that weren't send upstream yet)
[09:03] <hverkuil> /home/hans/work/build/media_build/v4l/v4l2-mc.c: In function 'v4l2_mc_create_media_graph':
[09:03] <hverkuil> /home/hans/work/build/media_build/v4l/v4l2-mc.c:60:69: warning: variable 'sensor' set but not used [-Wunused-but-set-v
[09:03] <hverkuil> ariable]
[09:04] <hverkuil> I also get that ^^^ warning
[09:04] <hverkuil> about unused sensor variable.
[09:05] <hverkuil> Thanks for picking up the adv7604 regression fix, BTW.
[09:36] <hverkuil> pinchartl: do you want to discuss multiple concurrent streams now? I have time.
[09:37] <sailus> What a coincidence!
[09:39] <sailus> Could pinchartl be still asleep?
[09:46] <mchehab> hverkuil: patches sent. the first two patches should address the above issues
[09:47] <mchehab> I'll check later the issue with the "sensor" var
[09:52] <mchehab> i won't have much time today for discussions... the best would be if we can start discussing in ~10-15 mins
[09:53] <mchehab> as I'll have some other meetings in ~1 hour from now
[09:53] <hverkuil> well, pinchartl is MIA, so fingers crossed.
[09:54] <mchehab> oh
[09:55] <mchehab> I might be have more time at the afternoon (on my local time), but that could be late for sailus
[09:55] <mchehab> but I'm receiving some visitors today
[09:56] <mchehab> so it is hard to foresee in advance
[09:56] <hverkuil> I'm available on Monday as well for discussions.
[09:56] <mchehab> Monday is OK to me
[09:56] <hverkuil> Tue-Thu is difficult for me these days for long discussions.
[09:57] <hverkuil> BTW, I've been thinking about connectors and I really like the 'signal functions' idea. I think it will work very well.
[09:58] <mchehab> yes, I guess so
[09:59] <mchehab> I've thinking about the MEDIA_ENT_F_CONN_TEST, and I think this one is misnamed... it should be actually named as: MEDIA_ENT_F_VIDEO_TEST_GENERATOR, and this is not really a connector
[10:02] <hverkuil> Shouldn't it be removed altogether? If this is an input for the video generator, then this should be done with the V4L2_CID_TEST_PATTERN control (as in drivers/media/platform/s3c-camif/camif-capture.c).
[10:03] <hverkuil> As you say, it is not an input at all, it is a setting in the video receiver entity.
[10:15] <mchehab> hverkuil: fixed the sensor warning
[10:15] <mchehab> hverkuil: it is a input that could be set via SETUP_LINK
[10:16] <mchehab> and it is a hardware block
[10:17] <hverkuil> Reading tvp5150 code: does the tvp5150 create connector entities?
[10:17] <mchehab> on several devices, this is an input for the decoder
[10:17] <mchehab> for an internal hardware generator block
[10:17] <mchehab> hverkuil: yes and no ;)
[10:19] <mchehab> the creation of the connector/input entities are done either via DT or by the bridge driver
[10:19] <mchehab> e. g. it is created by the piece of software that knows the full hardware diagram
[10:20] <mchehab> so, in the case where the hardware is known by the bridge (em28xx is the only bridge that uses tvp5150)...
[10:20] <mchehab> it is up to the bridge (em28xx) to create the tvp5150 connectors
[10:20] <hverkuil> Good.
[10:20] <mchehab> in the case of omap3 boards with tvp5151...
[10:21] <mchehab> the connectors are created by tvp5150 driver using DT info
[10:23] <mchehab> see changeset 82c2ffeb217a
[10:23] <hverkuil> I'm a bit worried about the link to connectors in tvp5150. The tvp5150 sink pads may be connected to another device instead of to a connector. An FPGA for example. It makes assumptions that may not be true.
[10:24] <hverkuil> BTW, my apologies for not reviewing MC patches for the past 2-3 months: it's just been too busy. But it looks like I'll have more time now.
[10:25] <mchehab> hverkuil: do you have a better idea to describe connectors?
[10:25] <mchehab> I can see only three alternatives for DT to describe the connectors:
[10:25] <mchehab> 1) as a property to the entities that have it;
[10:26] <mchehab> (tvp5150)
[10:26] <mchehab> 2) as a master/bridge property (omap3)
[10:26] <mchehab> 3) as a property that a "connectors" driver would handle
[10:26] <mchehab> (2) seems wrong, as omap3 should not know anything about the input ports of the tvp5150 driver
[10:27] <mchehab> (3) also seems worse than (1), specially since we could not label things as: TVP5150_COMPOSITE0 on such generic driver
[10:28] <hverkuil> Let me try to understand the tvp5150 code better: it looks at the connectors property and it creates connector entities based on that (in the registered_async function), right?
[10:29] <mchehab> btw, I don't think that the case of a FPGA->tvp5150 should be mapped as 'connector'... this would actually be a separate entity (FPGA) that would be created, and such link would be done via SETUP_LINK
[10:29] <mchehab> yes
[10:31] <mchehab> the point is that, IMHO, from DT PoV, connectors are actually a hardware attribute, and not a separate piece of hardware
[10:31] <mchehab> it is just like a GPIO pin
[10:32] <hverkuil> You mean MEDIA_IOC_SETUP_LINK? Userspace shouldn't have to call an ioctl to setup a link to an fpga. Or do you mean media_entity_setup_link?
[10:33] <mchehab> either way would work... I guess that depends on the actual board design
[10:33] <hverkuil> Anyway, shouldn't the DT port/endpoint mechanism be used to describe the links between connectors/entities?
[10:34] <hverkuil> (of course if there is no DT then it comes from the board description in a PCI/USB device driver)
[10:34] <hverkuil> connectors have source pads and those link up to tvp5150 sink pads.
[10:35] <mchehab> I'm not against using port/endpoint for setting up the pipeline via DT...
[10:35] <mchehab> but I guess this is an overkill for connectors
[10:36] <hverkuil> One very practical problem I have with the current code in tvp5150 is that it bails out if there are no connectors (e.g. in the case of an FPGA). It's basically makes assumptions about how it is hooked up, and history has proven that that always bites us in the ass :-)
[10:36] <mchehab> representing connectors like this seem to work fine for me:
[10:36] <mchehab> + connectors {
[10:36] <mchehab> + composite0 {
[10:36] <mchehab> + label = "Composite0";
[10:36] <mchehab> + input = <TVP5150_COMPOSITE0>;
[10:36] <mchehab> + };
[10:37] <mchehab> hverkuil: well, that's easy to fix ;)
[10:37] <hverkuil> I don't think it is overkill. I like that it uses the same mechanism.
[10:37] <mchehab> well, feel free to propose a patch
[10:38] <hverkuil> Note that more complex connectors (HDMI) will have multiple output ports: one for video/audio (tmds) one for CEC, one for ARC and theoretically one for HEC (HDMI ethernet).
[10:38] <hverkuil> These can be hooked up to different entities.
[10:38] <mchehab> true
[10:38] <hverkuil> So I really think we should keep to the port/endpoint mechanism.
[10:38] <mchehab> ok
[10:38] <hverkuil> That's generic and is consistent with other entities.
[10:38] <mchehab> let's do it then
[10:39] <hverkuil> Really sorry for seeing this so late.
[10:39] <mchehab> we should ping javier__ about that
[10:39] <mchehab> no problem. this is easily fixed
[10:40] <hverkuil> Thank you!
[10:40] <mchehab> javier__ is probably still sleeping, but hopefully he'll see the above and provide us his comments
[10:40] <mchehab> when he arrives
[10:42] <hverkuil> And the TVP5150_GENERATOR 'connector' should be replaced by the TEST_PATTERN control. It's really not a connector.
[10:43] <mchehab> it is not a control
[10:43] <mchehab> it is a separate input source
[10:43] <hverkuil> let me check the datasheet
[10:44] <mchehab> see tvp5150_selmux
[10:45] <mchehab> hmm... it could be mapped as a control, I guess
[10:45] <mchehab> ok, I'm OK mapping it as a control
[10:47] <hverkuil> I'm trying to find the relevant section in the tvp5150am1 datasheet. Do you know which register I should look at?
[10:48] <hverkuil> (now I am getting interested :-) )
[10:48] <mchehab> TVP5150_VD_IN_SRC_SEL_1
[10:49] <mchehab> bit 3
[10:49] <mchehab> drivers/media/i2c/tvp5150_reg.h:#define TVP5150_VD_IN_SRC_SEL_1 0x00 /* Video input source selection #1 */
[10:49] <hverkuil> Ah, just a black screen if that bit is set.
[10:50] <hverkuil> Definitely a control, not an input.
[10:50] <mchehab> please notice that only tvp5150am1 and upper
[10:50] <hverkuil> very poor-mans test signal :-)
[10:50] <mchehab> we need to take a look on some other drivers:
[10:50] <mchehab> git grep -e VMUX --and -e DEBUG drivers/media
[10:50] <mchehab> yes
[10:51] <mchehab> cx88 and cx23885 seem to have VMUX_DEBUG mapped as inputs for some boards
[10:51] <mchehab> .name = "Hauppauge WinTV 34xxx models",
[10:51] <hverkuil> These drivers were made when the test pattern control didn't exist.
[10:52] <mchehab> .name = "Hauppauge WinTV 28xxx (Roslyn) models",
[10:53] <mchehab> .name = "KWorld LTV883RF",
[10:53] <mchehab> .name = "PowerColor RA330", /* Long names may confuse LIRC. */
[10:53] <mchehab> ..
[10:53] <mchehab> if we're going to convert to a control, this needs to be fixed
[10:54] <mchehab> but *I have no idea* how to do it
[10:54] <mchehab> as we don't have all those hardware
[10:55] <mchehab> in the case of cx88, it is not only a VMUX input selection, the test input also has different GPIOs
[10:55] <hverkuil> I wonder if it works *at all*.
[10:57] <mchehab> I've no idea... I don't have such boards
[10:58] <mchehab> on cx23885: .name = "Hauppauge WinTV-HVR1800lp",
[10:58] <mchehab> au0828 and cx231xx also declare a VMUX_DEBUG input, but those are unused
[10:59] <mchehab> so, the only two drivers we need to take kare are cx88 and cx23885
[10:59] <mchehab> (saa7134 used to declare, but I removed it last week)
[11:08] <hverkuil> mchehab: I'll go through my hw collection to see if I have one of these models.
[11:16] <mchehab> ok, thanks
[11:21] * pinchartl reads the backlog
[11:22] <mchehab> got rid of the VMUX_DEBUG from au0828 and cx231xx... only cx88 and cx23885 remaining
[11:25] <pinchartl> mchehab: 82c2ffeb217a is very, very wrong
[11:25] <pinchartl> connectors should *not* be created by the tvp5150 driver
[11:25] <pinchartl> and certainly not described in its DT node !
[11:25] <pinchartl> connectors should have their own DT node
[11:25] <pinchartl> with a compatible property
[11:26] <pinchartl> and linked to other devices using the of graph bindings
[11:26] <pinchartl> with port nodes
[11:29] <pinchartl> agreed ?
[11:30] <hverkuil> pinchartl: it's what I said as well and mchehab agreed. Will be changed.
[11:31] <pinchartl> :-)
[11:31] <pinchartl> one question is whether we should create drivers for connectors
[11:31] <pinchartl> it's probably overkill
[11:32] <pinchartl> but on the other hand duplicating the connector entities creation code in many drivers isn't a good idea either
[11:32] <hverkuil> I see no reason for that (yet). A driver implies that you can change something, and that's not the case for connectors.
[11:32] <hverkuil> You obviously want helpers for that.
[11:34] <hverkuil> mchehab: I don't have any of the hw with a debug input. (I'm close: I have the cx23885 HVR1800, but I need the HVR1800lp :-) )
[11:34] <hverkuil> I would just remove it (or comment it out waiting for someone with HW to test).
[11:34] <hverkuil> Or ask stoth, he might have hw.
[11:35] <hverkuil> I have never heard of anyone using it and I have frankly no idea what it does or if it still works.
[11:50] <mchehab> hverkuil: one of the hardware profiles says that without the VMUX_DEBUG, the hardware breaks
[11:50] <javier__> mchehab, hverkuil: good morning, give me some mins to read the long backlog :)
[11:50] <mchehab> (one of the cx88 profile RA 330, I guess)
[11:51] <mchehab> we could just ignore them when converting those drivers to MC
[11:52] <mchehab> I mean: create connectors just for the other inputs and not creating anything for the VMUX_DEBUG ones
[11:53] <awalls_> 1800lp should just be a low profile board.
[11:54] <awalls_> I'm not sure why it would differ greatly from a normal hvr1800.
[11:59] <awalls_> the hvr1800s card entry has the vmux_debug entry as well.
[12:02] <javier__> hverkuil, pinchartl: yeah I thought about using port / endpoints for connectors but then noticed that the remote point would point to the same device node (tvp5150) so I didn't know if that was the correct approach
[12:04] <javier__> pinchartl: same question for having a compatible string with no driver to bind
[12:04] <pinchartl> a compatible string with no driver isn't an issue from a DT point of view
[12:04] <pinchartl> DT doesn't know about drivers
[12:05] <hverkuil> awalls_: I see no hvr1800s entry?
[12:05] <javier__> pinchartl: yes I know that is a HW description but I thought the idea of the compatible is to bind to "something"
[12:06] <pinchartl> no, it's to tell what the device is compatible with
[12:06] <pinchartl> we use it to bind drivers to devices of course
[12:06] <awalls_> That's the plural of hvr1800.
[12:06] <awalls_> not a 's' variant.
[12:06] <awalls_> sorry.
[12:06] <javier__> pinchartl: Ok, I'll give a try to the graph DT binding then
[12:07] <awalls_> but the plain hvr1800 entry has it
[12:08] <hverkuil> awalls_: it does? I don't see it.
[12:08] <pinchartl> thanks
[12:08] * awalls_ realizes hvr1800s was a weird phone autocorrect entry.
[12:08] <awalls_> http://lxr.free-electrons.com/source/drivers/media/video/cx23885/cx23885-cards.c?v=2.6.24
[12:08] <awalls_> oops old code.
[12:08] <hverkuil> Ah, I thought it might be.
[12:09] <hverkuil> let me look in the git log
[12:10] <awalls_> looks like the lp might not have ever been tested with analog.
[12:10] <javier__> hverkuil: any example of a driver using the TEST_PATTERN control ?
[12:11] <awalls_> based on the change to get th regular 1800 working with analog
[12:11] <hverkuil> stoth removed VMUX_DEBUG support in commit 7b8880140ff6aec6a5bec7929b03ce0b96a7c79a
[12:11] <hverkuil> in 2008.
[12:11] <hverkuil> the log doesn't tell why, but I think it was just pointless code.
[12:11] <awalls_> looks like it.
[12:11] <hverkuil> javier__: drivers/media/platform/s3c-camif/camif-capture.c
[12:12] <javier__> hverkuil: ok, thanks!
[12:12] <awalls_> placeholder for the analog tuner input.
[12:13] <hverkuil> javier__: also drivers/media/i2c/ov9650.c
[12:14] <javier__> hverkuil: ok
[12:29] <mchehab> pinchartl, hverkuil, sailus, javier__: I have some time right now for discussions
[12:29] <hverkuil> I don't. meeting.
[12:29] <pinchartl> I do
[12:30] <pinchartl> hverkuil: do you know when you will be done with the meeting ?
[12:30] <mchehab> hverkuil: when do you have time?
[12:30] <hverkuil> 30-60 minutes from now (probably closer to 30)
[12:31] <mchehab> seems good for me
[12:32] <pinchartl> fine with me
[12:32] <pinchartl> sailus: ?
[12:33] <javier__> fine with me as well
[12:54] <sailus> I'm available in 5 minutes.
[12:54] <sailus> I'll need to leave in an hour and 15 minutes though, but before that will be fine.
[12:58] <hverkuil> meeting almost done
[12:59] <mchehab> hverkuil: ping us when you're ready
[12:59] <hverkuil> ping!
[12:59] <hverkuil> :-)
[13:00] <hverkuil> mchehab: pinchartl: sailus: ping
[13:00] <sailus> Pong.
[13:01] <pinchartl> pong
[13:02] <mchehab> pong
[13:02] <hverkuil> all complete.
[13:02] <mchehab> ok, let's start meeting - the focus is connectors... a quick summary about what's discussed so far:
[13:03] <mchehab> 1) we'll remove the CONN_TEST... it is not really a connector
[13:03] <mchehab> 2) on our yesterday's discussions, both I and Hans think that the connector function should identify the signals of the connector, not its physical connector
[13:04] <mchehab> if needed/wanted, the physical connector could be mapped via the properties API
[13:05] <mchehab> pinchartl was reluctant on allowing that a connector would have multiple functions... hverkuil presented the case of HDMI connectors, where multiple functions could be present
[13:05] <pinchartl> no
[13:05] <pinchartl> what I don't like is a connector having multiple types
[13:05] <pinchartl> such as reporting it's both an svideo connector and a composite connector
[13:05] <mchehab> pinchartl: we removed "types" from entities
[13:06] <pinchartl> we did, but the function field is currently used to report connector types
[13:06] <hverkuil> it can have multiple signals, it can't have multiple types. Which makes sense.
[13:06] <pinchartl> if we use it to report what signals the connector can carry then it's a different story
[13:06] <pinchartl> in which case reporting multiple signal types can make sense
[13:06] <hverkuil> ack
[13:07] <hverkuil> So F_CONN should be renamed to F_SIG or F_SIGNAL (no preference)
[13:07] <mchehab> ack
[13:07] <pinchartl> if we go that way I want to make sure the documentation clearly explains that the functions relate to signals, not connector types
[13:07] <pinchartl> sailus: that's a recap of yesterday's discussions. what's your opinion ?
[13:07] <mchehab> hverkuil: I don't like naming it as F_SIG/F_SIGNAL...
[13:07] <sailus> I'm in a process of forming an opinion. :-)
[13:08] <mchehab> I guess it is just a matter to make it clearer ad the documentation
[13:08] <hverkuil> or F_CONN_SIG_
[13:09] <hverkuil> I think I like to see SIG in the define to prevent confusion with connector type as opposed to connector signal.
[13:09] <mchehab> could be, but it is just a bigger macro name for no good reason, IMHO ;)
[13:09] <pinchartl> it's clearer. just F_CONN_ is ambiguous
[13:10] <sailus> I think it'd be important to tell what signals there are in the connector, but not necessarily by providing an exhaustive enumeration API.
[13:10] <mchehab> too big names would cause lots of 80 cols troubles
[13:10] <pinchartl> think of F_CONN_CEC for instance
[13:10] <hverkuil> If I see CONN_SVIDEO, then I think it is about the type.
[13:10] <pinchartl> there's no CEC connector
[13:10] <pinchartl> hverkuil: agreed
[13:10] <sailus> The 4-contact plug connectors can carry audio or audio+video, for instance.
[13:10] <pinchartl> do you mean the 4-contact 3.5mm jack connectors ?
[13:11] <sailus> Well, plugs and jacks.
[13:11] <sailus> Yes.
[13:11] <hverkuil> mchehab: F_SIG_ is shorter than F_CONN_ if length is a concern :-)
[13:11] <hverkuil> I'm OK with SIG, SIGNAL, CONN_SIG, as long as there is a SIG :-)
[13:12] <pinchartl> let me recap this
[13:12] <pinchartl> we agree that connector entities should report
[13:12] <pinchartl> - their physical type
[13:12] <pinchartl> - their label
[13:12] <pinchartl> - their colour
[13:12] <pinchartl> - their location
[13:12] <pinchartl> - the signals they carry
[13:12] <pinchartl> correct ?
[13:12] <mchehab> s/should/could/
[13:13] <mchehab> (I mean, those attributes should be optional)
[13:13] <pinchartl> ok, to rephrase it
[13:13] <hverkuil> 'should' for the signals, 'could' for the others.
[13:13] <pinchartl> "that the API shall allow connector entities to report"
[13:13] <sailus> Possibly also which pins carry which signals.
[13:14] <mchehab> pinchartl: IMHO, different signals should be mapped via different PADs (in cases like the HDMI connector)
[13:14] <hverkuil> sailus: I don't think that makes sense. That's more a thing for a product manual.
[13:14] <mchehab> but it should be represented as a single entity
[13:14] <pinchartl> one question at a time please
[13:14] <pinchartl> 1. "the API shall allow connector entities to report: physical type, label, colour, location, signals being carried"
[13:14] <sailus> hverkuil: I'm certainly fine postponing. I just wanted to give you something to think about. :-)
[13:14] <pinchartl> yes or no ?
[13:15] <mchehab> yes
[13:15] <hverkuil> pinchartl: almost. Which signals it carries *must* be reported, the others are optional.
[13:16] <pinchartl> that's not the question :-)
[13:16] <sailus> hverkuil: What'd the background for mandatory signals?
[13:16] <pinchartl> the question is about what the API can report
[13:16] <pinchartl> the second question will be what is mandatory and what isn't
[13:16] <hverkuil> 1): OK
[13:16] <pinchartl> mchehab, sailus: opinion about 1. ?
[13:16] <mchehab> 1) OK
[13:16] <sailus> Sounds good to me.
[13:18] <pinchartl> ok
[13:18] <pinchartl> then
[13:18] <pinchartl> regarding mandatory properties
[13:18] <pinchartl> label, colour and location should in my opinion be optional
[13:19] <hverkuil> I agree. Although it is desirably that at least one is given.
[13:19] <hverkuil> desirable
[13:19] <pinchartl> physical type should be mandatory, even though we can't report it today due to a lack of API
[13:19] <pinchartl> yes, it's desirable
[13:19] <pinchartl> but it doesn't always make sense
[13:19] <hverkuil> I am not sure if the physical type should be mandatory. I'd group it as optional.
[13:19] <mchehab> IMO, the mandatory properties to be reported is the signal type and label... and the primary one should be at entity->function. All other signals reported via properties API
[13:20] <hverkuil> The point is to allow the user to identify the connector by label, type, color, location.
[13:20] <mchehab> we can't make pyhsical type mandatory...
[13:20] <pinchartl> not all connectors have labels
[13:20] <hverkuil> You may not know the type if it is e.g. on a daughterboard and they change the connector type.
[13:20] <mchehab> there are several boards with a proprietary physical connector
[13:21] <mchehab> mapping those nowadays seems mission impossible
[13:21] <hverkuil> E.g. a composite input can come in quite a few variations and a manufacturer can change that at will.
[13:21] <pinchartl> we could have a custom physical type. I don't like it much, but some connectors are really custom
[13:21] <pinchartl> the idea of the type is to help the user identify the connector
[13:22] <pinchartl> if an applications tells me "connect an input to connector 5" it doesn't help me much
[13:22] <mchehab> Hauppauge uses a custom connector (it is all the same, I guess) for USB sticks to connect to S-Video and Composite
[13:22] <hverkuil> It does if '5' is a label.
[13:22] <pinchartl> if the application tells me "connect an input to the HDMI connector" or "to the blue audio jack", it's much better
[13:22] <pinchartl> only if there's a label
[13:23] <hverkuil> As I said it is desirable that at least one of (label, type, color, location) is given in order to locate the connector.
[13:23] <sailus> How many users can in general recognise connectors based on how do they look like?
[13:23] <hverkuil> It depends on the product which combination works best.
[13:23] <mchehab> where there's no label, we can use the name of the connector type as the label (e. g. "S-Video", "Composite")
[13:23] <sailus> Colours and labels are much better for that purpose.
[13:23] <pinchartl> it's desirable to report all of the label, type, colour and location properties when they're available/applicable
[13:24] <mchehab> sailus: yes, it is, but it is hard to map on already existing boards
[13:24] <hverkuil> 'it is desirable to report as many of the label, type, colour and location properties as possible for the product'
[13:24] <pinchartl> sailus: for common connector types it's not too bad. most users can tell an HDMI connector apart from a 3.5mm audio jack
[13:24] <pinchartl> although the main function of the connector might be something more useful
[13:24] <mchehab> I guess we have >1000 boards supported
[13:24] <hverkuil> s/desirable/recommended/
[13:25] <pinchartl> "connect an input to the video connector"
[13:25] <pinchartl> "connect an input to the audio connector"
[13:25] <mchehab> we don't have 10% of those boards in hands to check those props
[13:25] <hverkuil> label and type is available in most drivers.
[13:25] <hverkuil> color/location isn't
[13:25] <pinchartl> mchehab: we're not talking about making them mandatory
[13:26] <pinchartl> as they're optional, if we don't have the information, we don't have to report it
[13:26] <hverkuil> right
[13:26] <pinchartl> regarding using the connector type as a label, I don't like that
[13:26] <pinchartl> I'd prefer reporting the connector type separately
[13:26] <hverkuil> ??? type is a separate property.
[13:26] <pinchartl> and let applications decide how to display the information to the user
[13:26] <pinchartl> hverkuil: Mauro proposed "where there's no label, we can use the name of the connector type as the label (e. g. "S-Video", "Composite")"
[13:27] <pinchartl> I'm fine doing something like that in userspace
[13:27] <sailus> Could we just consider type, label and colour all optinal, and report what's available?
[13:27] <hverkuil> Well, we will do that for ENUMINPUT.
[13:27] <sailus> That's up to the user space anyway.
[13:27] <pinchartl> but in kernelspace we shouldn't fill the label with the connector type
[13:27] <hverkuil> for backwards compat.
[13:27] <mchehab> yes, ENUMINPUT requires a label
[13:27] <hverkuil> But the MC shouldn't report a label where there isn't one defined.
[13:27] <mchehab> so, the label is already mandatory
[13:28] <hverkuil> Well...
[13:28] <pinchartl> let's not change what ENUMINPUT reports today
[13:28] <pinchartl> no need to modify existing drivers when it comes to labels reported by ENUMINPUT
[13:28] <mchehab> hverkuil: how do you propose to discover what those labers are not defined ?
[13:28] <mchehab> on the already existing boards?
[13:29] <hverkuil> mchehab: sorry, I don't understand your question
[13:29] <mchehab> I mean, right now, all PC-consumer's boards have a label defined
[13:30] <hverkuil> So those have a label and we should use that label. You are right, there are no consumer boards without a label.
[13:30] <hverkuil> I think they all provide both label and connector type.
[13:30] <mchehab> and those labels (or pseudo-labels) are the ones used by userspace apps when they present the inputs of a boards
[13:30] <hverkuil> so the case where there is only a type and no label isn't found in the current drivers.
[13:31] <mchehab> yes
[13:31] <mchehab> (if those labels match what users see in board or not is a separate question, but mapping it for all boards would be impossible)
[13:32] <pinchartl> it's not a separate question
[13:32] <hverkuil> so we all agree that: "it is recommended that as many as possible of the label, type, colour and location properties are filled in"
[13:32] <pinchartl> the label reported through entity properties should be the user-visible label present on the device
[13:32] <pinchartl> not a pseudo-label created by drivers
[13:33] <hverkuil> pinchartl: yes it should but we don't know. We have no choice in the matter.
[13:33] <pinchartl> hverkuil: I'd still like the connector type to be mandatory, as there's always a type
[13:33] <mchehab> pinchartl: are you offering to map all those boards and check what labels they actually have?
[13:33] <mchehab> that's something that I won't do
[13:33] <pinchartl> mchehab: no. for boardw we can't map we can leave the label empty
[13:33] <hverkuil> pinchartl: you may not know the type. It's rare, but it can happen.
[13:33] <pinchartl> s/boardw/boards/
[13:33] <pinchartl> ok, one question at a time please
[13:33] <pinchartl> labels first
[13:33] <javier__> but if there is no label, to what should be set the entity .name ?
[13:34] <pinchartl> that's a third question :-)
[13:34] <javier__> ok :)
[13:34] <mchehab> no, it is the same question
[13:34] <pinchartl> the label property should carry the user-visible label as present on the device
[13:34] <pinchartl> if there's no label, or if a driver can't know the label, then the property should not be reported
[13:35] <javier__> pinchartl: that's really hard to enforce without access to all the hw IMHO
[13:35] <pinchartl> javier__: why ?
[13:35] <hverkuil> Agreed. But for existing drivers we *don't know* if the label matches a backplane (or documentation! I think that is a viable alternative). So let's just keep what existing drivers report. No need to mess that up.
[13:36] <pinchartl> it's hard to know what labels are used on all boards, but it's not hard to know we don't know :-)
[13:36] <mchehab> pinchartl: on my experience, most PCI hardware have labels for the inputs
[13:36] <javier__> pinchartl: right
[13:36] <sailus> pinchartl: Do you need struct media_entity.name or a would-be property called "name"?
[13:36] <mchehab> most USB hardware don't
[13:36] <pinchartl> sailus: one question at a time please!
[13:36] <mchehab> but there are exceptions on both cases
[13:36] <hverkuil> What ENUMINPUT reports should match hw or manual, so I think it is a safe assumption that it is a useful label.
[13:37] <pinchartl> hverkuil: I doubt that
[13:37] <pinchartl> I'm pretty sure lots of drivers report the connector type as a label for ENUMINPUT
[13:37] <pinchartl> especially when there's no label
[13:37] <pinchartl> again, let's not change what ENUMINPUT reports
[13:37] <mchehab> pinchartl: on lots of hardware, the label *is* the connector type
[13:37] <hverkuil> I have a large collection of hardware and I can't think of a single instance where the label doesn't help me identify the connector.
[13:37] <mchehab> (plus a number, when there are multiple outputs of the same connector type)
[13:37] <pinchartl> but let's not report a label property through MC if we don't have a label or don't know if we have a label
[13:38] <mchehab> pinchartl: I'm guessing that maybe we're talking about different things...
[13:39] <mchehab> right now, the way it is currently mapped on the MC graph (see https://mchehab.fedorapeople.org/mc-next-gen/?C=M;O=D)
[13:39] <mchehab> is that the entity->name is associated with the connector label
[13:39] <mchehab> with matches what's reported by ENUM_INPUT
[13:39] <pinchartl> right now we have no label in the MC API
[13:40] <pinchartl> we're talking about a new label property
[13:40] <mchehab> ah, ok
[13:40] <mchehab> so, if I understand you, you're saying that we should keep using what we currently have at ENUM_INPUT for entity->name...
[13:40] <mchehab> and add a *new* property for the label
[13:40] <mchehab> right?
[13:41] <pinchartl> I haven't thought about entity->name yet
[13:41] <pinchartl> what I'm saying it
[13:41] <pinchartl> s/it/is/
[13:41] <pinchartl> - let's not touch ENUMINPUT
[13:42] <pinchartl> - let's add a new label property that reports the label as present on the device. the property will be optional and recommended, devices that have no label or for which the label isn't known will not report that property
[13:43] <mchehab> I'm ok with that, but before that we need the properties API patch....
[13:43] <mchehab> while we don't have, IMHO, we should focus on what the API can currently report
[13:43] <hverkuil> pinchartl: I've changed my mind about the label. Sorry :-)
[13:44] <hverkuil> I think there should always be a label. Asking apps to make up a label based on other properties will cause a big inconsistent mess.
[13:44] <pinchartl> mchehab: I won't block the implementation until the property API is available, but I think we should already agree on what properties should be defined
[13:44] <hverkuil> And requiring that the label matches the backplane is also untenable since in many, many cases all you have is an icon.
[13:45] <pinchartl> icons are interesting too
[13:45] <hverkuil> Usually the user manual provides proper names, and the label should match those.
[13:45] <pinchartl> if the user manual has a label I could be convinced to report that, even if it's not printed on the device
[13:45] <hverkuil> And if there is nothing in the user manual, then saying "S-Video" as the label is fine by me.
[13:45] <pinchartl> but when it doesn't
[13:45] <pinchartl> when there's no label at all
[13:45] <pinchartl> I don't want the kernel to make one up
[13:45] <javier__> maybe we can discuss about a "name" property for now and forget the label?
[13:46] <hverkuil> But all that happens in that case is that the applications make one up.
[13:46] <pinchartl> javier__: if we can't agree on the label I don't think we can agree on the name
[13:46] <hverkuil> You just move the problem to apps.
[13:46] <hverkuil> And they will do it inconsistently.
[13:46] <hverkuil> So different apps give different names.
[13:46] <hverkuil> Probably based on the connector type, but new types will be added all the time that apps don't know how to translate to a string.
[13:46] <pinchartl> we can handle that in a libmediactl
[13:47] <mchehab> I agree with hverkuil... inconsistent labeling is a very bad issue
[13:47] <pinchartl> the kernel API can't handle i18n
[13:47] <pinchartl> it's already pretty messy for controls
[13:47] <pinchartl> let's not repeat the same mistake
[13:47] <pinchartl> I'm fine with helpers in libmediactl to create a display name
[13:47] <hverkuil> so who's going to make the mythical libmediactl?
[13:48] <pinchartl> we already have a libmediactl :-)
[13:48] <mchehab> what we have doesn't work... it would need to be rewritten, with a different ABI
[13:48] <pinchartl> we need to finalize its API, we never took the time to review it all together
[13:48] <hverkuil> and kernel and libs typically go out of sync very quickly.
[13:48] <mchehab> for it to benefit the changes with V2
[13:48] <pinchartl> mchehab: no issue with that, the API isn't set in stone, it's not even built as a .so now
[13:49] <pinchartl> which needs to be fixed at some point
[13:49] <pinchartl> and I expect API changes then
[13:49] <hverkuil> I don't mind having a libmediactl that does i18n, but I believe a fallback in the kernel is always good so we can always provide a label.
[13:49] <pinchartl> I don't agree
[13:50] <pinchartl> if we make up a label in the kernel
[13:50] <pinchartl> applications won't know whether it's a proper label or a made-up one
[13:50] <mchehab> hverkuil, pinchartl: I guess I need to see the properties API patchset and the libmediactl proposal in order to better position myself about that matter
[13:50] <pinchartl> the philosophy behind the MC API is to expose device information as-is to userspace
[13:50] <sailus> If we assign e.g. type as a label when there's no label, applications won't know for sure the label is real.
[13:50] <hverkuil> OK. So we don't provide a label. Then apps see there is no label and they make up one.
[13:51] <hverkuil> How does that help anyone?
[13:51] <sailus> How about this as a guidance for application developers: use label if it exists, otherwise use name.
[13:51] <pinchartl> it helps i18n, it helps making a label based on the type of user too
[13:51] <hverkuil> And that label will differ between apps.
[13:51] <sailus> I wouldn't want applications to make up labels either.
[13:51] <pinchartl> a professional video application would likely display information different than an app for consumers
[13:51] <sailus> Name is... a name, something we call an entity.
[13:52] <sailus> Label, on the other hand, has a very specific meaning: it's a written string describing a something, such as a connector.
[13:52] <hverkuil> sailus: I could work with that.
[13:53] <mchehab> I could work with that
[13:53] <hverkuil> Under no circumstance should apps have to make up a label, that's asking for trouble.
[13:53] <mchehab> agreed
[13:53] <pinchartl> applications should certainly not make up a label
[13:53] <sailus> pinchartl?
[13:53] <pinchartl> but applications can control what they want to show
[13:54] <pinchartl> an application might want to display a dialog box with a text that refers to a connector
[13:54] <pinchartl> or it might want to display an image with the drawing of the connector
[13:54] <pinchartl> or both, or something else
[13:54] <hverkuil> I don't care about that. But the kernel has to provide something half-way decent that can be used as a fallback and the name works for that.
[13:54] <pinchartl> my point is that the kernel API should report the information that is available
[13:55] <pinchartl> and then applications should use it to perform their tasks, with guidance on how they should create a text representation for instance ("use the label if available, use the name otherwise" is one possible way to guide applications)
[13:55] <pinchartl> and I also believe libmediactl should provide helper functions to perform that task
[13:55] <hverkuil> right.
[13:55] <pinchartl> with guidance in the documentation and with helper functions I think we're fine
[13:56] <pinchartl> if applications really want to screw it up they will always be able to anyway
[13:56] <hverkuil> sailus: thanks for the great suggestion!
[13:57] <pinchartl> how do we summarize that for the label ?
[13:57] <hverkuil> "it is recommended that as many as possible of the label, type, colour and location properties are filled in. If there is no label given, then applications can use the entity name."
[13:58] <pinchartl> "the label is optional ; it should only be reported when a label is present on the device"
[13:58] * headless wished #dri-devel had such a talk about new connectors :-)
[13:58] <headless> *wishes
[13:58] <hverkuil> "The label should refer to a label on the backplane or (if there is none) the connector name as mentioned in the manual"
[13:59] <pinchartl> location is still ill-defined, but I propose postponing the discussion on that particular property
[13:59] <hverkuil> right. I think location will be difficult.
[13:59] <mchehab> hmm... backplane is too specific... the label may be outside the box of the device
[14:00] <hverkuil> "should refer to the label next to the connector"
[14:00] <sailus> hverkuil: Ack.
[14:00] <mchehab> yes, that's OK
[14:00] <hverkuil> or perhaps just "label of the connector"
[14:00] <mchehab> works too
[14:00] <pinchartl> "the label should contain the text displayed on the PCB, backplane or device case (as applicable) ; or, when no such label exists, the label mentioned in the product manual ; or, when no such label exist, be left out" ?
[14:00] <hverkuil> or 'associated with'
[14:01] <mchehab> I like "associated with"
[14:01] <pinchartl> we don't have to agree on the exact wording right now, but does that convey the meaning we want ?
[14:01] <mchehab> yes
[14:01] <hverkuil> y
[14:01] <sailus> Yes.
[14:01] <hverkuil> hoorah!
[14:02] <sailus> :-)
[14:02] <pinchartl> good :-)
[14:02] <hverkuil> Next up signals?
[14:02] <pinchartl> position can be postponed, it will be difficult to define
[14:02] <sailus> I'll need to leave in ~ 10 minutes. :-I
[14:02] <pinchartl> colour seems simple
[14:02] <pinchartl> but could still be tricky
[14:02] <pinchartl> I propose discussing it later too
[14:03] <pinchartl> type
[14:03] <mchehab> let's focus on what to be filled at entity->name and entity->function
[14:03] <pinchartl> should it really be optional ?
[14:03] <mchehab> those are the ones we need now
[14:03] <mchehab> the other properties require the property API, so we have some time
[14:03] <pinchartl> ok, let's start with entity->function then
[14:03] <pinchartl> or rather
[14:03] <pinchartl> let's start with signals
[14:03] <pinchartl> as that's what we currently think we will use in entity->function
[14:04] <shuah> signals to be not confused by SIG*
[14:04] <pinchartl> I'd prefer discussing signals first as they should be reported using properties (we can have multiple signals for a connector, so we'll need that at some point)
[14:04] <pinchartl> and when we agree on the concept of signals, see what to set in entity->function
[14:04] <pinchartl> ok ?
[14:04] <hverkuil> ok
[14:05] <mchehab> well, we already agreed in the past that entity->function is the primary function of an entity
[14:05] <pinchartl> yes, but we haven't clearly defined what a function is (especially for connectors)
[14:05] <mchehab> true
[14:05] <pinchartl> that's what we have to define here
[14:05] <mchehab> that's the reason for this meeting ;)
[14:05] <pinchartl> and we're leaning towards using signals for that
[14:06] <pinchartl> my point is that, if we define the function of a connector as the signals it can carry, I'd like to define what the signals are first
[14:06] <pinchartl> instead of saying "the function is the still undefined concept of signals"
[14:06] <hverkuil> I think that is the right definition.
[14:07] <mchehab> let's start then with simpler connectors: composite and s-video...
[14:07] <hverkuil> Signals refer to standards (otherwise nobody would be able to interpret them).
[14:07] <mchehab> how we would call the signals on those?
[14:07] <hverkuil> https://en.wikipedia.org/wiki/Composite_video
[14:08] <pinchartl> mchehab: yes, an example-based discussion is good
[14:08] <hverkuil> commonly know as composite :-)
[14:08] <hverkuil> https://en.wikipedia.org/wiki/S-Video
[14:08] <mchehab> so, ENT_F_SIG_COMPOSITE_VIDEO?
[14:08] <sailus> Are other connectors used for composite video than RCA?
[14:08] <mchehab> yes
[14:08] <hverkuil> sailus: yes
[14:08] <pinchartl> sailus: yes, lots of them
[14:09] <sailus> The jack I suppose. :-)
[14:09] <pinchartl> jack, svideo connectors, lots of custom connectors I assume
[14:10] <mchehab> yes
[14:10] <pinchartl> the composite video signal is pretty well documented I think
[14:10] <mchehab> there are connectors like this: http://www.hauppauge.com/site/webstore2/webstore_avcable-svideo.asp
[14:10] <pinchartl> so ENT_F_SIG_COMPOSITE_VIDEO seems fine (we can discuss the ENT_F_SIG prefix later if needed, it's not specific to composite)
[14:10] <mchehab> http://www.hauppauge.com/site/webstore2/webstore_hvr_avcable.html
[14:11] <pinchartl> is that a USB connector ?
[14:12] <mchehab> those are the cables for two different USB custom connector
[14:12] <mchehab> *connectors
[14:12] <hverkuil> When we describe a connector we shouldn't describe the break-out connector but the connector at the other end of the break-out connector.
[14:12] <hverkuil> It is fair to assume that the break out cable/box is hooked up.
[14:12] <pinchartl> hverkuil: that's an interesting question. what if there can be multiple break-out cables ?
[14:12] <hverkuil> is always hooked up.
[14:12] <pinchartl> with different connectors
[14:12] <mchehab> http://www.hauppauge.com/site/products/data_usblive2.html
[14:13] <hverkuil> Different break-out cables and switching from one to another gives you different inputs?
[14:14] <hverkuil> If that's the case, then the label should say something like "breakout1, composite 1".
[14:14] <javier__> different break-out cables is a similar case than mchehab board where you can change the input connector with a physical switch
[14:14] <pinchartl> javier__: yes, it's a similar case
[14:14] <pinchartl> in those cases I don't think we'll find a perfect solution
[14:14] <pinchartl> it will likely be a best effort
[14:15] <sailus> I need to leave now but I'll read the log later.
[14:15] <sailus> Have a relaxing weekend! :-)
[14:15] <hverkuil> thanks!
[14:15] <pinchartl> sailus: we've just started ! :-)
[14:15] <mchehab> sailus: thanks
[14:15] <hverkuil> Anyway, back to signals.
[14:16] <hverkuil> SIG_COMPOSITE and SIG_SVIDEO are well defined, I think.
[14:16] <hverkuil> And both can be set on the same connector if supported by the hardware.
[14:16] <pinchartl> SIG_COMPOSITE seems fine
[14:16] <pinchartl> for SIG_SVIDEO
[14:16] <mchehab> ok
[14:16] <hverkuil> SIG_RF?
[14:17] <mchehab> SIG_RF sounds good
[14:17] <pinchartl> is it conceivable that the Y and C signals will be carried on separate connectors ?
[14:17] <pinchartl> (for SVIDEO)
[14:17] <hverkuil> I think SIG_RF is basically always two pins carrying radio signals?
[14:18] <hverkuil> pinchartl: actually, it is. Cisco has a product like that.
[14:18] <hverkuil> (two BNC connectors)
[14:18] <pinchartl> hverkuil: how do we handle that ?
[14:18] <hverkuil> Good point.
[14:18] <mchehab> should we handle it?
[14:18] <pinchartl> one option would be SIG_VIDEO_Y and SIG_VIDEO_C
[14:19] <mchehab> I mean: this is the exception... very few boards have...
[14:19] <pinchartl> in which case I'm not sure we'd need a SIG_SVIDEO, we could combine SIG_VIDEO_Y and SIG_VIDEO_C for real svideo connectors
[14:19] <pinchartl> (just thinking out loud)
[14:19] <mchehab> I would, instead, expose the fact that it is actually two physical connectors as a property
[14:19] <hverkuil> I'm thinking F_SIG_SVIDEO_Y and F_SIG_VIDEO_C and #define F_SIG_SVIDEO to the OR of those two.
[14:19] <pinchartl> hverkuil: the functions are not bitfields
[14:20] <pinchartl> they're enumerated integers
[14:20] <hverkuil> Ah, of course.
[14:20] <hverkuil> Stick to SVIDEO.
[14:20] <hverkuil> In practice if there are two separate connectors they tend to be labeled together.
[14:20] <javier__> the problem with separate Y and C functions is that then we will need 2 entities right?
[14:21] <mchehab> javier__: right now, yes
[14:21] <hverkuil> It's the same for component RCA cables. Three connectors, but they are always grouped.
[14:21] <mchehab> with properties API, no
[14:21] <javier__> mchehab: right
[14:21] <pinchartl> hverkuil: agreed, similar issue with component RCA
[14:21] <hverkuil> I'm not sure if it is worth modeling it as three separate connectors.
[14:22] <pinchartl> it's a good question
[14:22] <mchehab> I don't think it is worth mapping as separate connectors
[14:22] <pinchartl> how about this case
[14:22] <pinchartl> 3 RCA sockets
[14:22] <pinchartl> that can be used for component video
[14:23] <pinchartl> (thus one channel)
[14:23] <pinchartl> *or* for 3 composite video channels
[14:23] <mchehab> well, on all such devices I know, they all will have the same label (but one different collor for each component)
[14:23] <pinchartl> analog video hardware developers love to reuse connectors for different purposes with a big mux/switch behind them
[14:24] <mchehab> IMHO, we should map it as one connector entity, and use the props to describe its physical appareance
[14:24] <hverkuil> I would see that as four connectors: one component and three composite. WIth the label telling the end user where those connectors are.
[14:24] <pinchartl> how about the case where you have 3 RCA sockets for composite video ? they're separate connectors, aren't they ?
[14:24] <mchehab> (e. g. if each component is 3 RCA, 3 BNC or whatever)
[14:24] <hverkuil> (or colour, or location)
[14:25] <hverkuil> This is how this is done in ENUMINPUT as well in cases like that.
[14:25] <pinchartl> hverkuil: that one bothers me. if we have 3 physical connectors, having 4 connector entities seem messy
[14:25] <pinchartl> let's assume for a second that we go for a single connector entity for the 3 RCA sockets
[14:25] <pinchartl> would that entity have one or three source pads ?
[14:26] <mchehab> hverkuil: do you have any example of it bein mapped as 3 different inputs at ENUM_INPUT? this doesn't make sense
[14:26] <mchehab> pinchartl: one connector, 3 source pads seems fine for me
[14:27] <mchehab> hmm... connectors don't have source pads
[14:27] <mchehab> as there's nothing to connect there
[14:27] <pinchartl> if we have 3 RCA sockets, each of them used for a different composite input, we would have 3 connector entities, each with a single source pad, right ?
[14:27] <pinchartl> what ? no source pad ?
[14:27] <javier__> mchehab: you mean sink?
[14:27] <pinchartl> do you mean no sink pad ?
[14:27] <mchehab> sorry... I messed
[14:27] <pinchartl> (for input connectors)
[14:28] <hverkuil> I thought I saw examples of that, but I may be wrong.
[14:28] <pinchartl> (output connectors will have sink pads and no source pad)
[14:28] <mchehab> I miss-understood what you've said... I need more coffee
[14:29] <pinchartl> coffee break ?
[14:29] <javier__> I believe that if a connector is multiplexed like pinchartl said, then it should be handled like separate hw connectors
[14:29] <mchehab> from SW PoV, this is a single thing to be controlled
[14:30] <mchehab> just one VMUX setting for the connector
[14:30] <mchehab> no matter if it has multiple physical connectors or a single one
[14:31] <mchehab> I mean, if you have 2 composite inputs, each with 3 inputs...
[14:31] <pinchartl> javier__: won't it be confusing for users if an application tells them about 4 connectors when there are only 3 physical connectors ?
[14:31] <pinchartl> I'd prefer mapping the connector entities to physical connectors
[14:31] <mchehab> you can't setup a link that would use the RED connector from input 1 and GREEN/BLUE from input 2
[14:31] <javier__> pinchartl: but from a user pov, I expect it to have 4 labels in the device explaining how to connect
[14:31] <pinchartl> providing we can find a clean way to make this work through the stack
[14:31] <hverkuil> You definitely need three connectors (one for each composite), but I'm not sure what to do with the component.
[14:31] <hverkuil> javier__: good point
[14:32] <pinchartl> javier__: that can possibly be the case, yes
[14:32] <pinchartl> something like this
[14:32] <pinchartl> / ------ Component ------- \
[14:32] <pinchartl> | RCA 1 | | RCA 2 | | RCA 3 |
[14:32] <pinchartl> Comp 1 Comp 2 Comp 3
[14:32] <mchehab> no, what we cacutally have is:
[14:33] <pinchartl> (sorry about the misalignment
[14:33] <pinchartl> line 1 and 3 are labels
[14:33] <pinchartl> line 2 is connectors
[14:33] <mchehab> COMPONENT 1 | COMPONENT 2
[14:33] <mchehab> blue red green | blue red green
[14:34] <pinchartl> (Comp. stands for composite, that was not clear)
[14:34] <pinchartl> mchehab: I'm not sure to follow you
[14:35] <hverkuil> http://www.ospreyvideo.com/images/osprey/datasheets/Osprey_Analog_PCIe_UserGuide.pdf
[14:35] <hverkuil> page 23
[14:35] <javier__> pinchartl: yes but Comp1-3 are all part of the same label right?
[14:35] <hverkuil> precisely this scenario
[14:36] <pinchartl> javier__: no, they're separate labels
[14:36] <pinchartl> (let's assume they're all printed on the backplane)
[14:36] <pinchartl> 4 labels, 3 connectors
[14:36] <pinchartl> hverkuil: yes, this exact case
[14:36] <hverkuil> ENUMINPUT for this card reports it as three as connectors (I think it should be 5, COMPOSITE2-3 are not reported)
[14:36] <pinchartl> (ignoring the fact that it then all goes to a DB15 connector)
[14:37] <pinchartl> let's assume that the 3 BNC connectors are directly on the device, ok ?
[14:37] <mchehab> hverkuil: no, "This dongle also provides three Composite inputs. Only one of these can be selected at a time."
[14:37] <mchehab> that's the description of figure 21
[14:38] <hverkuil> mchehab: and only composite 1 is supported in the card definition. You can't select 2 or 3 as input. As far as I can tell.
[14:38] <hverkuil> The windows apps in the picture reports 5 inputs as well.
[14:38] <hverkuil> app
[14:39] <pinchartl> I'd view this as 3 connectors and 5 inputs
[14:39] <pinchartl> that are mutually exclusive
[14:39] <pinchartl> or possibly as one connector if we decide to group the 3 BNC (or RCA) as a single connector, but I'm not too thrilled about that
[14:39] <pinchartl> the question is
[14:39] <pinchartl> if we create 3 connector entities
[14:40] <pinchartl> can we handle that cleanly through the stack and provide 5 inputs ?
[14:40] <hverkuil> The label for the svid connector would be "SVideo", for composite there are three connectors "Composite 1/2/3" and for the component it would be "Component Y/Pr/Pb"
[14:40] <mchehab> pinchartl: what I said can be seen in this picture: http://www.pcstats.com/articleimages/200903/samLN40A650A_conn4.jpg
[14:40] <mchehab> you can see how the components are labeled there:
[14:41] <mchehab> component IN 1 - with 5 connectors (3 for video, 2 for audio)
[14:41] <mchehab> Component IN 2 (also with 5 connectors)
[14:42] <mchehab> the video component is identified by the color of the jack
[14:42] <mchehab> s/jack/plug
[14:42] <pinchartl> we'd have to define how to create labels from that
[14:42] <mchehab> from software PoV, there are just 2 component inputs
[14:43] <mchehab> so, just 2 entities are needed for SETUP_LINK
[14:43] <pinchartl> now I don't think I'm following you :-)
[14:43] <mchehab> ok, the end user will need to connect 5 physical RCA cables there, but this is just how it was physically wiredthe physical property
[14:43] <mchehab> ok, the end user will need to connect 5 physical RCA cables there, but this is just how it was physically wired
[14:43] <javier__> yeah, that's what I meant. What's important is what the labels says in the device not the real input connectors
[14:44] <javier__> if I connect both composite video and stereo audio cables, is just one connector from the user pov
[14:44] <mchehab> pinchartl: imagine how you would setup a link there...
[14:44] <hverkuil> I think so as well. HW designers can wire things up in crazy ways and double-up on connectors. But the labels and/or manual will describe the actual possible groupings.
[14:45] <pinchartl> hmmmm...
[14:45] <mchehab> it doesn't make *any sense* to link each RCA independently
[14:45] <javier__> if the phyicall connectors can be reused / muxed, then another label will be needed for the user
[14:45] <hverkuil> So in the ViewCast example above if you talk about a "Composite 1" connector it is uniquely identified in the manual.
[14:45] <javier__> so another entity in MC for the muxed connectors IMHO
[14:45] <pinchartl> when multiple physical connectors are always used together it might make sense to have a single connector entity
[14:46] <pinchartl> but if signals can be combined in multiple ways, it gets messy
[14:46] <hverkuil> Same for the component input, even though that is three physical connectors.
[14:46] <javier__> hverkuil: exactly
[14:46] <pinchartl> I don't think we should create connector entities based on the possible input combinations
[14:47] <mchehab> you can't combine RGB componet connectors in multiple ways
[14:47] <pinchartl> you can if you use them for different kinds of signals
[14:47] <mchehab> you can't get COMPONENT IN (1) R and COMPOENT IN (2) G B
[14:47] <mchehab> as the timings won't match
[14:47] <hverkuil> Right. If multiple connectors have to be grouped, then you can't switch them. Which is why they are color-coded.
[14:48] <pinchartl> that's the same issue as the one we discussed yesterday with the svideo connector used to carry either svideo or composite
[14:48] <pinchartl> or the example in the osprey user manual
[14:48] <pinchartl> there are 3 connectors
[14:48] <pinchartl> 3 BNC connectors
[14:48] <pinchartl> that can be combined in different ways
[14:49] <pinchartl> for component video, svideo, or composite video
[14:49] <hverkuil> Yes. ENUMINPUT currently reports SVid/Composite as two connectors as well. So perhaps that isn't such a bad idea after al.
[14:49] <hverkuil> all
[14:49] <pinchartl> the device doesn't support capturing from multiple channels, but it would otherwise be entirely conceivable that the 3 BNC connectors could be used for 3 simultaneous composite video channels
[14:49] <hverkuil> (it would also cover the case where S-Video is two separate connectors)
[14:49] <pinchartl> or a single component channel
[14:50] <pinchartl> or a single svideo channel + a single composite channel
[14:50] <hverkuil> as is the case for the viewcast.
[14:50] <pinchartl> we there's lots of options here
[14:50] <hverkuil> it does exactly that.
[14:50] <pinchartl> my point here
[14:50] <pinchartl> is that connectors and inputs seem to be different concepts
[14:50] <pinchartl> an input is a logical combination of signals carried over one or multiple connectors
[14:51] <pinchartl> while the connectors are fixed physical devices
[14:51] <hverkuil> true, good point
[14:51] <pinchartl> I'm leaning towards reporting connectors in MC as connector entities
[14:51] <pinchartl> *if* we can find a good way to report inputs
[14:51] <pinchartl> in a clean fashion
[14:51] <pinchartl> the problem is complex
[14:51] <pinchartl> but so far I don't see it as impossible to solve :-)
[14:52] <hverkuil> Perhaps we should just report inputs and ignore connectors? The input label should identify the connectors to use.
[14:52] <hverkuil> But it is input signal that we want.
[14:52] <pinchartl> hmmmm...
[14:52] <mchehab> hverkuil: yes, this seems better
[14:53] <hverkuil> s/CONNECTOR/INPUT/g :-)
[14:53] <pinchartl> I don't think it's better :-)
[14:53] <pinchartl> for one thing
[14:53] <pinchartl> how would you describe the inputs in DT ?
[14:53] <mchehab> what we actually want to represent at the MC disagram is the sources/sinks of signals, and the blocks that process it
[14:53] <pinchartl> connectors are physical components, it's easy to represent them with DT nodes
[14:53] <pinchartl> but inputs... DT bindings for inputs might be difficult to get accepted
[14:53] <pinchartl> I don't really see how they would look like
[14:54] <mchehab> the source of signal is the input, with may have one or multiple connectors, depending on how the hardware vendor wired it)
[14:54] <pinchartl> if we create input entities instead of connector entities, how do we represent in the graph the dependencies between them ?
[14:54] <hverkuil> Or an input could be seen as one or more connectors.
[14:54] <mchehab> an input is a group of physical connectors
[14:54] <pinchartl> I'm also not sure how they would be routed
[14:54] <pinchartl> I don't think that's a good idea
[14:55] <hverkuil> I also come back to the fact that you may not know the exact connectors. E.g. whether an S-Video input is one or two physical connectors is something that may not be known by the DT.
[14:56] <mchehab> we're actually representing an Input connection
[14:56] <hverkuil> There may be two variants for example.
[14:56] <hverkuil> variants of the hw
[14:56] <hverkuil> From the point of view of the DT and software they are identical, but the connectors differ.
[14:56] <pinchartl> from the point of view of DT, not really
[14:57] <pinchartl> if you have different connectors you should have different DTs
[14:57] <hverkuil> why?
[14:57] <pinchartl> because DT is a hardware description
[14:57] <pinchartl> if the hardware is different, it should result in different DT files
[14:57] <pinchartl> if you look at the beagleboard-xm revisions for instance
[14:57] <pinchartl> same board, different revisions, different DT files
[14:57] <hverkuil> there is nothing you need or can set based on that information. Whether it is one or two connectors makes no difference whatsoever to the setup or configuration of the hardware.
[14:58] <hverkuil> Of course, if that *does* make a difference (you need to program a gpio or mux differently), then you need two DTs
[14:58] <pinchartl> let's take an extreme case
[14:58] <pinchartl> same connectors
[14:58] <pinchartl> different colours
[14:58] <pinchartl> the colour would need to come from DT
[14:59] <pinchartl> (unless you have a colour sensor next to the connector, but I think we can ignore that case ;-))
[14:59] <mchehab> pinchartl: you don't need to have that, you could have multiple compatible using a single DT file for multiple boards
[14:59] <pinchartl> mchehab: you can if the boards are compatible. it all boils down to whether you want to report accurate information to the user
[15:00] <pinchartl> in general if you have different connectors you should have different DTs
[15:00] <pinchartl> if you use the same onoe
[15:00] <pinchartl> it won't be accurate on some board variants
[15:00] <pinchartl> and applications might then display unaccurate information to the user
[15:00] <pinchartl> if the information isn't available to Linux in the first place there's little we can do about it
[15:01] <mchehab> pinchartl: how would you then represent this hardware: https://cdn-c.verkkokauppa.com/images/86/2_73488-2126x1599.jpg
[15:01] <shuah> right - we also have to balance complexity vs information
[15:01] <pinchartl> if you DT file tells that the connector is red while it is blue on the board, then you're screwed, applications will tell the user that the connector is red. we can't fix that in drivers/userspace
[15:01] <mchehab> there's a physical switch to change from SCART to S-Video/Composite
[15:02] <pinchartl> mchehab: that one is why I was talking about best effort
[15:02] <mchehab> there's no way to identify it from softare
[15:02] <pinchartl> software doesn't know about the switch
[15:02] <pinchartl> so there's no way it can handle this accurately
[15:02] <hverkuil> I think that it makes more sense to be input oriented (and for each input identify the connectors through label, color(s), location, type).
[15:02] <mchehab> if you had to represent this in DT, assuming what you told so far, we would need 2 DT entires...
[15:02] <mchehab> one for each position of the switch
[15:03] <pinchartl> mchehab: you could have a switch entity in MC without software control, that's one option
[15:03] <pinchartl> hverkuil: I think it makes sense to be input-oriented when presenting information to the user
[15:03] <pinchartl> but I'm still not convinced we should be input-oriented in MC entities
[15:03] <pinchartl> nor in DT
[15:03] <mchehab> btw, from Linux PoV, this looks like the Schrodinger's Cat issue... only manually observing the board you would be able to know the status of the switch
[15:03] <mchehab> :-)
[15:04] <pinchartl> I wonder if we shouldn't sleep on this one
[15:04] <mchehab> representing it on a non-input oriented way in MC would be a *real pain*, as all we have so far is based on inputs
[15:04] <pinchartl> it's all new
[15:05] <pinchartl> I'm not sure how it would look like in MC if we were input-oriented
[15:05] <hverkuil> pinchartl: do you agree that you can describe cases like the ViewCast by using an input oriented approach? If you take a connector oriented approach, how would you describe such cases?
[15:05] <pinchartl> maybe we need examples to discuss on concrete use cases ?
[15:05] <mchehab> but even if we had started in green field, I still think that the Kernel should care about inputs, not about physical dirty details
[15:05] <pinchartl> hverkuil: which one is the viewcast ?
[15:05] <hverkuil> That's where I feel things would become really complicated and hard to manage.
[15:05] <mchehab> pinchartl: it is not all new.. you need to convert whatever is already mapped on the +1000 boards to MC
[15:05] <hverkuil> http://www.ospreyvideo.com/images/osprey/datasheets/Osprey_Analog_PCIe_UserGuide.pdf
[15:06] <hverkuil> The Osprey.
[15:06] <pinchartl> mchehab: it's new in the sense that replacing connector entities with input entities has only been proposed 20 minutes ago for the first time
[15:07] <hverkuil> It is not unreasonable to allow for the possibility that 1000+ boards do it right :-)
[15:07] <pinchartl> hverkuil: in that case we have connectors and inputs that don't map 1:1. there are thus two concepts that need to be described in one way or another. it's not clear how at the moment
[15:07] <pinchartl> hverkuil: those 1000+ boards don't have MC support
[15:07] <javier__> and also don't represent their connectors in DT
[15:07] <pinchartl> we're in new territory here
[15:07] <mchehab> but they support ENUM_INPUT and should be converted to MC
[15:07] <hverkuil> but the problem we have (how to represent 'overloaded' connectors) remains the same.
[15:08] <pinchartl> javier__: given that they're USB or PCI devices, they will certainly not represent their connectors in DT :-)
[15:08] <mchehab> whatever we decide, it should not require someone to get all those hardware to do the conversion
[15:08] <hverkuil> And apparently, representing it as inputs makes sense.
[15:08] <javier__> pinchartl: yes, I mean that is not a problem we had before
[15:08] <hverkuil> pinchartl: the board definition takes the same role as a DT effectively.
[15:09] <pinchartl> hverkuil: and the board definition has been written without the concept of MC in mind, it tackled the ENUMINPUT issue
[15:09] <pinchartl> I'm curious to see how the MC graph would look like
[15:09] <mchehab> yes, and, btw, he had in the past the desire to convert the board definition into something like DT
[15:09] <pinchartl> in the viewcast case for instance
[15:09] <mchehab> putting those data on userspace
[15:09] <mchehab> (years before DT)
[15:11] <hverkuil> But to go back to my question: how would you represent that osprey board using connectors in the dt?
[15:11] <mchehab> pinchartl: the worse case is cx25821-based boards...
[15:11] <mchehab> If I remember well, they may have up to 24 connectors...
[15:11] <pinchartl> hverkuil: and how would you represent it with inputs ? :-)
[15:11] <mchehab> that could be routed as either input or output
[15:12] <mchehab> the current driver is too limited, and there are very few boards in the market, afaikt
[15:12] <pinchartl> same question about the MC graph with inputs instead of connectors, how would it look like ?
[15:12] <hverkuil> pinchartl: 5 inputs (svid, 3 composite, one component), with label/color/location/type as discussed before.
[15:13] <mchehab> https://wiki.zoneminder.com/images/8/86/PCIe.JPG?
[15:13] <pinchartl> mchehab: quite common. usually with a big mux. something the mux can be programmed to cycle automatically between inputs, it's a mess
[15:13] <pinchartl> hverkuil: can you draw an MC graph ?
[15:14] <mchehab> it is not a big mux... the board is able to handle everything in parallel
[15:15] <pinchartl> 16 channels captured in parallel ?
[15:15] <hverkuil> pinchartl: never actually done that. But it just represents the hw as if there were 5 separate physical connectors instead of 'overloaded' connectors.
[15:15] <pinchartl> full frame rate ?
[15:15] <mchehab> and 8 outputs
[15:15] <mchehab> full frame rate
[15:15] <pinchartl> hverkuil: I understand that, what I'm unsure about is how it would look like internally, how those input entities would be connected
[15:15] <pinchartl> ah, output, that's cheating
[15:16] <pinchartl> that's a bandwidth of 318MB/s + overhead though
[15:17] <pinchartl> 2.5Gb/s
[15:17] <mchehab> yes, it goes close to the PCIe limit
[15:17] <mchehab> when all channels are enabled
[15:17] <hverkuil> pinchartl: each input has a source pad that connects to the corresponding sink pad on the receiver. This also implies that the sink pads are also separate for composite/component. It is likely that internally those are overloaded as well.
[15:18] <hverkuil> But how the sink pads are interpreted is typically controlled by a mux.
[15:18] <pinchartl> hverkuil: that's what I'd like to see, a couple of examples of how it would work in practice
[15:18] <pinchartl> with real devices
[15:18] <pinchartl> including, if possible, an adv7604-based one
[15:18] <pinchartl> the analog inputs on that chip are painful
[15:19] <pinchartl> there 8 (or 10 ? 12 ?) input channels
[15:19] *** teob has left
[15:19] <pinchartl> with a mux
[15:19] <pinchartl> and a possibility to combine them
[15:19] <pinchartl> it's messy to represent properly
[15:19] <pinchartl> I wonder how an MC graph for that would look like if the use input entities
[15:21] <mchehab> pinchartl: there are lots of examples at: https://mchehab.fedorapeople.org/mc-next-gen/?C=M;O=D
[15:21] <hverkuil> Hmm, actually, I wonder if an S-Video/component input shouldn't have respectively 2 and 3 source pads. That way you could wire it up to the right sink pads on the receiver (i.e. an S-Video input has Y and C source pads)
[15:21] <pinchartl> mchehab: they don't have input entities
[15:22] <mchehab> they have, but they're called there as connectors
[15:23] <pinchartl> can we take a couple of the most representative examples (and possibly the most annoying ones too) and see how they would look like with input entities ?
[15:23] <mchehab> for example, on this one: https://mchehab.fedorapeople.org/mc-next-gen/cx231xx_usb_live2.png
[15:23] <mchehab> the output of the device is actually a single custom connector
[15:23] <javier__> pinchartl: the igep2 / tvp5150 maps input to connectors 1:1 so you could get an idea with https://mchehab.fedorapeople.org/mc-next-gen/omap3-igepv2-with-tvp5150.png
[15:23] <pinchartl> the output ?
[15:24] <pinchartl> javier__: 1:1 is the easy case
[15:24] <javier__> the tvp5150 also has S-video but the igep2 doesn't have a connector for that
[15:24] <mchehab> s/output/input
[15:24] <pinchartl> it's the hairy cases I'm concerned about
[15:24] <pinchartl> mchehab: in https://mchehab.fedorapeople.org/mc-next-gen/cx231xx_usb_live2.png how are things physically connected in the hardware ?
[15:24] <mchehab> well, let's solve first the 99.99% of the cases, and then concern about the exceptions ;)
[15:24] <pinchartl> and what physical connectors does it have ?
[15:25] <mchehab> http://www.hauppauge.com/pics/usb-live2_connectors_small.jpg
[15:25] <pinchartl> mchehab: if you want to focus on the 99.99% of the 1:1 mapping cases, then let's keep connectors in MC instead of inputs, and we're done :-)
[15:25] <pinchartl> so two video connectors, one composite, one svideo
[15:26] <mchehab> pinchartl: a composite input is 3 connectors
[15:26] <pinchartl> 3 signals
[15:26] <hverkuil> We should ignore the breakout connector and assume that is always connected.
[15:26] <mchehab> 1 for video, 2 for audio
[15:26] <pinchartl> let's ignore audio for now
[15:26] <pinchartl> so 3 signals, 2 on the svideo connector, 1 on the composite video connector
[15:26] <mchehab> pinchartl: audio is routed together with the input with S_INPUT
[15:26] <pinchartl> how are they connected internally in the device ?
[15:27] <mchehab> one breakout connector to the device
[15:27] <mchehab> 4 connectors out of the breakout cable
[15:27] <pinchartl> I can see that on the picture
[15:27] <pinchartl> what is *inside* the device ?
[15:27] <mchehab> 1 S-Video, 3 for composite
[15:28] <mchehab> a tvp5150, a em28xx (not sure what specific model, likely em2860 or upper)...
[15:28] <mchehab> and an em202 (AC97 audio mixer)
[15:28] <pinchartl> so it isn't https://mchehab.fedorapeople.org/mc-next-gen/cx231xx_usb_live2.png ?
[15:28] <hverkuil> based on the card definition the composite goes to one input of the device and the S-Video to two other inputs.
[15:29] <mchehab> ops... sorry, this it based on cx231xx
[15:29] <mchehab> it should have then just one chip inside
[15:29] <mchehab> cx231xx
[15:29] <mchehab> cx25840 is inside cx231xx silicon
[15:29] <mchehab> on cx231xx, I guess
[15:29] <pinchartl> what physical inputs does it have ?
[15:30] <mchehab> at the device, one physical custom connector
[15:30] <pinchartl> the chip
[15:31] <pinchartl> the cx25840 seems to have 8 inputs
[15:31] <mchehab> enum AUDIO_INPUT {
[15:31] <mchehab> AUDIO_INPUT_MUTE,
[15:31] <mchehab> AUDIO_INPUT_LINE,
[15:31] <mchehab> AUDIO_INPUT_TUNER_TV,
[15:31] <mchehab> AUDIO_INPUT_SPDIF,
[15:31] <mchehab> AUDIO_INPUT_TUNER_FM
[15:31] <mchehab> };
[15:31] <pinchartl> at least according to http://pdf1.alldatasheet.com/datasheet-pdf/view/117265/CONEXANT/CX25840.html
[15:31] <mchehab> enum cx231xx_v_input {
[15:31] <mchehab> CX231XX_VIN_1_1 = 0x1,
[15:31] <mchehab> CX231XX_VIN_2_1,
[15:31] <mchehab> CX231XX_VIN_3_1,
[15:31] <mchehab> CX231XX_VIN_4_1,
[15:31] <mchehab> CX231XX_VIN_1_2 = 0x01,
[15:31] <mchehab> CX231XX_VIN_2_2,
[15:31] <mchehab> CX231XX_VIN_3_2,
[15:31] <mchehab> CX231XX_VIN_1_3 = 0x1,
[15:31] <mchehab> CX231XX_VIN_2_3,
[15:31] <mchehab> CX231XX_VIN_3_3,
[15:31] <mchehab> };
[15:32] <hverkuil> weird. Different defines, same value.
[15:32] <hverkuil> yuck
[15:32] <mchehab> yep
[15:33] <pinchartl> my time is up for today I'm afraid
[15:33] <mchehab> pinchartl: from the driver, it seems it has 8 video inputs, 4 stereo audio inputs
[15:34] <mchehab> most devices based on cx23102 have a max of 4 video inputs (RF radio and/or RF video, S-video, Composite is a typical setup)
[15:35] <pinchartl> I'll have some time on Monday to resume the discussion
[15:35] <mchehab> the RF inputs are actually wired to the tuner
[15:36] <hverkuil> I've available as well on Monday except for 2-3 pm.
[15:36] <hverkuil> I'm
[15:36] <mchehab> right now, the driver only allows 4 inputs
[15:36] <mchehab> #define MAX_CX231XX_INPUT 4
[15:36] <mchehab> on the same board entry
[15:36] <mchehab> Monday should be ok for me, up to 3pm on my local time
[15:37] <pinchartl> let's resume on Monday then. we should focus on real examples. hverkuil, if you have a complex adv7604-based example it would be useful, I'd like to see how the MC graph would look like
[15:38] <hverkuil> I'll see if I can make something.
[15:40] <mchehab> I'll try to review shuah's alsa patches and see if I can add the audio path to one board
[15:42] <mchehab> pinchartl: btw, that's what inside USB live2: https://linuxtv.org/wiki/index.php/Hauppauge_USB-Live-2
[15:43] <mchehab> just one cx25840 is indeed just an IP inside cx23102
[15:43] <mchehab> internally wired via a I2C like bus
[15:44] <mchehab> the only other chip in the board is the EEPROM
[15:56] <javier__> oh, I've just noticed something when looking at the tvp5151 dathasheet again
[15:57] <javier__> the igepv2 does support s-video as well by using the two composite video connectors as Y and C
[15:58] <javier__> so is another case of muxed connectors and there is no labels in this case (that's why I didn't notice)
[16:00] <javier__> *datasheet
[16:04] <mchehab> interesting
[16:04] <mchehab> I guess what we need in the above case is a mux entity that would group Y and C together into one S-Video
[16:07] <mchehab> this could also be mapped as a third input source
[16:07] <mchehab> it would be good to have some tests to be sure
[16:09] <javier__> mchehab: yes, my current implementation supports that as a third connector
[16:09] <javier__> I just left it out of the DT because I (wrongly) thought that the board didn't have a connector for s-video
[16:09] <javier__> but is listed as a possible connector in the DT binding document
[16:10] <javier__> the setup link already does the needing mux'ing in the driver register to choose between composite0, composite1 or s-video
[16:10] <javier__> I just need to find out how to physically connect the s-video Y and C signals
[16:11] <javier__> but the good news is that I've access to a hw with the complex setup we were discussing :)
[16:12] <javier__> eballetbo that used to work for the IGEPv2 manufacturer agrees with my assumptions
[16:13] <mchehab> https://sep.yimg.com/ay/videoware/pro-4-pin-s-video-to-3-rca-23.gif
[16:14] <mchehab> I guess it is easier to wire it yourself than to find it in the market
[16:15] <javier__> mchehab: yeah, I guess so
[16:15] <hverkuil> mchehab: pinchartl: this would be the fully expanded adv7604 example: https://hverkuil.home.xs4all.nl/adv7604.png
[16:16] <hverkuil> (I gave the pads symbolic names to make it easier to see how it works)
[16:17] <hverkuil> While in theory any VGA/Component pin can route to any AIN* pin, the recommendation is to group AIN1-3, 4-6, 7-9 and 10-12 together.
[16:18] <hverkuil> So we might be able to combine those AIN pads together to reduce the number of pads. It's a bit risky, though.
[16:41] <hverkuil> mchehab: pinchartl: example for the adv7842, including 'overloaded' composite/S-Video connectors: https://hverkuil.home.xs4all.nl/adv7842.png
[16:42] <hverkuil> This is real hardware (except that we don't use HDMI2)
[16:42] <hverkuil> There are two BNC connectors on the backplane: one is used for composite and S-Video Y signal, the other only for S-Video C.
[16:43] <mchehab> that seems to work fine
[16:44] <hverkuil> Actually, this is also a good reason not to combine the AINX pads into groups as that won't work for Composite/S-Vid signals.
[16:44] <mchehab> mapping inputs seem better than mapping connectors
[16:45] <mchehab> one pad for each signal, a single entity for the entire input
[16:48] <hverkuil> This is the product: https://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/sx-series/physical-interface-guide/sx80-physical-interface-guide.pdf
[16:49] <hverkuil> Page 6 has a picture of the backplane.
[16:49] <hverkuil> The DVI-I and Y and C connectors all hook up to the adv7842.
[16:52] <hverkuil> updated the png.
[16:52] <hverkuil> The component and HDMI2 inputs I made up, the remainder are as per SX80.
[16:54] <javier__> hverkuil: the IGEPv2 expansion board I've here is similar to your adv7842 example
[16:54] <javier__> https://www.isee.biz/images/ISEE_Products/Expansion_Boards/IGEPv2/igepv2_expansion_front.png
[16:55] <javier__> it has two connectors that could be Composite0 Y, Composite1 Y or S-video Y and C
[16:56] <javier__> the board has a tvp5151 chip
[16:58] <hverkuil> In the adv7842 example I would give the composite input the label "Composite (BNC Y)" and the S-Video the label: "S-Video (BNC Y+C)"
[17:04] <hverkuil> And just for fun, the DVI-A signals can be interpreted as RGB or YPbPr.
[17:05] <hverkuil> (some cameras output YPbPr over a VGA connector)
[17:06] <hverkuil> So the single DVI-I connector has three inputs: DVI-A, DVI-D and DVI-A (Component).
[17:14] <mchehab> if we use this concept, the Terratec AV350 graph would be: https://mchehab.fedorapeople.org/terratec_av350-modified.png
[17:16] <mchehab> the problem of mapping this way is that SETUP_LINK should act, on all PADs of a connectors, for most connectors
[17:17] <mchehab> HDMI is an exception, as CEC, for example, should not be touched if the video input is switched
[17:18] <mchehab> perhaps this could be handled by some ancillary routines, but that would make shuah's enable/disable logic more complex ;)
[17:21] <shuah> mchehab: :) yeah it could
[17:22] <javier__> mchehab: that's exactly how the IGEPv2 will look like (no surprises since uses the same chip) + another Composite1 linked to AIP1A
[17:22] <shuah> The changes I made for S-video and Composite weren't complex (I was concerned about them), didn't turn out bad
[17:23] <javier__> s/AIP1A/AIP1B
[17:23] <mchehab> shuah: good, but the point is that any SETUP_LINK ioctl (or the corresponding S_INPUT calls) should change several pads at once
[17:24] <mchehab> if the entity is a input
[17:24] <mchehab> and we decide to change from connector to input
[17:24] <mchehab> ok, on au0828, this is really simple, but the routine should be generic enough to work on other drivers too
[17:25] <mchehab> s/routine/algorithm/
[17:43] <hverkuil> pinchartl: has similar needs regarding SETUP_LINK. We did discuss it, but I can't remember if we came to a conclusion.
[17:44] <pinchartl> in the context of the request API ?
[17:44] <hverkuil> y
[17:49] <pinchartl> well, for the request API it's pretty simple in theory, create a request, setup links, apply it
[17:49] <pinchartl> still, the new version of the link setup ioctl should take a list of links, not a single link
[17:54] <awalls> pinchartl: The CX2584x and CX2583x chips have 8 analog front end input, of which, conditioned on mux-ing settings and restrictions, only 3 can be used at once.
[17:56] <awalls> And often they are used in combinations: CVBS & SIF (tuner), Y & C (svideo), Y & Cr & Cb (component), or just CVBS
[17:57] <awalls> The audio comes in on I2S inputs (unless it's tuner SIF).
[17:58] <awalls> The CX23888 chips also have a Direct IF input which, after demod, somehow either feeds the analog front end mux or bypasses it (I can't remember).
[18:07] <shuah> mchehab: yes that would get complex
[18:16] <pinchartl> awalls: thanks
[18:34] <mchehab> hverkuil: there's a problem on media build:
[18:34] <mchehab> VB2-based drivers don't run on older kernels:
[18:34] <mchehab> [ 115.632929] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
[18:34] <mchehab> [ 115.632950] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
[18:34] <mchehab> [ 115.632966] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
[18:34] <mchehab> [ 115.632981] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
[18:34] <mchehab> (testing on a 3.19.8-100.fc20.x86_64)
[18:35] <mchehab> I guess we need to revert the patch that created those things at the core, removing from VB2
[19:00] <mchehab> I guess any kernel < 4.2 would have the same issue
[23:12] *** awalls has left