<!-- 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>
prabhakarlad: Oops wrong channel
***: albeu has left "PING 1443696327"
alb3u: Hi all! I have a question regarding CSI subdev.
<br> In v4l2_subdev_video_ops there is g_mbus_config and s_mbus_config
<br> g_mbus_config return a mask of supported configs, but s_mbus_config is documented as deprecated
<br> So how should one set the desired config?
larsc: <u>albeu</u>: set_pad_format I think
twb: Can you guys help me with ir-keytable?
<br> http://sprunge.us/aUac <-- my remote is working, but some keys don't turn into XF86<blah> keydown events in xev(1)
<br> What do I do to change that?
<br> (Specifically KEY_INFO and KEY_SUBTITLE)
albeu: <u>larsc</u>: I'm not sure which driver method you mean, but the pad format only have the mbus format, not the mbus config
<br> as far as i can tell the mbus config is the only way to specify the CSI parameters such as number of lanes
larsc: hm right
<br> I guess the config is supposed to come from either platform data or DT
<br> but that does not allow dynamic reconfiguration
albeu: still one has to select the correct one
<br> with DT the sensor driver *could* read the endpoint parameter for the number of lanes, but that doesn't sound right to me design wise
larsc: I think that's how it is supposed to work
albeu: and it would still leave out the CSI channel which can't be set in DT
<br> clock-noncontinuous can be set in DT, but I'm wondering how they got that in the binding as it doesn't describe the hardware
<br> I suppose it isn't a problem at the moment as all CSI sensor driver only support a fixed mbus config
larsc: sailus might be the person to talk to about htis
stormer: <u>hverkuil</u>: we found that enumerating the color spaces supported can be really expensice, as we loop over 3 enumerations, is there any plan to make that enumeratable in another way ?
<br> for the reference, https://bugzilla.gnome.org/review?bug=755937&attachment=312475
***: benjiG has left
headless: <u>larsc</u>: any progress w/deleting autodetect in adv7180?
larsc: no
headless: <u>larsc</u>: OK
<br> <u>larsc</u>: the bad thing is that mchehab has already committed a patch switching rcar_vin to g_std()
mchehab: ?
headless: at least this patch is in the master branch, so that we have timne before 4.4 t deal with the regression this caused
<br> <u>mchehab</u>: I wrote to you abt that
<br> http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=f00ae754c536511055ed6162778be8348e093514
mchehab: ah, I see
headless: breks frame capture si nce adv7180 doesn;t implement g_std()
<br> breaks even
<br> s/;/'/
<br> *since
mchehab: well, we should either fix adv7180 (the best approach, IMHO) or revert that patch
headless: unfortunbately, the patches got appled separately, despite being grouped in the series
<br> *applied
<br> <u>mchehab</u>: there's still hope for adv7180 to be fixed. we have several weeks ahead
<br> <u>mchehab</u>: am I correct in thinking the master branch gets pushed out only for -rc1's?
mchehab: yes, that's true
<br> still, not too nice to keep it broken for a long time
<br> I guess I'll revert that patch and wait for the submission of a proper fix
<br> from you
<br> please add the SOBs/ACKs on this patch when re-submitting
<br> pushing the revert patch
<br> OK
<br> keeping the driver broken for a long time is not a good idea, as other patches will be in the middle, making harder for one that might be trying to do git bisect to fix some problem on this driver
headless: <u>mchehab</u>: OK, thank you. that works too
mchehab: and one less problem on my sholders ;)
headless: <u>mchehab</u>: have you pushed to the server? I'm not seeing it yet...
mchehab: it takes up to 5 or 10 minutes for the web to be updated
<br> as gitk keeps a cache
<br> cgit
<br> (not sure how long the cgit cache is configured... it is either 5 or 10 mins)
headless: <u>mchehab</u>: stiil nothing. so I'll have to add hverkuil's and your SoBs?
<br> *still
mchehab: no need to add mine
<br> but please keep the other acks/sobs as the original patch, if you will be just re-submitting it
headless: OK
<br> <u>larsc</u>: any hope you'll have time for this work before 4.4?
mchehab: <u>headless</u>: patch is there
headless: indeed, TY
<br> <u>mchehab</u>: s/two/one/ (speaking about the patches :-)
<br> although, as I remember hverkuil had idea for yet another patch in addition to the autodetection removal
mchehab: <u>headless</u>: your note was:
<br> Note that merging this patch without the 2 patches preceding it in the the series will break the frame capture.
<br> I just did a sum-up
<br> anyway, it doesn't matter ;)
headless: <u>mchehab</u>: the 2nd one was ml86v7667 patch and it got merged today
mchehab: ah
headless: well, what's done is done :-)
mchehab: yep
<br> and it doesn't really matter if we'll need 1, 2 or 10 patches in the future ;)
headless: well, unless it's the person who'll have to work on them :-)
-: headless feels it would be him in the end
larsc: <u>headless</u>: my resources are rather limited at the moment
<br> deadlines everywhere
headless: <u>larsc</u>: OK, I'll negotiate with the boss about doing that myself