Re: [PATCH] pxafb: Add support for other palette formats

From: Paulo Marques <pmarques@grupopie.com>
To: "Hans-Jürgen Koch" <hjk@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-fbdev-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [PATCH] pxafb: Add support for other palette formats
Date: Tue, 03 Jul 2007 19:18:40 +0100	[thread overview]
Message-ID: <468A9300.7060608@grupopie.com> (raw)
In-Reply-To: <200707031944.21467.hjk@linutronix.de>

Hans-Jürgen Koch wrote:
> Am Dienstag 03 Juli 2007 19:21 schrieb Paulo Marques:
>> [...]
>> I don't see this as a good reason not to implement 18bpp support in 
>> fbcon. "Just PXA270 18bpp devices" can be a lot of devices out there.
> 
> I guess most hardware developers will connect their LCD with only
> 16-bit, use RGB565, and are happy with that. It's a pity that this
> requires a physically different wiring of the LCD.

Yes, this is not an option for me or all the OpenEZX users/developers 
with 18bpp phones :(

>> Anyway, can fbcon work with 18bpp palette mode? If it does, then this 
>> should be enough for most users of 18bpp pxafb users: have a console 
>> with a palette mode and then switch to non-palette mode and run whatever 
>> windowing system supports 18bpp.
> 
> I need to run gtk-directfb, and I'd be surprised if libcairo could handle
> that...

I wouldn't be so surprised... at least the documentation of DirectFB has 
this:

   DFBSurfacePixelFormat:
      ....
      DSPF_RGB18 ->  6 bit RGB (3 byte/ red 6@16, green 6@6, blue 6@0)
      ....

I assume the "red 6@16" is a typo for "red 6@12", since the "3 byte / 
green 6@6 and blue 6@0" match exactly the 18bpp packed format. Even 
more, the "DSPF_ARGB6666" format is described as having "alpha 6@18" and 
"red 6@16" which is of course impossible. It only makes sense as "red 6@12".

So maybe this is supposed to work with DirectFB...

>> I guess that even if it doesn't support 18bpp palette mode now, it 
>> shouldn't be that hard to implement (nor should it cause that much bloat 
>> to fbcon).
> 
> fbcon is not the big problem. But there's a lot of userspace stuff out there
> where they create graphics in their own buffers and blit it into the 
> framebuffer when ready. Most of them are definitely not prepared to support
> this format.

If we can't provide a 18bpp pxafb kernel driver, then there is *no* 
userspace stuff that will be able to work.

At least "some userspace" will be better than "no userspace". And we can 
always use the power of open-source to bring 18bpp support to those apps 
that don't support it currently ;)

-- 
Paulo Marques - www.grupopie.com

"The Computer made me do it."

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php