| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| gnurou | hverkuil: would you be opposed to a slight refactoring of the way controls are applied in v4l2-ctrls.c?
hverkuil: namely, it would make my life easier if I could reorder try_set_ext_ctrls() to first set all the new values, before looping and calling try_or_set_cluster() for each master control right now both are done in the same loop, and this prevents me from reusing that part of the code when applying controls for the jobs API (i.e. I am finally trying to do controls the right way :)) | [06:48] |
| hverkuil | gnurou: what exactly do you mean with 'set all the new values'? | [06:55] |
| gnurou | hverkuil: set all p_new in a first loop
basically, when starting a job I would have the job framework set all the p_new values for changing controls, then calling into the control framework to validate and set these values or to generalize the idea more, try_set_ext_ctrls() expects user-space parameters (v4l2_ext_controls), and I would like a variant that also works for values contained inside the kernel (v4l2_ctrl_ptrs stored in jobs) | [06:56] |
| hverkuil | There are two parts here. The first is that when userspace tries to set controls for a job then try_set_ext_ctrls() needs to be called to verify (i.e. 'try') the given controls. You still need to call try_or_set_cluster() since that calls the try_ctrl op (if available). | [07:04] |
| gnurou | yep, that part is ok I think
but then there is the second part, where you try to actually apply the job's parameters because it has been scheduled to run | [07:05] |
| hverkuil | In the old request API that chromeos is using (or in this patch in my old requests2 branch: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=requests2&id=7e3ee57dad05bc32b16a60a4d76c33057c68486e) the try_or_set_cluster() function is modified to check if it is for a request, then return without calling the s_ctrl op. | [07:06] |
| gnurou | controls have been stored as v4l2_ctrl_ptrs inside the job, and I think it would make sense to re-validate the controls at that time too, so I would like to use the same code path | [07:06] |
| hverkuil | To actually set the controls I created a new v4l2_ctrl_apply_request() function that does that: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=requests2&id=91f63b20568d12a2a45ffed8092d05749ef3a197 | [07:07] |
| gnurou | except this time, the controls are not provided as v4l2_ext_controls (and cannot be, since v4l2_ext_controls are excepted to be backed by user-space memory) | [07:07] |
| hverkuil | I think the same thing should be done for jobs. | [07:08] |
| gnurou | ok, let me look again at that code first, maybe a solution will pop-up :) | [07:08] |
| hverkuil | The problem is that refactoring as you propose will change the error handling in subtle ways: when trying an array of controls the ioctl should fail for the first control in the array that is invalid (either because of basic checks or because of the try_ctrl op returning an error).
By splitting this up into effectively doing the basic checks (validate_new) first, and only later the try_ctrl op the behavior will change. When applying controls for a job the code will be much simpler though. You already have the v4l2_ctrl pointers, and they are already validated with validate_new, so no need to do that again. | [07:10] |
| It's going to be tricky, it all depends on how you store the controls and their new values in the job.
In my original request API patch the new request values are stored as part of the control as a list of v4l2_ctrl_req structs: +struct v4l2_ctrl_req { + struct list_head node; + u32 request; + union v4l2_ctrl_ptr ptr; +}; The ptr field was a pointer to the new value. This probably won't work for the jobs API where you probably want to store the ctrl + new value in a jobs-specific struct. You'd need to store the v4l2_ctrl pointer + the union v4l2_ctrl_ptr. Feel free to ask me questions or mail me patches. It's not easy, mainly due to the subtleties of control clusters. I have to go to the office, I should be back here in 30-40 minutes. | [07:18] | |
| gnurou | hverkuil: thanks, I think I can figure something out based on your code
indeed, here controls are stored inside the job structure, and I would like to keep this separate of the control framework as much as possible this should be doable though, the challenge is getting a clear understanding of how controls are applied :) | [07:34] |
| ..... (idle for 24mn) | ||
| hverkuil | gnurou: I was wondering: do you really need to keep the job and control framework separate? I am asking because the existing request API control code does almost everything you need. The only thing you need to keep in the job data structure is a pointer to the control handler(s) that have job-specific controls that need to be applied.
The advantage is that the control code has already proven itself in practice. In other words, you'll still be using that code to store the per-job control data. | [07:59] |
| gnurou | well keeping them as separate as possible seems to be a better design, if we can reuse the control framework code
but if that turns out to be impractical, I will of course switch to the reasonable solution :) | [08:01] |
| hverkuil | Just keep it in mind. | [08:02] |
| gnurou | hverkuil: just a question: it seems to me that v4l2_ctrl_helper::next could be omitted if we loop on the master's control cluster instead, is that correct? I think I am missing something here
or maybe v4l2_ctrl_helper::next is better here since it will only contain the controls that we actually change? s/contain/list | [08:06] |
| ......... (idle for 40mn) | ||
| hverkuil: ok, I think I have something basic working here. Probably not perfect but much better than my initial dirty hack
I just need to export try_or_set_cluster since it needs to be called from the generic jobs state handler would have preferred to enter the control framework at a higher level, but that will do | [08:47] | |
| hverkuil | The 'next' index is there to easily find all the controls in the array that belong to the same cluster. So when you need to try/set the controls of a cluster you can just follow the 'next' index into the array to locate them. The next field is there to make this efficient. | [08:56] |
| ....... (idle for 34mn) | ||
| pinchartl | pinchartl just noticed that you have been discussing the request API
gnurou: I'll have lots of comments about your patches and you won't like my comments :-( (but that's fair, as I don't like the patches either ;-)) | [09:30] |
| gnurou | pinchartl: please focus on the general structure & API, I know the implementation of controls is crap
doing it hopefully properly now | [09:31] |
| pinchartl | yes, it's the API I'm concerned about, the implementation is a second step | [09:34] |
| gnurou | happy to hear your comments then | [09:34] |
| pinchartl | I think we'll discuss that in Prague | [09:35] |
| gnurou | guess I will need to bring some ukon no chikara... >_< | [09:36] |
| pinchartl | lots of it :-)
when will you arrive by the way ? | [09:37] |
| gnurou | wednesday evening it seems | [09:40] |
| pinchartl | I'm tempted to fetch you from the airport and discuss the API on the way to the hotel, just to punish you :-D | [09:42] |
| gnurou | tempting!
do you have a car there? | [09:43] |
| pinchartl | no I don't
if we come back by taxi we'll need at least two of them, as I don't expect any taxi driver to withstand a whole ride full of request API discussions | [09:46] |
| gnurou | s/request/jobs :P | [09:49] |
| pinchartl | s/jobs/request/ :-)
well, names don't matter much | [09:52] |
| gnurou | if possible, please try to send me an overview of your concerns before Prague though, so we can enter the discussion with some background | [09:57] |
| pinchartl | ok, I think I should be able to | [10:00] |
| gnurou | will help, thanks!
which day will you arrive btw? | [10:01] |
| pinchartl | Saturday, and I'll leave on the next Sunday
when will you leave ? | [10:03] |
| gnurou | saturday, it will be a short trip | [10:08] |
| pinchartl | :-S | [10:08] |
| *** | prabhakarlad has left | [10:19] |
| ......... (idle for 41mn) | ||
| sailus | Hello! | [11:00] |
| hverkuil | Hei!
(or should I use the dutch 'Hallo :-) | [11:00] |
| mchehab | hi | [11:00] |
| pinchartl | hello | [11:01] |
| sailus | Good, we're all here!
So, I wanted to have this meeting to discuss two matters. | [11:01] |
| pinchartl | pinchartl is still reviewing the glossary patch, I'll send the review as soon as it's complete, later today | [11: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).
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. But. Let's go to the first item first. | [11:02] |
| mchehab | ok | [11:04] |
| sailus | We haven't had a name for such a device and I understand the need for that became apparent. | [11:04] |
| pinchartl | sailus: one question first
when you say "the device consisting of multiple pieces of the hardware" are you looking for a name to describe the hardware, or a name to describe the software model of that hardware ? | [11:04] |
| sailus | The hardware. | [11:05] |
| mchehab | that's the proposal for it:
+ Media hardware + A group of hardware components that together form the + functional media hardware. For instance the :term:`SoC` + :term:`ISP` :term:`IP cores <ip core>` and external camera + sensors together form the camera media hardware. we also have: + V4L2 hardware + Hardware that is controlled by a :term:`V4L2 main driver` or a + :term:`V4L2 sub-device driver`. V4L2 hardware is a subset of the + :term:`media hardware`. Often the two are the same, but + :term:`media hardware` can also contain other non-V4L2 hardware + such as Digital TV hardware. (that's glossary v8) in other words, if it includes DVB, ALSA, RC, etc, it is "media hardware" if it is just the stuff seen by V4L2 core, "V4L2 hardware" | [11:06] |
| 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.
I proposed "aggregate device", i.e. media aggregate device and V4L2 aggregate device, but we haven't used such a term in the past. | [11:07] |
| pinchartl | I'm not fond of the word "device" | [11:08] |
| sailus | I'd be happy to hear better proposals though. Or opinions on what's been discussed so far. | [11:08] |
| pinchartl | it's one of the most confusing ones | [11:08] |
| sailus | Yes, but it is still "a device", isn't it? | [11:09] |
| pinchartl | "aggregate device" is bound to be abbreviated "device" in discussions, creating confusion | [11:09] |
| sailus | Well, if we can have a good name that doesn't contain "device" I'm totally fine with it. | [11: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. | [11: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" :-) | [11:09] |
| sailus | pinchartl: That's what always happens when you have a kind of devices. :-)
Device nodes, for instance. | [11:09] |
| mchehab | i like the term hardware too | [11:10] |
| pinchartl | I could go with "media hardware device"
if we then enformed a standard abbreviation for hardware device my point is basically that I don't want to see "device" used standalone for device nodes, we use devnode | [11:10] |
| hverkuil | pinchartl: +1 | [11:11] |
| pinchartl | that's the de facto standard abbreviation | [11:11] |
| mchehab | works for me | [11:11] |
| pinchartl | everybody understands it | [11:11] |
| sailus | Works for me. | [11:11] |
| mchehab | oh, that was quick! | [11:11] |
| hverkuil | pinchartl: how is "hardware device" better than just plain "hardware"? | [11:11] |
| sailus | Good! We're done here then. :-) | [11:11] |
| pinchartl | and it's short enough to avoid the use of "device" alone | [11:11] |
| sailus | hverkuil: Hardware is a substance, device is a object. | [11:11] |
| pinchartl | "hardware device" could be similarly abbreviated to "hwdev" | [11:12] |
| mchehab | people will still call it device :-) | [11:12] |
| sailus | :-D | [11:12] |
| pinchartl | hwdev is short enough that we can push people to use that | [11:12] |
| mchehab | ok | [11:12] |
| pinchartl | it's shorter than device :-)
of course I'm not saying that we need to use an abbreviation but if in practice we realize that "hardware device" is too long for people to write | [11:12] |
| mchehab | well, it doesn't hurt adding it to the glossary | [11:12] |
| pinchartl | we'll have hwdev that is unambiguous | [11:12] |
| 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"? | [11:13] |
| pinchartl | that's a good point | [11:13] |
| mchehab | sailus: just using hardware is better | [11:14] |
| pinchartl | we don't have "hardware device" in the glossary at the moment | [11:14] |
| sailus | I'm not proposing "media hardware aggregate device". :-) | [11:14] |
| pinchartl | we have "hardware component" | [11:14] |
| mchehab | yeah, the glossary makes clear that "hardware component" is a subdevice and "media hardware" is the hole thing | [11: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. | [11:14] |
| sailus | So... device (or hardware) is a collection of components? That sounds a bit like redefining existing terms. | [11:15] |
| pinchartl | hverkuil: as Sakari said, hardware in uncountable, you can't say "a media hardware" to describe one instance | [11:15] |
| mchehab | + Hardware component
+ A subset of the :term:`media hardware`. For example an :term:`I²C` + or :term:`SPI` device, or an :term:`IP block` inside an + :term:`SoC` or :term:`FPGA`. | [11:15] |
| sailus | What do you think of "media aggregate device"? | [11:15] |
| mchehab | I don't like it | [11:16] |
| sailus | Are there other objections than we haven't used the word "aggregate" previously? | [11:16] |
| mchehab | I could live it that, though | [11:16] |
| pinchartl | sailus: that's an intirely new term that is long to type and doesn't have a good abbreviation
it's bound to become "device" in discussions | [11:16] |
| sailus | What we need here is a formal name to describe it when needed. | [11:17] |
| pinchartl | yes, but a name that isn't too difficult to use
otherwise nobody will use it | [11:17] |
| mchehab | I still thing that media hardware/v4l2 hardware is OK | [11:17] |
| hverkuil | What's wrong with saying: "my devkit has media hardware" (meaning an SoC with an ISP. DMA engines, sensors) | [11:17] |
| mchehab | s/thing/think/ | [11: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. | [11:17] |
| pinchartl | sailus: I disagree, it means that we've had lots of confusing discussions before :-) | [11:18] |
| sailus | What if we drop "device" from "media aggregate device"? | [11:19] |
| pinchartl | ("aggregate device" seems to be used to describe aggregate audio outputs on macosx :-)) | [11:19] |
| sailus | It becomes "media aggregate". | [11:19] |
| mchehab | I doubt anyone would ever use it
in practice it is just too weird on my ears | [11:19] |
| pinchartl | sailus: aggregate is an adjective in this case, you can't use it alone
although in the geological sense it's a noun | [11:20] |
| mchehab | aggregate reminds the time I worked with telecommunications... it actually means part of a data stream | [11:20] |
| sailus | pinchartl: From WordNet: "a sum total of many heterogenous things taken together".
It's a noun as well. | [11:20] |
| pinchartl | another option: we could use the word peripheral instead of device. "media peripheral"
(I'm not very fond of that, but I could probably live with it) | [11: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 :-) | [11:21] |
| pinchartl | (just brainstorming) | [11:21] |
| mchehab | pinchartl: it used to be peripheral... people argued against it at the ML
(don't remember the exact comments) | [11:21] |
| pinchartl | I hope I wasn't the one arguing against it :) | [11:22] |
| sailus | A peripheral is still just a... device.
I guess I was. :-) | [11:22] |
| mchehab | ah, I remember... people was thinking on printers and mice with this term | [11:22] |
| pinchartl | sailus: yes, but it's not commonly used for lots of different meanings | [11:22] |
| hverkuil | A 'media peripheral' is a webcam, printer, etc. | [11:22] |
| mchehab | argued that a SoC ISP is not a peripheral | [11:22] |
| sailus | pinchartl: How do you feel about "V4L2 hardware" and "Media hardware"? | [11:23] |
| pinchartl | hverkuil: webcam is great, that's part of what we want to describe :) | [11:23] |
| sailus | My dislike comes from the fact that this is improper use of the word hardware. | [11:23] |
| mchehab | ????
please ellaborate | [11: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 | [11:23] |
| mchehab | what's improper? | [11:23] |
| sailus | It's a substance, such as milk. | [11:24] |
| mchehab | so?
it is an incontable noun | [11:24] |
| pinchartl | mchehab: it's uncountable | [11:24] |
| mchehab | but that's exactly what it is: | [11:24] |
| sailus | You can't add an article to that. | [11:24] |
| pinchartl | you can say "two media hardware devices"
you can't say "two media hardwares" | [11:24] |
| mchehab | something that can be split or merged | [11:25] |
| pinchartl | two webcams, two media hardware devices, two media hardware
the latter is incorrect | [11:25] |
| mchehab | if we ever need to count it, we can just add "device" at the end
two media hardware devices | [11:25] |
| pinchartl | then we should use "media hardware device" in singular form too :-) | [11:26] |
| hverkuil | Right. A media device has media hardware. | [11:26] |
| sailus | Which we discussed already: can that be confused with what is a sub-device?
From the term alone nothing suggests it may not be a sub-device. | [11: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 | [11:26] |
| sailus | I'd have to look up the definition, and I bet a lot of people won't. | [11:26] |
| hverkuil | sailus: Which term are you referring to? "media device" or "media hardware"? | [11:26] |
| sailus | "Media hardware device". | [11:27] |
| pinchartl | (the English language also has the term "equipment", but that doesn't sound much better) | [11:27] |
| sailus | Media, hardware and device are all very generic terms. | [11:27] |
| mchehab | pinchartl: an ISP IP block inside a SoC is not an equipment | [11:27] |
| hverkuil | "media hardware" is defined as a collection of hardware components. So I don't think there can be confused with a sub-device. | [11:28] |
| pinchartl | mchehab: an ISP isn't a "media hardware device". the camera made by combining the ISP and the sensor is | [11:28] |
| mchehab | it is not even a "device" from hardware PoV | [11:28] |
| sailus | "Media agglomerate device"? | [11:28] |
| mchehab | it is parto of "media hardware" | [11:28] |
| hverkuil | but an ISP is part of "media hardware". | [11:28] |
| sailus | I think I prefer "media aggregate device" to that. :-) | [11:29] |
| mchehab | sailus: if you add "device", you excluse ISP
s/excluse/exclude/ | [11:29] |
| pinchartl | sailus: I agree with you that aggregate is probably the right term to describe this, but it will be hard to use :-/ | [11:29] |
| sailus | mchehab: Why?
It's a device, too. An IP block can be a device, can't it? | [11:29] |
| mchehab | a device implies that it is something physically distinct | [11:29] |
| sailus | Well, it is, just in a silicon. :-) | [11:30] |
| mchehab | https://en.oxforddictionaries.com/definition/device
piece of mechanical or electronic equipment. | [11:30] |
| pinchartl | device: "Any piece of equipment made for a particular purpose, especially a mechanical or electrical one."
or "(Ireland) An improvised explosive device, home-made bomb" :-) | [11:30] |
| sailus | X-) | [11:30] |
| pinchartl | media bomb :-) | [11:30] |
| sailus | A home-made ISP? | [11:31] |
| hverkuil | I agree with mchehab: I wouldn't call an IP block a "device". The SoC is a device, though. | [11:31] |
| sailus | hverkuil: Linux views this in a different way. | [11:31] |
| mchehab | yes, the SoC, as a hole, is a device | [11:31] |
| BanHammor | a device is a node in /dev/, y'all :P | [11:31] |
| sailus | We can't redefine terms that have established meanings. | [11:31] |
| mchehab | linux device is software - let's not mix with hw | [11:31] |
| sailus | Well, in Linux in particular. | [11:31] |
| pinchartl | hverkuil: from the point of view of the Linux driver model, an ISP is a device (or sometimes a collection of devices) | [11:31] |
| sailus | struct device is (may be) a software representation of hardware. | [11:32] |
| hverkuil | pinchartl: yes, software wise (in the linux kernel) you are correct. But we're talking about describing hardware. | [11:32] |
| mchehab | let's call it "struct device" to avoid mixing it with "hardware device" | [11:32] |
| hverkuil | it's why the term "device" is so confusing and overloaded. | [11:32] |
| mchehab | struct device is just an abstraction to represent something managed by a linux driver | [11: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 | [11:33] |
| mchehab | it can even be virtual
with no actual hardware attached to it | [11:33] |
| pinchartl | so for the hardware we need to either qualify it ("hardware device") | [11:33] |
| sailus | "Media device group"? | [11:33] |
| pinchartl | or not use "device" at all | [11:33] |
| sailus | "Media device ensemble"? | [11:33] |
| hverkuil | "Media hardware group"? | [11:33] |
| sailus | hverkuil: I like that. | [11:34] |
| mchehab | IMHO, just media hardware is enough | [11:34] |
| pinchartl | (another word to throw in the brainstorm: unit) | [11:34] |
| sailus | pinchartl: Unit is too close to being a device IMO. | [11:34] |
| pinchartl | mchehab: but hardware is uncountable :-( | [11:34] |
| mchehab | so what?
where, at the API, is it relevant? | [11:34] |
| 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 | [11:35] |
| mchehab | are there any place at API where you need to count the media hardware devices? | [11:35] |
| pinchartl | mchehab: you often have to say "a media hardware device"
you can't say "a media hardware" | [11:35] |
| 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. | [11:36] |
| mchehab | where does it need to say "a media hardware device"?
I don't recall any place there where such distinguish is needed | [11:36] |
| sailus | If there's just a single "aggregate device" in a system, you're fine, otherwise not. | [11:36] |
| mchehab | from both V4L2 uAPI and kAPI PoV, it doesn't matter if you have a single media hardware device or multiple ones | [11:37] |
| sailus | pinchartl, mchehab: How do you like hverkuil's proposal "media hardware group"? | [11: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? | [11:37] |
| mchehab | hverkuil: I'm OK with that
sailus: I don't see the need of "group" | [11:37] |
| pinchartl | sailus: I think I'd prefer aggregate device in that case | [11:38] |
| sailus | It makes it countable and bounded. | [11:38] |
| mchehab | the thing is: for the API spec, it doesn't matter how many media devices are present | [11:38] |
| sailus | Just as adding "device", but includes the suggestion it does not consist of a single piece of hardware. | [11:38] |
| mchehab | on our discussions, we may need to refer to the case where multiple hw devices are present... | [11: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 | [11:39] |
| mchehab | for such usage, we can live very well with either "hw device" or "media device" or "media hw device" | [11:39] |
| sailus | "Media hardware bunch"? | [11:40] |
| pinchartl | so we need a name that can be instantiated. it needs to be countable | [11:40] |
| mchehab | pinchartl: no! | [11:40] |
| pinchartl | no to what ? | [11:40] |
| mchehab | pinchartl: the V4L2 API provide multiple devnodes per a single media hardware device
there are even multiple devnodes for a single DMA engine there | [11:40] |
| pinchartl | mchehab: I meant one MC devnode :-)
(this is really why a glossary is important...) | [11:41] |
| mchehab | ok, first of all, this glossary is only at the V4L2 spec
it doesn't apply to MC (nor DVB, RC, CEC) | [11:41] |
| sailus | "Media hardware set"? | [11:42] |
| mchehab | second, for MC, we can use "media hardware device" | [11:42] |
| sailus | "Media hardware... herd"? | [11: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. | [11: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 | [11:42] |
| sailus | hverkuil: Why would we need two terms? | [11:43] |
| mchehab | true, but it is out of the escope to extend the glossary to apply to the hole media documentation | [11:43] |
| sailus | Do you anticipate people using "media hardware device", rather than just e.g. media device? | [11:43] |
| pinchartl | mchehab: sure | [11:43] |
| hverkuil | hole -> whole :-) | [11:43] |
| sailus | There's a lack of clear distinction. | [11:43] |
| mchehab | :-) | [11:43] |
| pinchartl | hverkuil: "media hardware" really means all the media-related hardware present in the system | [11:43] |
| mchehab | pinchartl: for the API PoV, such definition is fine
only MC requires to distinguish | [11:44] |
| pinchartl | mchehab: I don't think so :-) if you have two PCI capture cards, you want to refer to them separately | [11:44] |
| mchehab | as we have one /dev/mediaX per media hardware device | [11:44] |
| pinchartl | trying to provide a summary of my current opinions: | [11:45] |
| mchehab | so, adding "media hardware device" to the glossary should meet the goal | [11:45] |
| pinchartl | - "media hardware aggregate" is the most precise term I've seen so far | [11:45] |
| mchehab | pinchartl: Hauppauge has some devices that have two PCI cards bundled into one | [11:45] |
| pinchartl | but it's also not commonly used
(mchehab: I was talking about the general case, there can of course be exceptions) | [11:45] |
| mchehab | from kernel and userspace PoV, it doesn't matter if you buy two HVR-150 or one HVR-500
they'll look the same | [11:46] |
| hverkuil | other synonyms: grouping, constellation, assembly (or is that assemblage?) | [11: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)
- "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 | [11:46] |
| 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" | [11:47] |
| pinchartl | - "media hardware" is uncountable, I don't like that | [11: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. | [11:47] |
| pinchartl | sailus: that too, yes. but again, as it's a new term, we can define it | [11:48] |
| sailus | Yes, we'll be fine, but we're steepening the learning curve. | [11:48] |
| hverkuil | sailus: that's why we have a glossary, to define such things. | [11: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 | [11:48] |
| sailus | The terms should be easy to remember, consistent and in best case self-explanatory. | [11:48] |
| 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
for instance if you have a sensor, an ISP and a USB bridge the combination of the three is what we want to define but sensor + ISP or ISP + bridge would also be an aggregate | [11:49] |
| hverkuil | http://www.dictionary.com/browse/grouping | [11:50] |
| pinchartl | aggregate carries the meaning that there are multiple components, but not that they're all there | [11:50] |
| mchehab | as I said before, in telco, "aggregate" is a component of something bigger | [11: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.
The only real possible confusion with "aggregate" I can think of comes from this: | [11:50] |
| pinchartl | mchehab: "A mass, assemblage, or sum of particulars; something consisting of elements but considered as a whole." | [11:51] |
| sailus | https://fi.wikipedia.org/wiki/Aggregaatti | [11:51] |
| pinchartl | (https://en.wiktionary.org/wiki/aggregate#English) | [11:51] |
| mchehab | https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/aggregate-edit-interfaces-sonet-options.html | [11:51] |
| hverkuil | "media hardware grouping". Hmm, still not great. | [11:51] |
| sailus | hverkuil: I prefer group over grouping, if it's between the two. | [11:51] |
| hverkuil | sailus: me too | [11:51] |
| pinchartl | sailus: I wonder what the etymology of that Finnish word is :) | [11:52] |
| sailus | I like pinchartl's proposal of "media hardware aggregate" as well. | [11:52] |
| pinchartl | (other words: cluster, collection) | [11:52] |
| sailus | You see the word "group" being used in many other languages. | [11:53] |
| pinchartl | mchehab: aggregate interfaces have a meaning in networking, yes | [11:53] |
| mchehab | I won't doubt that "aggregate" could be used on DVB hierarchic transmissions with a similar meaning that it is for SDH | [11:53] |
| pinchartl | mchehab: not "media hardware aggregate" though :-) | [11:53] |
| mchehab | pinchartl: aggregate is a logical container
on some hierarchical transmissions | [11:54] |
| pinchartl | aggregate is an ensemble | [11:54] |
| hverkuil | Hmm: interesting synonym: media hardware ensemble
:-) | [11:54] |
| pinchartl | now we're getting in the music field, which is somehow related :-) | [11:54] |
| sailus | hverkuil: That sounds very musical to me. :-)
"Media hardware herd". | [11:54] |
| hverkuil | (warning: I have a meeting in 5 minutes) | [11:55] |
| sailus | There can be many different species in the herd, such as cameras and ISPs.
You can also have two herds in the system. | [11:55] |
| pinchartl | either there's no good term for this in English, or we're missing something very obvious. I can't tell :-/ | [11:55] |
| sailus | Hmm. The more I use it, the more I like it.
pinchartl: I'd say that there's no common need to refer such groupings of hardware devices. That's why it has no established name. | [11:55] |
| hverkuil | The two realistic options I've seen are: media hardware device or media hardware aggregate. | [11:56] |
| mchehab | I still think that, if we use group/ensemble/aggregate/herd/... it won't be representing what we want | [11:56] |
| hverkuil | I lean towards the first, but will be OK with the second. | [11:56] |
| sailus | From the two, I prefer "media hardware aggregate". | [11:56] |
| 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 | [11:57] |
| mchehab | as one could understand a "media hardware heird/group/ensemble/aggregate" as group of PCI devices... | [11:57] |
| hverkuil | I think sailus is right: there is no real term for this. I've used 'constellation' in the past in V4L2 presentations. | [11:57] |
| pH5 | how about 'complex' | [11:57] |
| hverkuil | "media hardware complex". Not bad. | [11:58] |
| sailus | pH5: Works for me. | [11:58] |
| pinchartl | pH5: that's an adjective too :-/ | [11:58] |
| mchehab | the only term that really defines a single PCI device would be to use the word "device" :=) | [11:58] |
| pinchartl | (actually it can be a noun, indeed) | [11:58] |
| sailus | pinchartl: Complex is a noun, too.
Will it be "media hardware aggregate" or "media hardware complex"? | [11:58] |
| mchehab | using any other word different than "device" when we need to count media hardware pieces will cause confusion | [11:59] |
| pinchartl | mchehab: that's why we need to define the term, yes
"media hardware complex" isn't bad either I think but maybe I only like it because it's new and we've been discussing this for an hour already :-) | [11:59] |
| mchehab | it isn't bad, but it is worse than "media hardware device" | [12:00] |
| pinchartl | Hans has a meeting now, should we use that time to let "media hardware complex" sink in our brains ?
mchehab: you could call it media hardware device complex is you insist :-) | [12:00] |
| sailus | Sounds like a good idea.
=> Sinking, that is. | [12:00] |
| mchehab | singing :-p | [12:01] |
| sailus | I wouldn't object singing either though. | [12:01] |
| pH5 | yeah, sorry for jumping in with a new suggestion at the very end, I just read the backlog :) | [12:01] |
| sailus | pH5: New suggestions are always good. :-)
Especially before decisions. Hans said his meeting will take an hour and I'll need to leave soon after he'll be back. | [12:01] |
| pinchartl | pH5: that's what brainstorming is about | [12:02] |
| sailus | How about continuing in Friday?
Before or after the weekly meeting. We can decide that today. I prefer before, I'll also need to leave the office soon after the weekly meeting on Friday. | [12:02] |
| mchehab | works for me | [12:03] |
| pinchartl | works for me too | [12:04] |
| sailus | I.e. same time than today, but on Friday. | [12:05] |
| .... (idle for 17mn) | ||
| hverkuil | It should be OK on Friday.
I rather like "complex" as it also has the connotation of the constituent parts being connected (as in a "building complex"). "an intricate or complicated association or assemblage of related things, parts, units, etc." | [12:22] |
| snawrocki | let me throw these in: "media composite device", "media hardware subsystem", "media compound device" | [12:36] |
| sailus | snawrocki: Thanks, good suggestions! | [12: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?
both seem to free all buffers, both call the stop_streaming op. | [12:47] |
| sailus | VIDIOC_STREAMOFF does not release buffers, just stops streaming.
It might have done that with videobuf1 though. REQBUFS with count=0 releases the buffers. | [12:50] |
| BanHammor | ah i see
i was confused by "all images captured but not dequeued yet will be lost, likewise all images enqueued for output but not transmitted yet" | [12:51] |
| sailus | Yes, the buffers are dequeued and shall have the V4L2_BUF_FLAG_ERROR flag set.
But not released. | [12:53] |
| BanHammor | so how does one reset that flag?
(oh i guess you just overwrite it in userspace when you pass struct v4l2_buffer) thanks! | [12:58] |
| sailus | The flag is just informational to the user space AFAIR.
No need to clean it explicitly before requeuing the buffer. That's at least as far as I remember. | [13:01] |
| pinchartl | snawrocki: thanks. I like composite and compound too. less fan of subsystem personally as it has an established meaning in the kernel | [13:10] |
| sailus | I put the suggestions to Etherpad here:
http://muistio.tieke.fi The pad name is media-device-naming | [13:10] |
| ............................... (idle for 2h30mn) | ||
| *** | benjiG has left | [15:40] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |