date:20050217

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

2005-02-17 Thread Bukie Mabayoje

I can't look into this problem tonight I will be able to see if I can help you 
tomorrow.

If you need to use your laptop without the external crt, use the vesa driver 
for now.

Nqnsome wrote:

> Hi,
>
> Can someone help me, please!?
>
> I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci):
>
> :00:02.0 VGA compatible controller: Intel Corp. 82852/855GM
> Integrated Graphics Device (rev 02)
> :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
> Graphics Device (rev 02)
>
> I read all material on the net about the memory/vbios problems with this
> chipset. I do not think I have this problem because I can change the
> memory allocated to the graphics card in the BIOS setup program, and the
> XFree output reflects these changes.
>
> I have tried all kinds of patchs, all the latest XFree versions
> available (including 4.4.0), several distros (FC1, FC2, Mandrake 10 and
> now, Debian unstable), the IBM driver, asked the dealer and manufacturer
> for a BIOS update, but my LCD never reaches 1024x768 (only 800x600 and
> 640x480). Actually, a few months ago, I gave out trying to make the LCD
> work under 1024x768, after all this dozens of failed trials.
>
> I am getting back to this because I just find out that, if I connect a
> external CRT monitor (actually a Samsung SyncMaster 700p) to the CRT out
> of my laptop, 1024x768 works on it! I am completely puzzled. If XFree
> can make the external monitor works on 1024x768, why it can not do the
> same with the LCD?
>
> I was told that my graphics chipset has a vbios problem that prevents
> Xfree from recognizing its ability to work under 1024x768, but, if this
> is true, why that external CRT works under 1024x768?
>
> I must note that under WinXP the LCD works on 1024x768 and that the XiG
> X server can also do the same.
>
> Now that it is clear that Xfree can produce 1024x768 with my chipset and
> my LCD supports 1024x768, how can I force Xfree to try 1024x768 on the LCD?
>
> My XF86Config-4 can be found here:
>
> http://paginas.terra.com.br/educacao/nqnsome/xf86config.txt
>
> The XFree output can be found here:
>
> http://paginas.terra.com.br/educacao/nqnsome/xfree_output.txt
>
> I am really sorry for my bad English.
>
> Thanks a lot for your assistance.
>
> Regards,
>
> Sergio
> ___
> XFree86 mailing list
> XFree86@XFree86.Org
> http://XFree86.Org/mailman/listinfo/xfree86
>
> ___
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005
>
> ___
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

To submit graphics driver supporting for XGI Volari V5, V8, and Z7

2005-02-17 Thread Jong Lin









Hi there,

 

Per marketing’s strong demand, we plan to
release source code of 2D, Video modules of Volari V5, V8, and Z7

for XFree86 4.4.0 in the near feature. According to
description of XFree86.Org, we just need to submit the source code to [EMAIL PROTECTED]. Is it right? I was wondering if we need to
do precedent preparation before submitting to

[EMAIL PROTECTED]. By the way, is there any
example or format to prepare source code for submitting to

[EMAIL PROTECTED]?

Re: Modeline behavior changed (broken)?

2005-02-17 Thread Mark Vojkovich

On Thu, 17 Feb 2005, David Dawes wrote:
> On Thu, Feb 17, 2005 at 10:52:33AM -0800, Mark Vojkovich wrote:
> >
> >   I think the priority should be:  Section "Monitor", EDID, builtin.
> >But it appears that it's EDID, Section "Monitor", builtin.
>
> Yes, I agree that the modes specified explicitly in the Monitor section
> should have first priority.  The attached patch prevents EDID modes matching
> Monitor section modes from being added to the pool, much the same way as
> happens already for the built-in default/VESA modes.
>
> Let me know how it goes.

   With the patch, it works as I expect it to.


Mark.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

External CRT works on 1024x768 but LCD not. Please Help!!!

2005-02-17 Thread Nqnsome

Hi,
Can someone help me, please!?
I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci):
:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM
Integrated Graphics Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
I read all material on the net about the memory/vbios problems with this
chipset. I do not think I have this problem because I can change the
memory allocated to the graphics card in the BIOS setup program, and the
XFree output reflects these changes.
I have tried all kinds of patchs, all the latest XFree versions
available (including 4.4.0), several distros (FC1, FC2, Mandrake 10 and
now, Debian unstable), the IBM driver, asked the dealer and manufacturer
for a BIOS update, but my LCD never reaches 1024x768 (only 800x600 and
640x480). Actually, a few months ago, I gave out trying to make the LCD
work under 1024x768, after all this dozens of failed trials.
I am getting back to this because I just find out that, if I connect a
external CRT monitor (actually a Samsung SyncMaster 700p) to the CRT out
of my laptop, 1024x768 works on it! I am completely puzzled. If XFree
can make the external monitor works on 1024x768, why it can not do the
same with the LCD?
I was told that my graphics chipset has a vbios problem that prevents
Xfree from recognizing its ability to work under 1024x768, but, if this
is true, why that external CRT works under 1024x768?
I must note that under WinXP the LCD works on 1024x768 and that the XiG
X server can also do the same.
Now that it is clear that Xfree can produce 1024x768 with my chipset and
my LCD supports 1024x768, how can I force Xfree to try 1024x768 on the LCD?
My XF86Config-4 can be found here:
http://paginas.terra.com.br/educacao/nqnsome/xf86config.txt
The XFree output can be found here:
http://paginas.terra.com.br/educacao/nqnsome/xfree_output.txt
I am really sorry for my bad English.
Thanks a lot for your assistance.
Regards,
Sergio
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

