| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| pinchartl | hverkuil: did you really mean is_media_entity_v4l2_video_device() and not is_media_entity_video_device() ? just checking it's not a typo | [09:15] |
| hverkuil | I did mean is_media_entity_v4l2_video_device, although I think it is too long. is_media_entity_v4l2_vdev might be better. I like the 'v4l2' since it refers to the subsystem.
We might have is_media_entity_alsa_ in the future as well. | [09:17] |
| pinchartl | time again to rename struct video_device ? ;-)
it would be painful, but I'd be happy if it happened or rather I'd be happy after it's done and the fallout settled, not during the process | [09:18] |
| hverkuil | Mauro didn't go for it. I tried that once.
Renaming v4l2_device would be a higher prio for me, that was a really bad choice. | [09:20] |
| *** | dannas has left | [09:22] |
| pinchartl | yes, I remember you tried. we need to find more incentives ;-) | [09:23] |
| hverkuil: another quick question, would you like me to keep is_media_entity_v4l2_io() if it's not used, or can we only add it later when a driver will need it ? | [09:37] | |
| mchehab | pinchartl: you didn't comment about connectors... I'm assuming that you're ok with the proposal ;) | [09:47] |
| pinchartl | mchehab: s/didn't comment/didn't comment yet/ :-)
I'm finishing the entity types patch series based on Hans' proposal should be done this afternoon and I'll then comment on the connectors there's too many patch series floating around at the same time | [09:48] |
| hverkuil | pinchartl: put is_media_entity_v4l2_io() in a separate patch. That way it is archived and as you say, it can always be added later. | [09:59] |
| pinchartl | hverkuil: great, I'll do that | [10:00] |
| ................ (idle for 1h17mn) | ||
| mchehab | good news: I tested the G_TOPOLOGY ioctl for compat32 issues, on both arm64 and x86_64: 32 bits apps runs fine there. No issues
so, I don't see any need to change the interface. We could still align the reserved fields to improve performance on 64 bits, but this is not really a requirement for the API to work | [11:17] |
| ........................................... (idle for 3h31mn) | ||
| pinchartl | mchehab: nice. not having to implement a compat32 handler is nice
oops, bad copy & paste, I'll resend the media entity type v3 with the right mailing list address :-( sorry for the noise, I'll be careful next time | [14:49] |
| hverkuil | pinchartl: I seems to be author of patch 4/8, which I definitely am not.
I'm only author of 5-8. | [14:51] |
| pinchartl | hverkuil: you are but it has been reworked a lot :-)
I'll change it | [14:54] |
| mchehab: I've sent v3 of the media entity type patch series, based on both my previous proposal and Hans' capabilities series | [15:00] | |
| mchehab | ok | [15:01] |
| pinchartl | hopefully we should be good now :-) | [15:01] |
| mchehab | I'll review it later | [15:01] |
| pinchartl | I have a ~40 patches series for vsp1 that builds on top of it, I'll send it after you review (and hopefully accept :-)) the media entity type patches if that's fine with you | [15:01] |
| mchehab | I'll do it after handling the pending stuff related to connectors and G_TOPOLOGY
(those takes prority, as it will affect Kernel 4.5) | [15:03] |
| pinchartl | I'll reply to those e-mails now | [15:04] |
| mchehab | ok, thanks | [15:04] |
| pinchartl | but I expect we'll need a couple more days to discuss them
I'll call Sakari tomorrow and ask him to review them he will be back late at night today hverkuil: I've sent the is_media_entity_v4l2_io() patch as part of the series, but it can be left out as we discussed previously. would you prefer to take it in now ? | [15:04] |
| hverkuil | pinchartl: no point to take it if there is no user. It's good to have it archived though. | [15:07] |
| pinchartl | hverkuil: I agree. I'll leave it out of the pull request then
feel free to include the device_caps patches in your tree if you want they can go in indepedently of the media entity type | [15:08] |
| hverkuil | will do. | [15:08] |
| javier__ | mchehab: for G_TOPOLOGY you meant s/4.5/4.6 right?
since the ioctl was disabled for 4.5 | [15:13] |
| mchehab | javier__: yes, true
sorry for the mess connectors is 4.5, though, as it is seen via the legacy ioctl | [15:14] |
| javier__ | nod | [15:14] |
| pinchartl | even if we can get the connectors fixed for v4.5 wouldn't it make sense to delay that API change to v4.6 to have one kernel cycle of testing ? | [15:20] |
| hverkuil | mchehab: do you know yet if you'll be at the ELC? I can't wait longer with booking my flight. | [15:20] |
| pinchartl | v4.5 is roughly two weeks ago
we can agree on what we want in two weeks but we won't have enough testing I mean, rewriting a kernel API one or two weeks before the release, that's pushing it a bit :-) | [15:20] |
| mchehab | pinchartl: this has been testing since the merge window | [15:22] |
| pinchartl | yes, but we're changing it now
I'm not saying that what we have hasn't been tested | [15:22] |
| mchehab | are we? | [15:22] |
| pinchartl | it's what we will agree on as the result of the discussion that won't be tested | [15:22] |
| mchehab | did you read the emails? | [15:22] |
| pinchartl | I'm reading the whole thread now | [15:23] |
| mchehab | hverkuil: the approval process is still running... I should have an answer later today, I guess | [15:24] |
| hverkuil | I think that if you will attend the ELC, then we should add a day (Thursday I guess) for discussion (either formal or informal) | [15:25] |
| mchehab | I guess I'll be in ELC, but can't tell for sure until the approval process finishes
yes, I'm reserving Thrusday for that. I also requested a room for LF... waiting for answer s/room for LF/room to LF/ they're checking if there will be an empty room for us on Thursday I expect to have an answer from him later today | [15:25] |
| pinchartl | by the way, Hans, hverkuil.home.xs4all.nl replies on ipv4 only | [15:28] |
| hverkuil | pinchartl: that's weird. It's on my isp and as far as I know they've supported ipv6 for ages. | [15:31] |
| pinchartl | it has an ipv6 address
but when my brother tries to access the server using ipv6 it receives a timeout | [15:40] |
| hverkuil | there is nothing I can do, it is out of my control. | [15:41] |
| pinchartl | looks like http works but not https | [15:41] |
| mchehab: I'm trying to put my thoughts in writing, they're a bit fuzzy still, so the e-mail reply will likely look like it goes in random directions
by the way, have you thought about how all this would be represented in DT bindings ? | [15:52] | |
| ............ (idle for 55mn) | ||
| *** | benjiG has left | [16:47] |
| mchehab | pinchartl: javier__ will be addressing the DT binding stuff | [16:54] |
| pinchartl | as DT and MC are two ways to represent the same (or very similar) information I think they're related | [16:55] |
| mchehab | the information model on DT is different than on MC. So, it will be different anyway | [16:56] |
| pinchartl | that's up to us :-)
if we create one pad per signal then we get an MC representation that is very close to the hardware | [16:56] |
| mchehab | one pad per signal is what it was proposed
and one entity for the connector as a hole I think this can be easily represented in DT too | [17:00] |
| ....... (idle for 31mn) | ||
| javier__ | pinchartl: I expect it will be similar to the DT binding representation used for media bridges and attached external devices as you said (OF graph / ports / endpoints)
pinchartl: now I wonder if the pads is too detailed for the DT since that I guess could be known by the driver | [17:32] |
| hverkuil | javier__: different pads can go to different entities. | [17:33] |
| javier__ | i.e: if I've an S-video connector that has two separate y and c signals as source pads that will be connected to pin A and B in a particular hw | [17:33] |
| hverkuil | E.g. the HDMI CEC signal is often processed by a separate driver. | [17:33] |
| pinchartl | javier__: I'd expect us to use the OF graph bindings, yes. the question is how detailed it should be
hverkuil: DDC in general can be processed separately, that's a common case, yes | [17:34] |
| hverkuil | Also in a case like this: https://hverkuil.home.xs4all.nl/adv7842.png | [17:34] |
| pinchartl | but looking at http://hverkuil.home.xs4all.nl/adv7604.png I really wonder whether we should represent each AIN with a pad
(the question is valid for both MC and DT) | [17:35] |
| hverkuil | the pads of the S-Video input can be hooked up to different AINX pins | [17:35] |
| javier__ | hverkuil: and how configurable that is? I'm asking since is there is a 2-tuple (AINX, AINY) and another one (AINA, AINB) for S-video, maybe in DT that can be represented as 2 endpoints S-Video0, S-Video1
I mean, to provide a higher level description in DT and the driver map that to individual pins | [17:37] |
| hverkuil | the adv's are very configurable. Not all combinations are possible, but there are certainly a lot of them. | [17:38] |
| javier__ | hverkuil: I see | [17:38] |
| hverkuil | It's an extreme case, and unusual. | [17:39] |
| javier__ | I guess FPGA are other tricky HW since those are very flexible as well | [17:39] |
| hverkuil | Digital inputs (DVI-D, HDMI) are much simpler since they have only 1 or 2 pads. | [17:40] |
| pinchartl | FPGAs are the worst. you can be sure that whatever model you come up with will be defeated by FPGAs, it's not even worth trying :-) | [17:40] |
| hverkuil | yep | [17:40] |
| javier__ | pinchartl: fair enough :) | [17:40] |
| pinchartl | for digital inputs I think we're mostly fine, we should be able to agree on something in the near future
analog is a mess | [17:40] |
| hverkuil | javier__: the reality is that VGA/DVI-A/component connectors are rare in practice and they are a (very slowly) dying breed. | [17:41] |
| pinchartl | what is certain is that, whatever model we use for DT, we need to tell to which AIN pin(s) the individual video signals part of a logical input are connected to | [17:41] |
| hverkuil | I'm OK with more complex analog pad connections. | [17:41] |
| pinchartl | there's two points that bother me in http://hverkuil.home.xs4all.nl/adv7842.png
one is the large number of pads I'm thinking about possible alternative solutions, and their pros and cons the other one is that the s-video connector is represented by two entities (18 and 19) that's the part that bothers me the most | [17:42] |
| hverkuil | No, there are two BNC connectors on the backplane. You can either use one as a composite input or both as S-VIdeo. | [17:44] |
| pinchartl | ah ok
but if there was a single s-video connector that could be used in either s-video more or composite mode (with a single signal) we would have the same MC graph, right ? | [17:44] |
| javier__ | pinchartl: yes, connectors with overlapping signals will be modeled as 2 entities | [17:45] |
| hverkuil | Yes.
Same here with the DVI-A and DVI-D connectors: on the real product this is a DVI-I connector (another invention from hell) | [17:45] |
| javier__ | for example the IGEPv2 board I've here, has 2 connectors that can be used for 2 composite or a s-video signal
so I will need 3 entities to model that | [17:47] |
| pinchartl | am I the only one thinking, reading the above descriptions, that there's something fundamentally wrong ? :-) | [17:48] |
| hverkuil | Well, they are two connectors, but the HW designers overloaded them.
This is the mechanism that we're using in V4L2 today, and it works well. As long as the additional properties (label, color, position, whatever) clarify where to find the connector it doesn't matter for the end-user. Alternative solutions are welcome, but I don't see any. | [17:49] |
| pinchartl | I'm trying to find them
would an alternative that works better in the vast majority of cases and be a little quirky in the quirky cases be considered ? | [17:52] |
| hverkuil | Isn't that what we have now? | [17:53] |
| pinchartl | I find that what was have now is quirky in all cases :-)
or rather, too verbose | [17:54] |
| hverkuil | It works in the vast majority of the cases, but it is a little quirky for 'overloaded' connectors. | [17:54] |
| pinchartl | the DVI-A + DVI-D entities to represent a single DVI-I connector for instance
starting a meeting in 5 minutes | [17:54] |
| hverkuil | I'm not sure what the problem is: the number of pads (unavoidable for analog signals I think) or that there are two entities for a single connector? | [17:56] |
| javier__ | pinchartl: I agree that what we have now is quirky but OTOH I guess that is how the users maps the conectors in their head | [17:56] |
| shuah | in HDMI case, we probably have to represent ARC | [17:56] |
| javier__ | and probably how the vendor will label them | [17:56] |
| hverkuil | shuah: yes, but the adv7842 doesn't support that (I think) | [17:56] |
| javier__ | as a user I see my IGEPv2 connectors as 3 possible options: composite0, composite1 or s-video even when there are only 2 physical connectors in the board | [17:57] |
| hverkuil | Actually, thinking about it you could make a good case for making a DVI-I connector. DVI-I requires special handling w.r.t. the EDID. | [17:57] |
| pinchartl | javier__: my grandma would map DVI-I as "the white rectangular connector", not "DVI-A + DVI-D" :-) | [17:57] |
| javier__ | pinchartl: hehe, yeah | [17:58] |
| hverkuil | Your grandma would call you to hook it up :-) | [17:58] |
| pinchartl | :-) | [17:58] |
| hverkuil | 'for making a DVI-I connector entity' | [17:59] |
| pinchartl | but jokes aside, we need to consumer both application developers and end-users
meeting starting now, I'll be back later | [17:59] |
| hverkuil | DVI-I is a really nasty example. Ideally you would see it as a DVI-I connector that automatically detects whether it should capture analog (DVI-A) or digital (DVI-D).
Unfortunately not all devices follow the rules (Hi Apple!) so what we had to do in our product is to let the customer choose between auto detect, analog and digital. Most of the time auto detect would be OK, but sometimes you had to force it to DVI-A or DVI-D. | [18:02] |
| mchehab | hverkuil: I guess the decision on using just one PAD or multiple pads to represent multi-signal inputs should be a developer's decision...
I mean: in the case of S-Video, where both Y and C signals go from the connector to the demod, representing just one connection could be enough | [18:10] |
| pinchartl | mchehab: I think we should at least have guidelines
for the common use cases otherwise every driver will use a different approach | [18:10] |
| mchehab | pinchartl: the core will handle the common usecases | [18:11] |
| pinchartl | and it will be hell for userspace developers
what I'd like to avoid is see an adv7604 with one pad per input on one board and a couple of logical input pads on another board | [18:11] |
| hverkuil | mchehab: that's where the DT will be interesting. That should be generic and I am not sure if it is a good idea to be able to represent S-Video using one or two pads.
video receiver entities can of course choose to have a single pad for S-Video. An S-Video connector would then point both pads to the same video receiver sink pad. | [18:12] |
| pinchartl | hverkuil: we could really do with a whiteboard :-) | [18:13] |
| mchehab | btw, I looked at saa7115... svideo is a mess...
physically, the device supports several ways to connect s-video on its two s-video inputs | [18:13] |
| hverkuil | This assumes that that video receiver cannot assign the Y and C signals to different pins, of course. | [18:13] |
| mchehab | but, basically, it can use just one pin for Y+C, or one pin for Y and another one for C | [18:14] |
| pinchartl | how many time have I heard "it's a mess" when we discussed analog inputs ? :-)
one pin for Y+C ? | [18:14] |
| mchehab | yes | [18:14] |
| pinchartl | how does that work ? | [18:14] |
| mchehab | well, analog use signal carriers...
chroma is a separate frequency than the main signal so, it can be combined without any issue | [18:14] |
| hverkuil | isn't y+c just composite? | [18:15] |
| mchehab | with a simple RC mixer | [18:15] |
| pinchartl | ok, with external components
(just a capacitor actually) and it becomes composite, yes | [18:15] |
| mchehab | hverkuil: still, it has different register settings for it
not sure what's the difference of setting the input pin as S-Video or as Composite, in the case a single pin is used but it should have some difference I guess it probably assumes that the source is not TV and has a more precise clock (there are lots of analog demods that require special settings for non-TV sources, in order to better stablize the image) and to support progressive scan instead of interlaced one | [18:16] |
| hverkuil | I'm not sure where you see Y+C on one pin. I think you misread. | [18:18] |
| mchehab | if you have the datasheet, it is at table 54 | [18:19] |
| hverkuil | "Analog Control 1"?
The Y+C modes (modes 6-9) all specify 2 pins Modes 0-5 are all CVBS (aka composite) single pin inputs. (Register SA 02, it's table 53 in my datasheet) | [18:20] |
| mchehab | you should look at table 32 too
analog video signal inputs, e.g. six CVBS signals or two Y/C plus two CVBS pairs signal groups can be connected simultaneously to this device; several combinations are possible; see table 54. | [18:22] |
| hverkuil | oh, sure, but S-Video signals (YC) always use two pins. | [18:23] |
| mchehab | hmm.. you're right... I got confused the first time I read it | [18:25] |
| hverkuil | dinner time | [18:25] |
| mchehab | s-video is always AI11/AI21 or AI12/AI22 | [18:26] |
| pinchartl | mchehab: can't blame you, analog is confusing :-( | [18:26] |
| mchehab | yep
yet, from the datasheet, it seems that a "combined" s-video would require a different setting, in order to get full luminance bandwidth Note: To take full advantage of the YC-modes 6 to 9 the control-bit BYPS (sub address 09h, bit 7) should be set to “1†(full luminance bandwidth) (Note was from datasheet) that's probably one of the reasons why some analog drivers has "composite over s-video" input... a different configuration is needed for the demod to properly handle it pinchartl: didn't receive any email from you with regards to the connector... did you send it, or is it a problem on my e-mail client? (IT is changing some setups, so it is possible to be a problem on my side) | [18:26] |
| hverkuil | mchehab: that's correct. The composite signal needs completely different handling. So 'composite over s-video' just routes the composite signal over one of the two S-Video pins, the other is unused. But the hw must be told that it is getting a composite signal over that pin or it won't be able to use it.
(I think you get a monochrome image since the color is discarded) | [18:38] |
| pinchartl | mchehab: seriously... give me time to write it !
I'm in a meeting now I'll get back to that after | [18:39] |
| awalls1 | BYPS probably just bypasses the color carrier filter, when you know the S-Video Y signal jhas no color carrier on it.
s/carrier/signal/g | [18:40] |
| ................................... (idle for 2h54mn) | ||
| *** | awalls1 has left | [21:34] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
