On Tue, 1 Mar 2011 13:31:19 -0800
Corbin Simpson wrote:
> I am slightly curious about this as well; I have a device with only YUV
> scanout and was considering KMS, but don't know what the best approach is.
The problem with hiding behind a fake RGB frame buffer is you've then
completely stuffed
On Tue, 1 Mar 2011 13:31:19 -0800
Corbin Simpson wrote:
> I am slightly curious about this as well; I have a device with only YUV
> scanout and was considering KMS, but don't know what the best approach is.
The problem with hiding behind a fake RGB frame buffer is you've then
completely stuffed
On Tue, Mar 1, 2011 at 09:25, Magnus Damm wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm wrote:
>>> Please ditch the SH_FB_YUV constant all together. No need to build
>>> some abstraction on top of a hackish interface. Just che
I am slightly curious about this as well; I have a device with only YUV
scanout and was considering KMS, but don't know what the best approach is.
At least one KMS driver, nouveau, has to wrap all accesses to its scanout
buffers on certain chipsets for tiling reasons, so the same strategy might
wo
I am slightly curious about this as well; I have a device with only YUV
scanout and was considering KMS, but don't know what the best approach is.
At least one KMS driver, nouveau, has to wrap all accesses to its scanout
buffers on certain chipsets for tiling reasons, so the same strategy might
wo
On Tue, Mar 1, 2011 at 09:25, Magnus Damm wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm wrote:
>>> Please ditch the SH_FB_YUV constant all together. No need to build
>>> some abstraction on top of a hackish interface. Just che