External CRT works on 1024x768 but LCD not. Please Help!!!

2005-02-17 Thread SLCB

Hi,
Can someone help me, please!?
I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci):
:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM
Integrated Graphics Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
I read all material on the net about the memory/vbios problems with this
chipset. I do not think I have this problem because I can change the
memory allocated to the graphics card in the BIOS setup program, and the
XFree output reflects these changes.
I have tried all kinds of patchs, all the latest XFree versions
available (including 4.4.0), several distros (FC1, FC2, Mandrake 10 and
now, Debian unstable), the IBM driver, asked the dealer and manufacturer
for a BIOS update, but my LCD never reaches 1024x768 (only 800x600 and
640x480). Actually, a few months ago, I gave out trying to make the LCD
work under 1024x768, after all this dozens of failed trials.
I am getting back to this because I just find out that, if I connect a
external CRT monitor (actually a Samsung SyncMaster 700p) to the CRT out
of my laptop, 1024x768 works on it! I am completely puzzled. If XFree
can make the external monitor works on 1024x768, why it can not do the
same with the LCD?
I was told that my graphics chipset has a vbios problem that prevents
Xfree from recognizing its ability to work under 1024x768, but, if this
is true, why that external CRT works under 1024x768?
I must note that under WinXP the LCD works on 1024x768 and that the XiG
X server can also do the same.
Now that it is clear that Xfree can produce 1024x768 with my chipset and
my LCD supports 1024x768, how can I force Xfree to try 1024x768 on the LCD?
My XF86Config-4 can be found here:
http://paginas.terra.com.br/educacao/nqnsome/xf86config.txt
The XFree output can be found here:
http://paginas.terra.com.br/educacao/nqnsome/xfree_output.txt
I am really sorry for my bad English.
Thanks a lot for your assistance.
Regards,
Sergio
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Modeline behavior changed (broken)?

2005-02-17 Thread David Dawes

On Thu, Feb 17, 2005 at 10:52:33AM -0800, Mark Vojkovich wrote:
>On Wed, 16 Feb 2005, David Dawes wrote:
>
>> On Wed, Feb 16, 2005 at 06:07:43PM -0800, Mark Vojkovich wrote:
>> >   It used to be that if you specified a modeline, say "1600x1200" in
>> >the XF86Config file, that modeline would take preference over any
>> >internal modelines of the same name.  This no longer appears to be
>> >the case.  If I have a "1600x1200" modeline in the XF86Config file,
>> >it no longer gets used, but another mode instead (I presume the
>> >internal mode).  I have to name my mode to something else in order
>> >to use it.
>> >
>> >   It seems like the server was changed to ignore modes placed
>> >in the monitor section if they conflict with internal modes.  Was
>> >this change intentional?
>>
>> It works correctly for me.  If explicitly provided modes are not
>> overriding the default modes then it is a bug.  Can you send your
>> log file?
>
>   It appears that what's happening is modes from the monitor's
>edid take precedence over Section "Monitor" overrides.  I specified
>mode "1600x1200" in my SubSection "Display" Modes.  I provided a custom
>modeline in the Section "Monitor":
>
># 1600x1200 @ 79.1 Hz, 98.9 kHz
>   Modeline  "1600x1200" 213.6 1600 1664 1856 2160 1200 1201 1204 1250
>
>but the monitor is reporting 86 Hz, 106 kHz.
>
>(**) NV(0): *Preferred EDID mode "1600x1200": 230.0 MHz, 106.5 kHz, 85.2 Hz

Adding the EDID modes to the set is part of the recent autoconfig enhancements.

>  ...
>
>(**) NV(0):  Mode "1600x1200": 213.6 MHz, 98.9 kHz, 79.1 Hz
>(II) NV(0): Modeline "1600x1200"  213.60  1600 1664 1856 2160  1200 1201 1204 
>1250
>
>   I think the priority should be:  Section "Monitor", EDID, builtin.
>But it appears that it's EDID, Section "Monitor", builtin.

Yes, I agree that the modes specified explicitly in the Monitor section
should have first priority.  The attached patch prevents EDID modes matching
Monitor section modes from being added to the pool, much the same way as
happens already for the built-in default/VESA modes.

Let me know how it goes.

David
Index: xf86Mode.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Mode.c,v
retrieving revision 1.75
diff -u -r1.75 xf86Mode.c
--- xf86Mode.c  17 Feb 2005 03:46:48 -  1.75
+++ xf86Mode.c  17 Feb 2005 21:47:19 -
@@ -1241,10 +1241,6 @@
 return MODE_OK;
 }
 
