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