On 8/16/19 10:22 AM, Tomasz Figa wrote:
> On Fri, Aug 16, 2019 at 5:10 PM Hans Verkuil <hverk...@xs4all.nl> 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 <acour...@chromium.org>
>>> Tomasz Figa <tf...@chromium.org>
>>> Jacopo Mondi <jac...@jmondi.org>
>>> Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>>> Hans Verkuil <hverk...@xs4all.nl>
>>>
>>> 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
>>>
>>
