When I start X without describing my monitor in xorg.conf, I get an incorrect resolution and DPI (and xrandr is unable to reconfigure the resolution to match the monitor's native resolution). The most recent manifestation is with X server version 1.4.2-2 (from Debian sid) and driver version 2.3.2-2+lenny2 (which is a prerelease package which fixes a Debian-specific bug in 2.3.2-2+lenny1). With that combination of versions, accurately describing my hardware and not overriding anything will lead X to launch in 1280x768, with 96x96 DPI. The native resolution of my monitor is 1280x1024. I'll attach my config, log, and the output of xdpyinfo. I also discussed this in bug #11368, but Michael Fu told me to open a separate bug for this misbehavior.
Created attachment 18052 [details] xorg.conf
Created attachment 18053 [details] Xorg.0.log
Created attachment 18054 [details] Output of xdpyinfo
I should add that this hardware has a laptop display chipset, but is actually a small-form-factor PC (http://www.cappuccinopc.com/slimpro-sp625f.asp) without any LVDS display; the only monitor I care about is an LCD attached to the VGA output, and the only reason I became aware of the LVDS output at all was that it was interfering with my VGA monitor's resolution (hence my attempts to disable it, as you can see in xorg.conf above).
So the problem is why VGA monitor is recognized as 1280x768 (it should be 1280x1024), even LVDS interfere issue has been workarounded (LVDS has been disabled in xorg.conf, that'st the problem bug#11368 want to resolve). Andrew, to help us to understand why EDID doesn't work, please add below line in Device section of xorg.conf and attach the new log. Thanks. Option "ModeDebug" "yes"
Created attachment 18079 [details] xorg.0.log (with ModeDebug) Well, a perfect solution to bug #11368 would involve a quirk so that I don't have to disable LVDS in xorg.conf, but disabling LVDS is certainly better than nothing. I'm attaching a log with ModeDebug turned on. Thanks!
If I added the quirk, it will look strange, as your hardware use same subsystem/device id as pci device ids. And I don't know if other machine might be affected. So using option in config now. It looks driver can't get EDID from VGA, you may try two things. - generate a 1280x1024 modeline yourself, using cvt or gtf, and adding it into xorg.conf, then using Monitor's PreferredMode option to let xserver choose it. - try to change GPIO register in the end of src/i830_crt.c, try with other port like GPIOB/C/D/E, etc.
zhenyu, from this pic: http://www.cappuccinopc.com/solutions/options/multiple-coms.asp?show_menu=true&show_price=0 It seems that the VGA port is multiplexed in a DVI-I port. Could it be the same bug as our G45? Do you have patch to let Andrew try or other action to very this?
It looks like you're looking at http://www.cappuccinopc.com/Media/images/gallery/solutions/multiple-com/1-1.jpg which shows the Slimpro SP635; the machine I have is the Slimpro SP625F (picture at http://www.cappuccinopc.com/Media/images/gallery/solutions/multiple-com/2-1.jpg showing only VGA output). I don't understand any of the code, but I've tried just replacing GPIOA at the last line of i830_crt_init() with GPIOB, which didn't lead to any apparent change in behavior. I haven't had time yet to gather detailed information or try GPIOC or later values.
Andrew, please finish the experiment of GPIOB/C/D/E and confirm from log file that the change is in effect, then let us know whether there are any new findings. thanks.
lost connection with bug reporter...
No, you didn't lose the connection with the bug reporter; I'm just too busy to help you right now. The fact that I'm not helping you track down the problem does not mean that the bug is suddenly not a bug, although it may well mean that it's too much trouble to track down right at the moment. Reopening.
more than a month passed but we still didn't get useful information...please reopen only when you have required feedback, or we will still reject.
Reopening until this bug is believed fixed. See https://developer.mozilla.org/En/What_to_do_and_what_not_to_do_in_Bugzilla for documentation on the correct use of the "INVALID" resolution.
You've stated that you're simply going to "reject" the bug until I provide "required feedback", so I should expand: I've done my job as a bug reporter. I've filed a detailed bug describing the misbehavior, and I've provided logs and tried various things as requested. My responsibility as a bug reporter does _not_ extend to modifying code according to vague instructions and recompiling my X server. It's nice that I used to have time and inclination to do that sort of thing, but it doesn't suddenly invalidate my bug reports now that I'm not doing it anymore. You may come from a corporate environment where you have a certain amount of authority, so you may be unaccustomed to this sort of thing, but you're not in charge of this bug tracker. You do not get to define "INVALID" to mean what's convenient for you, or decide when bugs can be closed without being fixed. Please talk to the xorg bugzilla administrators or your contact in x.org if that's not your understanding. Cheers.
(In reply to comment #15) > You've stated that you're simply going to "reject" the bug until I provide > "required feedback", so I should expand: > > I've done my job as a bug reporter. I've filed a detailed bug describing the > misbehavior, and I've provided logs and tried various things as requested. My > responsibility as a bug reporter does _not_ extend to modifying code according > to vague instructions and recompiling my X server. It's nice that I used to > have time and inclination to do that sort of thing, but it doesn't suddenly > invalidate my bug reports now that I'm not doing it anymore. > > You may come from a corporate environment where you have a certain amount of > authority, so you may be unaccustomed to this sort of thing, but you're not in > charge of this bug tracker. You do not get to define "INVALID" to mean what's > convenient for you, or decide when bugs can be closed without being fixed. > Please talk to the xorg bugzilla administrators or your contact in x.org if > that's not your understanding. > > Cheers. > sorry, we have this rule. and I also stated clearly please only reopen when you have useful information.
So I got mad about the childishness of this continuing exchange and started to investigate this bug tonight as a constructive path forward. I don't know what it says about me that I have that reaction ("That guy is SO WRONG! I will do EXACTLY WHAT HE SAYS!"), but anyway: Jesse added a quirk for my machine to disable LVDS output (see bug #11368) which went into 2.5. That seems likely to change the behavior of this bug (if not solve it), because the behavior I saw was in a situation with erroneous detection of an LVDS output involved. This bug only cropped up when I rewrote my xorg.conf to be aware of an LVDS output. 2.5 is actually difficult for me to test, because Debian sid doesn't have a modern enough version of libdrm for me to compile 2.5. I could compile a modern libdrm by hand, but I'd rather not. So I'll reopen this bug, mark it NEEDINFO, and retest once Debian catches up and it's straightforward to investigate the behavior on 2.5. Is that an acceptable compromise?
OK. I think we can wait for another month. To be honest with you, I don't understand why you can't reopen this bug after you test.
Andrew, would you please attach your vbios rom? you can get it via: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom thanks.
I don't want to reopen after testing because that's not what you do with bugs. They get closed when they're believed fixed, or determined to be invalid, or it's been a year since the last contact with the bug submitter. You don't close a bug to indicate "there's nothing we're going to do about this for the next month or two." I'll attach the vbios rom.
Created attachment 20462 [details] VBIOS ROM
It seems your machine is using GPIOD for VGA DDC. Andrew, your problem is likely fixed by zhenyu in his patch 2f93cfbc7e96acc32efb5e1ca49b817a81cba6e3 on 19th, Sept, as a side-effect. Anyway, Please have a test and post your log with ModeDebug turns on. //one month counting down starts...:)
ping...
Where were you guys when I had a ton of free time? Back in 2007 I was answering questions about these bugs left and right, and there was no fixing and nothing for me to test. Now my car needs $2000 of repair, my business has busted heat and a basement filled with sewage, I'm speaking to a lawyer for reasons best left unspecified, my property tax is overdue, and my computer with an 855GM is no longer at my place of residence so I need to make a special trip. So naturally there are new versions to test now, and it has to be done SOON, unlike fixing the bugs in the first place when I reported them, back in 2007. Anyway, my month's not up yet, so there. P.S. My landlord's in Dubai.
I've retested with 2f93cfbc7e96acc32efb5e1ca49b817a81cba6e3, and X doesn't work at all. It brings up garbage on the screen and a non-working "X"-shaped cursor. I tried it in gdb from a remote session, and I got a black screen, with nothing pertinent-looking in gdb. I can't test master, unfortunately, because now that depends on libdrm 2.4.2 and Debian only has 2.4.1. Once Debian's libdrm catches up with master, I'll retest with master and see what happens (and file a bug if things still don't work at all).
(In reply to comment #25) > I've retested with 2f93cfbc7e96acc32efb5e1ca49b817a81cba6e3, and X doesn't work > at all. It brings up garbage on the screen and a non-working "X"-shaped > cursor. I tried it in gdb from a remote session, and I got a black screen, > with nothing pertinent-looking in gdb. > > I can't test master, unfortunately, because now that depends on libdrm 2.4.2 > and Debian only has 2.4.1. Once Debian's libdrm catches up with master, I'll > retest with master and see what happens (and file a bug if things still don't > work at all). > log with modedeubug on, please?
Created attachment 21316 [details] xorg.conf
Created attachment 21317 [details] xorg.0.log (with ModeDebug)
Does recent 2.6.1 work for you? How about assign a Modeline in xorg.conf and use that instead?
We have updated LVDS check in git master now with commit commit f6d8ae69b0f97e696c142f06c8038f336ed024f9 Author: Zhenyu Wang <zhenyu.z.wang@intel.com> Date: Wed Feb 25 09:57:00 2009 +0800 Use LVDS config in Driver feature BDB for integrated LVDS check The LVDS config bits in VBT driver feature block is used by vendor to identify the board implement of integrated LVDS/eDP or SDVO LVDS. And video bios uses these bits for LVDS enabling or not. So check these bits for integrated LVDS might eliminate more quirks. So please try it, if the issue still exists after testing, please reopen. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.