Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus <sakari.ailus@xxxxxx> escreveu: > Hi Mauro, > > On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote: > > We had some discussions on Feb, 12 about how to represent connectors via > > the Media Controller: > > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri&sel=31#l27 > > > > We tried to finish those discussions on the last two weeks, but people > > doesn't seem to be available at the same time for the discussions. So, > > let's proceed with the discussions via e-mail. > > > > So, I'd like to do such discussions via e-mail, as we need to close > > this question next week. > > While I agree that we shouldn't waste time in designing new APIs, we also > musn't merge unfinished work, and especially not when it comes to user space > APIs. Rather, we have to come up with a sound user space API/ABI and *then* > get it to mainline and *not* the other way around. Well, we've agreed with connectors during the MC workshop in August, 2015. The problem is that, when mapping the connectors on a particular driver (saa7134), we noticed that things are not so simple, because of the way it implements S-Video. > I just read the IRC discussion beginning from when I needed to leave, and it > looks like to me that we need to have a common understanding of the relevant > concepts before we can even reach a common understanding what is being > discussed. I'm not certain we're even at that level yet. > > Besides that, concepts should not be mixed. Things such as > MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an > S-video connector (which doesn't really exist). The signal is S-video and > the connector is variable, but often RCA. Well, "CONN" can be an alias for "connection", with is what we're actually representing. "Signal" is something else. As discussed, a single S-Video connection has 2 signals: Y and C. > > At least connector, input (and output I presume?) and signal need to be > defined. My problem with terms such as input and output at this level of the > API is that they're really generic terms, and we chose not to use them in MC > in the past exactly for that reason. After all the discussions, I guess "CONN" for connection is the best way to represent it. > > For instance, luminance and chrominance certainly are signals, but is > S-video a signal as well? I'd say so. No. S-video has 2 signals only: luminace and chrominance. Nothing else. > But should we make a difference between the two? For S-Video, we may not need to represent two pads. For HDMI, for sure we'll need to represent multiple signals, as they're routed on a different way (CEC, for example is a bus, that can be connected to multiple HDMI inputs and outputs). > Connectors are easy, everyone knows what they are. Having > read the meeting IRC log, I guess the word "input" was likely used to refer > signals transmitted over multiple physical wires, at least some of the time. > I'd prefer not to guess. > > > > > QUESTION: > > ======== > > > > How to represent the hardware connection for inputs (and outputs) like: > > - Composite TV video; > > - stereo analog audio; > > - S-Video; > > - HDMI > > > > Problem description: > > =================== > > > > During the MC summit last year, we decided to add an entity called > > "connector" for such things. So, we added, so far, 3 types of > > connectors: > > > > #define MEDIA_ENT_F_CONN_RF (MEDIA_ENT_F_BASE + 10001) > > #define MEDIA_ENT_F_CONN_SVIDEO (MEDIA_ENT_F_BASE + 10002) > > #define MEDIA_ENT_F_CONN_COMPOSITE (MEDIA_ENT_F_BASE + 10003) > > > > However, while implementing it, we saw that the mapping on hardware > > is actually more complex, as one physical connector may have multiple > > signals with can eventually used on a different way. > > > > One simple example of this is the S-Video connector. It has internally > > two video streams, one for chrominance and another one for luminance. > > > > It is very common for vendors to ship devices with a S-Video input > > and a "S-Video to RCA" cable. > > > > At the driver's level, drivers need to know if such cable is > > plugged, as they need to configure a different input setting to > > enable either S-Video or composite decoding. > > > > So, the V4L2 API usually maps "S-Video" on a different input > > than "Composite over S-Video". This can be seen, for example, at the > > saa7134 driver, who gained recently support for MC. > > > > Additionally, it is interesting to describe the physical aspects > > of the connector (color, position, label, etc). > > > > Proposal: > > ======== > > > > It seems that there was an agreement that the physical aspects of > > the connector should be mapped via the upcoming properties API, > > with the properties present only when it is possible to find them > > in the hardware. So, it seems that all such properties should be > > optional. > > > > However, we didn't finish the meeting, as we ran out of time. Yet, > > I guess the last proposal there fulfills the requirements. So, > > let's focus our discussions on it. So, let me formulate it as a > > proposal > > > > We should represent the entities based on the inputs. So, for the > > already implemented entities, we'll have, instead: > > > > #define MEDIA_ENT_F_INPUT_RF (MEDIA_ENT_F_BASE + 10001) > > #define MEDIA_ENT_F_INPUT_SVIDEO (MEDIA_ENT_F_BASE + 10002) > > #define MEDIA_ENT_F_INPUT_COMPOSITE (MEDIA_ENT_F_BASE + 10003) > > I presume INPUT would be for both input and output? We already have > MEDIA_ENT_F_IO and that's something quite different. > > I'd really like to have a better name for this. See above. > Another question indeed is whether modelling signals consisting of multiple > electrical signals is the way to go (vs. connectors, where the discussion > started). That's certainly another viewpoint. > > However it disconnects the actual connectors from the signals. What the user > sees in a device are connectors, not the signals themselves. Naturally that > approach does have its issues as well (such as break-out boxes), but > connectors are hardware and I believe we're not making a wrong choice if our > basic unit of modelling is a connector. I can't say the same on modelling > sets of signals instead. > > Applications that present information to the user would likely be much > better off with connectors, and such applications certainly are a valid use > case. Huh? you said above that you're against using "connectors"... now you're saying that you prefer using it??? The problem with "connector" is: sometimes the same physical connector is used to carry on different types of signals. This is very common with the S-video connector. We need to be able to distinguish between: - Composite via a composite RCA connector; - S-Video (with Y+C signals) via a S-Video 4-pin miniDIN connector; - Composite using a S-Video 4-pin miniDIN connector. >From software perspective, Composite over S-Video is a different mux configuration than S-Video (see saa7134 driver, for example). Yet, if we represent the connection entity as proposed, using one entity for each different input/output alternative, and PADs for signals, we cover all cases. We can even associate the physical connector associated with the connection via the properties API in the future. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
