14:00 < sailus> Hello! 14:00 < hverkuil> Hei! 14:00 < hverkuil> (or should I use the dutch 'Hallo 14:00 < hverkuil> :-) 14:00 < mchehab> hi 14:01 < pinchartl> hello 14:01 < sailus> Good, we're all here! 14:01 < sailus> So, I wanted to have this meeting to discuss two matters. 14:02 * pinchartl is still reviewing the glossary patch, I'll send the review as soon as it's complete, later today 14:02 < sailus> 1) What do we call the device consisting of multiple pieces of the hardware, which can be accessed using the media device node (on drivers that support MC). 14:02 -!- ndec [sid219321@linaro/ndec] has quit [Read error: Connection reset by peer] 14:02 -!- ntrrgc [uid105287@gateway/web/irccloud.com/x-aszhsqpbpdkrhqkn] has quit [Ping timeout: 248 seconds] 14:03 -!- ntrrgc [uid105287@gateway/web/irccloud.com/x-tlripedsawnjcviq] has joined #v4l 14:03 -!- ndec [sid219321@linaro/ndec] has joined #v4l 14:04 < sailus> 2) Should a V4L2 sub-device node be considered a "V4L2 device node" or not? From the point of view that V4L2 sub-devices *are* exposed by V4L2 sub-device drivers and seemingly, from user space, don't look that much different, yes, but we've always documented it somewhat differently. The sub-device nodes also don't implement many IOCTLs that all other node types do. 14:04 < sailus> But. Let's go to the first item first. 14:04 < mchehab> ok 14:04 < sailus> We haven't had a name for such a device and I understand the need for that became apparent. 14:04 < pinchartl> sailus: one question first 14:05 < pinchartl> when you say "the device consisting of multiple pieces of the hardware" 14:05 < pinchartl> are you looking for a name to describe the hardware, or a name to describe the software model of that hardware ? 14:05 < sailus> The hardware. 14:06 < mchehab> that's the proposal for it: 14:06 < mchehab> + Media hardware 14:06 < mchehab> + A group of hardware components that together form the 14:06 < mchehab> + functional media hardware. For instance the :term:`SoC` 14:06 < mchehab> + :term:`ISP` :term:`IP cores ` and external camera 14:06 < mchehab> + sensors together form the camera media hardware. 14:06 < mchehab> we also have: 14:06 < mchehab> + V4L2 hardware 14:06 < mchehab> + Hardware that is controlled by a :term:`V4L2 main driver` or a 14:06 < mchehab> + :term:`V4L2 sub-device driver`. V4L2 hardware is a subset of the 14:06 < mchehab> + :term:`media hardware`. Often the two are the same, but 14:06 < mchehab> + :term:`media hardware` can also contain other non-V4L2 hardware 14:06 < mchehab> + such as Digital TV hardware. 14:06 < mchehab> (that's glossary v8) 14:07 < mchehab> in other words, if it includes DVB, ALSA, RC, etc, it is "media hardware" 14:07 < mchehab> if it is just the stuff seen by V4L2 core, "V4L2 hardware" 14:07 < sailus> My issue with the current proposal is that hardware is a substance such as milk: you can't say "a hardware". Therefore media hardware or V4L2 hardware are bound to be somewhat vague, at least. 14:08 < sailus> I proposed "aggregate device", i.e. media aggregate device and V4L2 aggregate device, but we haven't used such a term in the past. 14:08 < pinchartl> I'm not fond of the word "device" 14:08 < sailus> I'd be happy to hear better proposals though. Or opinions on what's been discussed so far. 14:08 < pinchartl> it's one of the most confusing ones 14:09 < sailus> Yes, but it is still "a device", isn't it? 14:09 < pinchartl> "aggregate device" is bound to be abbreviated "device" in discussions, creating confusion 14:09 < sailus> Well, if we can have a good name that doesn't contain "device" I'm totally fine with it. 14:09 < hverkuil> I would argue that it is vague intentionally: engineers are endlessly inventive and I think "media hardware" and "V4L2 hardware" (being the part of the media hardware controlled by V4L2 drivers/interfaces) is the right level of abstraction. 14:09 < pinchartl> it's still a "device" the same way it is a "thing", yet you won't call it a "media thing" or "aggregate thing" :-) 14:09 < sailus> pinchartl: That's what always happens when you have a kind of devices. :-) 14:09 < sailus> Device nodes, for instance. 14:10 < mchehab> i like the term hardware too 14:10 < pinchartl> I could go with "media hardware device" 14:10 < pinchartl> if we then enformed a standard abbreviation for hardware device 14:11 < pinchartl> my point is basically that I don't want to see "device" used standalone 14:11 < pinchartl> for device nodes, we use devnode 14:11 < hverkuil> pinchartl: +1 14:11 < pinchartl> that's the de facto standard abbreviation 14:11 < mchehab> works for me 14:11 < pinchartl> everybody understands it 14:11 < sailus> Works for me. 14:11 < mchehab> oh, that was quick! 14:11 < hverkuil> pinchartl: how is "hardware device" better than just plain "hardware"? 14:11 < sailus> Good! We're done here then. :-) 14:11 < pinchartl> and it's short enough to avoid the use of "device" alone 14:11 < sailus> hverkuil: Hardware is a substance, device is a object. 14:11 < pinchartl> "hardware device" could be similarly abbreviated to "hwdev" 14:12 < mchehab> people will still call it device :-) 14:12 < sailus> :-D 14:12 < pinchartl> hwdev is short enough that we can push people to use that 14:12 < mchehab> ok 14:12 < pinchartl> it's shorter than device :-) 14:12 < pinchartl> of course I'm not saying that we need to use an abbreviation 14:12 < pinchartl> but if in practice we realize that "hardware device" is too long for people to write 14:12 < mchehab> well, it doesn't hurt adding it to the glossary 14:12 < pinchartl> we'll have hwdev that is unambiguous 14:13 < sailus> pinchartl: Will that encompass the fact that the device consists of multiple physical devices? So that sub-devices won't be confused with "media hardware device"? 14:13 < pinchartl> that's a good point 14:14 < mchehab> sailus: just using hardware is better 14:14 < pinchartl> we don't have "hardware device" in the glossary at the moment 14:14 < sailus> I'm not proposing "media hardware aggregate device". :-) 14:14 < pinchartl> we have "hardware component" 14:14 < mchehab> yeah, the glossary makes clear that "hardware component" is a subdevice and "media hardware" is the hole thing 14:14 < hverkuil> Sorry, I'm not sure "media hardware device" is a good name. A device can contain media hardware, yes, but also other things. 14:15 < sailus> So... device (or hardware) is a collection of components? That sounds a bit like redefining existing terms. 14:15 < pinchartl> hverkuil: as Sakari said, hardware in uncountable, you can't say "a media hardware" to describe one instance 14:15 < mchehab> + Hardware component 14:15 < mchehab> + A subset of the :term:`media hardware`. For example an :term:`I²C` 14:15 < mchehab> + or :term:`SPI` device, or an :term:`IP block` inside an 14:15 < mchehab> + :term:`SoC` or :term:`FPGA`. 14:15 < sailus> What do you think of "media aggregate device"? 14:16 < mchehab> I don't like it 14:16 < sailus> Are there other objections than we haven't used the word "aggregate" previously? 14:16 < mchehab> I could live it that, though 14:16 < pinchartl> sailus: that's an intirely new term that is long to type and doesn't have a good abbreviation 14:16 < pinchartl> it's bound to become "device" in discussions 14:17 < sailus> What we need here is a formal name to describe it when needed. 14:17 < pinchartl> yes, but a name that isn't too difficult to use 14:17 < pinchartl> otherwise nobody will use it 14:17 < mchehab> I still thing that media hardware/v4l2 hardware is OK 14:17 < hverkuil> What's wrong with saying: "my devkit has media hardware" (meaning an SoC with an ISP. DMA engines, sensors) 14:17 < mchehab> s/thing/think/ 14:17 < sailus> The fact we haven't had a term so far and are now coming up with one means that there's not an active need for it. 14:18 < pinchartl> sailus: I disagree, it means that we've had lots of confusing discussions before :-) 14:19 < sailus> What if we drop "device" from "media aggregate device"? 14:19 < pinchartl> ("aggregate device" seems to be used to describe aggregate audio outputs on macosx :-)) 14:19 < sailus> It becomes "media aggregate". 14:19 < mchehab> I doubt anyone would ever use it 14:19 < mchehab> in practice 14:19 < mchehab> it is just too weird on my ears 14:20 < pinchartl> sailus: aggregate is an adjective in this case, you can't use it alone 14:20 < pinchartl> although in the geological sense it's a noun 14:20 < mchehab> aggregate reminds the time I worked with telecommunications... it actually means part of a data stream 14:20 < sailus> pinchartl: From WordNet: "a sum total of many heterogenous things taken together". 14:21 < sailus> It's a noun as well. 14:21 < pinchartl> another option: we could use the word peripheral instead of device. "media peripheral" 14:21 < pinchartl> (I'm not very fond of that, but I could probably live with it) 14:21 < hverkuil> I also think 'aggregate' is too obscure. Just the fact that we're now looking it up in a dictionary really says it all :-) 14:21 < pinchartl> (just brainstorming) 14:21 < mchehab> pinchartl: it used to be peripheral... people argued against it at the ML 14:22 < mchehab> (don't remember the exact comments) 14:22 < pinchartl> I hope I wasn't the one arguing against it :) 14:22 < sailus> A peripheral is still just a... device. 14:22 < sailus> I guess I was. :-) 14:22 < mchehab> ah, I remember... people was thinking on printers and mice with this term 14:22 < pinchartl> sailus: yes, but it's not commonly used for lots of different meanings 14:22 < hverkuil> A 'media peripheral' is a webcam, printer, etc. 14:22 < mchehab> argued that a SoC ISP is not a peripheral 14:23 < sailus> pinchartl: How do you feel about "V4L2 hardware" and "Media hardware"? 14:23 < pinchartl> hverkuil: webcam is great, that's part of what we want to describe :) 14:23 < sailus> My dislike comes from the fact that this is improper use of the word hardware. 14:23 < mchehab> ???? 14:23 < mchehab> please ellaborate 14:23 < pinchartl> hverkuil: and if you're concerned about printers (or even disks) then we should s/media/multimedia/ everywhere. that would likely be more correct, but would also be painful 14:23 < mchehab> what's improper? 14:24 < sailus> It's a substance, such as milk. 14:24 < mchehab> so? 14:24 < mchehab> it is an incontable 14:24 < mchehab> noun 14:24 < pinchartl> mchehab: it's uncountable 14:24 < mchehab> but that's exactly what it is: 14:24 < sailus> You can't add an article to that. 14:24 < pinchartl> you can say "two media hardware devices" 14:25 < pinchartl> you can't say "two media hardwares" 14:25 < mchehab> something that can be split or merged 14:25 < pinchartl> two webcams, two media hardware devices, two media hardware 14:25 < pinchartl> the latter is incorrect 14:25 < mchehab> if we ever need to count it, we can just add "device" at the end 14:25 < mchehab> two media hardware devices 14:26 < pinchartl> then we should use "media hardware device" in singular form too :-) 14:26 < hverkuil> Right. A media device has media hardware. 14:26 < sailus> Which we discussed already: can that be confused with what is a sub-device? 14:26 < sailus> From the term alone nothing suggests it may not be a sub-device. 14:26 < mchehab> there aren't many places (if any) where we need to distinguish, at uAPI or kAPI if we have one or multiple media hardware devices 14:26 < sailus> I'd have to look up the definition, and I bet a lot of people won't. 14:26 < hverkuil> sailus: Which term are you referring to? "media device" or "media hardware"? 14:27 < sailus> "Media hardware device". 14:27 < pinchartl> (the English language also has the term "equipment", but that doesn't sound much better) 14:27 < sailus> Media, hardware and device are all very generic terms. 14:27 < mchehab> pinchartl: an ISP IP block inside a SoC is not an equipment 14:28 < hverkuil> "media hardware" is defined as a collection of hardware components. So I don't think there can be confused with a sub-device. 14:28 < pinchartl> mchehab: an ISP isn't a "media hardware device". the camera made by combining the ISP and the sensor is 14:28 < mchehab> it is not even a "device" from hardware PoV 14:28 < sailus> "Media agglomerate device"? 14:28 < mchehab> it is parto of "media hardware" 14:28 < hverkuil> but an ISP is part of "media hardware". 14:29 < sailus> I think I prefer "media aggregate device" to that. :-) 14:29 < mchehab> sailus: if you add "device", you excluse ISP 14:29 < mchehab> s/excluse/exclude/ 14:29 < pinchartl> sailus: I agree with you that aggregate is probably the right term to describe this, but it will be hard to use :-/ 14:29 < sailus> mchehab: Why? 14:29 < sailus> It's a device, too. 14:29 < sailus> An IP block can be a device, can't it? 14:29 < mchehab> a device implies that it is something physically distinct 14:30 < sailus> Well, it is, just in a silicon. :-) 14:30 < mchehab> https://en.oxforddictionaries.com/definition/device 14:30 < mchehab> piece of mechanical or electronic equipment. 14:30 < pinchartl> device: "Any piece of equipment made for a particular purpose, especially a mechanical or electrical one." 14:30 < pinchartl> or "(Ireland) An improvised explosive device, home-made bomb" :-) 14:30 < sailus> X-) 14:30 < pinchartl> media bomb :-) 14:31 < sailus> A home-made ISP? 14:31 < hverkuil> I agree with mchehab: I wouldn't call an IP block a "device". The SoC is a device, though. 14:31 < sailus> hverkuil: Linux views this in a different way. 14:31 < mchehab> yes, the SoC, as a hole, is a device 14:31 < BanHammor> a device is a node in /dev/, y'all :P 14:31 < sailus> We can't redefine terms that have established meanings. 14:31 < mchehab> linux device is software - let's not mix with hw 14:31 < sailus> Well, in Linux in particular. 14:31 < pinchartl> hverkuil: from the point of view of the Linux driver model, an ISP is a device (or sometimes a collection of devices) 14:32 < sailus> struct device is (may be) a software representation of hardware. 14:32 < hverkuil> pinchartl: yes, software wise (in the linux kernel) you are correct. But we're talking about describing hardware. 14:32 < mchehab> let's call it "struct device" to avoid mixing it with "hardware device" 14:32 < hverkuil> it's why the term "device" is so confusing and overloaded. 14:33 < mchehab> struct device is just an abstraction to represent something managed by a linux driver 14:33 < pinchartl> hverkuil: as we're writing a glossary that will be part of the kernel, I think we can assume that the word "device" alone will be understood by most in the Linux software sense. I don't want to redefine that 14:33 < mchehab> it can even be virtual 14:33 < mchehab> with no actual hardware attached to it 14:33 < pinchartl> so for the hardware we need to either qualify it ("hardware device") 14:33 < sailus> "Media device group"? 14:33 < pinchartl> or not use "device" at all 14:33 < sailus> "Media device ensemble"? 14:33 < hverkuil> "Media hardware group"? 14:34 < sailus> hverkuil: I like that. 14:34 < mchehab> IMHO, just media hardware is enough 14:34 < pinchartl> (another word to throw in the brainstorm: unit) 14:34 < sailus> pinchartl: Unit is too close to being a device IMO. 14:34 < pinchartl> mchehab: but hardware is uncountable :-( 14:34 < mchehab> so what? 14:34 < mchehab> where, at the API, is it relevant? 14:35 < pinchartl> sailus: it's another word, and has less of a pre-established meaning in the kernel. it might not be a good one, but I thought about it 14:35 < mchehab> are there any place at API where you need to count the media hardware devices? 14:35 < pinchartl> mchehab: you often have to say "a media hardware device" 14:35 < pinchartl> you can't say "a media hardware" 14:36 < sailus> mchehab: It's not just that it's uncountable, if you refer to media hardware you refer to all media hardware, whether it's a related group of devices or not. 14:36 < mchehab> where does it need to say "a media hardware device"? 14:36 < mchehab> I don't recall any place there where such distinguish is needed 14:36 < sailus> If there's just a single "aggregate device" in a system, you're fine, otherwise not. 14:37 < mchehab> from both V4L2 uAPI and kAPI PoV, it doesn't matter if you have a single media hardware device or multiple ones 14:37 < sailus> pinchartl, mchehab: How do you like hverkuil's proposal "media hardware group"? 14:37 < hverkuil> Perhaps have two terms in the glossary? One for "media hardware" using the current description, one for "media hardware device" which is defined as a device containing media hardware? 14:37 < mchehab> hverkuil: I'm OK with that 14:38 < mchehab> sailus: I don't see the need of "group" 14:38 < pinchartl> sailus: I think I'd prefer aggregate device in that case 14:38 < sailus> It makes it countable and bounded. 14:38 < mchehab> the thing is: for the API spec, it doesn't matter how many media devices are present 14:38 < sailus> Just as adding "device", but includes the suggestion it does not consist of a single piece of hardware. 14:39 < mchehab> on our discussions, we may need to refer to the case where multiple hw devices are present... 14:39 < pinchartl> mchehab: from the API point of view you need to be able to tell them apart. there will be one media devnode per media hardware device for instance 14:39 < mchehab> for such usage, we can live very well with either "hw device" or "media device" or "media hw device" 14:40 < sailus> "Media hardware bunch"? 14:40 < pinchartl> so we need a name that can be instantiated. it needs to be countable 14:40 < mchehab> pinchartl: no! 14:40 < pinchartl> no to what ? 14:40 < mchehab> pinchartl: the V4L2 API provide multiple devnodes per a single media hardware device 14:41 < mchehab> there are even multiple devnodes for a single DMA engine there 14:41 < pinchartl> mchehab: I meant one MC devnode :-) 14:41 < pinchartl> (this is really why a glossary is important...) 14:41 < mchehab> ok, first of all, this glossary is only at the V4L2 spec 14:41 < mchehab> it doesn't apply to MC (nor DVB, RC, CEC) 14:42 < sailus> "Media hardware set"? 14:42 < mchehab> second, for MC, we can use "media hardware device" 14:42 < sailus> "Media hardware... herd"? 14:42 < hverkuil> Again: is there any reason why we can't have two terms: "media hardware" and "media hardware device" in the glossary? I'm fine with that. 14:42 < pinchartl> mchehab: I don't think we should use one term in MC and another term in V4L2 to refer to the same physical concept, that would be quite confusing 14:43 < sailus> hverkuil: Why would we need two terms? 14:43 < mchehab> true, but it is out of the escope to extend the glossary to apply to the hole media documentation 14:43 < sailus> Do you anticipate people using "media hardware device", rather than just e.g. media device? 14:43 < pinchartl> mchehab: sure 14:43 < hverkuil> hole -> whole :-) 14:43 < sailus> There's a lack of clear distinction. 14:43 < mchehab> :-) 14:43 < pinchartl> hverkuil: "media hardware" really means all the media-related hardware present in the system 14:44 < mchehab> pinchartl: for the API PoV, such definition is fine 14:44 < mchehab> only MC requires to distinguish 14:44 < pinchartl> mchehab: I don't think so :-) if you have two PCI capture cards, you want to refer to them separately 14:44 < mchehab> as we have one /dev/mediaX per media hardware device 14:45 < pinchartl> trying to provide a summary of my current opinions: 14:45 < mchehab> so, adding "media hardware device" to the glossary should meet the goal 14:45 < pinchartl> - "media hardware aggregate" is the most precise term I've seen so far 14:45 < mchehab> pinchartl: Hauppauge has some devices that have two PCI cards bundled into one 14:45 < pinchartl> but it's also not commonly used 14:46 < pinchartl> (mchehab: I was talking about the general case, there can of course be exceptions) 14:46 < mchehab> from kernel and userspace PoV, it doesn't matter if you buy two HVR-150 or one HVR-500 14:46 < mchehab> they'll look the same 14:46 < hverkuil> other synonyms: grouping, constellation, assembly (or is that assemblage?) 14:46 < pinchartl> - "media aggregate device" retains the important information that it is an aggregate but lacks the hardware part (which could be fine, as this is a new term, we can define its meaning) 14:47 < pinchartl> - "media hardware device" lacks the aggregate part, but we could also decide that we define its meaning. on the plus side it has an easy abbreviation 14:47 < mchehab> again, if one needs to distinguish between two HVR-150 or one HVR-500, it could be said "two media hardware HVR-150 devices" or "one media hardware HVR-500 device" 14:47 < pinchartl> - "media hardware" is uncountable, I don't like that 14:47 < sailus> pinchartl: The downside with "media hardware device" is that there's no clear suggestion it may not refer to a sub-device alone. 14:48 < pinchartl> sailus: that too, yes. but again, as it's a new term, we can define it 14:48 < sailus> Yes, we'll be fine, but we're steepening the learning curve. 14:48 < hverkuil> sailus: that's why we have a glossary, to define such things. 14:48 < pinchartl> - "media hardware aggregate" is quite annoying to use, but on the plus side, as it doesn't contain the word "device", it won't be abbreviated to "device", so there should less risks of confusion and misuse 14:48 < sailus> The terms should be easy to remember, consistent and in best case self-explanatory. 14:49 < pinchartl> but to play the devil's advocate, "media hardware aggregate" is any assembly of hardware, even if it doesn't provide the complete user-oriented functionality 14:49 < pinchartl> for instance 14:50 < pinchartl> if you have a sensor, an ISP and a USB bridge 14:50 < pinchartl> the combination of the three is what we want to define 14:50 < pinchartl> but sensor + ISP or ISP + bridge would also be an aggregate 14:50 < hverkuil> http://www.dictionary.com/browse/grouping 14:50 < pinchartl> aggregate carries the meaning that there are multiple components, but not that they're all there 14:50 < mchehab> as I said before, in telco, "aggregate" is a component of something bigger 14:50 < sailus> pinchartl: Of course you could pick a set of devices that are not related, and call it an aggregate. But that'd be a bit of misuse of the term. 14:51 < sailus> The only real possible confusion with "aggregate" I can think of comes from this: 14:51 < pinchartl> mchehab: "A mass, assemblage, or sum of particulars; something consisting of elements but considered as a whole." 14:51 < sailus> https://fi.wikipedia.org/wiki/Aggregaatti 14:51 < pinchartl> (https://en.wiktionary.org/wiki/aggregate#English) 14:51 < mchehab> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/aggregate-edit-interfaces-sonet-options.html 14:51 < hverkuil> "media hardware grouping". Hmm, still not great. 14:51 < sailus> hverkuil: I prefer group over grouping, if it's between the two. 14:51 < hverkuil> sailus: me too 14:52 < pinchartl> sailus: I wonder what the etymology of that Finnish word is :) 14:52 < sailus> I like pinchartl's proposal of "media hardware aggregate" as well. 14:52 < pinchartl> (other words: cluster, collection) 14:53 < sailus> You see the word "group" being used in many other languages. 14:53 < pinchartl> mchehab: aggregate interfaces have a meaning in networking, yes 14:53 < mchehab> I won't doubt that "aggregate" could be used on DVB hierarchic transmissions with a similar meaning that it is for SDH 14:53 < pinchartl> mchehab: not "media hardware aggregate" though :-) 14:54 < mchehab> pinchartl: aggregate is a logical container 14:54 < mchehab> on some hierarchical transmissions 14:54 < pinchartl> aggregate is an ensemble 14:54 < hverkuil> Hmm: interesting synonym: media hardware ensemble 14:54 < hverkuil> :-) 14:54 < pinchartl> now we're getting in the music field, which is somehow related :-) 14:54 < sailus> hverkuil: That sounds very musical to me. :-) 14:54 < sailus> "Media hardware herd". 14:55 < hverkuil> (warning: I have a meeting in 5 minutes) 14:55 < sailus> There can be many different species in the herd, such as cameras and ISPs. 14:55 < sailus> You can also have two herds in the system. 14:55 < pinchartl> either there's no good term for this in English, or we're missing something very obvious. I can't tell :-/ 14:55 < sailus> Hmm. The more I use it, the more I like it. 14:56 < sailus> pinchartl: I'd say that there's no common need to refer such groupings of hardware devices. 14:56 < sailus> That's why it has no established name. 14:56 < hverkuil> The two realistic options I've seen are: media hardware device or media hardware aggregate. 14:56 < mchehab> I still think that, if we use group/ensemble/aggregate/herd/... it won't be representing what we want 14:56 < hverkuil> I lean towards the first, but will be OK with the second. 14:56 < sailus> From the two, I prefer "media hardware aggregate". 14:57 < pinchartl> hverkuil: those are my two favourite ones. the former only provided that we enforce the hwdev abbreviation is someone tries to call it dev 14:57 < mchehab> as one could understand a "media hardware heird/group/ensemble/aggregate" as group of PCI devices... 14:57 < hverkuil> I think sailus is right: there is no real term for this. I've used 'constellation' in the past in V4L2 presentations. 14:57 < pH5> how about 'complex' 14:58 < hverkuil> "media hardware complex". Not bad. 14:58 < sailus> pH5: Works for me. 14:58 < pinchartl> pH5: that's an adjective too :-/ 14:58 < mchehab> the only term that really defines a single PCI device would be to use the word "device" :=) 14:58 < pinchartl> (actually it can be a noun, indeed) 14:58 < sailus> pinchartl: Complex is a noun, too. 14:59 < sailus> Will it be "media hardware aggregate" or "media hardware complex"? 14:59 < mchehab> using any other word different than "device" when we need to count media hardware pieces will cause confusion 14:59 < pinchartl> mchehab: that's why we need to define the term, yes 14:59 < pinchartl> "media hardware complex" isn't bad either I think 15:00 < pinchartl> but maybe I only like it because it's new and we've been discussing this for an hour already :-) 15:00 < mchehab> it isn't bad, but it is worse than "media hardware device" 15:00 < pinchartl> Hans has a meeting now, should we use that time to let "media hardware complex" sink in our brains ? 15:00 < pinchartl> mchehab: you could call it media hardware device complex is you insist :-) 15:00 < sailus> Sounds like a good idea. 15:00 < sailus> => Sinking, that is. 15:01 < mchehab> singing :-p 15:01 < sailus> I wouldn't object singing either though. 15:01 < pH5> yeah, sorry for jumping in with a new suggestion at the very end, I just read the backlog :) 15:01 < sailus> pH5: New suggestions are always good. :-) 15:01 < sailus> Especially before decisions. 15:02 < sailus> Hans said his meeting will take an hour and I'll need to leave soon after he'll be back. 15:02 < pinchartl> pH5: that's what brainstorming is about 15:02 < sailus> How about continuing in Friday? 15:02 < sailus> Before or after the weekly meeting. 15:02 < sailus> We can decide that today. 15:03 < sailus> I prefer before, I'll also need to leave the office soon after the weekly meeting on Friday. 15:03 < mchehab> works for me 15:04 < pinchartl> works for me too 15:05 < sailus> I.e. same time than today, but on Friday. 15:19 -!- syoung [~sean@gofer.mess.org] has quit [Quit: leaving] 15:22 -!- LazyGrizzly [~edt@31.209.95.242] has quit [Quit: Leaving.] 15:22 < hverkuil> It should be OK on Friday. 15:25 < hverkuil> I rather like "complex" as it also has the connotation of the constituent parts being connected (as in a "building complex"). 15:26 < hverkuil> "an intricate or complicated association or assemblage of related things, parts, units, etc." 15:36 < snawrocki> let me throw these in: "media composite device", "media hardware subsystem", "media compound device" 15:38 -!- YuGiOhJCJ [~YuGiOhJCJ@gateway/tor-sasl/yugiohjcj] has quit [Quit: YuGiOhJCJ] 15:39 -!- headless [~headless@31.173.80.222] has quit [Quit: Konversation terminated!] 15:47 < sailus> snawrocki: Thanks, good suggestions! 15:47 < BanHammor> the docs are a little unclear on this: what is the difference between calling VIDIOC_REQBUFS with count=0 and calling VIDIOC_STREAMOFF? 15:48 < BanHammor> both seem to free all buffers, both call the stop_streaming op. 15:49 -!- iive [~iive@87.119.101.204.client.entry.bg] has joined #v4l 15:49 -!- iive [~iive@87.119.101.204.client.entry.bg] has quit [Changing host] 15:49 -!- iive [~iive@unaffiliated/iive] has joined #v4l 15:50 < sailus> VIDIOC_STREAMOFF does not release buffers, just stops streaming. 15:50 < sailus> It might have done that with videobuf1 though. 15:50 < sailus> REQBUFS with count=0 releases the buffers. 15:51 < BanHammor> ah i see 15:51 < BanHammor> i was confused by "all images captured but not dequeued yet will be lost, likewise all images enqueued for output but not transmitted yet" 15:53 < sailus> Yes, the buffers are dequeued and shall have the V4L2_BUF_FLAG_ERROR flag set. 15:54 < sailus> But not released. 15:57 -!- dmt [~dmt@cpe.xe-3-0-1-778.vbrnqe10.dk.customer.tdc.net] has joined #v4l 15:58 < BanHammor> so how does one reset that flag? 15:59 < BanHammor> (oh i guess you just overwrite it in userspace when you pass struct v4l2_buffer) 15:59 < BanHammor> thanks! 16:01 < sailus> The flag is just informational to the user space AFAIR. 16:02 < sailus> No need to clean it explicitly before requeuing the buffer. 16:02 < sailus> That's at least as far as I remember. 16:06 -!- syoung [~sean@gofer.mess.org] has joined #v4l 16:10 < pinchartl> snawrocki: thanks. I like composite and compound too. less fan of subsystem personally as it has an established meaning in the kernel 16:10 < sailus> I put the suggestions to Etherpad here: 16:10 < sailus> http://muistio.tieke.fi 16:10 < sailus> The pad name is media-device-naming --- Day changed Thu Oct 12 2017 --- Day changed Fri Oct 13 2017 12:45 < mchehab> hverkuil, sailus, pinchartl: can we do our meeting today earlier? I have to do lots of errands today, as I'll be traveling for the next two weeks 12:48 < hverkuil> mchehab: fine by me. 12:53 -!- prabhakarlad [~prabhakar@194.75.40.178] has joined #v4l 12:55 < pinchartl> mchehab: at what time ? 12:56 < mchehab> right now? 12:57 < mchehab> (one hour earlier than previously scheduled) 12:59 < pinchartl> if Sakari is available it works for me 13:00 -!- Elladan [~elladan@unaffiliated/elladan] has quit [Quit: ZNC - http://znc.in] 13:00 < pinchartl> hverkuil: my 50 patches series for omapdrm now conflicts due to your omap4 cec work. damnit :-) 13:02 -!- Elladan [~elladan@unaffiliated/elladan] has joined #v4l 13:09 -!- headless [~Thunderbi@31.173.81.77] has quit [Quit: headless] 13:15 -!- iive [~iive@87.119.101.204.client.entry.bg] has joined #v4l 13:15 -!- iive [~iive@87.119.101.204.client.entry.bg] has quit [Changing host] 13:15 -!- iive [~iive@unaffiliated/iive] has joined #v4l 13:15 < pinchartl> and now my pandaboard fails to boot. *sigh* 13:22 < mchehab> pinchartl: out of curiosity, does such patch series finally get rids of OMAP-specific DMA stuff and allows building omap drivers with COMPILE_TEST? 13:24 < pinchartl> mchehab: nope 13:24 < pinchartl> the patch series touches the omap drm driver, not the V4L2 driver 13:25 < pinchartl> omap_vout should be dropped 13:25 < pinchartl> but there's one last feature not present in omapdrm that would make that a regression 13:25 < pinchartl> if we could get feature parity then we should drop the omap_vout driver completely 13:25 < pinchartl> it's unmaintained and TI isn't interested in it 13:26 < hverkuil> pinchartl: would be nice to drop it! 13:27 < pinchartl> hverkuil: all it needs is a customer willing to sponsor the development of display rotation on omap3 in omapdrm :-) 13:27 < mkrufky> hverkuil: yes i will be there all week 14:02 -!- ttomov [~ttomov@37.157.136.206] has quit [Quit: Leaving.] 14:02 < sailus> Hello! 14:03 < hverkuil> sailus: you'll be at the ELCE for the whole week as well? 14:04 < sailus> hverkuil: Yeah. 14:05 < hverkuil> good, I wasn't 100% certain. 14:07 < pinchartl> hverkuil: I've just seen the "[ANN] Call for topics for the media mini-summit on Friday Oct 27 in Prague" mail thread 14:07 < pinchartl> better late than never... 14:21 -!- headless [~headless@31.173.81.77] has joined #v4l 14:27 -!- ttomov [~ttomov@37.157.136.206] has joined #v4l 14:40 < sailus> Let's continue our discussion on naming-related things from Wednesday. 14:40 < hverkuil> ah, yes 14:40 < sailus> There are two topics to discuss: 14:41 < mchehab> let's continue topic 1 14:41 < sailus> The name for the related or interconnected set of hardware devices, typically which can be controlled through the media device (if supported by the drivers). 14:41 < sailus> (Which is the first one.) 14:41 < sailus> The second one is V4L2 sub-device nodes should be documented to be "V4L2 device nodes". 14:41 < sailus> Let's start with the first one. 14:42 < pinchartl> regarding the first one, I like "media hardware complex" 14:42 < hverkuil> +1 14:42 < sailus> The meeting ended with a few options that there was no yet common agreement. 14:42 < mchehab> I took those days to think about "media hardware" and the proposed alternatives... I still think that, whenever we don't need to count the number of devices, "media hardware" is the best choice 14:42 < sailus> There were a few more options proposed after the meeting, also people who missed the meeting. 14:42 < sailus> I wrote them all down here: 14:42 < sailus> http://muistio.tieke.fi/p/media-device-naming 14:43 < sailus> Please take a brief moment to read it, and then let's discuss it. 14:43 < mchehab> you forgot "media hardware device" there 14:43 < hverkuil> I really want to avoid the word "device". And of the remaining options "media hardware complex" fits best IMHO. 14:44 < sailus> mchehab: Thanks for bringing this one up. 14:44 < hverkuil> complex: "an intricate or complicated association or assemblage of related things, parts, units, etc." 14:45 < sailus> hverkuil: I like it, too. 14:45 < mchehab> let's go by parts... 14:45 < mchehab> a) do we really want to use an accountable name everywhere? 14:45 < sailus> Most related words would do IMO (compound, complex, aggregate). 14:45 < mchehab> b) where an accountable name is required, what would be such name 14:46 < pinchartl> sailus: agreed, and amount those three I like complex the best 14:46 < sailus> mchehab: I think it should be countable, yes. 14:46 < mchehab> IMHO, the answer for (a) is NO 14:46 < pinchartl> mchehab: I think it should be countable 14:46 < mchehab> on most places, it should not be accountable 14:46 < sailus> mchehab: Why should it not be countable? 14:46 < mchehab> s/accountable/countable/ 14:47 < mchehab> because, on most parts of the V4L2 API, it doesn't matter at all if a set of device nodes belong to a single or to multiple physical devices 14:47 < sailus> mchehab: Here, we especially *want* to convey the meaning that these devices belong together. 14:47 < sailus> That's what the term means. 14:48 < mchehab> if we add an accountable term, we will likely need to say "one or more BAR" 14:48 < mchehab> (where BAR is whatever we name it) 14:49 < pinchartl> no we won't need to say "one or more" 14:49 < mchehab> sailus: where at the API spec you *want* the meaning that these devices belong together? 14:50 < sailus> Devices can be counted, too. Pretty much everything can be. 14:50 < sailus> Except hardware. :-) 14:50 < sailus> (Well, there's software, tupperware, milk, etc.) 14:51 < hverkuil> An MC relates to a media hw complex. "media hardware" can contain multiple media hw complexes. I think that is a good distinction to make. 14:52 < pinchartl> hverkuil: in that case it would be a system containing media hardware complexes 14:52 < pinchartl> not "media hardware" 14:52 < hverkuil> yes 14:52 < pinchartl> you wouldn't say "silicon can contain multiple media hardware complexes" 14:53 < hverkuil> "a system containing media hardware complexes": nice phrase 14:53 < pinchartl> but "an SoC/computer/system/... can contain multiple media hardware complexes" 14:53 < mchehab> hverkuil: I'm talking about https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l 14:54 < mchehab> try to replace the word "device" there to "media hardware" at chapter 1 14:54 < mchehab> 14:54 < mchehab> (not only at open section) 14:54 < mchehab> then try to replace it to "media hardware complex" 14:54 < mchehab> IMHO, if we use "media hardware complex", we'll make it a lot more complex to understand the meaning 14:54 < mchehab> e.g.: 14:55 < mchehab> Devices can support several functions. For example video capturing, VBI capturing and radio support. 14:55 < mchehab> Media hardware can support several functions. For example video capturing, VBI capturing and radio support. 14:55 < mchehab> that's OK 14:55 < sailus> mchehab: Media controller isn't part of V4L2. 14:55 < mchehab> Media hardware complexes can support several functions. For example video capturing, VBI capturing and radio support 14:55 < mchehab> (that sounds really weird) 14:56 < pinchartl> mchehab: it sounds weird because we're used to the word "device" 14:56 < mchehab> it sounds weird because "complex" means nothing 14:56 < sailus> mchehab: Yes, it does. 14:56 < mchehab> for a casual reader 14:57 < mchehab> is a PCI device a complex? 14:57 < hverkuil> For non-platform devices (usb, pci, etc) the term "device" effectively refers to a single 'media hardware complex' that is part of the product. 14:57 < pinchartl> hverkuil: doesn't it refer to the whole product in that context ? 14:57 < mchehab> on a PCI device with a PCI bridge inside it, a complex is each PCI sub-device or the hole thing? 14:57 < hverkuil> Most PCI cards have a bunch of ICs, so it definitely is a complex. 14:58 < mchehab> an embedded hardware with multiple PCI capture boards is a single "complex" or multiple complex? 14:58 < pinchartl> mchehab: "an embedded hardware" is not correct English, hardware is uncountable 14:58 < sailus> mchehab: In most cases when you refer to hardware, a "device" will suffice. If you want to underline the fact that the device actually consists of multiple smaller pieces of hardware, then you have to use "media hardware complex". That's how I'd see it. 14:58 < mchehab> the problem with "complex" as this is not an usual term to refer to a board 14:59 < hverkuil> I think I would only used it in the context of the MC. 14:59 < mchehab> hverkuil: I agree with that 14:59 < mchehab> talking about a media hardware complex at MC makes a lot of sense 15:00 < pinchartl> mchehab: it doesn't make more sense in MC than in V4L2 15:00 < mchehab> but talking about that at the places we need at uapi/v4l will only cause confusion, for no good reason 15:00 < mchehab> pinchartl: the V4L2 API doesn't care how the hardware is bundled 15:00 < pinchartl> yes it does 15:01 < mchehab> where? 15:01 < pinchartl> because it refers to "devices" today 15:01 < mchehab> if you replace "devices" by "hardware" it will work just fine, on almost all places 15:01 < pinchartl> any use of the word "device" that means a piece of hardware offering features usable directly by end-users is what we're trying to define 15:01 < mchehab> it doesn't need to count the hardware 15:02 < pinchartl> no, hardware is uncountable, you can't replaces "devices" by "hardware" 15:02 < mchehab> on almost all places at the documentation, yes you can 15:02 < mchehab> (v4l2 documentation - not mc documentation) 15:02 < pinchartl> no you can't, that's not English, sorry 15:03 < mchehab> pinchartl: of course if you replace "devices" to "hardware" you'll need to change the phrase to be in singular to match English gramaar 15:04 < mchehab> but there's nothing in English forbidding the usage of uncountable words 15:04 < sailus> mchehab: Uncountable comes with certain vaguety when you actually have a number of items that belong to different groups. 15:05 < mchehab> the discussion here is not about English... is about changing the document in order to count the number of hardware elements 15:05 < pinchartl> grepping in the V4L uAPI documentation and taking the first hit 15:05 < mchehab> sailus: precisely 15:05 < pinchartl> "Video devices typically support one or more different video standards" 15:05 < mchehab> the question is: where do we need, within V4L2 API, to not be vague - e. g. where do we need to count for hardware elements? 15:06 < pinchartl> if you say "Video hardware typically supports one or more different video standards" it's not the same meaning 15:06 < mchehab> "Media hardware typically supports one or more different video standards" 15:06 < mchehab> it has the same meaning 15:06 < pinchartl> no 15:06 < pinchartl> second hit in the same file 15:06 < pinchartl> "Special rules apply to devices such as USB cameras where the notion of video standards makes little sense." 15:07 < pinchartl> that would become "Special rules apply to hardware such as USB cameras where the notion of video standards makes little sense." which doesn't have the exact same meaning 15:07 < mchehab> s/devices/hardware/ 15:08 < pinchartl> trying to fine another use of "device" that doesn't refer to a devnode 15:08 < sailus> I think it'd make sense to apply this (media hardware complex) to MC-centric devices, and the MC API. 15:09 < mchehab> pinchartl: on the above senteces, using hardware didn't make the sentence false, nor anything got lost 15:09 < pinchartl> Video capture devices sample an analog video signal and store the 15:09 < pinchartl> digitized images in memory. Today nearly all devices can capture at full 15:09 < pinchartl> 25 or 30 frames/second. With this interface applications can control the 15:09 < pinchartl> capture process and move images from the driver into user space. 15:09 < sailus> From the user's point of view, there's much more room for confusion with MC than there is without, and that's what I think we want to resolve. 15:09 < pinchartl> you can't s/devices/hardware/ there either 15:10 < sailus> "Device" can otherwise mean any kind of piece of hardware, also a media hardware complex. 15:10 < mchehab> pinchartl: replacing it by "Media hardware complex" will make it really bad 15:10 < sailus> Just as outside V4L2 / MC. 15:10 < pinchartl> mchehab: that I agree with 15:10 < sailus> hverkuil: Any opinion on the scoping? 15:11 < pinchartl> if we want to replace the term "device" in the V4L2 documentation by something short and self-explicit, I can only think of "peripheral" 15:11 < mchehab> "Video capture media hardware complexes sample an analog video signal and 15:11 < mchehab> store the digitized images in memory. Today nearly all 15:11 < mchehab> media hardware complexes can capture at full 25 or 30 frames/second. 15:11 < mchehab> With this interface applications can control the 15:11 < mchehab> capture process and move images from the driver into user space." 15:12 < pinchartl> as "device" is used to refer to a consumer (or at least end-user) device there, which is also referred to as peripheral by end-users 15:12 < mchehab> this sounds a lot better: 15:12 < mchehab> "Video capture media hardware sample an analog video signal and 15:12 < mchehab> store the digitized images in memory. Today nearly all new 15:12 < mchehab> hardware can capture at full 25 or 30 frames/second. With this 15:12 < mchehab> interface applications can control the capture process and move 15:12 < mchehab> images from the driver into user space." 15:12 < mchehab> (or just "Video capture hardware") 15:13 < pinchartl> no need for "media" in V4L2 15:13 < pinchartl> it's video (or radio, ...) 15:13 < pinchartl> it's already explicit in the documentation 15:13 < sailus> I don't really see a need to get rid of the plain good device in these sentences. 15:13 < pinchartl> sailus: neither do I 15:14 < mchehab> I would actually rephase the sentence to: 15:14 < mchehab> "Video capture works by sampling an analog video signal and 15:14 < mchehab> storing the digitized images in memory. Today nearly all new 15:14 < mchehab> hardware can capture at full 25 or 30 frames/second. With this 15:14 < mchehab> interface applications can control the capture process and move 15:14 < mchehab> images from the driver into user space." 15:14 < sailus> It's just when we want to tell that a device (the media hardware complex) actually consists of a number of devices. 15:15 < mchehab> sailus: that's exactily my point: we only need something like that where we need to explicitly say that it "consists of a number of devices". 15:15 < mchehab> and then, the term "device" is a way more accurate than "complex" 15:16 < sailus> mchehab: The problem with device in this case is that it may mean so many different things. 15:16 < sailus> And it's already being used in ways that conflict with what we want to convey with the term. 15:16 < sailus> That's why the device is not a good choice here. 15:16 < pinchartl> sailus: no, we need a term when we want to differentiate it from the other kind of "devices" 15:16 < pinchartl> not when we want to tell it's made of multiple pieces 15:16 < mchehab> sailus: at V4L uAPI spec, "device" should be used only when it refers to something physical. 15:16 < pinchartl> in the above sentence the meaning is quite explicit already 15:17 < sailus> Hmm. Aren't hardware devices physical in general? :-) 15:17 < mchehab> we may add "hardware device" to ensure that, where it is not ambiguous 15:18 < mchehab> sailus: within uAPI, I'm almost sure that, on all cases, it refers to hardware (physical) devices 15:19 < mchehab> the confusion happens at kAPI, where device can be either hw device or struct device 15:19 < mchehab> IMHO, what we should do there is to always prepend "device" with either "hw/hardware" or "struct" to remove the ambiguity 15:19 < sailus> I think we're drifting to other topics... 15:19 < mchehab> no, we're still on topic 1 15:20 < pinchartl> mchehab: we use the word "device" in the uAPI documentation to refer to a device node too. those usages should be fixed to use "device node" explicitly 15:20 < sailus> Good, good. 15:20 < mchehab> pinchartl: agreed! 15:21 < larsc> the device of the device represents the device 15:21 < sailus> :-D 15:21 < mchehab> I guess general rule is: never use "device" alone. It should *always* come to another word to distinguish: struct, hardware, node, etc 15:21 -!- LazyGrizzly [~edt@31.209.95.242] has left #v4l [] 15:21 < sailus> mchehab: At least if you want to be precise, I'd say. Which mostly is the case with documentation... 15:22 < sailus> hverkuil: Still there? 15:23 < mchehab> sailus: agreed. If you're OK with that, once we merge the mc-centric stuff, I can seek (as time permits) for all "device" at uAPI and check for the need of an extra word to solve ambiguity 15:24 < pinchartl> mchehab: "device" is used alone in many places in the V4L2 uAPI documentation. in the locations that are not ambiguous, it could be used standalone to avoid repeating the qualifier 15:24 < mchehab> at kAPI, what I'm actually doing is to always use "&struct device" to refer to Kernel's representation 15:24 < mchehab> pinchartl: shure 15:24 < mchehab> s/shure/sure/ 15:26 < sailus> mchehab: What pinchartl said makes also sense, if there's repeated need to refer to "hardware devices" only, then further referrences could be just "device" if there's no room for ambiguity. 15:26 < sailus> Otherwise there could be many, many repetitions of hardware, for instance. 15:26 < sailus> But those cases could be rare. I can't say. 15:26 < sailus> I have to admit I usually only read the documentation when I want to check how something is documented to work. :-) 15:27 < mchehab> well, I'm reading it a lot those days, but just because I'm trying to fix it :-) 15:28 < sailus> Going back to the terms... 15:28 < pH5> schtroumpf 15:29 < mchehab> that sounds a password :-) 15:29 < mchehab> pH5: ^ 15:29 < sailus> mchehab: Looks like me, pinchartl and hverkuil would be ok with "media hardware complex" when referring to hardware controlled through an MC interface. 15:29 < pH5> I agree that "complex" should not be used where the focus is not on it being comprised of multiple interconnected parts. 15:29 < sailus> I think that would mostly be only relevant when it comes to MC documentation, not V4L2. 15:30 -!- headless [~headless@31.173.81.77] has quit [Quit: Konversation terminated!] 15:30 < sailus> With V4L2 you can use "hardware device" since the user space API does not show how the hardware actually looks like. 15:30 < pH5> But it describes MC style hardware well in my mind. 15:30 < sailus> mchehab: What do you think? 15:30 < mchehab> sailus: while I think "media hardware device" would be better for MC, I can live with "media hardware complex" on such context 15:31 < sailus> mchehab: Great! 15:31 < pH5> mchehab: nope, just an involuntary reaction to larsc's comment 15:32 < sailus> Are there any remaining concerns regarding this, i.e. using "media hardware complex" in MC documentation when referring to the group of devices that are controlled (enumerated) through a MC device node? 15:32 < mchehab> pH5: in order to solve the ambiguity of your involuntary reaction, are you referring to https://fr.wikipedia.org/wiki/Les_Schtroumpfs? :-p 15:32 < pH5> mchehab: indeed 15:33 < sailus> Sounds good then. 15:34 < sailus> We can proceed to the following topic. 15:34 < sailus> Which is whether V4L2 sub-devices are considered, from the documentation point of view, to be "V4L2 device nodes" or not. 15:34 < mchehab> ok. as the glossary is (currently) only at v4l2, I guess it could remain without "media hardware complex" on my patch series. I'll add another patch at the end adding this term 15:35 < sailus> Ah I was too quick. :-) 15:35 < sailus> mchehab: Didn't you have "Media hardware" or such there? 15:35 < mchehab> yes, but that will remain as-is, right? Or should we replace it to "hardware device"? 15:36 < sailus> The glossary shouldn't be specific to V4L2 only btw. 15:36 < mchehab> yes, I know! 15:36 < sailus> I'd need to go back to the definition. 15:36 < mchehab> but moving I wouldn't be moving it out of V4L2 while we don't validate it first there 15:36 < sailus> Is "hardware device" enough? 15:36 < sailus> And do we even need to document such a thing? 15:37 < sailus> I'd say no, since it's very common and generic. 15:37 < mchehab> as it may conflict with other terms used inside DVB, CEC, RC and media 15:37 < sailus> mchehab: Works for me. 15:38 < sailus> But we shouldn't add any other terms that are used for the same purpose than "media hardware complex" to remain consistent going forward. 15:38 < mchehab> sailus: we need it in order to explain "V4L2 hardware" with is the subset of "media hardware" that doesn't have ALSA, DVB, RC, CEC on it 15:38 < sailus> Let me re-review the patch in the light of this discussion. 15:39 < sailus> mchehab: "V4L2 hardware device"? 15:39 < mchehab> works for me 15:40 < sailus> Agreed. 15:40 < mchehab> in order to move to the next item, I guess you could re-review the patchset and point for those things, as, now that we reached an agreement, it should be minor changes to be done there 15:40 < sailus> I'd propose doing that offline, it'll take some time and the discussion will likely continue on the mailing list. 15:40 < mchehab> (09:34:45) sailus: Which is whether V4L2 sub-devices are considered, from the documentation point of view, to be "V4L2 device nodes" or not. 15:41 < mchehab> OK 15:41 < sailus> We've also lost pinchartl and hverkuil. 15:41 < sailus> They haven't reviewed the set though. 15:41 < mchehab> they're likely listening 15:41 < mchehab> hverkuil did review the set a few times 15:41 < sailus> I'd like to see a sign of that. For now I assume they'll be able to read the logs. 15:41 < mchehab> pinchartl said he's reviewing it today 15:42 < sailus> Anyway, let's proceed. 15:42 < mchehab> (09:34:45) sailus: Which is whether V4L2 sub-devices are considered, from the documentation point of view, to be "V4L2 device nodes" or not. 15:42 < pinchartl> mchehab: I'm working on your 12-patches series first though 15:42 < pinchartl> sorry, 17 patches 15:42 < mchehab> OK 15:42 < mchehab> the real issue on topic 2 is that we need a consistent way to refer to: 15:43 < mchehab> "device nodes created by v4l-core that aren't MC nor subdev API nodes" 15:43 < mchehab> on a separate but related matter, the subdev API is different than the V4L2 API: 15:44 < mchehab> its "open" syscall handling doesn't have all complexity of V4L2 one; 15:44 < sailus> mchehab: Is there a need to refer to all device nodes exposed through V4L2 that are not sub-device nodes? 15:44 < sailus> Or, perhaps we should take a small step back first. 15:44 < mchehab> only a very limited of ioctls are valid on subdevs; 15:44 < sailus> There are two things that I had in mind, for the preparation of this discussion: 15:44 < mchehab> it has its own ioctls. 15:45 < mchehab> sailus: answering your question: YES. We need to refer to all device nodes exposed through V4L2 that are not sub-device nodes 15:45 < sailus> V4L2 sub-device interface is mostly separate from documentation, and it implements IOCTLs that are not plain V4L2 IOCTLs. It is also a plain control interface. 15:46 < mchehab> most of what's written at "open" V4L2 section refers to those devices *only* 15:46 < pinchartl> how about "V4L2 streaming device nodes" for the non-subdev ones ? 15:46 < mchehab> (and on several other parts of - at least - chapter 1) 15:46 < sailus> Then again, V4L2 sub-device nodes *are* V4L2 device nodes in three respects: V4L2 sub-device interface is documented as part of V4L2, includes V4L2 in the name and the device nodes themselves are exposed by V4L2, using the same major number. 15:46 < mchehab> pinchartl: radio is a non-streaming V4L2 device node 15:47 < mchehab> and so it is touch devices 15:47 < sailus> So I'd say the current way things are documented is internally inconsistent, at least. 15:47 < mchehab> (well, I guess touch devices are streaming) 15:47 < mchehab> sailus: yes, it is inconsistent 15:48 < sailus> Btw. the V4L2 sub-device IOCTLs are documented as part of V4L2 IOCTL documentation, too. 15:48 < pinchartl> we could explicitly state that radio devnodes are considered as "V4L2 streaming device nodes" 15:48 < mchehab> that sounds *wrong* 15:49 < mchehab> that are some radio devices that don't stream *at all* 15:49 < pinchartl> yes, I know 15:49 < sailus> There's the proposal of adding VIDIOC_QUERYCAP support for sub-devices. That would bridge the gap from node identification point of view, so all V4L2 device nodes could be queried this way. 15:49 < mchehab> the audio is just output via an external analog PAD 15:50 < pinchartl> we can't rewrite history and deal with that abuse of the V4L2 API though :-) 15:50 < mchehab> sailus: please don't add ioctls due to documentation issues!!! 15:50 < sailus> mchehab: It wasn't proposed for that, and I did not propose it. 15:50 < pinchartl> but I still think that "V4L2 streaming device node" is a good enough description. it makes it clear that it's not a subdev 15:50 < sailus> It's also not about documentation only: if you have a V4L2 device node, that's how you can query what kind of a node it is. 15:50 < mchehab> pinchartl: we can move subdev ReST file to be a new part of the media documentation 15:50 < mchehab> IMHO, that's the best way to solve it 15:51 < pinchartl> they're still part of V4L2 15:51 < pinchartl> but if you want my opinion on the subject 15:51 < pinchartl> we should get rid of subdev devnodes 15:51 < pinchartl> (that's a topic for Prague though) 15:51 < sailus> pinchartl: I'd ask you to elaborate, but let's save that for later. :-) 15:52 < mchehab> well, I never liked them :-) yet, it sounds too late to get rid of them 15:52 < mchehab> anyway, topic for Prague 15:53 < pinchartl> definitely not for now :-) 15:53 -!- neg [~neg@unaffiliated/neg] has quit [Read error: Connection reset by peer] 15:53 -!- neg [~neg@unaffiliated/neg] has joined #v4l 15:53 < mchehab> sailus: from what I remind, the VIDIOC_SUBDEV_QUERYCAP discussions were leading into a different structure for subdev capabilities 15:54 < sailus> mchehab: I just looked at the patch, and there doesn't seem to be a technical reason for that. 15:54 < sailus> Or did I miss it? 15:54 < sailus> Controls use the exactly same IOCTL argument struct, too. 15:54 < pinchartl> the idea was to use the same structure 15:55 < mchehab> the point is: whatever rules apply to a "normal" V4L2 device, it doesn't apply to a subdev, except if such thing is explicitly described at the subdev ReST chapter 15:55 < pinchartl> but that required a VIDIOC_QUERYCAP_V2 15:55 < pinchartl> (if I remember correctly) 15:55 < mchehab> hverkuil's proposal were to add something there in order to discover the "parent" devnode for a subdev 15:56 < mchehab> pinchartl nacked, but that was the proposal :-) 15:56 < mchehab> anyway, we're diverging from the topic 15:56 < mchehab> I need to leave in a few 15:56 < sailus> Yes. 15:57 < pinchartl> my opinion is that subdevs are part of V4L2, so I would expect V4L2 device node to include subdev devnodes too 15:57 < sailus> I think the inconsistency in the documentation could best be arranged by making V4L2 sub-device interface a part of V4L2 proper. 15:57 < pinchartl> we could use "V4L2 video device node" for the non-subdev devnodes 15:58 < sailus> Otherwise there's no end of explaining why it continues to be separate. 15:58 < pinchartl> I know they don't all carry video, but in the kernel they're all video_device instances 15:58 < mchehab> pinchartl: let's then stick with: "V4L2 video/radio device node" 15:58 < hverkuil> sorry guys, I got pulled into a series of short meetings. 15:58 < mchehab> we can review it later 15:58 < sailus> hverkuil: Though so. 15:58 < sailus> Good to have you back! 15:59 < mchehab> IMHO, long term solution (assuming that we keep subdev devnodes), would be to split subdevs into a separate part 15:59 < sailus> V4L2 radio device node and V4L2 video device node seem good to me. 15:59 < mchehab> ok. At glossary, I'll replace it to "V4L2 video/radio device node" 16:00 < hverkuil> jeez, you guys have been typing a lot. 16:00 < sailus> Perhaps add "SDR". 16:00 < mchehab> (as, at least at Open chapter, we don't need to distinguish) 16:00 < mchehab> SDR is radio 16:00 < sailus> mchehab: Works for me. 16:00 < sailus> mchehab: I don't think it'll be easy to get rid of the sub-device nodes now. 16:00 < sailus> We've had them soon for 10 years. 16:00 < hverkuil> do you need me to urgently look at something/give my opinion? Otherwise it will take me some time to read through it all. 16:00 < mchehab> technically, a v4l-touch is neither video/radio, but I guess we can live with it 16:01 < sailus> hverkuil: We're finishing the sub-device node discussion. 16:01 < mchehab> sailus: agreed 16:01 < pinchartl> sailus: 10 years ? can't be... 16:01 < sailus> Not quite, but close. 16:01 < mchehab> 20? 16:01 < sailus> It's already 2017. 16:01 < mchehab> V4L removal took more than 10 years 16:01 < pinchartl> sailus: we had V4L1 for a long time and we still got rid of it :-) 16:02 < sailus> I guess we could document another interface offering the same functionality (just thinking) and have that reflected in the documentation. 16:02 < sailus> But still we'll need to keep the old documentation which we could later deprecate. 16:02 < mchehab> removing V4L1 was "easy" as we had libv4l to provide backward compatibility 16:02 < sailus> But it'd take a number of years. 16:02 < mchehab> but we don't have any library for MC/subdev 16:02 -!- lyakh [~lyakh@cable-84-44-207-202.netcologne.de] has quit [Ping timeout: 255 seconds] 16:02 < sailus> Let's see. 16:03 < mchehab> (nor we are sure we can ever have it) 16:03 < sailus> The first thing would be to define what would replace V4L2 sub-device interface. 16:03 < mchehab> so, I guess 10 years is an optimistic view 16:03 < sailus> We don't have that yet. Then we can think of a wrapper or something. 16:03 < mchehab> as we'll never be able to be sure when everybody will stop using subdev, if we get rid of that 16:04 < sailus> mchehab: It's too early to go there, I think. 16:04 < pinchartl> mchehab: we likely won't convert existing drivers 16:04 < mchehab> as there's no public widely used apps for subdev API (except for media-ctl) 16:04 < mchehab> pinchartl: if we're not converting existing drivers, then the API will be there forever 16:05 < pinchartl> mchehab: I don't mind 16:05 < pinchartl> when I said getting rid of them, I meant for new drivers 16:05 < mchehab> we won't be getting rid of it, from Documentation PoV, with is all this discussion is about 16:06 -!- cybrNaut [cybrNaut@2001:0:53aa:64c:42c:a33a:bcca:6bba] has joined #v4l 16:06 -!- cybrNaut [cybrNaut@2001:0:53aa:64c:42c:a33a:bcca:6bba] has quit [Changing host] 16:06 -!- cybrNaut [cybrNaut@unaffiliated/cybrnaut] has joined #v4l 16:06 < mchehab> in other words, no matter if future drivers will use it or not, we should fix the documentation 16:06 -!- lyakh [~lyakh@cable-84-44-207-202.netcologne.de] has joined #v4l 16:07 < pinchartl> I agree 16:07 < mchehab> I need to go. sailus, my understanding is that, for the current patchset, using "V4L2 video/radio device node" solves the issue 16:07 < pinchartl> (by the way I finished reviewing your 17 patches series. I won't have time for the 24 patches one) 16:08 < mchehab> I'll address it on the next patchset for it 16:08 < mchehab> pinchartl: thanks for looking into them 16:08 < pinchartl> I assume you will send a v3 ? and a v2 for the 24 patches to address Sakari's comments ? 16:09 < sailus> mchehab: Does that include making V4L2 sub-devices as part of V4L2 documentation, assuming we can address the QUERYCAP issue? 16:09 < sailus> There may be a need for EXT_QUERYCAP or something. 16:09 < sailus> But that was already planned for V4L2. 16:09 < mchehab> pinchartl: my intention is to merge all patches that nobody argued against... sending a v3 only with the stuff that required changes 16:10 < mchehab> (the patches within this series are pretty much independent) 16:10 < pinchartl> for the ones that don't require changes, sure, no issue with that 16:10 < pinchartl> however please check my comments first, some of them can apply to multiple patches 16:10 < mchehab> OK, I will 16:11 < mchehab> sailus: let's do such discussion on another time. for the mc-centric patchset, I guess we have everything set 16:12 < mchehab> but yeah, we still have to fix the issues with v4l2 sub-devices that it is, right now, an alien virus at the V4L2 spec :-) 16:12 < sailus> Let's continue at another time then. 16:12 < sailus> I'm quite happy that we could agree on the terminology. 16:12 < sailus> I think it's pretty good. 16:12 < sailus> Thanks for the meeting! 16:12 < sailus> I'll write brief notes and post to the list. 16:13 < mchehab> "alien virus" in the sense that it doesn't quite match the "dna" of the rest of V4L2 spec :-) 16:13 < mchehab> sailus: OK, thanks! 16:13 < sailus> mchehab: Are you emphasising that V4L2 evolved, it wasn't designed? X-) 16:14 < mchehab> your words, not mine :-D 16:14 < mchehab> ttyl... urge to go 16:14 < sailus> New hardware, new requirements. 16:14 < sailus> mchehab: Safe travel! 16:17 < BanHammor> at some point i gotta ask why there was a watershed moment between v4l and v4l2 but no such moment after, despite v4l2 evolving over years and years. 16:17 < BanHammor> e.g. why there isn't a v4l3 :) 16:22 < pinchartl> BanHammor: partly because V4L2 was designed better than V4L1, so it was easier to extend it 16:22 < pinchartl> but I believe we now need a V4L3 16:22 < pinchartl> or at least an API evolution that would have a similar impact than the V4L1 to V4L2 transition 16:22 < pinchartl> or possibly the FBDEV to KMS transition 16:23 < pinchartl> I don't care how it will be called 16:23 < BanHammor> V4LX, obviously, it's all the rage in software :P