Adam Jackson a...@redhat.com writes:
On Mon, 2015-07-27 at 13:29 -0700, Eric Anholt wrote:
It's clearly derived from fb/fb24_32.c. But I'm not sure where
things would have switched from SuSE to keithp.
It does make me wonder why we don't just use fb's CopyArea to do the
job, though.
On Mon, 2015-07-27 at 13:29 -0700, Eric Anholt wrote:
It's clearly derived from fb/fb24_32.c. But I'm not sure where
things would have switched from SuSE to keithp.
It does make me wonder why we don't just use fb's CopyArea to do the
job, though.
shadow's not really set up that way in
Matt Turner matts...@gmail.com writes:
On Wed, Jul 22, 2015 at 9:14 AM, Adam Jackson a...@redhat.com wrote:
From: Dave Airlie airl...@redhat.com
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
On Wed, Jul 22, 2015 at 9:14 AM, Adam Jackson a...@redhat.com wrote:
From: Dave Airlie airl...@redhat.com
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
chips, the hardware can't do 32bpp at all.
From: Dave Airlie airl...@redhat.com
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
chips, the hardware can't do 32bpp at all. It's better to just allocate
a 32bpp shadow and downconvert in the upload
On Wed, Jul 22, 2015 at 12:14 PM, Adam Jackson a...@redhat.com wrote:
From: Dave Airlie airl...@redhat.com
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
chips, the hardware can't do 32bpp at all.
