Issues w/ Xorg 7.0, Dell L610, and i810 drivers

[Philip Prindeville]

Alan Hourihane wrote:
> On Tue, 2006-06-20 at 16:34 -0600, Philip Prindeville wrote:
>   
>> Alan Hourihane wrote:
>>     
>>> On Tue, 2006-06-20 at 15:36 -0600, Philip Prindeville wrote:
>>>   
>>>       
>>>> I'm using a Dell D610 to run FC5 (updated), and it has an i915GM controller,
>>>> which uses the i810 drivers...
>>>>
>>>> I can't seem to configure it correctly (I've attached the config I'm
>>>> using).  It seems to have two issues.
>>>>
>>>> (1) it probes for the monitor DDC sync values, which disagree with what I've
>>>>     explicitly configured, but looking at the Xorg.0.log file, it gives
>>>>     no indication of what the EDID actually said the values were (grrr... you
>>>>     can never have too much logging).
>>>>     
>>>>         
>>> You've actually specified "noddc" so it's not going to read the DDC
>>> information.
>>>   
>>>       
>> I've tried it both ways, and it doesn't seem to make any difference.
>>
>> And since it won't tell me what it thinks the sync-timings of the flat-panel
>> are, I can enter those manually into xorg.conf in the "Monitor" section.
>>     
>
> From what I can see it is detecting DDC and showing you the sync timings
> as well as using them.
>   

Well, then I'm confused.  It looked to me like it was detecting the DDC 
settings
from the DVI-attached monitor twice, rather than properly detecting the LFP
(do LFP's even speak DDC? I didn't think LVDS accommodated it).

I've seen other drivers (like the Via Unichrome driver) always detecting 
what
was on the first CRTC for the DDC settings, regardless of how many devices
were attached... so that it believed that the same type of monitor was 
attached
on all interfaces:  LVDS, DVI, VGA, S-video, etc.

Can anyone confirm that this has been fixed?

I've attached both the xorg.conf and the Xorg.0.log that I'm using 
currently.
The log file shows the DDC information for the LCD monitor being
repeated twice.  Putting:

Option "DDC" "no"

and uncommenting the timing values for Monitor0 just causes Monitor1 to come
up in 640x480 mode...  Not sure why.


>> I also can't tell if the built-in screen is LFP, and if it's on PipeA or 
>> PipeB,
>> etc...
>>     
>
> Again, according to the log, it certainly shows you it's an LFP on
> PipeB.
>
>   
>>>> (2) it then complains that "1400x1050" isn't a known modeline (no mode of
>>>>     this name), even though I've explicitly configured a modeline with that
>>>>     exact setting.
>>>>     
>>>>         
>>> Specifying a modeline with the i810 driver without a matching BIOS
>>> modeline is fruitless.
>>>   
>>>       
>> You'd think the BIOS would know the modeline for the native resolution
>> of the panel!
>>     
>
> You would, but this is a majorly common problem. Look at bug 643 on
> bugs.freedesktop.org to see.
>   

I spent an hour on the phone yesterday with Dell desktop/laptop support: 
they
said that it might indeed be a bug (it took 40 minutes to even locate 
someone who
knew what video BIOS was), but that they were "firewalled" from engineering
so they had no way of getting information back to the engineering 
department.

I said that this was odd, since normally customer input gets used to 
refine products
in successive generations, and in any case the customers would inherently be
able to test many more permutations of equipment together than even the Q/A
department with a huge budget.

He allowed that I was probably right, and said that if I posted on some 
Dell-related
(but not Dell-sponsored) forum, maybe one of the Dell engineers might 
notice the
posting and do something about it, but it was a long-shot.

This from the company that prides itself on support.

Oh, well.  He also allowed that even though the video BIOS might be broken,
the Windows drivers ignore what they find since they know better...  
therefore
it wasn't really broken.

Sigh.  How is MS software ever going to improve when all of their 
PC-manufacturing
partners are so eager to bend over and grab their ankles?  Don't answer 
that...
there's no happy answer...


>>> You should check out the program i915resolution to override one of your
>>> existing modes to the 1400x1050 mode. Given that your BIOS manufacturer
>>> neglected to add a 1400x1050 mode into the BIOS - this is currently your
>>> best route - unless you want to build the "modesetting" branch from git
>>> which programs the modes directly.
>>>
>>> Hope that helps,
>>>
>>> Alan.
>>>
>>>   
>>>       
>> I hate VBE.
>>
>> Grrr.
>>
>> Usually the Dell hardware is fairly solid.  Are we positive that there's no
>> VBE mode for 1400x1050?  I made some minor changes to the config...
>> now I'm not getting that warning any longer, but the local flat-panel is
>> coming up 1280x1024...  As if the settings for the two monitors were
>> backwards...
>>     
>
> Positive. No mode for 1400x1050 so use i915resolution, or the
> "modesetting" branch as I've mentioned.
>
> Alan.
>   

So... is there going to be an Xorg release that "throws the switch" and 
starts
using modesetting uniformly (hopefully in a modular way so that the code
doesn't get hideously duplicated)?

Anyway, I wrote an .rpm wrapper for 915resolution and put it up, and also
did a build for FC5:

ftp://ftp.redfish-solutions.com/pub/915resolution-0.5.2-1.i386.rpm
ftp://ftp.redfish-solutions.com/pub/915resolution-0.5.2-1.src.rpm

Hopefully Steve will pick this up and include it in future releases.

Once last thing I was thinking of doing, but wasn't sure on all the details,
is adding an /etc/rc.d/init.d/ wrapper to run 915resolution early in the
boot process (so that people using that abomination RHGB [Redhat Graphical
Boot] would be accommodated) on start-up...  Anyone have a link to a
howto on writing those?

I poked around on my own system but didn't find anything...

If I figure it out, I'll put up a new version of the .rpm's with an 
init.d script
included...

-Philip

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 103806 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060623/e52a1bec/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorg.conf
URL: <http://lists.x.org/archives/xorg/attachments/20060623/e52a1bec/attachment.ksh>