pxafb: RGBT555 support

[Eric Miao]

On Wed, Nov 4, 2009 at 5:28 PM, pieterg <pieterg at gmx.com> wrote:
> On Thursday 29 October 2009 12:35:55 pieterg wrote:
>> Great to see the 'recent' work on overlay support and color format fixes
>> in pxafb.c.
>> Looks like I no longer need my local patches.
>>
>> However, there is one thing that I cannot seem to accomplish just yet.
>> We have an LCD which is connected in an RGBT555 configuration.
>> That means somehow var->transp.length should be set to 1.
>> After that, it looks like pxafb_set_pxifmt should do its job just fine.
>>
>> Would it make sense to add transparency info to pxafb_mode_info?
>> After all it is a hardware property, with our LCD and the way it is
>> connected we won't be able to do RGB565, so our var->transp.length should
>> be fixed at 1.
>> If pxafb_setmode could do that, based on the pxafb_mode_info, that would
>> probably solve my problem.
>> Maybe something could be done by comparing 'depth' and 'bpp', if one is
>> 16 and the other 15, one could make the assumption the remaining bit is
>> used for transparency.
>>
>> Or am I overlooking something here, and is there a better way to force
>> pxafb to RGBT555 for my LCD?
>
> Sorry to ask again, but is there an official/preferred way to select RGBT555
> mode in pxafb, or should I just continue hacking it in for now?
>

Unfortunately, transparency is part of depth and it's really not easy to
distinguish between RGB565 and RGBT555 by depth and bits_per_pixel
only without introducing something else.