<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
pinchartl: <u>mchehab</u>: please give me until this afternoon, nearly there :-)
hverkuil: <u>posciak1</u>: ping
pinchartl: <u>hverkuil</u>: fyi, http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=vsp1-kms-request-20151122
<br> let's discuss here after I finish reviewing the MC patche
<br> s
larsc: for devices with multi-plane buffers is read()/write() supported? And if yes how?
hverkuil: <u>larsc</u>: no, that's not supported.
<br> I could be possible to just read/write the planes in sequentially, but someone would have to write the code for that.
larsc: hm
pinchartl: <u>larsc</u>: we don't really need read()/write(), do we ? ;-)
larsc: no
<br> I was just wondering how you'd do that if you had to do it
<br> but usually you don't have to do it
milliz: crope is an idiot
<br> why does he hang out on irc
<br> can't answer simple questions
<br> he does respond though !
<br> which is good for him
<br> because it makes him feel special
hverkuil: <u>milliz</u>: and you think he'll answer your question now after you calling him an idiot?
milliz: I don't owe him anything
hverkuil: He does it in his free time, what little he has.
milliz: so what
<br> i don't deserve arrogance
<br> typical schmuck coding community
<br> I just want to know how to get my pctv 461e performing better
<br> asked him a legit question regarding tuning , he comes back
<br> what's an amiko alien 2 ? a der
<br> any1 got a delayed response of higher intellegence regarding my simple questions
<br> ?
<br> yep !
<br> how bout the delayed respone in regards to a working driver for the pctv 461e (queue sarcastic laugh)
-: milliz waits 3-4 years
milliz: you guys must be really good coders
crope: <u>milliz</u>: ugh. get the another device if you cannot answer questions
<br> and amigo alien is stb
pinchartl: <u>mchehab</u>: ping
mchehab: <u>pinchartl</u>: pong
pinchartl: wow that was fast :-)
mchehab: :)
pinchartl: have I overlooked something, or is documentation of the new MC ioctl missing from your patches ?
<br> there were so many different versions that I might have missed it
mchehab: <u>pinchartl</u>: as I commented on one of the versions of the patches, I will do it after we agreed that what's there is ok
pinchartl: ok
<br> who needs documentation when we have source code... ;-)
mchehab: well, for us, there's no need ;)
<br> for the others, yes we need it
<br> and I'll add the documentation for it
<br> there are/were some things that would affect the documentation... like the ID definition and the "name" field at the V2 entities
pinchartl: I've finished going through the whole series, answering individual patches now
<br> I'll proceed slightly differently than usual
mchehab: the ID definition is now OK (although I guess we're waiting for the sailus_ new version of his patch series - I guess)
pinchartl: as you haven't squashed all fixes into the original patches
<br> I'll point issues I see in latter patches in the branch
mchehab: ok
pinchartl: instead of pointing them in the first patch where the issue occured
<br> is that ok with you ?
mchehab: sure
sailus_: mchehab, pinchartl: I'll try to update my entity ID set this week.
mchehab: ok
sailus_: I've got a ton of other stuff to do so I can't quite promise that. :-I
hverkuil: <u>mchehab</u>: can you merge rc2 into our master? It fixes a bunch of pci_set_dma_mask() regressions that broke quite a few media PCI drivers.
mchehab: sure, I will
hverkuil: thanks!
mchehab: <u>pinchartl</u>: did you finish sending your reviews to the patches? If so, could you please send your acked-by? to current patch series? I'll then start working on addressing the remaining issues pointed during the 8.4 review on separate patches (except for one or two special cases pointed by sailus, where compilation broke for some arm device)
<br> s/acked-by?/acked-by:/
pinchartl: <u>mchehab</u>: I got interrupted, resuming now
mchehab: ah, ok
pinchartl: the phone always ring when you're in your bath. and if you don't have a bathtub, it's when you're busy reviewing patches
mchehab: please ping me when you finished (or add a note on one of your patch reviews that you finished)
<br> :)
pinchartl: I'll ping you :-)
mchehab: ok, thanks!
pinchartl: I might take 20 minutes off for dinner at some point, please forgive me ;-)
mchehab: np
<br> <u>pinchartl</u>: please notice that I resent the comments to your patch 24/83 review again at the linux-media ML
pinchartl: thanks
mchehab: if you're willing to reply to it, please use the "Subject: Re: [PATCH v8.2 19/55] [media] media: convert links from array to list" :)
pinchartl: if you start replying to my comments now how do you expect me to send comments to the rest of the patches ? ;-)
mchehab: well, please finish your review first, before looking on my replies ;)
<br> just wanted to remember you about this special case... e. g the one you replied only to the media-workshop ML
<br> as you'll find two replies from me with identical content...
<br> so, be sure to ignore the first one ;)
pinchartl: I've resent the replies I had sent to the workshop list my mistake, I'll pay more attention now
awalls: <u>hverkuil</u>: ping
hverkuil: <u>awalls</u>: pong
awalls: sry meeting. BBiab
pinchartl: by the way I'm still feel very uncomfortable with not rebasing the patch series to incorporate review feedback. it makes it quite difficult to do a final round of review and check that everything is fine. I could understand that you don't want to do so at every round, but one last rebase would help (let's not discuss that now though, otherwise I'll never complete the review)
<br> <u>mchehab</u>: your mauro-experimental/mc_next_gen.v8.4-rebased branch contains everything, right ?
hverkuil: 4.4.0-rc1 is seriously broken. Trying to use ssh over vpn on my virtual machine fails as well (took me a long time to figure out it's caused by the kernel since ssh was just sitting there). Luckily rc2 fixes this problem too.
mchehab: <u>pinchartl</u>: it is just a dummy rebase version of 8.4
<br> after 4.3-rc1
<br> no changes at the patches, nor at the comments
<br> just a few trivial conflict changes
<br> s/4.3-rc1/4.4-rc1/
<br> <u>hverkuil</u>: weird... here ssh to a 4.4.0-rc1 machine works:
<br> $ ssh mytestmachine
<br> Linux silver 4.4.0-rc1+ #17 SMP Mon Nov 16 21:14:30 BRST 2015 x86_64
<br> ...
hverkuil: it only fails in combination with vpn. And possibly vmware.
mchehab: ah
-: mchehab don't use vmware for ages
mchehab: vmware doesn't like -rc Kernels
pinchartl: <u>mchehab</u>: yes that's what I've seen. same as remotes/mauro-experimental/mc_next_gen.v8.4+4.4-rc1 with three whitespace fixes
hverkuil: Of course, I use vmware+vpn+ssh. On an rc kernel as well, it's a lot better recently.
pinchartl: my question was whether all the patches were there or if there was anything else
mchehab: <u>pinchartl</u>: true
<br> there are patches out of there, sent by others...
pinchartl: <u>hverkuil</u>: out of curiosity do you know which commit fixed it ?
mchehab: neither shuah or sakari's patches are merged
pinchartl: I've seen Sakari's series
hverkuil: no. I saw a lot of networking patches in rc2, no idea which one fixed it. Although I suspect it might be related to a 'set_feature()' failure that is now resolved.
<br> Whatever 'set_feature' is...
mchehab: and a few patches from Javier are also not there (the 2 or 3 ones fixing a MC bug that he pointed on his e-mails)
<br> basically, sakari will be working on a v3 of his series addressing a few remaining issues
<br> and I didn't review shuah patches yet
<br> I'm planning to work on shuah patches after finishing the MC next gen merge
shuah: <u>hverkuil</u>: set_feature() changes VPN tunnel config - there is a missing error leg that leaves VPN is bad state when there is no change to features
<br> anyway fixed in 4.4-rc2
<br> I ran into this and verified the fix in 4.4-rc2
hverkuil: <u>shuah</u>: ah, that sounds like that was indeed the cause of my problem. Drove me nuts :-)
shuah: yes indeed - I checked all my routers and switches before I suspected kernel
<br> VPN connects and web/ssh access fails
mchehab: <u>hverkuil</u>: v4.4-rc2 pull merged
hverkuil: great! much appreciated
mchehab: btw, it seems that some backport patches broke on media_build
pinchartl: <u>mchehab</u>: I don't want to comment on that for every patch, can you remove the gerrit "Change-Id:" from all commit messages ?
hverkuil: <u>mchehab</u>: I know. -ENOTIME.
mchehab: <u>pinchartl</u>: I answered that already ;)
pinchartl: and your answer was ? :-)
mchehab: I don't use gerrit here... I'm using the gerrit ID's only to allow identifying me the same patch during a rebase ;)
<br> those are autmatically splitted when I send the patches to the ML via my scripts, or when I merge them
pinchartl: ok
mchehab: the thing is that the series I sent to the WS ML were not using my scritps, to avoid running get_maintainers.pl
pinchartl: no worries
hverkuil: <u>awalls</u>: sorry, got to go.
mchehab: <u>hverkuil</u>: I'll try to fix at least some of them
<br> before people start complain ;)
pinchartl: <u>hverkuil</u>: will you have some time to discuss the request API this week ?
hverkuil: On Friday certainly. For Tue-Thu you'll have to ping me, I can't predict if I'll have time or not.
pinchartl: Friday sounds good
<br> I'll be busy this week too
<br> feel free to have a quick look at the series whenever you want of course
<br> <u>mchehab</u>: I assume you'd rather want me *not* to review the dvbdev patches ;-)
hverkuil: <u>mchehab</u>: fixed some, but not all, of the media_build issues.
<br> 3.0 fails with a missing clk_name.
mchehab: <u>pinchartl</u>: it is up to you, but I as this is not the area where you've been working with, feel free to skip them
pinchartl: I mean I might send comments you might not agree on, I don't know :-)
mchehab: <u>hverkuil</u>: thanks
pinchartl: I'll handle them last if I have time
mchehab: <u>pinchartl</u>: sounds ok
<br> <u>pinchartl</u>: yeah, we'll likely disagree on some of your comments, specially there ;)
awalls: <u>hverkuil</u>: when you asked for cx88 data, did you mean BT878 or CX2388[0123] ?
<br> I interpreted it as BT878
***: fling has quit IRC (Ping timeout: 240 seconds)
<br> awalls has left
<br> zequence has left
<br> WeaselSoup has quit IRC (Read error: Connection reset by peer)
pinchartl: <u>mchehab</u>: I have to call it a day
<br> I'll continue tomorrow
<br> there's already enough material for discussions I think