|
I'm not sure that this is necessarily the
case.
The dot clock used in XF86Config is never actually
used to directly calculate the dot clock that the Geode uses. The XFree86
Geode driver (geode_driver.c) basically selects the appropriate mode from a set
of modes provided in the Durango driver in gfx_disp. These
are:
320x200 @ 70Hz Doublescan
320x240 @ 75Hz Doublescan
400x300 @ 75Hz Doublescan
512x384 @ 75Hz Doublescan
640x400 @ 70Hz
640x480 @ 60Hz, 72Hz, 75Hz, 85Hz
800x600 @ 56Hz, 60Hz, 72Hz, 75Hz, 85Hz
1024x768@ 56Hz, 60Hz, 72Hz, 75Hz,
85Hz 1152x864 @ 75Hz
1280x1024 @60Hz, 75Hz, 85Hz
I don't believe that when using the above modes
(which I believe came from National's orignal driver source) that at any time
the dot clock actually goes into unsupported territory. The changes I was
suggesting simply allow a modeline to be specified in XF86Config that gets
translated to one of the above modes in the geode_driver.c code.
Ed
----- Original Message -----
Sent: Monday, December 09, 2002 3:40
PM
Subject: Re: [Xpert]Re: Geode driver
question
The minimum DOT clock for the Geode cores (GX1, SCxxx) is indeed 25.175 MHz
which limits our lowest official supported resolution to 640X480 @ 60
Hz. Unfortunately it's this middle region of display resolution that
isn't covered well as we have customers using either serial or PCI interfaces
driving lower resolutions displays, all the way down to 16 X 2 character LCD
displays. We can't really officially supports any resolutions that
require a DOT clock below the minimum specified.
As a side note, the DOT clock has been used as low as 12 Mhz but the PLL
controlling this clock becomes unstable at this limit.
To answer the question on source for the Geode driver we are making period
submissions to the XFree development community and as well continuing to
evolve the framebuffer driver internally as it contains the extra
functionality to control the video process functions of the SC1200 device
regards
bob m / nat semi IA apps
Ed Anuff <[EMAIL PROTECTED]> wrote: BR>> To:
<[EMAIL PROTECTED]>
> Sent: Sunday, December 08, 2002 10:47 PM
>
Subject: Geode driver question
>
>
> > I see from looking
at the source that the new Geode driver supports
> several
> >
modes such as 320x240 and 512x384 that I would like to make use of.
>
> Unfortunately, I've been unable to create a modeline that works
with
them.
> > Does anyone have the set of modelines that match
the resolutions
supported
> > by the new driver?
>
>
> > Thanks
> >
> > Ed
>
>
>
> _______________________________________________
>
Xpert mailing list
> [EMAIL PROTECTED]
>
http://XFree86.Org/mailman/listinfo/xpert
>
_______________________________________________
Xpert
mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Do you Yahoo!?
Additional
changes necessary to make this work:
In geode_driver.c:
Line 1414:
minPitch = 320;
Line 1445: PitchInc, 240, 1024,
Otherwise, you'll
be able to display the resolution, but it will always be
in virtual
screen with a minimum area of 640x480.
However, with the change put
in, you end up dealing with the notorious Geode
XF86Config Virtual entry
wierdness, where the Virtual entry needs to be set
to an odd setting like
"Virtual 513 384" or you get display problems.
Because of the Virtual
stangeness, I'm not sure whether these changes should
be added to the
driver in CVS, but this may be of use to others, especially
since the
Geode is often used in embedded PC's that need to display on
small
screens with lower resolutions.
Ed
----- Original
Message -----
From: "Ed Anuff" <[EMAIL PROTECTED]>
To:
<[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 10:38 AM
Subject:
[Xpert]Re: Geode driver question
> I think that I found the
problem. The minimun clock frequency in line 844
> of geode_driver.c
is too high to allow the lower resolutions to
be
accepted:
>
> static ClockRange GeodeClockRange = { NULL,
25175, 135000, 0, FALSE, TRUE,
> 1, 1, 0 };
>
> Changing
the minimum clock frequency to 1 solves the problem:
>
> static
ClockRange GeodeClockRange = { NULL, 1, 135000, 0, FALSE, TRUE,
1,
1,
> 0 };
>
> Clearly, this is not a valid lower
boundery, but it solves the problem,
and
> it looks like other
drivers are taking the same approach of setting a
> minimum of 0 or
1.
>
> Also, the HorizSync range in XF86Config will need to
allow a lower minimum
> value so something like 10-60 will be
necessary.
>
> Hope this helps others,
>
>
Ed
>
>
> ----- Original Message -----
> From: "Ed
Anuff" <[EMAIL PROTECTED]><Yahoo!
Mail Plus - Powerful. Affordable. Sign up
now
|
