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