<!-- 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>
***: cybrNaut has quit IRC (Ping timeout: 255 seconds)
<br> WeaselSoup has quit IRC (Quit: WOOPS)
<br> _franck__ has quit IRC (Ping timeout: 264 seconds)
<br> mchehab has quit IRC (Ping timeout: 260 seconds)
ribalda: <u>hverkuil</u>: mchehab: Good morning! Laurent has prepared a patch for vsp1 in order to support hsv. How shall we proceed from here? I send a v6 of the patchset with that, or hans cheery picks Laurent patch on top of my patchset?
pinchartl: <u>ribalda</u>: unless there has been changes in your patches since v5 (or v5.2 for patch 10), you can either prepare a branch in which your cherry-pick my patch and send a pull request, or let Hans handle it
<br> I can also do it
ribalda: <u>mchehab</u>: It is ok to send a pull request from github?
<br> s/ mchehab /pinchartl/ :)
pinchartl: technically I think so
ribalda: ok, then I do that and also rebase the patchset on top of master
hverkuil: OK, then I won't do anything :-)
pinchartl: <u>hverkuil</u>: if you're bored with nothing to do, could you have a look at the channel log from yesterday evening ? :-)
hverkuil: <u>ribalda</u>: I've acked the patch series, so please add my ack when you prepare your pull request.
<br> <u>pinchartl</u>: I'm neither bored, nor do I have time :-)
<br> I could do with a bit of boredom, frankly.
pinchartl: :-)
<br> the discussion was about the metadata API
<br> and specifically Mauro doesn't like the fact that, for the VSP1 histogram format, the actual buffer layout depends on the value of controls
hverkuil: <u>mchehab</u>: https://patchwork.linuxtv.org/patch/36729/
ribalda: I have just made the git pull. Plase tell me if I made a mistake, it is my first one :)
<br> shall I remove the old patches from patchwork?
hverkuil: <u>mchehab</u>: This pull request was accepted, but I don't see the patches in your fixes branch. Just want to verify that there wasn't a mistake.
pinchartl: <u>ribalda</u>: it looks good. next time please specify the target version in the subject line ("[GIT PULL FOR v4.9] HSV formats")
svarbanov: <u>hverkuil</u>: Hi Hans, did you tried v4l-utils cross-compilation for arm64?
pinchartl: <u>svarbanov</u>: I did
svarbanov: <u>pinchartl</u>: Hi Laurent, did you made some fixes in configure.ac or somewhere else
pinchartl: <u>svarbanov</u>: no I didn't, but I've disabled a few features I don't need that used to cause compilation issues in the past (I haven't checked recently if that's still the case)
<br> HOST=aarch64-buildroot-linux-gnu
<br> g
<br> ./configure --host=$HOST CC=$HOST-gcc CXX=$HOST-g++ --prefix=$PREFIX --disable-libdvbv5 --without-jpe
<br> I've just checked now and it compiles fine
svarbanov: <u>pinchartl</u>: thx, I will try that, following on the instructions form INSTALL it fails with "machine `aarch64-linux-gnu' not recognized", last time I built it I've made some tricks
pinchartl: I've tried again, --disable-libdvbv5 isn't needed if you apply the patch I've just sent to the linux-media mailing list :-):
<br> and --without-jpeg isn't either
svarbanov: <u>pinchartl</u>: thx, it seems that CC and CXX are not needed :)
pinchartl: even better :-)
<br> <u>hverkuil</u>: ping
<br> quick question about controls
<br> I have a compound control with 12 u8 values
<br> with a hardware constraint that value[i] <= value[i+1]
<br> when the constraint is not fulfilled, should the .s_ctrl() handler return -EINVAL or fix the values ?
<br> the values represent boundaries for histogram buckets
<br> wrong values fixed by the driver would likely result in semi-random values returned by the histogram generator
<br> I'm thus thinking that returning -EINVAL could be better to avoid userspace thinking that the control was successfully set
<br> but then -EINVAL could be returned for values that match the min/max/step criteria, which could be considered confusing by userspace
hverkuil: Implement this check in try_ctrl: that's the right place for such checks.
pinchartl: good point
<br> but should it return -EINVAL or fix the values ? :-)
hverkuil: I'm checking that...
<br> -EINVAL is fine as a return code.
<br> Obviously the constraint should be documented in the control description.
pinchartl: for a range control that has hardware constraints making some values not acceptable, fixing the value is generally fine. but in this case configuring histogram buckets in a way different than what is requested by the application will result in a totally different, likely unusable histogram
<br> speaking of control descriptions
***: stdint has quit IRC (Read error: Connection reset by peer)
pinchartl: did I miss something, or does our documentation contain no driver-specific controls apart from the MPEG encoding controls ?
hverkuil: You didn't miss anything.
pinchartl: :-)
hverkuil: They should be documented in the driver, but that really should be moved to the main spec.
<br> For a lot of old drivers there is no documentation whatsoever.
pinchartl: in the driver's source code ?
hverkuil: source or header.
pinchartl: ok we're good then, there's already a comment in the code
<br> on the same topic
<br> for driver-specific controls
<br> I'm guilty of using V4L2_CID_USER_BASE | 0x100* in several drivers
<br> instead of reserving a driver-specific range
hverkuil: Now that we have driver-specific documentation I think that might be a good place to document driver-specific controls.
pinchartl: that doesn't cause any technical issue as the controls are specific to subdevs
<br> so there's no conflict
<br> but I'd like to make sure that's fine, or is it mandatory to reserve a range of driver-specific controls ?
hverkuil: Mandatory. I really don't like to have control IDs that are not unique.
<br> And it is not as if we can run out of IDs :-)
pinchartl: you've missed the issue when reviewing a few patches then ;-)
<br> I'll fix that
<br> <u>hverkuil</u>: when would you have time to discuss whether metadata formats can/should/could/may/must[not] depend on controls ?
hverkuil: <u>pinchartl</u>: certainly next week, but I don't know if I can find time this week.
pinchartl: ok
<br> <u>mchehab</u>: I'd like to get at least part of the patches in for v4.9
<br> the HGT format doesn't depend on controls
<br> would you accept a pull request for HGT without HGO this week ?
BanHammor: How do I restrict changes to controls and to S_FMT calls while actively streaming?
<br> I honestly want to NOT deal with concurrent applications using my device at all -_-
hverkuil: <u>BanHammor</u>: Changes to the format are prohibited while streaming. The driver should call vb2_is_busy() in the s_fmt implementation and return EBUSY when busy.
<br> If an application wants exclusive access, then it should use VIDIOC_S_PRIORITY to increase the prio to RECORD. Then no other applications can make changes.
pinchartl: <u>hverkuil</u>: changes to the format are actually not prohibited by the API, but they're prohibited by most (if not all) drivers
hverkuil: I simplified :-)
<br> All mainlined drivers prohibit it (and if not, then that's a bug).
pinchartl: <u>BanHammor</u>: you can use vb2_is_busy() to disallow format changes after buffers have been allocated (this covers more than just the streaming state)
<br> be careful about locking though
<br> but for controls, changes during streaming can be helpful
<br> even without multiple concurrent applications
BanHammor: well, it's mostly that my device can go haywire if reconfigured while activated, so yeah, I'll probably use vb2_is_busy().
pinchartl: are you developing a driver ? what device is that ?
hverkuil: You typically need vb2_is_busy() for S_FMT, S_SELECTION, S_STD and S_DV_TIMINGS.
<br> <u>svarbanov</u>: that was quick!
<br> I'll hope to be able to review it next week.
BanHammor: pinchartl, an m2m thingy for stereoscopic vision/analysis
svarbanov: <u>hverkuil</u>: Thx for the review, I hope that more of the comments are addressed.
BanHammor: it's probably never going mainline, since I had to put a hack into m2m to get it to distinguish left/right buffers :D
pinchartl: <u>BanHammor</u>: nice
<br> no no no that's the wrong approach
<br> it will go to mainline
<br> so let's work on a proper solution for that :-)
<br> (I'm serious)
svarbanov: <u>hverkuil</u>: it is strange but v4l2-compliance still passing without errors :)
hverkuil: <u>svarbanov</u>: you have to remind me: why is that strange?
svarbanov: <u>hverkuil</u>: you said that you made some improvements regarding s|g_parm and g|s_selections and I had expected failures
mchehab: <u>pinchartl</u>: sorry, I can't discuss anything today... Yesterday I forgot that today is a national holiday (independence day). I have some plans for today already :( Let's discuss it tomorrow
pinchartl: <u>mchehab</u>: no issue. just let me know if you think that it would be easier to merge HGT first (as its format is fixed)
ndufresne: <u>javier__</u>: curiosity, are you attending ELCE this year ?
javier__: <u>ndufresne</u>: no this year unfortunately
kbingham: <u>ndufresne</u>: Does that mean you will? (I owe you a beer :D )
***: egavinc has quit IRC (Read error: Connection reset by peer)
<br> larsc has quit IRC (*.net *.split)
<br> capOM has quit IRC (*.net *.split)
<br> Peetz0r has quit IRC (*.net *.split)
<br> Muzer has quit IRC (*.net *.split)
<br> sic_ has quit IRC (*.net *.split)
<br> indy has quit IRC (*.net *.split)
<br> henr_k has quit IRC (*.net *.split)
<br> crope has quit IRC (*.net *.split)
<br> prabhakarlad has left
<br> benjiG has left
<br> pfallenop has quit IRC (Ping timeout: 240 seconds)
<br> awalls has left
<br> bp0 has quit IRC (Quit: Leaving)
<br> snawrocki has quit IRC (Ping timeout: 240 seconds)