public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Hans Verkuil <hansverk@cisco.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Tomasz Stanislawski <t.stanislaws@samsung.com>,
	linux-media@vger.kernel.org, m.szyprowski@samsung.com,
	kyungmin.park@samsung.com,
	sakari.ailus@maxwell.research.nokia.com
Subject: Re: [PATCH 0/2] V4L: Extended crop/compose API
Date: Wed, 18 May 2011 15:03:13 +0200	[thread overview]
Message-ID: <4DD3C391.3060407@samsung.com> (raw)
In-Reply-To: <201105181431.59580.hansverk@cisco.com>

On 05/18/2011 02:31 PM, Hans Verkuil wrote:
> On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote:
>> On 05/16/2011 09:21 AM, Laurent Pinchart wrote:
>> > On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote:
>> >> On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote:
>> >>> On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote:
>> >>>> On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote:
>> >
> 
>> > [snip]
>> ...
> 
>> >>>>> * resolution of an image combined with support for
> 
>> >>>>> VIDIOC_S_MULTISELECTION
> 
>> >>>>>
> 
>> >>>>> allows to pass a triple format/crop/compose sizes in a single
> 
>> >>>>> ioctl
> 
>> >>>>
> 
>> >>>> I don't believe S_MULTISELECTION will solve anything. Specific
> 
>> >>>> use-cases perhaps, but not the general problem of setting up a
> 
>> >>>> pipeline. I feel another brainstorm session coming to solve that. We
> 
>> >>>> never came to a solution for it in Warsaw.
> 
>> >>>
> 
>> >>> Pipelines are configured on subdev nodes, not on video nodes, so I'm also
> 
>> >>> unsure whether multiselection support would really be useful.
> 
>> >>>
> 
>> >>> If we decide to implement multiselection support, we might as well use
> 
>> >>> that only. We would need a multiselection target bitmask, so selection
> 
>> >>> targets should all be < 32.
> 
>> >>>
> 
>> >>> Thinking some more about it, does it make sense to set both crop and
> 
>> >>> compose on a single video device node (not talking about mem-to-mem,
> 
>> >>> where you use the type to multiplex input/output devices on the same
> 
>> >>> node) ? If so, what would the use cases be ?
> 
>>
> 
>> I can't think of any, one either use crop or compose.
> 
> 
> I can: you crop in the video receiver and compose it into a larger buffer.
> 
> Actually quite a desirable feature.

Yes, right. Don't know why I imagined something different.
And we need it in Samsung capture capture interfaces as well. The H/W
is capable of cropping and composing with camera interface as a data source
similarly as it is done with memory buffers.


Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center

  parent reply	other threads:[~2011-05-18 13:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05  9:39 [PATCH 0/2] V4L: Extended crop/compose API Tomasz Stanislawski
2011-05-05  9:39 ` [PATCH 1/2] v4l: add support for extended " Tomasz Stanislawski
2011-05-05  9:39 ` [PATCH 2/2] v4l: simulate old crop API using " Tomasz Stanislawski
2011-05-09  6:23   ` Jonghun Han
2011-05-09 11:01     ` Tomasz Stanislawski
2011-05-07 11:52 ` [PATCH 0/2] V4L: Extended " Hans Verkuil
2011-05-13 12:43   ` Laurent Pinchart
2011-05-14 10:50     ` Hans Verkuil
2011-05-16  7:21       ` Laurent Pinchart
2011-05-18 12:06         ` Sylwester Nawrocki
     [not found]           ` <201105181431.59580.hansverk@cisco.com>
2011-05-18 13:03             ` Sylwester Nawrocki [this message]
2011-05-19 13:47               ` Laurent Pinchart
2011-05-19 14:05                 ` Marek Szyprowski
2011-05-19 14:06                 ` Tomasz Stanislawski
2011-05-19 14:12                   ` Laurent Pinchart
2011-05-19 13:45             ` Laurent Pinchart
2011-05-18 16:55         ` Tomasz Stanislawski
2011-05-19 15:50           ` Tomasz Stanislawski
2011-05-23 21:29           ` Laurent Pinchart
2011-05-24 12:28             ` Tomasz Stanislawski
2011-05-25 13:43               ` Laurent Pinchart
2011-05-25 16:03                 ` Tomasz Stanislawski
  -- strict thread matches above, loose matches on Subject: below --
2011-03-28 15:19 Tomasz Stanislawski
2011-03-29  6:58 ` Hans Verkuil
2011-03-29  9:22   ` Tomasz Stanislawski
2011-03-29  9:50     ` Hans Verkuil
2011-03-29 10:38       ` Tomasz Stanislawski
2011-04-05 14:00         ` Laurent Pinchart
2011-04-05 14:14           ` Tomasz Stanislawski

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=4DD3C391.3060407@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=hansverk@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=sakari.ailus@maxwell.research.nokia.com \
    --cc=t.stanislaws@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox