| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | stdint has quit IRC (Disconnected by services) | [01:16] |
| .................................................... (idle for 4h16mn) | ||
| pmp has quit IRC (Ping timeout: 245 seconds) | [05:32] | |
| ................................................... (idle for 4h10mn) | ||
| hverkuil | mchehab: just a reminder: this one is for 4.10: https://patchwork.linuxtv.org/patch/38575/
A few small cec fixes and a fix for a nasty race condition that took me a day and a half to track down. | [09:42] |
| ............. (idle for 1h0mn) | ||
| mchehab | I really hate python:
File "/usr/local/bin/pwclient", line 748, in main print(unicode(s).encode("utf-8")) some patch broke pwclient again | [10:43] |
| ..... (idle for 22mn) | ||
| it seems that the damn python changed again something at unicode handling... this doesn't seem to work anymore:
print(unicode(s).encode("utf-8")) Changing it to: print(unicode(Exception(s)).encode("utf-8")) seemed to work Well... sort of: From: =?utf-8?q?Jean-Philippe_Fran=C3=A7ois?= <jp.francois@cynove.com> at least my script doesn't die anymore and my script fixes that utf-8 tag properly: GIT_AUTHOR_NAME=Jean-Philippe François | [11:05] | |
| ...................................... (idle for 3h8mn) | ||
| *** | WeaselSoup has quit IRC (Ping timeout: 260 seconds)
MJRider has quit IRC (Ping timeout: 260 seconds) | [14:18] |
| .......................... (idle for 2h5mn) | ||
| javier___ | pinchartl: tested your tvp5150 patches on my IGEPv2 boaard and both composite inputs (AIP1A and AIP1B) are still working for me
pinchartl: funny that I was not remembering writing commit ec2c4f3f93cb ("[media] media: tvp5150: Add mbus_fmt callbacks") that did the reset in the get/set fmt handler but then I noticed that the author is Javier Martin and not me, so that explains why I didn't remember it :) | [16:23] |
| pinchartl | :-D
why do people have the same first name ? it's confusing :-) | [16:25] |
| javier___ | hehe, in this case is even more confusing because our last name are also quite similar
pinchartl: I'll try to re-spin the input signal patches so hopefully you can review it and fix this mess... | [16:28] |
| pinchartl | thanks | [16:33] |
| javier___ | pinchartl: one question is if in the case of defining the input ports, all ports (digital output video port + analog input video ports) should be under a ports subnode | [16:35] |
| pinchartl | the ports node is optional. its main purpose is to allow the #address-cells and #size-cells properties to be isolated
core code should handle that, drivers shouldn't care I think we have functions to iterate over the ports, regardless of whether they are direct children of the device node or are grouped in a ports node so it's up to the DT writer, both should be supported | [16:38] |
| javier___ | pinchartl: yes, my question was rather if all should just be ports regardless if are input or output and use the reg property to let the driver know if the ports are TVP5150_{COMPOSITE0,TVP5150_COMPOSITE0,SVIDEO,OUTPUT)
the reason why I originally had the input ports under a connectors was to differentiate between the output port and the input ones | [16:41] |
| pinchartl | there should be 3 ports
two for the inputs, one for the output with fixed numbers I'd number them 0 and 1 for the inputs, and 2 for the output | [16:42] |
| javier___ | pinchartl: shouldn't be 3 for the inputs? (AIP1A, AIP1B and AIP1A + AIP1B)
which should be composite0, composite1 and s-video | [16:43] |
| pinchartl | DT should describe the physical inputs
similarly, the S-Video connector should have two output ports so when using s-video you would have the two S-Video connector output ports connected to the two tvp5151 input ports | [16:45] |
| javier___ | pinchartl: ah, Ok. I thought we had agreed in that past that this level of details would not be exposed in DT and MC
so the ports would be the possible video signals and not how the individual pins are wired | [16:48] |
| pinchartl | I don't think we should expose it in MC though
in DT we have to well, we need to at least expose two ports but in MC, there's no need to | [16:49] |
| javier___ | pinchartl: Ok, so for MC we should keep using a single pad for the connector -> tvp5150 link | [16:50] |
| pinchartl | we've gone back and forth on this topic. given that S-Video is pretty much the only annoying case, I think exposing the two ports is a pragmatic solution
(I used to think that we should have used pads instead of ports in the DT bindings or the other way around in MC, but now I realize that using different names make discussions much easier) | [16:51] |
| javier___ | pinchartl: Ok, just to confirm we are on the same page. The DT should reflect the actual wiring of the connectors to the tvp5150
so 2 input ports for the 2 input pins and for example the s-video connector should have 2 output ports for Y + C | [16:54] |
| pinchartl | correct | [16:55] |
| javier___ | but in MC, we have a more abstract representation since exposing s-video as 2 pads makes things more complicated for no gain | [16:55] |
| pinchartl | so in MC I'm fine with a single pad and a single link
*but* it can make sense to use two pads and two links if the individual signals from the S-Video connector can be used independently to carry two separate composite signals | [16:55] |
| javier___ | pinchartl: but in this case you would have in DT 2 connectors each with one output port connected to each input port
so in DT you would have 2 entities with 1 pad each | [16:56] |
| pinchartl | no
that's if you have two separate connectors | [16:57] |
| javier___ | pinchartl: ah, got what you meant | [16:58] |
| pinchartl | you could have a single ushiden connector
with an external splitter you can't know that in the driver so it could make sense to have two pads and two links I mean unconditionally (I wish people would really not use external splitters) the problem with this setup is that the driver can't know whether the ushiden connector will potentially be used to carry to separate composite signals so it has to support all options and expose three inputs (in the V4L2 API sense) to userspace that's confusing for users when a system is primarily meant to be used for s-video and the user has no external splitter then showing three possible inputs ina GUI is simply confusing but we have no way to know in the driver the other option, which is to have a single pad and link, would be less confusing but then it becomes more difficult to expose routing to userspace | [16:59] |
| javier___ | pinchartl: now, from the tvp5150 pov how the Video Input Source Selection register in the chip will be configured when carrying 2 composite signals? | [17:02] |
| pinchartl | the tvp5151 can only process a single input signal at a time
so if both links are enabled, the driver would use the s-video configuration | [17:03] |
| javier___ | right, so if only one is enabled then it will assume that is not s-video but a composite signal | [17:04] |
| pinchartl | if a single link is enabled, that input would be used
yes | [17:04] |
| javier___ | pinchartl: if external splitters could be described in DT then things would be easier since a ushiden -> 2 composite adapter could be described as 2 composite connectors
but the problem is that these are plugable | [17:09] |
| pinchartl | yes :-)
and they're pluggable to any system even systems not designed for them | [17:10] |
| javier___ | yeah
is just confusing from the MC pov that setup a link between a S-Video entity Y pad and the tvp5150, will select the input source as composite but I guess we don't have another option if we want to support all cases s/S-Video entity/S-Video connector entity pinchartl: anyway, thanks a lot for all your feedback. I'll re-spin the patches and post them as RFC again | [17:10] |
| pinchartl | I'd love to have another option, but I can't think of one just now :-/
you're welcome. thanks for working on this | [17:14] |
| mchehab | pinchartl, javier___: FYI, when tvp5150 is selected to S-Video, it won't accept composite video... it seems it does more than just AIP1A+AIP1B
I mean: switching to S-Video with the S-video input disconnected and composite connected show a black screen | [17:21] |
| javier___ | mchehab: yes, the discussion was to use the S-Video (or rather the ushiden connector) for composite | [17:22] |
| pinchartl | mchehab: I wouldn't have expected that to work, thanks for the confirmation
javier___: looks like it's spelled Hosiden although the French wikipedia page says otherwise "For its application in S-Video, the 4-pin mini-DIN connector is sometimes called the Hosiden connector." in https://en.wikipedia.org/wiki/Hosiden while in https://fr.wikipedia.org/wiki/Ushiden, "Ushiden, ou parfois Oshiden, est une connectique de type Y/C adaptée à la vidéo à composantes séparées. Elle est parfois appelée à tort « Mini DIN » ou « S-Video »." | [17:22] |
| javier___ | pinchartl: Ok, I always just called it S-video connector so I assumed you were right on the naming :) | [17:24] |
| mchehab | I either call it s-video connector or 4-pin mini-DIN | [17:24] |
| javier___ | pinchartl: now that I think about it, then we would need to do the same for the opposite case (what happens on the IGEPv2) | [17:24] |
| mchehab | :) | [17:25] |
| pinchartl | "Ushiden, sometimes called Oshiden, is a connector type of Y/C type suited for separate component video. It's sometimes incorrectly called "Mini DIN" or "S-Video"" | [17:25] |
| javier___ | pinchartl: the DT will describe 2 composite connectors wired to AIP1A and AIP1B
pinchartl: so if someone wants to use S-Video, linking both connector 0 and 1 single pad to tvp5150 should select the input source to s-video | [17:25] |
| pinchartl | javier___: does the IGEPv2 have two RCA jack connectors | [17:26] |
| mchehab | IMHO, in the case of DT, I would also have a separate connector type for S-video - as the connector is there physically on devices with S-Video inputs (either directly or via some adapter cable) | [17:26] |
| javier___ | pinchartl: yes | [17:26] |
| pinchartl | javier___: correct | [17:26] |
| javier___ | pinchartl: https://www.isee.biz/products/igep-expansion-boards/igepv2-expansion | [17:26] |
| mchehab: Laurent point is that you can't describe the adapter cable in the DT since isn't really part of the HW | [17:31] | |
| mchehab | in the case of IGEPv2, I agree | [17:32] |
| javier___ | I guess you could add it with a DT fragment / overlay though | [17:32] |
| mchehab | but tvp5051/tvp5151 supports it, so, if the connectors will be bound to it, the DT documentation should mention S-Video | [17:33] |
| javier___ | mchehab: yes, it will document it | [17:33] |
| *** | awalls1 has left | [17:34] |
| mchehab | well, make a proposal... we'll review when you submit :-)
mchehab is unsure about what you meant by "DT fragment / overlay" | [17:37] |
| javier___ | mchehab: yes :)
mchehab: http://lxr.free-electrons.com/source/Documentation/devicetree/overlay-notes.txt | [17:37] |
| pinchartl | javier___: I'm not sure that's a good idea
having to load a DT overlay when plugging a cable sounds pretty complicated it should really all work out of the box :-) thinking about it I don't think it's too bad userspace will have the necessary information | [17:38] |
| javier___ | pinchartl: right, I didn't mean instead of the other solution we discussed | [17:39] |
| pinchartl | if there's a Hosiden (or whatever that should be called) connector | [17:39] |
| javier___ | pinchartl: but I think a user should be able to do it | [17:39] |
| pinchartl | we'll have three possible inputs
on for s-video and two for each composite input s/two/one/ so three in total that situation requires an external cable which userspace can detect, as userspace will know the connector type from MC same if you have two RCA connectors, an external cable will be needed to use S-Video so in the GUI that allows selecting the input, userspace could notify the user that an external cable is needed for those options no confused user, all options possible, everybody is happy | [17:40] |
| mchehab | makes sense | [17:42] |
| pinchartl | I don't think we can do better than that | [17:42] |
| javier___ | pinchartl: agreed | [17:43] |
| pinchartl | we should document that somewhere
hverkuil: sailus: just FYI (now it's documented in the brain of core developers, but a written documentation would still be good) | [17:43] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |