Hi James and others,

I've been playing with trying to get something which uses fb_monspecs
put together. The patch is littered with FIXME, TODO and debugging cruft
but it seems to work for the two panels I have bothered to put in the
LCD DB. If the general approach is satisfactory for you I will look at
tidying it up and making everything work properly. I'm not sure about
the aesthetics physical_interface stuff in fb_monspecs but that can be
changed as you wish. Perhaps a ->type field + a union to cover
MONITOR/TFT/STN in a space efficient manner?? I'm not sure what sort of
API/ABI guarentees are being made for fb_monspecs and fb_videomode at
this time.

I couldn't find suitable places for a few settings. They are commented
in fb.h (and hardcoded for now in pxafb). The settings are the bit depth
and some color map stuff.

I'm not happy with the way the fb_videomode and the fb_monspecs are
separated in lcddb.c. I'm not sure if there is syntax in C to allow me
to put the pointer to fb_videomode inline in the fb_monspecs
declaration. Perhaps I will define a datatype fb_lcd_info which is
roughly the same as the commented out stuff in
include/asm-arm/arch-pxa/pxafb.h and have fb_lcd_lookup construct the
fb_monspec with dynamically allocated fb_videomode from that (which
might be best anyway, since other code looks like it might expect the
modedb to be dynamically allocated).

My only thought is that having done that, perhaps it makes sense to
dispense with the fb_monspecs stuff and have drivers use fb_lcd_info
directly. What does using fb_monspecs gain us over this scenario? 

Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.  Email to and from Arcom is automatically monitored for operational and lawful business reasons.

This message has been checked for all viruses by MessageLabs Virus Control Centre.