<!-- 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>
bbrezillon: <u>hverkuil</u>: pong (5 days later :-/)
hverkuil: <u>bbrezillon</u>: I was wondering if you can prepare some slides for the 'Future work' media session at the ELCE?
<br> Quick intro to the proposed changes, and esp. open questions.
bbrezillon: We're just talking about the EXT_BUF ioctl()s, right?
hverkuil: Yes. Your RFC v3.
bbrezillon: I prepare 2 or 3 slides, yes
hverkuil: Thank you, much appreciated!
bbrezillon: *I can prepare
KitsuWhooa: I'm trying to finish up support for a saa7134-based card I have and I'm working on DVB-T. Firmware upload and communication with the frontend seems to be fine: [ 3887.313879] tda1004x: found firmware revision 29 -- ok. debug=1 in tda1004x shows successful I²C transfers
<br> There are no errors anywhere that I can see, however when trying to tune with dvbscan, I get "Unable to query frontend status", after the FE_READ_STATUS ioctl which returns 0 according to strace
<br> Any idea what the issue might be/how I should approach this?
hverkuil: <u>dafna2</u>: ping
KitsuWhooa: ...maybe dvbscan is broken, because it seems to throw the same error on my RTL2832U which I know works in VLC
<br> Okay, I switched to scan. It seems to be able to tune to a frequency but it doesn't list any services (that are known to exist using a known working device). Instead I get WARNING: filter timeout pid 0x....
<br> https://tasossah.com/gb7131_scan.txt
hverkuil: paulk-leonov: ping
bbrezillon: <u>hverkuil</u>: https://gitlab.collabora.com/bbrezillon/v4l2-ext-fmt-buf-slides/blob/master/v4l2-ext-fmt-buf-ioctls.pdf
<br> let me know if you want something with more detailed
<br> s/with//
hverkuil: <u>bbrezillon</u>: add a slide with 'open questions'. Looks good otherwise.
<br> <u>bbrezillon</u>: and upload with a right suffix: it wasn't a pdf :-)
bbrezillon: <u>hverkuil</u>: fixed
bingbu: Does any meet code pull failure from git://linuxtv.org/media_tree.git today?
hverkuil: <u>tfiga</u>: ping
<br> <u>bingbu</u>: works for me.
tfiga: <u>hverkuil</u>: pong
hverkuil: <u>tfiga</u>: thanks for your replies and thoughts about the future API. Much appreciated.
bingbu: <u>hverkuil</u>: thanks, likely something wrong with my proxy.
hverkuil: See also my reply to the ANNv2: I think we need a brainstorm session for this since there is no way we can ever come to a conclusion in just 4 hours next week.
<br> It would be very useful to include you in such a brainstorm session, so think about when that would work for you.
<br> Most of the other stakeholders are nicely concentrated in Europe, so it tends to be easier to find a date that works. You're a bit further away, though :-)
tfiga: <u>hverkuil</u>: I might be a bit busy in November and December is a bit of a holiday season (and I need to spend my vacation balance...), but Jan/Feb should work for me
<br> anywhere with a good connection to Poland would be appreciated ;)))
hverkuil: December is out for me as well. But I was thinking about the week before FOSDEM in Brussels.
tfiga: and Google Tokyo is always open to host us ;)
<br> we got a really nice new office recently
<br> otherwise, the week before FOSDEM might be a good ide
<br> idea*
hverkuil: I'd be fine with Tokyo, but I suspect the cost will be a problem for others.
tfiga: yeah, given how many people are based in Europe, that's not the most convenient option
<br> (and not the cheapest)
<br> that said, we would at least have lunches included ;)
hverkuil: If we go with Brussels, then we need to find and book a hotel and conference room very soon after the ELCE, to keep the cost down.
tfiga: anyway, let's maybe see what level of interest we get
hverkuil: paulk-leonov: ping
<br> <u>tfiga</u>: stateless decoder spec just got merged! mchehab: much appreciated!
<br> <u>gnurou</u>: ^^^^
<br> Many thanks to everyone who worked on this.
<br> <u>jernej</u>: ping
<br> <u>jernej</u>: mailed you: v4l2-compliance claims that your deinterlace driver supports scaling, but I think that's wrong.
<br> So it's either a driver bug or a compliance test bug. Most likely the latter.
tfiga: <u>hverkuil</u>: \o/
<br> thanks everyone
paulk-leonov: <u>hverkuil</u>: pong
<br> oh nice :)
hverkuil: paulk-leonov: did you see mchehab's comments on the HEVC series? Do you think you can look at that this week? It shouldn't be difficult.
<br> It would be great if that can be merged before the ELCE.
paulk-leonov: <u>hverkuil</u>: yes it looks doable for me to send a new version
<br> indeed
hverkuil: paulk-leonov: Mauro also had comments about the use of (1 << X) for the 64-bit 'flags' fields. He preferred (1ULL << X). This was in an irc discussion over on #media-maint.
<br> https://linuxtv.org/irc/irclogger_log/media-maint?date=2019-10-17,Thu
paulk-leonov: <u>hverkuil</u>: understood, thanks for the context
hverkuil: If you post a new series anyway, then just change that too. I don't quite agree with Mauro :-) but it is certainly not wrong or worth spending time on.
<br> <u>ribalda</u>: ping
paulk-leonov: sure
ribalda: <u>hverkuil</u>: pong!
hverkuil: Hi Ricardo! I wonder if you have time to add a test control of the new AREA type to vivid, and add support for it to v4l2-ctl and (if needed) v4l2-compliance?
<br> That way this new type is actually regression tested.
ribalda: sure
hverkuil: I should have mentioned this before, sorry for the late comment.
ribalda: no worries at all. Can you give me 1 week?
hverkuil: I've just sync v4l-utils to the latest headers, so that's why this cropped up now.
<br> Sure.
ribalda: I havent touched before v4l2-ctl, so I probably fuck it up :)
hverkuil: Do vivid first, then v4l2-ctl, and v4l2-compliance last (this may not be needed at all)
<br> vivid already has test user controls for all standard types (v4l2-ctl -l), so just add an area control.
ribalda: if you merge (or at least intent to merge) the last one (for custom areas) I could add 2 controls
<br> 1 for the pixel size
<br> 1 for setting the area for the autos
<br> the first one (pixel size) is read only, the second is read-write.
<br> and will show how to use https://patchwork.linuxtv.org/patch/59505/
hverkuil: You are not recreating V4L2_CID_UNIT_CELL, this is just to test the control type. So you add a VIVID_CID_AREA control (vivid-ctrls.c), which is otherwise meaningless.
ribalda: to add VIVID_CID_AREA I need https://patchwork.linuxtv.org/patch/59505/ . Otherwise I can only add UNIT_CELL
hverkuil: The key thing is that you should be able to set/get it with v4l2-ctl.
<br> Yes, you need some form of that patch :-) I'll reply to your proposal. That patch can be the first patch in a series adding vivid support.
ribalda: ferpect!, lets do it like that
hverkuil: <u>koike</u>: ping
mjourdan-: <u>hverkuil</u>: there are a few more complications to fixing the corner case I'm having. I sent an email in the same thread 3 days ago but you answered the previous one, so unsure if you saw it.
hverkuil: mjourdan-: I didn't see it, thanks for pointing it out.
jernej: <u>hverkuil</u>: H3 deinterlacer does indeed support scaling, so it's not a bug.
<br> it also supports color adjustment via CSC matrix and pixel format conversion, but that's not really implemented
<br> mostly because there is no good documentation and BSP driver doesn't support that
<br> well, proposed mainline driver supports converting NV12 input to NV21 and vice versa, but that's it
hverkuil: <u>jernej</u>: OK, good to know. Is it mentioned somewhere explicitly in e.g. the Kconfig entry and source that this driver supports scaling? (Sorry, didn't check this).
jernej: No, there is no explicit mention of scaling. I didn't know it should be
shuah: <u>hverkuil</u>: Hi Hans! Here is the autogenerated regression tests git repo announcement - https://lkml.org/lkml/2019/10/15/756
<br> Also link to the e-curse for new developers - https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfc103/
<br> This is a free e-course I wrote for beginners
hverkuil: <u>jernej</u>: In any case, the remaining issues are tiny, so I'll take the v5.
jernej: <u>hverkuil</u>: so scaling capability must be mentioned or not?
hverkuil: It should be mentioned in the Kconfig (it's not at the moment), and in the driver. I see that the comment at the top says:
<br> + * Allwinner sun8i deinterlace driver
<br> That should be:
<br> + * Allwinner sun8i deinterlace and scaler driver
jernej: <u>hverkuil</u>: Why? scaling is not standalone feature
<br> at least I understand your suggestion in a way that you could only do scaling, which isn't true
<br> well, there might be a way, but HW wasn't designed with that in mind
hverkuil: Ah, good point. Hmm, how to phrase this.
<br> "Allwinner sun8i deinterlacer with scaler driver" perhaps?
jernej: ok
hverkuil: The point is that this feature is unusual for a deinterlacer, so it should be mentioned somewhat prominently.
savo: Hi, some of the key codes are above 255 on my Bluetooth remote so i use ir-keytable to remap them. This has just stopped working with v1.18. I think its the removal of --device argument
***: hnrk has quit IRC (Quit: Lost terminal)