On 8/16/19 10:22 AM, Tomasz Figa wrote: > On Fri, Aug 16, 2019 at 5:10 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> On 8/16/19 10:06 AM, Hans Verkuil wrote: >>> Rather then discussing topics for a meeting under the subject 'Lisbon' >>> let's start a new thread referring to the right place :-) >>> >>> I will try to organize a room, either during the ELCE or (if that doesn't >>> work) perhaps on the Thursday afterwards. If that's going to be a problem >>> for someone, please let me know. >>> >>> I do need to know how many people I can expect. I have the following >>> confirmed attendees (and please reply if you are not listed!): >>> >>> Alexandre Courbot <acourbot@xxxxxxxxxxxx> >>> Tomasz Figa <tfiga@xxxxxxxxxxxx> >>> Jacopo Mondi <jacopo@xxxxxxxxxx> >>> Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> >>> Hans Verkuil <hverkuil@xxxxxxxxx> >>> >>> I know there were more who mentioned on irc that they would attend, >>> but it is easier to keep track if I have it in an email. >>> >>> Topics posted under the previous thread: >>> >>> Tomasz: >>> >>> I would want to discuss various v4l2_buffer improvements, e.g. >>> - DMA-buf import with plane offsets, >>> - unifying the buffer structs for M and non-M formats, >>> - ability to import different FDs with offsets for non-M formats if the >>> layout matches driver expectations, etc. >>> >>> Besides that, I would be interested in the general idea on handling >>> complex cameras in the Linux kernel in spite of the remaining V4L2 >>> limitations, e.g. >>> - combinatorial explosion of /dev/video nodes, >>> - significant ioctl overhead, >>> - huge amount of historical legacy making the driver and userspace >>> implementations overly difficult and prone to repetitive mistakes, >>> - the above also limiting the flexibility of the API - formats, frame >>> rates, etc. set using distinct APIs, not covered by Request API, with >>> non-failure "negotiation hell", etc. >>> - lack of fences, etc. >> >> Tomasz, I am not sure if this is suitable for a media summit: my feeling >> is that this is much more suitable for a three day brainstorming session. >> >> My 'roadmap' was to get the codec support sorted first, then start working >> on this. > > I mostly dumped the topics I had in my head, leaving out the codecs as > the obvious thing that people are already planning to talk about. > > That said, there's been more interest in having proper Linux drivers > for camera capture IFs and ISPs and also a lot of feedback about the > issues I listed above. I'm afraid that if we don't start looking into > them early enough, we're going to end up in the same state as with > codecs where we're few years too late or even in the worst case just > the interest fading away. :( I agree that this shouldn't wait too long. And my view is that we should start working on this later this year. I suspect that I should be able to spend time on this in 1-2 months since it looks like the codec work should be mostly complete by then. Regards, Hans > > I guess we could try to organize a separate session on another day for > this, though. +Sakari Ailus who might be also interested in this. > > Best regards, > Tomasz > >> >> Regards, >> >> Hans >> >>> >>> Jacopo: >>> >>> Apart from discussing libcamera and hope we could kickstart a review of >>> its API, I would like to re-start discussing multiplexed stream support, >>> but that would require Sakari to be there, something I'm not certain >>> about. Sakari? >>> >>> Alexandre: >>> >>> If Collabora/Bootlin is there, I'd certainly want to discuss stateless >>> codecs, in particular m2m codec helpers and finalize the specification >>> in general. >>> >>> Regards, >>> >>> Hans >>> >>
