Hi Laurent,
On 12/13/2011 01:02 PM, Laurent Pinchart wrote:
> Hi everybody,
> fbdev: Add FOURCC-based format configuration API
> Here's the fifth version of the fbdev FOURCC-based format configuration API.
Applied this series.
Thanks and congratulations,
Florian Tob
OURCC mode (as additional safety barrier).
Best regards,
Florian Tobias Schandinat
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
urent Pinchart wrote:
>> On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
>>> Hi Laurent,
>>>
>>> On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
>>>> This API will be used to support YUV frame buffer formats in a standard
>>&g
zation for
‘cfag12864bfb_var.activate’)
make[2]: *** [drivers/auxdisplay/cfag12864bfb.o] Error 1
Any idea?
Best regards,
Florian Tobias Schandinat
>
> Last but not least, create a much needed fbdev API documentation and
> document the format setting APIs.
>
> Signed-off
k.
>
> Mauro, what's your preference ? Should the patch go through the media tree ?
> If so, how should we synchronize it with the fbdev tree ? Should I push it to
> 3.2 ?
ping
What's going on? I could carry the patch but I'd want an Ack to do so.
Best regards,
Hi all,
as there was no reaction to this patch series I am scheduling it for 3.3 merge
window (3.2 seems too close to me as this is an API change). As the second patch
has nothing to do with fbdev it should go mainline via V4L2. Any
problems/comments?
Best regards,
Florian Tobias Schandinat
Hi Laurent,
On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
>> Hi all,
>>
>> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>>> Just as a note, there are many drivers like m
ivers to implement FOURCC for formats that cannot be
represented in the old scheme. This is my preferred solution if anyone has
problems with (1).
I don't see how IOCTLs would help here. The pixel format just belongs into var
and fix so it has to be represented there anyway and thus set th
2;
> + if (cfg->fourcc == V4L2_PIX_FMT_NV12 ||
> + cfg->fourcc == V4L2_PIX_FMT_NV21)
> + info->fix.ypanstep = 2;
> +
> + if (sh_mobile_format_yuv(var))
> info->fix.line_length = var->xres;
> else
> - i
x27;fourcc' and not 'format'
as the other struct contains format information as well and who knows, maybe in
10 or 20 years we'll have yet another format description that can do things none
of the existing can do.
> + };
>
> __u32 nonstd; /* != 0 Non standard pixel format */
>
Thanks,
Florian Tobias Schandinat
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent,
On 07/31/2011 11:28 PM, Laurent Pinchart wrote:
Hi Florian,
Thanks for the feedback.
On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
As for struct
d cover all fields that are undefined/unused in FOURCC mode.
Hope we can find anything that everyone considers acceptable,
Florian Tobias Schandinat
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majo
On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
On Fri, Jun 24, 2011 at 08:19, Paul Mundt wrote:
On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
wrote:
On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
On Tuesday
cale and fourcc (avoid
unions where possible).
I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a FOURCC
mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very happy
with that, and proposed using the vmode field instead.
Given that there's vi
Hi Laurent,
On 05/23/2011 09:00 PM, Laurent Pinchart wrote:
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
- Other solutions are possible, such as adding new ioctls. Those
solutions are more intrusive, and require larger
for
the videomode. You could than reuse any RGB-specific field you like to pass more
information.
Maybe we should also use this chance to declare one of the fix_screeninfo
reserved fields to be used for capability flags or an API version as we can
assume that those are 0 (at least in sane dri
el for a long future and with a common library the same patch would not need
to be done 3 times but only once. Or even more often if drivers have there
private EDID implementation which I just throw out of mine to replace it later
with a common one.
Regards,
Florian Tobias Schandinat
--
To un
Guennadi Liakhovetski schrieb:
On Fri, 28 May 2010, Florian Tobias Schandinat wrote:
Well hiding complexity is actually the job of an API. I don't see any need for
major changes in fbdev for complex display setups. In most cases as a
userspace application you really don't want to b
to set them up on
module load time (as only limited runtime changes are permited given
that we must always be able to support a mode that we once entered
during runtime).
The thing that's really missing in fbdev is a way to allow hardware
acceleration for userspace.
Regards,
Florian T
19 matches
Mail list logo
