Hi everyone,

On 11 July 2018 at 09:33, Daniel Stone <[email protected]> wrote:
> Hi,
> On Wed, 11 Jul 2018 at 09:16, Pekka Paalanen <[email protected]> wrote:
>> On Tue, 10 Jul 2018 17:53:15 +0200 Emilio Pozuelo Monfort 
>> <[email protected]> wrote:
>> > No need to write libdrm driver specific code for each supported
>> > driver, we can just let GBM call the right one for us now.
>> >
>> > Signed-off-by: Emilio Pozuelo Monfort <[email protected]>
>> > ---
>> >
>> > Hi,
>> >
>> > This simplifies the code a lot, using gbm_bo as Emil suggested. Some 
>> > problems
>> > I still see:
>> >
>> > - NV12 doesn't work, it seems that 
>> > backends/dri/gbm_dri.c:gbm_format_to_dri_format()
>> >   doesn't support it.
>>
>> I think NV12 and other less common formats, should someone add them in
>> this program, should not be lost. That may be part of the reason GBM
>> wasn't used: the need to test YUV formats, and non-GPU-renderable
>> formats in general.
>
> Honestly, most of the reason was because I wrote the original client
> in about 15 minutes on a very short bus trip. You can probably see
> that in comments like 'XXX: would be nice to draw something that
> changes here'. So I don't think you can really read too much into the
> original code.
>
> Other great reasons include:
>   - we wanted to explicitly get modifiers allocated, and this was
> before the GBM modifiers interface existed
>   - at the time, I was doing bring-up of a GBM implementation which
> wasn't usable by generic clients (privileged allocation only)
>   - YUV format support
>
> I'm pretty ambivalent about it though. V4L2 and Vivid might well cover
> the YUV case well enough, and even if not, GBM should still be able to
> allocate R/RG buffers.
>
Darn, I did not spot NV12 in weston. Mesa is perfectly capable of
using YUV formats, so it should be a matter of adding the odd GBM
bits.

That said, it might be more involving than what you have time for, so
feel free to put this patch on hold.

Thanks
Emil
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to