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, 85Hz1152x864 @ 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 <BLOCKQUOTE dir=ltr > ----- Original Message ----- <DIV >From: bob martin To: <A title=xpert@xxxxxxxxxxx href="">xpert@xxxxxxxxxxx Cc: <A title=alanh@xxxxxxxxxxxxxxxxxxxx href="">alanh@xxxxxxxxxxxxxxxxxxxx Sent: Monday, December 09, 2002 3:40 PM Subject: Re: 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 <ed@xxxxxxxxx> wrote: BR>> To: > 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 withthem.> > Does anyone have the set of modelines that match the resolutionssupported> > by the new driver?> >> > Thanks> >> > Ed> >>> _______________________________________________> Xpert mailing list> Xpert@xxxxxxxxxxx> http://XFree86.Org/mailman/listinfo/xpert>_______________________________________________Xpert mailing listXpert@xxxxxxxxxxxxxxx://XFree86.Org/mailman/listinfo/xpert Do you Yahoo!? <BLOCKQUOTE >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 bein virtual screen with a minimum area of 640x480.However, with the change put in, you end up dealing with the notorious GeodeXF86Config Virtual entry wierdness, where the Virtual entry needs to be setto an odd setting like "Virtual 513 384" or you get display problems.Because of the Virtual stangeness, I'm not sure whether these changes shouldbe added to the driver in CVS, but this may be of use to others, especiallysince the Geode is often used in embedded PC's that need to display on smallscreens with lower resolutions.Ed----- Original Message -----From: "Ed Anuff" To: Sent: Monday, December 09, 2002 10:38 AMSubject: 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 beaccepted:>> 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" <<A href="">Yahoo! Mail Plus - Powerful. Affordable. <A href="">Sign up now