On 11/23/2013 10:04 PM, Benjamin Herrenschmidt wrote:
On Sat, 2013-11-23 at 18:38 +0100, Cedric Le Goater wrote:
So, 32bpp works but 16 is broken ... I guess my palette fix is just a lucky
hack and I need to dig deeper in fb code to have a better understanding of
the color map.
I should
On 11/21/2013 08:57 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-11-21 at 16:45 +0100, Cedric Le Goater wrote:
- fbdev *generally* assume native endian framebuffer, but of course
under qemu today, the adapter will use a big endian frame buffer
aperture. You can compile in support for
On Sat, 2013-11-23 at 18:38 +0100, Cedric Le Goater wrote:
So, 32bpp works but 16 is broken ... I guess my palette fix is just a lucky
hack and I need to dig deeper in fb code to have a better understanding of
the color map.
I should have provided you two patches in the first place. Do you
On Thu, 2013-11-21 at 16:45 +0100, Cedric Le Goater wrote:
- fbdev *generally* assume native endian framebuffer, but of course
under qemu today, the adapter will use a big endian frame buffer
aperture. You can compile in support for foreign endian but I don't know
how that actually works.
Hi,
On 11/20/2013 11:50 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-10-31 at 10:36 +0100, Cédric Le Goater wrote:
The screen properties : depth, width, height, linebytes need
to be converted to the host endian order when read from the device
tree.
Signed-off-by: Cédric Le Goater
On Thu, 2013-10-31 at 10:36 +0100, Cédric Le Goater wrote:
The screen properties : depth, width, height, linebytes need
to be converted to the host endian order when read from the device
tree.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
Did you actually test that ? IE, using
The screen properties : depth, width, height, linebytes need
to be converted to the host endian order when read from the device
tree.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
Changes in v2:
- replaced be32_to_cpu() by be32_to_cpup()
- fixed setcolreg ops
drivers/video/offb.c |
