[01:23] *** mchehab has quit IRC (Ping timeout: 260 seconds)
[01:24] *** ChanServ sets mode: +v mchehab
[11:59] <hverkuil> almost forgot the meeting :-)
[12:00] <sailus> Hello!
[12:00] <sailus> hverkuil: But you're the first one here. :-)
[12:04] <sailus> Is anyone else around?
[12:04] <sailus> mchehab: Ping?
[12:04] <sailus> hverkuil: While we're waiting, I've thought the options of adding events support to MC.
[12:05] <sailus> V4L2 has a pretty elaborate implementation and I was thinking of generalising that, instead of going with the trivial implementation written just to support requests in the older request API set.
[12:06] <sailus> Presumably MC would also benefit from the same implementation that supports subscribing and merging events.
[12:07] <pinchartl> hello
[12:07] <hverkuil> CEC might reuse such an implementation as well. It doesn't need something that elaborate at the moment, but that might change in the future.
[12:07] <sailus> pinchartl: EHLO
[12:07] <sailus> hverkuil: That's how it was for V4L2....
[12:07] <sailus> Good.
[12:07] <hverkuil> I'm very pleased with the V4L2 implementation: it has good guarantees against losing events.
[12:09] <sailus> I guess the meeting has started.
[12:10] <sailus> I'll send a pull request on the fwnode patches unless there are further comments or changes needed.
[12:10] <hverkuil> nice to get that in!
[12:11] <sailus> Yes.
[12:11] <hverkuil> I also posted a pull request for the remaining v18 request API patches for mchehab to review.
[12:11] <sailus> Albeit there's still work left to be done on the V4L2 fwnode framework.
[12:11] <hverkuil> once I have a v9 cedrus driver on top of that I can make a pull request for that as well.
[12:12] <hverkuil> I will likely resume my mc properties work after that.
[12:13] <hverkuil> pinchartl: uvc probably needs some patches for the extended control handling since it's not using the control framework for that.
[12:13] <mchehab> hi all
[12:13] <mchehab> sorry, missed the alarm
[12:13] <hverkuil> It has to reject attempts to set controls to a request since it doesn't support that.
[12:14] * mchehab is reading backlogs
[12:14] <hverkuil> I need to check other drivers that still implement *_ext_ctrls themselves for the same thing.
[12:14] <pinchartl> hverkuil: for the request API ?
[12:14] <hverkuil> yes
[12:15] <mchehab> wouldn't be better to port uvc to use the framework?
[12:15] <hverkuil> pinchartl: as an aside: I'm fixing some outstanding v4l2-compliance fails in uvc. All corner cases, but I would really like an (almost) clean bill of health from v4l2-compliance for this important driver.
[12:16] <mchehab> using a different implementation is asking for problems and non-compliance issues
[12:16] <pinchartl> hverkuil: I agree with you. thank you for working on it
[12:16] <hverkuil> mchehab: we looked at that in the past, it's very hard to do and requires a partial rewrite of the driver. As long as there are still old drivers that do not use the control framework it's not worth it.
[12:17] <mchehab> what drivers don't use it?
[12:17] <pinchartl> mchehab: uvcvideo has special needs when it comes to controls, and it would require major changes to the control framework
[12:17] <sailus> pinchartl: What kind of changes?
[12:18] <hverkuil> pvrusb2 for one.
[12:18] <sailus> I.e. what makes it not work so well?
[12:18] <pinchartl> sailus: I'm afraid I don't remember
[12:18] <sailus> X-)
[12:18] <mchehab> it is probably not worth touching pvrusb2... it is just for one specific model that it is not sold anymore (well, there are new models, but the driver doesn't support and would require major changes at pvrusb2, as far as I'm aware)
[12:19] <hverkuil> Hmm, actually, there are fewer than expected: uvc, pvrusb2 and the staging radio-bcm2048.
[12:19] <mchehab> so, the only one that is not staging nor for obsolete hardware is UVC
[12:19] <hverkuil> ah, drivers/video/fbdev/matrox/matroxfb_base.c (weird one, I think it just reuses ioctl defines)
[12:20] <mchehab> matrox??? I wander who has a matrox GPU those days
[12:20] <sailus> mchehab: I do.
[12:20] <sailus> It's in the cellar...
[12:20] <hverkuil> sailus: of course you do!
[12:20] <sailus> I've never used that driver though.
[12:21] <hverkuil> I don't think it applies to this: they just hijacked V4L2 ioctls for a few things but otherwise do their own thing.
[12:21] <hverkuil> radio-bcm2048 can be converted (probably not that much work)
[12:21] <hverkuil> so that leaves pvrusb2 and uvc.
[12:22] *** ChanServ sets mode: +v mchehab`
[12:22] <mchehab`> yeah, radio drivers don't have weird control requirements... it should likely be easy to convert... anyway, it is a staging driver... nobody cares :-p
[12:22] <hverkuil> Now, I *hate* the pvrusb2 code, so from that perspective I would not mind at all if it is killed off. But it still works and I don't think we can drop it.
[12:23] <hverkuil> An alternative would be to do a massive refactor of that driver, ripping out all the nonsense abstraction layers, but that takes a lot of time.
[12:24] <hverkuil> I have been tempted in the past.
[12:24] <mkrufky> Did mike isely walk away?
[12:25] <hverkuil> Not sure. There has been no development, but hey, it works.
[12:25] <mkrufky> i think he's just been way busy, like me....
[12:25] <mchehab`> hverkuil, I don't care much about pvrusb2... too much to fix there
[12:25] <hverkuil> Like the ivtv driver: nothing is really needed to do.
[12:25] <mkrufky> but he is still the maintainer of that driver and im sure he will do what needs to be done (if it doesnt involve removing layers)
[12:26] <hverkuil> but it would removing layers. It is very hard to switch to the control framework in that driver, and it also exposes controls to sysfs which no-one else does.
[12:26] <hverkuil> That's not supported by the control framework.
[12:26] <hverkuil> It would never have been merged today in this form.
[12:26] <mchehab> mkrufky: we have hot discussions in the past with regards to it... he never wanted to make it follow coding style, remove absraction layers and use V4l frameworks
[12:26] <hverkuil> We've come a long way w.r.t. quality control since those times.
[12:27] <mkrufky> i remember it clearly
[12:27] <mchehab> anyway, I guess it is not worth the efforts... some day, we'll just move it to staging or drop it
[12:27] <mchehab> as it is for obsolete hardware anyway
[12:28] <mkrufky> i asked ken from hauppauge for one , needed it for (doesnt matter why) and he couldnt give me anybecause because there are literally zero inventory remaining
[12:28] <hverkuil> I'd say that when uvc starts to use the control framework, then that leaves pvrusb2 and at that moment you can say that it is blocking further development and move it to staging and kill it later.
[12:28] <hverkuil> mkrufky: if you want one, I can give you one in Edinburgh.
[12:28] <hverkuil> just let me know
[12:29] <mkrufky> no thank you, i dont actually need another.   i wanted a specific sku that wasnt supported
[12:29] <hverkuil> ah
[12:29] <mkrufky> but its gone
[12:30] <mkrufky> thanks though :-)
[12:31] <hverkuil> Anyway, converting uvc isn't easy to do. From what I remember from looking at it in the past it would require a substantial rework.
[12:31] <mchehab> perhaps something that we could add to a TODO list for people asking for tasks
[12:32] <mchehab> (although I believe that only experienced people would be able to do such task)
[12:33] <mchehab> anyway, I think it is worth investing time with UVC driver, as this won't be gone any time soon
[12:33] <pinchartl> if someone can come up with a sane way to do it, sure
[12:34] <mchehab> anyway, we're side-tracking... anything for discussion related to patch handling?
[12:35] <hverkuil> I added an entry to the projects list.
[12:35] <mchehab> thanks
[12:35] <pinchartl> mchehab: I've sent you a pull request for uvcvideo
[12:35] <pinchartl> using a signed tag
[12:35] <mchehab> from my side, I probably won't be merging patches today...
[12:35] <pinchartl> have your scripts picked it up ?
[12:36] <mchehab> I'm planning to do patch handling tomorrow or on Monday
[12:36] <mchehab> pinchartl: good!
[12:36] <mchehab> didn't test yet. Thanks for doing that!
[12:36] <mchehab> I'll check my scripts by the time I handle the uvcvideo patchset
[12:37] <hverkuil> pinchartl: I noticed the pull request for on drm  for the omap DSS rework. Is that merged yet? And is there more work to do done on top of that (huge!) series?
[12:38] <pinchartl> hverkuil: it hasn't been merged yet, and there will be more patches on top
[12:38] <hverkuil> mchehab: there are several m2m drivers that are close to being ready for merging. I hope I can make pull requests for 1 or 2 of those on Monday.
[12:40] <mchehab> good
[12:40] <mchehab> please let me know if those depend on request_API or not
[12:40] <hverkuil> none do. Only the cedrus driver does (waiting for v9)
[12:41] <hverkuil> l -lrt
[12:41] <hverkuil> oops
[12:41] <mchehab> perhaps you could add something at the [GIT PULL] to indicate that they're for the topic branch
[12:41] <hverkuil> I've already done so for the post-v18 patch series
[12:41] <mchehab> OK!
[12:41] <hverkuil> will do the same for the cedrus driver.
[12:42] <hverkuil> I think v9 will be the one that can be merged.
[12:43] <mchehab> ok
[12:45] <hverkuil> got nothing else.