Linux-Media Archive on
 help / color / Atom feed
From: Hans Verkuil <>
To: Tomasz Figa <>, Sakari Ailus <>
Cc: Linux Media Mailing List <>,
	Alexandre Courbot <>,
	Laurent Pinchart <>,
	Jacopo Mondi <>
Subject: Re: [ANN] Topics for a media summit in Lyon in October
Date: Fri, 16 Aug 2019 10:31:09 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On 8/16/19 10:22 AM, Tomasz Figa wrote:
> On Fri, Aug 16, 2019 at 5:10 PM Hans Verkuil <> 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 <>
>>> Tomasz Figa <>
>>> Jacopo Mondi <>
>>> Laurent Pinchart <>
>>> Hans Verkuil <>
>>> 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.



> 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

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  8:06 Hans Verkuil
2019-08-16  8:10 ` Hans Verkuil
2019-08-16  8:22   ` Tomasz Figa
2019-08-16  8:31     ` Hans Verkuil [this message]
2019-08-16  9:37 ` Mauro Carvalho Chehab
2019-08-19  7:44 ` Hans Verkuil
2019-08-19 14:43   ` Ezequiel Garcia
2019-08-19 15:04     ` Laurent Pinchart
2019-08-19 15:24       ` Eugen.Hristev
2019-08-19 15:51         ` Laurent Pinchart

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Media Archive on

Archives are clonable:
	git clone --mirror linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ \
	public-inbox-index linux-media

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox