Hello Andrej - thanks for your comments regarding the LCM register setup:<br><br>>I think you can change the framebuffer size to 240x320 but you will<br>>need to also increase the number of dummy pixels sent by the cpu's LCD<br>>Contoller to the LCM between the framebuffer border and the line end<br>>(this value even has a strange name like vertical porch and horizontal<br>>porch or something with porches) - so that the timing fits the values<br>>configured in the LCM. I don't know which of this values fbset will<br>>let you change.<br>><br>>The minimal "horizontal cycle" value in the LCM's specs is 520 clocks<br>>and minimum "vertical cycle" is 648 lines, so even if you've only got<br>>240 significant pixels in a line you need to arrange with fbset so<br>>that the LCDC sends 520 or more pixels per row. I guess this means<br>>that you won't get a better refresh rate because of lower resolution,<br>>but instead the DMA will perform
fewer RAM accesses, so stuff should<br>>work faster.<br>><br>>The registers you want to change are named VFP, VBP, HFP and HBP, and<br>>iiuc the horizontal framebuffer size + HFP + HBP sum must not change<br>>(or be >= 520) and height + VFP + VBP sum must also not change (or<br>>perhaps be >= 648) for the LCM to work.<br><br>I will make some more experiments along the lines you mention but I <br>already have a feeling its more complex than this.<br><br>I dont know what the LCM is doing when its in this 'QVGA mode' but i have <br>tried several combinations of output from the LCDC which give wierd results:<br><br>240x320 from LCDC : the width is fine (stretched to full screen)<br> vertically the screen is split in two and
the<br> top half of the 320 is stretched and repeated<br> in both (i think this is actually two frames<br> one in the top half another in the bottom)<br><br>240x640 from LCDC : the width is fine (stretched to full screen)<br> vertically we see the top half of the console<br> stretched over the whole screen
(320>640)<br> when running mplayer, its as if the whole<br> 640 vertical pixels are displayed correctly<br> (no vertical stretching)<br><br>480x320 from LCDC : this shows 'perfectly', width stretched across<br> whole screen, height perfect. Of course<br> there is the right half of the frame buffer
<br> which is not visible but is assumed to be<br> visible by fbcon etc.<br><br>480x640 from LCDC : this shows 'perfectly', width strecthed across<br> whole screen, height perfect. In this case<br> the top left quadrant of the framebuffer<br> is shown in qvga - the other 3 quadrants<br> are
invisible but still assumed to be there<br> by fbcon, mplayer, X etc.<br><br>I'll check further regarding the porch timings - all these <br>experiments were carried out without changing those timings,<br>just the data display.<br><br>But note: setting the LCDC to output something 'wierd' like<br>360x360 results in strange effects on the display - so somehow<br>it much know its being given 'valid pixels' rather than <br>'dead space' like the porches...<br>I think it might be counting valid pixels or something, i dont<br>think it is just relying on where hsync and vsync happen.<br><br>Is there any information available on the LCM at all?<br>I found this "data sheet" for a similar display but its not really that helpful: <br><font size="-1"><span class="a">http://utv.eastpoint.se/egdisplay/files/TD035STEE1.pdf<br><br></span></font>Regards<br><br>John<p> 
<hr size=1> <a href="http://us.rd.yahoo.com/evt=51201/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3MtbmV3Y2Fy
">Check out </a> the hottest 2008 models today at Yahoo! Autos.