All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: video4linux-list@redhat.com
Subject: Re: [PATCH 3/3] soc-camera: let camera host drivers decide upon pixel format
Date: Sun, 09 Nov 2008 14:31:06 +0100	[thread overview]
Message-ID: <87prl5xbz9.fsf@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.0811091319540.4485@axis700.grange> (Guennadi Liakhovetski's message of "Sun\, 9 Nov 2008 13\:36\:14 +0100 \(CET\)")

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> Hi Robert,
> As I wrote in the comment to the patch, I think, lists of pixel formats, 
> supported by sensors are rather static, therefore they can be easily 
> represented by a list of structures, that's what our ->formats are about.  
> Now, the latest patch changes the logic in a way, that this list is now 
> what a sensor offers, and not what the user gets, requests to set a format 
> are now handled by camera hosts, so they decide how to implement the 
> requested format. Now, we are almost that far. What I've forgotten about 
> and why, probably, you decided we still don't do that, is that the 
> ->formats array is still used for format enumeration. It shall not be. So, 
> I'm going to write another patch, that would move format enumeration into 
> host drivers. To do that, we will probably have to create such a list 
> _dynamically_ in .add() method based on the ->formats list _and_ host's 
> capabilities. We might use the ->host_priv link, I suggested in my 
> previous email, to hold that list. It would be even better to not have to 
> create such a list and just enumerate formats dynamically in the host 
> driver, but I am not sure how to handle the index... I'll have to think 
> about it a bit more.
>
> Does this answer your question?
Yes, absolutely. That's the right direction. I'm looking forward to see the
incremental patch, as you may guess ;) My YUV work is over, I'm just waiting for
the soc_camera patchset to stabilize to fire my own serie.

I'll try to think about the fully dynamic formats list, even if I prefer the
computed list at sensor attachment.

--
Robert

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

      reply	other threads:[~2008-11-09 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-08 18:48 [PATCH 3/3] soc-camera: let camera host drivers decide upon pixel format Guennadi Liakhovetski
2008-11-09  0:47 ` Robert Jarzmik
2008-11-09 10:32   ` Guennadi Liakhovetski
2008-11-09 11:13   ` Robert Jarzmik
2008-11-09 12:36     ` Guennadi Liakhovetski
2008-11-09 13:31       ` Robert Jarzmik [this message]

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=87prl5xbz9.fsf@free.fr \
    --to=robert.jarzmik@free.fr \
    --cc=g.liakhovetski@gmx.de \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.