<div>at first, thanks for your best and detail replies. next, I have other issues to ask for you.</div>
<div> </div>
<div>my device uses geode lx processor (500MHZ) with 7" LCD display. at present, </div>
<div>I'm porting google android to my device. compile kernel 2.6.27 with geode lx frame buffer,</div>
<div>not the vesa framebuffer, one of the question found is that after</div>
<div>android booting, the display is blinking. it can obviously see the highlight horizontal line, </div>
<div>in the beginning, i think it maybe is related to vsync, but no matter whatever i adjust it to, it's no use. at the same</div>
<div>time, compile kernel with intelfb, then run android on PC with intel processor, the display </div>
<div>is very well. of course, the PC's intel processor (2.6G) is much faster than geode processor.</div>
<div>but it should not be the just reason, because android can run well on lower frequency smartphone.</div>
<div>since andoid uses openGL ES that i am not familiar with too much. but it seems to be much </div>
<div>related to the geode framebuffer.</div>
<div> </div>
<div>expect to get your professional hints or suggestion!<br><br></div>
<div class="gmail_quote">2009/4/29 Martin-Éric Racine <span dir="ltr"><<a href="mailto:q-funk@iki.fi">q-funk@iki.fi</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">As I recall, the only reason why some specific resolutions are in the<br>source code is because they are those that TFT output can only<br>
support. For VGA output, the driver should be capable of extrapolating<br>any arbitrary resolution that fits within its maximum clock pitch.<br>
<div>
<div></div>
<div class="h5"><br>On Tue, Apr 28, 2009 at 5:28 PM, John Yoder <<a href="mailto:john.yoder@twny.net">john.yoder@twny.net</a>> wrote:<br>> I apologize for not getting back to you sooner. To answer your earlier<br>
> question about adding a resolution that is currently not available, I<br>> would submit a patch, as I believe I can infer that you are using the<br>> VGA port rather then a direct connect to the panel connector. It<br>
> simplifies things a bit.<br>><br>> As I recall, the table entries are as follows:<br>> <name> <refresh,> <xres> <yres> <pixclock> <left_margin><br>> <right_margin> <upper_margin> <lower_margin> < hsync_length><br>
> <vsync_length> <sync> <vmode><br>> What is required are derived by calculation from modelines. So you will<br>> need to get a working custom modeline to start. Then some calculations.<br>> Lets start with an explanation of the fields:<br>
><br>> pixclock - pixel clock in pico seconds (I believe this is correct)<br>> left_margin - time from sync to picture<br>> right_margin - time from picture to sync<br>> upper_margin - time from sync to picture<br>
> lower_margin - time from picture to sync<br>> hsync_lenth - length of horizontal sync<br>> vsync_length - length of vertical sync<br>><br>> Modelines have the following fields<br>><br>> Modeline <name> <DCL> <HR> <HPS> <HPE> <HFL> <VR> <VPS> <VPE> <VFL><br>
><br>> Where:<br>> name - name assigned to mode<br>> DCL - Dot Clock (MHz)<br>> HR & VR - Horizontal and Vertical resolution<br>> HPS, HPE, VPS, VPE - Horizontal and Vertical Pulse Start and End<br>
> also known as Front and Back Porch<br>> HFL & VFL - Horizontal and Vertical Field Length<br>><br>> To get values that are required for these the calculations are as<br>> follows:<br>> left_margin = HFL - HPE<br>
> right_margin = HPS - HR<br>> hsync_length = HFE - HPS<br>><br>> upper_margin = VFL - VPE<br>> lower_margin = VPS - VR<br>> vsync_length = VPE - VPS<br>><br>> This should get you close. This information was pulled from memory and a<br>
> couple different sources.<br>> To get the custom modeline, I typically use<br>> <a href="http://xtiming.sourceforge.net/cgi-bin/xtiming.pl" target="_blank">http://xtiming.sourceforge.net/cgi-bin/xtiming.pl</a> to get a close<br>
> modeline. If this doesn't work, I check the log file to verify the DCL<br>> is within the range of the LX DCL. If it is and I get a black screen, I<br>> verify the other values like HFL & VFL then move around the Horizontal<br>
> and Vertical Sync Time in the above website. Waving a rubber chicken or<br>> other Voodoo incantations may help as well. :)<br>> I pulled this information from:<br>> <a href="http://ftp.utcluj.ro/pub/docs/how-to/mini-how-to/Modeline" target="_blank">http://ftp.utcluj.ro/pub/docs/how-to/mini-how-to/Modeline</a><br>
> <a href="http://tldp.org/HOWTO/Framebuffer-HOWTO-18.html" target="_blank">http://tldp.org/HOWTO/Framebuffer-HOWTO-18.html</a><br>><br>> For further reading on the subject of how Xorg get the timings:<br>> <a href="http://en.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/" target="_blank">http://en.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/</a><br>
><br>> I hope this helps.<br>><br>> Best Regards,<br>><br>> John Yoder<br>><br>> On Tue, 2009-04-28 at 10:51 +0800, wan michael wrote:<br>>> in the file drivers/video/geode/lxfb_core.c<br>>><br>
>> static struct fb_videomode geode_modedb[] __initdata = {<br>>> /* 640x480-60 */<br>>> { NULL, 60, 640, 480, 39682, 48, 8, 25, 2, 88, 2,<br>>> FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,<br>
>> FB_VMODE_NONINTERLACED, 0 },<br>>> ......<br>>> }<br>>><br>>> now i want to add the mode of 800x480, but how to calculate these<br>>> values. such as<br>>> 800x480-60, 800x480-70, 800x480-72, 800x480-80, 80x480-85, and so on.<br>
>> it is the case of changing the refresh frequency, what is the<br>>> calculation?<br>>><br>>><br>>> 2009/4/26 wan michael <<a href="mailto:michalwan@gmail.com">michalwan@gmail.com</a>><br>
>> is it possible to be standard modeline like 800X600 through<br>>> adding 800x480 into geode driver, not just the custom modeline<br>>> in the xorg.conf ?<br>>><br>>><br>
>> another question, like 7" LCD display, they are commonly used<br>>> in the embedded device, like MID or handheld device, the most<br>>> resolution is 800x480. not like common PC, which can provide<br>
>> much more higher resolution than 7" LCD display, such as<br>>> 1024X768, and so on. So, when used for PC, it always selects<br>>> the best resolution, and it can not do that for the embedded<br>
>> device, for the reason of 7" LCD display supporting the most<br>>> high resolution is 800X480, if both of them can not match<br>>> well, the display will not be normal. so is there one way to<br>
>> automatically match them, adapting to 800X480, not the higher?<br>>><br>>><br>>> 2009/4/24 John Yoder <<a href="mailto:jtyoder@twny.net">jtyoder@twny.net</a>><br>>><br>
>> On Wed, 2009-04-22 at 14:20 +0800, wan michael wrote:<br>>><br>>><br>>> > hi<br>>> ><br>>> > can the geode driver provide the mode 800x480? if<br>
>> > so, it can meet the 7' LCD display which is 800x480,<br>>> > and not the standard modes on pc.<br>>> ><br>>> ><br>
>> > _______________________________________________<br>>> > Xorg-driver-geode mailing list<br>>> > <a href="mailto:Xorg-driver-geode@lists.x.org">Xorg-driver-geode@lists.x.org</a><br>
>> > <a href="http://lists.x.org/mailman/listinfo/xorg-driver-geode" target="_blank">http://lists.x.org/mailman/listinfo/xorg-driver-geode</a><br>>> It should be able to provide the 800x480 mode.<br>
>> However, that will require a custom modeline in the<br>>> xorg.cong. I would use one of the modeline calculators<br>>> as a starting point. Whenever I need to provide custom<br>
>> modelines it takes a bit to get the dot clock<br>>> frequency of the LX and Monitor to be correct, but not<br>>> typically much of a problem.<br>>><br>
>> Best Regards,<br>>><br>>> John Yoder<br>>><br>>><br>><br>><br>> _______________________________________________<br>> Xorg-driver-geode mailing list<br>
> <a href="mailto:Xorg-driver-geode@lists.x.org">Xorg-driver-geode@lists.x.org</a><br>> <a href="http://lists.x.org/mailman/listinfo/xorg-driver-geode" target="_blank">http://lists.x.org/mailman/listinfo/xorg-driver-geode</a><br>
><br></div></div></blockquote></div><br>