-#ifndef MODENAMESIZE
-#define MODENAMESIZE (4 + 1 + 4 + 1)
-#endif
-
 /*
  * xf86ValidateModes
  *
@@ -1494,29 +1490,45 @@
hmax = h;
 
if (!haveEDIDModes) {
-   new = xnfcalloc(1, sizeof(DisplayModeRec));
-   new->type = M_T_DEFAULT | M_T_EDID;
-   new->Clock = dt->clock / 1000;
-   new->HDisplay = dt->h_active;
-   new->HSyncStart = new->HDisplay + dt->h_sync_off;
-   new->HSyncEnd = new->HSyncStart + dt->h_sync_width;
-   new->HTotal = new->HDisplay + dt->h_blanking;
-   new->VDisplay = dt->v_active;
-   new->VSyncStart = new->VDisplay + dt->v_sync_off;
-   new->VSyncEnd = new->VSyncStart + dt->v_sync_width;
-   new->VTotal = new->VDisplay + dt->v_blanking;
-   new->name = xnfalloc(MODENAMESIZE);
-   snprintf(new->name, MODENAMESIZE, "%dx%d",
-new->HDisplay, new->VDisplay);
-   if (firstPreferred && firstDetailed) {
-   new->type |= M_T_PREFER;
-   preferredName = new->name;
+   char *newName = NULL;
+
+   xasprintf(&newName, "%dx%d",
+ dt->h_active, dt->v_active);
+   if (newName && !xf86ModeIsPresent(newName,
+ monitor->Modes,
+ 0, M_T_DEFAULT)) {
+   new = xcalloc(1, sizeof(DisplayModeRec));
+   if (new) {
+   new->type = M_T_DEFAULT | M_T_EDID;
+   new->Clock = dt->clock / 1000;
+   new->HDisplay = dt->h_active;
+   new->HSyncStart = new->HDisplay +
+   dt->h_sync_off;
+   new->HSyncEnd = new->HSyncStart +
+   dt->h_sync_width;
+   new->HTotal = new->HDisplay + dt->h_blanking;
+   new->VDisplay = dt->v_active;
+   new->VSyncStart = new->VDisplay +
+   dt->v_sync_off;
+

Re: Modeline behavior changed (broken)?

2005-02-17 Thread Mark Vojkovich

On Wed, 16 Feb 2005, David Dawes wrote:

> On Wed, Feb 16, 2005 at 06:07:43PM -0800, Mark Vojkovich wrote:
> >   It used to be that if you specified a modeline, say "1600x1200" in
> >the XF86Config file, that modeline would take preference over any
> >internal modelines of the same name.  This no longer appears to be
> >the case.  If I have a "1600x1200" modeline in the XF86Config file,
> >it no longer gets used, but another mode instead (I presume the
> >internal mode).  I have to name my mode to something else in order
> >to use it.
> >
> >   It seems like the server was changed to ignore modes placed
> >in the monitor section if they conflict with internal modes.  Was
> >this change intentional?
>
> It works correctly for me.  If explicitly provided modes are not
> overriding the default modes then it is a bug.  Can you send your
> log file?

   It appears that what's happening is modes from the monitor's
edid take precedence over Section "Monitor" overrides.  I specified
mode "1600x1200" in my SubSection "Display" Modes.  I provided a custom
modeline in the Section "Monitor":

# 1600x1200 @ 79.1 Hz, 98.9 kHz
   Modeline  "1600x1200" 213.6 1600 1664 1856 2160 1200 1201 1204 1250

but the monitor is reporting 86 Hz, 106 kHz.

(**) NV(0): *Preferred EDID mode "1600x1200": 230.0 MHz, 106.5 kHz, 85.2 Hz

  ...

(**) NV(0):  Mode "1600x1200": 213.6 MHz, 98.9 kHz, 79.1 Hz
(II) NV(0): Modeline "1600x1200"  213.60  1600 1664 1856 2160  1200 1201 1204 
1250

   I think the priority should be:  Section "Monitor", EDID, builtin.
But it appears that it's EDID, Section "Monitor", builtin.


Mark.



___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Thighs thinner

2005-02-17 Thread Scot Rubio

Lose Weight: http://b's.clikonline.info

Try B0dy Wrap to burn off those inches.
Can't fit into those jeans anymore? Well try Body Wra.p!
B0dy [EMAIL PROTECTED] will decrease your fat and help you fit those new jeans!
Burn up the fat in those hard to reach places..
While cleansing it will rejuvenate your body while reducing inches.

Lose Weight: http://brother.clikonline.info  _Copy and paste the Website into 
your 
WebBrowser..
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

To submit graphics driver supporting for XGI Volari V5, V8, and Z7

Re: Modeline behavior changed (broken)?

External CRT works on 1024x768 but LCD not. Please Help!!!

External CRT works on 1024x768 but LCD not. Please Help!!!

Re: Modeline behavior changed (broken)?

Re: Modeline behavior changed (broken)?

Thighs thinner

8 matches

Site Navigation

Mail list logo

Footer information