[i945G] Samsung TV not detected on VGA output (no screens)

[Jordi Puigsegur]

Binary package hint: xserver-xorg-video-intel

After upgrading from Ubuntu Hardy to Intrepid Xserver stopped working. Then upgraded to Jaunty to see if the new driver version solved the problem, it didn't.

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

The computer is connected to a Samsung 27" TV via VGA output.

Forcing vesa driver on xorg.conf makes the xserver work again but with slow refresh and wrong resolutions. With hardy it worked perfectly!

If you need more information or anything else, just ask.

Thanks in advance.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-intel 2:2.6.3-0ubuntu9
ProcEnviron:
 LANG=ca_ES.UTF-8@valencia
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.28-11-generic i686

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
 Subsystem: ASUSTeK Computer Inc. Device [1043:817a]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
 Subsystem: ASUSTeK Computer Inc. Device [1043:817a]

[Geir Ove Myhr (gomyhr)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The logs that were uploaded to this bug report are both for when you are using the VESA driver. Could you change the driver in xorg.conf to "intel" and upload the resulting Xorg.0.log (even though it crashes).

[Jordi Puigsegur (jordi-puigsegur)]

Attached you can find the xorg log file when trying to stat x without forcing vesa driver.

[Geir Ove Myhr (gomyhr)]

Jordi, a crash is what happens when a program performs an illegal operation and is terminated by the operating system. In your case this is not what happens, so I have removed the crash tag and changed the title. What happens (see bottom of the last Xorg.0.log) is that the driver doesn't detect anything on the VGA connector, gets a bit confused and says "no screens" (because it doesn't know where to display an image) and the exits gracefully.

I have a few more questions:
1. What is the exact model of your Samsung TV?
2. Exactly how is it connected to the computer? Is there a VGA cable attaching them directly or are there any adapters involved?

And I would ask you to try the following:
3. Try the 2.7.1 driver from the x-updates personal private archive (PPA) at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates . Is the bug fixed there?
4. If it isn't, could you add the line
  Option "ModeDebug" "true"
to the "Device" section of your xorg.conf, log out and in again and attach the resulting Xorg.0.log here. The ModeDebug option should give some more information about what the driver is up to.

If you are ready for some hard-core testing, you may also try the xorg-edgers PPA which have the very newest drivers from the development tree. This has a higher chance of breaking something, but if you don't mind reinstalling afterwards it should be fine. https://launchpad.net/~xorg-edgers/+archive/ppa

[Jordi Puigsegur (jordi-puigsegur)]

1. The TV is a Samsung LE27S7

2. It is connected via direct VGA cable without any converter. It worked perfectly using Hardy and haven't changed any wiring.

3. I just installed the 2.7.1 driver from the x-updates ppa and it failed with the same no screens message.

4. Since it didn't work, I activated the mode debug as suggested and attach the log file.

Didn't have time today to try more things...

[Geir Ove Myhr (gomyhr)]

Thank you for the additional information. A few more questions:
1. You say this worked in Hardy. Did you use the "i810" legacy driver that was available in Hardy, or did it also work with the "intel" driver? If you don't remember, it would be nice if you could test a Hardy LiveCD and upload the Xorg.0.log here.
2. Do you have the possibility to attach another monitor to the VGA connector and see if it works? This should tell us if it is something particular with the TV that triggers this or if it is a generic problem with driver and your VGA adapter.
3. It would be interesting to see if the monitor is detected using other programs than xorg. Could you try `sudo get-edid >edid.bin 2>get-edid-errors.txt` and upload the files here? (edid.bin is binary, but if the monitor isn't detected it will be empty) You will need the read-edid package for this. Another program that does this is ddcprobe (run `sudo ddcprobe` and attach the output here). This is in the package xresprobe.

With the above questions answered, I think this bug is ready to be forwarded to the intel developers. If you want to give the xorg-edgers repository a try, I would wait until you have done that and create the upstream bug report with the logs from that release. If not, it is okay to forward it with the current information. However, you may be asked to test the latest development version later to test any proposed fixes. So this gives the final question:
4. Do you want to test xorg-edgers version before we send this upstream?

[Jordi Puigsegur (jordi-puigsegur)]

1. Didn-t use any specific configuration, therefore I suppose I was using intel driver. I attach xorg.0.log file after booting from live Ubuntu Hardy, which now I can confirm works properly.

[Jordi Puigsegur (jordi-puigsegur)]

3. get-edid does detect the monitor. I attach the two files.

[Jordi Puigsegur (jordi-puigsegur)]

3-b. I attach the result of ddcprobe

[Jordi Puigsegur (jordi-puigsegur)]

I'll try a different screen and also will install the latest drivers, but probably not today. Even if Jaunty works I'll probably format the PC and install it from scratch. At least that way I'll get ext4 and a clean installation. Too many upgrades (from Gutsy).

[Geir Ove Myhr (gomyhr)]

Thank you for the updated information. I'll hold off upstreaming until you get around to do the final testing.

It's interesting to see that ddcprobe and get-edid reads the edid information just fine. I thought one of the tests the driver does for detecting the presence of a monitor is to check for EDID information (i830_crt_detect_ddc() in http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/i830_crt.c).

[Jordi Puigsegur (jordi-puigsegur)]

2. I plugged another monitor (Eizo CRT) and didn't work with Intel driver (It worked with vesa driver). I attach the xorg.0.log file.

[Jordi Puigsegur (jordi-puigsegur)]

Just tried to install the edgers drivers on a live Cd but didn't work. So far I still need the machine running and do not want to destroy it yet :-) Maybe it would be better if you just submit the bug upstream. Later if necessary I will install newer drivers. Thanks.

[Geir Ove Myhr (gomyhr)]

I will file a bug report upstream. Not sure when I'll get the time, but probably within a few days (I have a couple of other things that I have to give priority). I will then ask you to subscribe to the upstream bug.

It was interesting to see that the bug wasn't triggered by that particular Samsung TV. I thought that was most likely. Could you describe your computer?

[Geir Ove Myhr (gomyhr)]

One more thing you could try: it has happened that setting
  AccelMethod "uxa"
has mysteriously fixed some bug that I really don't understand how that could fix. Since this will be the default for the upcoming versions it would be nice if you could verify that it does not change anything, when using the 2.7.1 driver.

I have put together a text file with the basic info for the upstream bug report, so I should be able to file it upstream tomorrow if I get the computer model and this verification.

[Geir Ove Myhr (gomyhr)]

Created an attachment (id=26303)
xorg.conf

I'm forwarding a bug from an ubuntu user:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/379157

Bug description:

On a Asus Mini Barebone (Pundit P3-PH4C SK775 DDR2) with 945G chipset, the monitor connected on the VGA port is not detected and the X server therefore exits with "Fatal server error: no screens found". Normally a Samsung TV (LE27S7) is connected via a VGA cable, but also when an Eizo CRT was connected, it is not detected. Both get-edid and ddcprobe is able to read the EDID of the monitor. When using the vesa driver it works normally.

It used to work in ubuntu 8.04 (which has intel driver 2.2.1), but stopped working in 8.10 (with driver version 2.4.1). It has been tested and found not to work in 2.7.1. While the default AccelMethod for ubuntu packages (including 2.7.1) is EXA, it has also been tested with UXA without working.

System environment:
-- chipset: 945G
-- system architecture: 32-bit
-- xf86-video-intel: 2.7.1
-- xserver: 1.6.0-0ubuntu14
-- mesa: 7.4-0ubuntu3
-- libdrm: 2.4.5-0ubuntu4
-- kernel: 2.6.28-11-generic
-- Linux distribution: Ubuntu 9.04 (Jaunty)
-- Machine or mobo model: ASUS PUNDIT P3-PH4C SK775 DDR2
-- Display connector: VGA

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
 Subsystem: ASUSTeK Computer Inc. Device [1043:817a]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
 Subsystem: ASUSTeK Computer Inc. Device [1043:817a]

Reproducing steps:
start computer

[Geir Ove Myhr (gomyhr)]

Created an attachment (id=26304)
Xorg.0.log with ModeDebug using the 2.7.1 driver

[Geir Ove Myhr (gomyhr)]

Created an attachment (id=26305)
Xorg.0.log from driver version 2.2.1

[Jordi Puigsegur (jordi-puigsegur)]

I tried also with uxa acceleration, but as expected didn't work.

The computer is an ASUS Mini Barebone (with an integrated intel graphics card):

* MINI BAREBONE INTEL CORE2 DUO ASUS PUNDIT P3-PH4C SK775 DDR2
* CPU INTEL CELERON 2.8 GHZ SK775
* MEMORY 1 GB DDR2 667 KINGSTON
* HD 160 GB SATA2 SEAGATE 7200 8MB
* DVD 16X ASUS
* WIRELESS KEYBOARD AND WIRELESS OPTICAL MOUSE LOGITECH EX110

Jordi.

[Geir Ove Myhr (gomyhr)]

I have forwarded the bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=22002 .
Please subscribe to the upstream bug report, so you can answer any questions the intel developers might have. Please identify yourself as the original reporter when you do.

If they are asking you to try something that you don't know how to do, you may ask here and we'll do our best to help (I'm also following the upstream bug report).

[Jordi Puigsegur (jordi-puigsegur)]

I'm the original user who submitted the bug in launchpad. I'll be glad to test anything you might need to test. I plan to re-format the machine, but still will wait several weeks.

[Jordi Puigsegur (jordi-puigsegur)]

I've subscribed to the upstream bug.

Thanks,
Jordi.

[Ling-ma (ling-ma)]

Created an attachment (id=26346)
please try the patch on your machine. thanks

[Michael Fu (michael-fu-intel)]

It's surprising to know that 2.2.1 works for you but 2.4.1 doesn't . git diff shows that there is really no difference on the crt detection code between these two releases. hmm..

[Michael Fu (michael-fu-intel)]

I speak too fast..seems that Ubuntu has cherry picked more patches against upstream..

https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel

Maybe 7b6f4d22211d71480caf6335a3eacaacff369371 cause this?

[Jordi Puigsegur (jordi-puigsegur)]

How do I have to proceed to try the patch?

Thanks,
Jordi.

[Geir Ove Myhr (gomyhr)]

Jordi, we will figure out the details about how to add the patch in the dowstream report (to keep noise down here).

Ling, can we try the patch against 2.7.1, or do we have to get git-master to test?

[Ling-ma (ling-ma)]

(In reply to comment #8)
> Jordi, we will figure out the details about how to add the patch in the
> dowstream report (to keep noise down here).
> Ling, can we try the patch against 2.7.1, or do we have to get git-master to
> test?

yes, you can try the patch against 2.7.1.

I also can not find any differnece between 2.2.1 and 2.4.1.
Because we have no hardware, would you please like to do git bisec to find which patch caused the regression between two versions

Michael mentioned 7b6f4d22211d71480caf6335a3eacaacff369371 ?

Thanks for your help.
Ma Ling

[Michael Fu (michael-fu-intel)]

(In reply to comment #9)
> (In reply to comment #8)
> > Jordi, we will figure out the details about how to add the patch in the
> > dowstream report (to keep noise down here).
> > Ling, can we try the patch against 2.7.1, or do we have to get git-master to
> > test?
>
> yes, you can try the patch against 2.7.1.
>
> I also can not find any differnece between 2.2.1 and 2.4.1.
> Because we have no hardware, would you please like to do git bisec to find
> which patch caused the regression between two versions
>
> Michael mentioned 7b6f4d22211d71480caf6335a3eacaacff369371 ?
>
> Thanks for your help.
> Ma Ling
>

yes, Ubuntu didn't just take our original 2.4.1 release, but cheery picked more in post-2.4.1 master, such as the commit 7b6f.. I think. check out the link I posted in comment# 6...

[Michael Fu (michael-fu-intel)]

(In reply to comment #7)
> How do I have to proceed to try the patch?
>
> Thanks,
> Jordi.
>

Jordi, could you try to check out 2.4.1 from freedesktop upstream repository and see if it works for your system? this may help us narrow the issue down because from upstream change log, 2.2.1 and 2.4.1 really makes no different on CRT detection. if upstream 2.4.1 works for you, then it should be the patch cherry picked by Ubuntu from our post-2.4 release.

[Geir Ove Myhr (gomyhr)]

Assuming that we may patch the 2.7.1 driver installed and the
x-updates entries in /etc/apt/sources.list (from
https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/) , this is
how to do it (the ubuntu/debian way):

1. Install some essential stuff to build packages `sudo apt-get
install build-essential`
2. Install the packages that xserver-xorg-video-intel needs to build:
`sudo apt-get build-dep xserver-xorg-video-intel`
3. (Optional) Make a subdirectory for the source code `mkdir
intel-testing; cd intel-testing`
4. Get the source package xserver-xorg-video-intel `apt-get source
xorg-server-video-intel`. This will download the package (a tar.gz
file and a .diff file) and create a new directory with the source code
called xserver-xorg-video-intel-2.7.1.
5. `cd xserver-xorg-video-intel-2.7.1`
6. Apply the patch with `patch -p1 </path/to/0001-vga-hotplug.patch`
7. Build the binary packages with `debuild -b -us -uc`. This should
produce two binary packages (.deb files) in the parent directory.
xserver-xorg-video-intel and xserver-xorg-video-intel-dbg.
8. Install the packages with `dpkg -i xorg-xserver-video-intel*.deb`

Whether it works or not, please upload the Xorg.0.log from this to the
upstream bug report. Make sure you still have ModeDebug enabled.

If you get stuck at some point, you may ask for help here.

[Jordi Puigsegur (jordi-puigsegur)]

Thanks Geir,

It'll probably take me some time to do all this, so you'll have to wait during the weekend...
In the meantime I see that there is another update on the upstream bug:

> Jordi, could you try to check out 2.4.1 from freedesktop upstream repository
> and see if it works for your system? this may help us narrow the issue down
> because from upstream change log, 2.2.1 and 2.4.1 really makes no different on
> CRT detection. if upstream 2.4.1 works for you, then it should be the patch
> cherry picked by Ubuntu from our post-2.4 release.

Would that be easier? How would I do that? Do I need to install a live CD Hardy and install some debian package ... ?

What should I do first?

[Geir Ove Myhr (gomyhr)]

I have seen the upstream comments, but I don't know yet...

I'll see if I can make some binary packages from 2.4.1 that you can
test, but I'm not awfully familiar with the packaging process, so it
will take me some time too... I think 2.4.1 should work alright on
Jaunty (I know some people downgrade to it because of performance
regressions). I will try to build and test a version without patches
applied on Jaunty, and then you may either get deb-packages from me,
or I'll give you the steps for how to do it. I guess I should set up
my own PPA at some point.

For testing the upstream patch, the list I posted above should be
fairly straightforward. Unless something goes wrong, you should be
able to go through that pretty quickly. Maybe you could do that,
report the result and Xorg.0.log (with ModeDebug) and say that we're
working on the rest?

[Jordi Puigsegur (jordi-puigsegur)]

Created an attachment (id=26407)
xorg.0.log with ModeDebug using 2.7.1 driver with patch provided

[Jordi Puigsegur (jordi-puigsegur)]

Just tried the patch provided (comment #4) and it doesn't work. I attached the Xorg.0.log file with debug option activated. Now we are working on checking 2.4.1 from freedesktop upstream repository.

Thanks, Jordi.

[Geir Ove Myhr (gomyhr)]

I see you added the results upstream - great! Too bad it didn't work.

I tried to build 2.4.1 on Jaunty and it didn't work straight away. I think we should be able to use the 2.4.1 driver from Reinahart Tartler, though (https://launchpad.net/~siretart/+archive/ppa). It includes the patch that is the potential problem, and I just have to figure out exactly what to remove to build a similar .deb without the patch. Then we would have a pair of nearly identical packages where hopefully one should work and the other shouldn't (given that the potentially problematic patch is the real problem).

[Jordi Puigsegur (jordi-puigsegur)]

Hi Geir,

Just tried Reinhart Tartler 2.4 from ppa and doesn't work either. I attach the log.

Jordi.

[Geir Ove Myhr (gomyhr)]

The 2.4.1 driver from git (well, really from http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.1.tar.gz) but I guess that would be the same) didn't compile properly on Ubuntu 9.04 (Jaunty). Instead I took the ubuntu package from https://launchpad.net/~siretart/+archive/ppa which is the same as the Intrepid (8.10) package but with a couple of extra patches to make it compile on Jaunty. I then disabled the patch 22_no_pipe_for_hotplug_detection.patch which is exactly the 7b6f... commit mentioned above. I hope that provides an equally good test case as your unpatched 2.4.1 would. If the deb-package with the patch disabled works for Jordi, it should be clear that 7b6f... is the problem.

[Geir Ove Myhr (gomyhr)]

> Just tried Reinhart Tartler 2.4 from ppa and doesn't work either. I
> attach the log.

Good. That was what I expected, since the 2.4.1 from that PPA contains
the patch from post-2.4.1. What would be good news, is if we could
revert the patch in question from that package and it would then work.
From browsing through the logs of the ubuntu -intel packages (linked
to from the upstream bug report), it looks like the problematic patch
came in through the script that starts with 22- (don't remember the
name right now, it is located in debian/patches in the source
package). What I'm not sure about is wheather disabling that patch or
just changing it is the right thing to do. I will hopefully have time
to look at it tomorrow.

If you want to give it a try with disabling it, you can do that by
commenting it out in the "series" file in the debian/patches directory
(if I remember the file name correctly - it's the only file there
which is not a patch). The way to go would be basically the same as
when you built 2.7.1. If you don't get the 2.4.1 source package with
apt-get source, you may download it (there are 3 files *orig.tar.gz,
*.diff.gz and *.dsc) from the PPA page and use dpkg-source -x to
unpack it the way apt-get source would do. If these instructions are
too vague, you may wait until I have had the time to look closer into
it.

[Geir Ove Myhr (gomyhr)]

Have you had the chance to get the logs with the package in the PPA yet?

[Jordi Puigsegur (jordi-puigsegur)]

Last weekend I tried to set up a boot USB stick but was not successfull. Have to check the creating procedure (used my laptop's Jaunty app. to create it) and/or maybe update the BIOS of the computer. Haven't had time during the week.

[Michael Fu (michael-fu-intel)]

Geir Ove Myhr , would you please help to ping Jordi to provide log after patch in comment# 25? thanks.

[Geir Ove Myhr (gomyhr)]

Jordi, upstream is pinging you about this...

I have noticed that my old computer (Dell Inspiron 8200 from 2002, 845GM chipset) does not boot from USB sticks. If your computer cannot boot from USB sticks either, it may be easier to use a LiveCD. It should not be a problem to use the xorg-edgers PPA from a LiveCD instead of a USB stick. You just have to download http://bazaar.launchpad.net/%7Exorg-edgers/xorg-server/xorg-pkg-tools/annotate/head%3A/xorg-edgers-live-test from within the live session instead of putting it on the USB stick.

[Bryce Harrington (bryce)]

Jordi, please test the patch upstream has produced for your bug and provide feedback on it. Geir's directions in the previous comment should help, but let us know if you have any difficulty doing this.

[Jordi Puigsegur (jordi-puigsegur)]

I first tried to use a live CD but didn't know how to reboot after the changes so I tried to use a boot USB stick but was not successful.

Since it might be a while until I am able to have a working USB stick I'll use a live CD ,but here I have doubts. I understand how I can install the patch in a live CD but I don't know how to test that the patch works. Before formatting I could just reboot the computer after every xorg.conf change and test everything but in a live CD I cannot reboot ... how do I test that the new X configuration works after installing? And how do I go back to a working conf. to submit the files?

Thanks,
Jordi.

[Geir Ove Myhr (gomyhr)]

With a LiveCD you lose all changes when you reboot, but you don't need to reboot to activate the changes[*]. It is sufficient to restart X, and you can do that by simply logging out (on a LiveCD you will be logged in again after 10 seconds IIRC). Alternatively, you can switch to a VT and do a `/etc/init.d/gdm restart`.

The easiest way to get the log files when your computer has a black screen is to ssh in from another computer. For that you need the computer to be connected via cable instead of wireless and you will need to `apt-get install openssh-server` and since it is a LiveCD you will need to set a password for the ubuntu user to be able to log in with `passwd`, or alternatively for the root user with `sudo passwd root`.

If you don't have another computer available to ssh from, you can also save the Xorg.0.log to a USB key. Before you restart X, insert the USB key and see where it gets mounted (should be /media/something). Then from a VT before you restart X, write `sleep 60; cp /var/log/Xorg.0.log /media/something` where you replace something with the appropriate directory. That should wait 60 seconds and copy the log file. If you restart X during those 60 seconds, a new Xorg.0.log will be created and despite your black screen you will get the log file on your USB stick.

[*] I remember you had some problems earlier that mysteriously went away when rebooting, but hopefully those won't show up now.

[Michael Fu (michael-fu-intel)]

ping from upstream~. Is there any progress, Jordi?

[Jordi Puigsegur (jordi-puigsegur)]

Hi,

First of all my apologies for the delay. I am quite busy during summer and haven't had time to check on that. Also, I didn't see any notification of last Geir answer and was still waiting ... :-)

The good news is that after one hour of setting up the environment I could test the driver with the patch and it works. I attach the xorg.1.log file (it is 1 because somehow session number 0 got stuck and the new driver opened the session in number 1). And as I said, the patch works: It detects the screen correctly and gets the right resolution.

Jordi.

[Jordi Puigsegur (jordi-puigsegur)]

Hi,

First of all my apologies for the delay. I am quite busy during summer and haven't had time to check on that.

I tested the driver with the patch and it works. You can find the xorg.1.log file (it is 1 because somehow session number 0 got stuck and the new driver opened the session in number 1) at http://launchpadlibrarian.net/30765627/Xorg.1.log

And as I said, the patch works: It detects the screen correctly and gets the right resolution.

Jordi.

[Michael Fu (michael-fu-intel)]

we've known that i830GetLoadDetectPipe is the key to this bug - without invoke it, hotplug detection fails. comparing the regdump before and after the call shows that disabling VGA (VGACNTRL register) might be the root-cause.

[yakuizhao (yakui-zhao)]

Created an attachment (id=29031)
disable VGA plane before doing CRT hotplug

Will you please try the debug patch on the latest graphics driver and see whether the issue still exists?
Please try it on UMS mode.
Thanks.

[Tormod Volden (tormodvolden)]

I added the patch from https://bugs.freedesktop.org/show_bug.cgi?id=22002#c31 to the Jaunty -intel driver in xorg-edgers:
xserver-xorg-video-intel 2.8.1+git20090829.7c48c21b-0ubuntu0tormod~jaunty2

[Jordi Puigsegur (jordi-puigsegur)]

just departing on holidays now ... for 10 days. When I come back I wll test the new package.

[Michael Fu (michael-fu-intel)]

ping~ Jordi

[Geir Ove Myhr (gomyhr)]

(In reply to comment #32)
> ping~ Jordi

Jordi reported downstream that he is on holiday 10 days from Sept. 2.

[Geir Ove Myhr (gomyhr)]

Hi Jordi,

Hope you had a nice holiday. In case you didn't get the xorg-edgers package with the patch applied, I copied it to http://www.kvante.info/LP379157/ . It's the 2.8.1 package. It should the replace the one that is currently in xorg-edgers, since that one does not have the patch anymore.

[Jordi Puigsegur (jordi-puigsegur)]

Geir,

There is a problem with permissions ...

http://www.kvante.info/LP379157/xserver-xorg-video-intel_2.8.1+git20090829.7c48c21b-0ubuntu0tormod~jaunty2_i386.deb

Forbidden
You don't have permission to access /LP379157/xserver-xorg-video-intel_2.8.1+git20090829.7c48c21b-0ubuntu0tormod~jaunty2_i386.deb on this server.

Jordi.

[Geir Ove Myhr (gomyhr)]

Sorry about that. I was in a hurry when I uploaded the file and didn't check the permissions. It should be fine now.

Geir Ove

[Jordi Puigsegur (jordi-puigsegur)]

Here is the Xorg.0.log with the package installed.

Jordi.

[Geir Ove Myhr (gomyhr)]

Created an attachment (id=29504)
Xorg.0.log with the patch in comment #31

Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes the issue or not, but maybe it is obvious from the log or he can comment here.

[Michael Fu (michael-fu-intel)]

(In reply to comment #34)
> Created an attachment (id=29504) [details]
> Xorg.0.log with the patch in comment #31
>
> Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes
> the issue or not, but maybe it is obvious from the log or he can comment here.
>

looks it's fixed...

[Jordi Puigsegur (jordi-puigsegur)]

(In reply to comment #35)
> (In reply to comment #34)
> > Created an attachment (id=29504) [details] [details]
> > Xorg.0.log with the patch in comment #31
> >
> > Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes
> > the issue or not, but maybe it is obvious from the log or he can comment here.
> >
>
> looks it's fixed...
>

No, it's not. I was in a rush and forgot to write it down. The screen went black (on power save).

[yakuizhao (yakui-zhao)]

Created an attachment (id=29654)
disable VGA plane before doing CRT hotplug detect

Will you please try the updated debug patch and see whether the issue still exists?
Thanks.

[Geir Ove Myhr (gomyhr)]

There's a new debug patch upstream. I have built the latest xorg-edgers package with the patch applied at https://launchpad.net/~gomyhr/+archive/ppa/ .

I haven't figured out how the patch system is supposed to work yet, so in the end I had to apply the patch manually (well, quilt import and quilt push) to make it work.

[Geir Ove Myhr (gomyhr)]

ping

[Michael Fu (michael-fu-intel)]

Ping ~ Jordi

[Jordi Puigsegur (jordi-puigsegur)]

Created an attachment (id=29883)
xorg.1.log file after testing last patch

I tried the patch and didn't work. I get the "Ubuntu is running in low graphics mode" message. I attach the xorg log file.

[Jordi Puigsegur (jordi-puigsegur)]

Tried it and didn't work. I get the "Ubuntu is running in low graphics mode" message. I attach the xorg log file.

[Alberto Milone (albertomilone)]

Please follow these steps:
1) set the driver to intel (instead of vesa)
2) reboot with the cable unplugged
3) Log in as usual
4) Connect the VGA cable, open the terminal and type:
xrandr

and attach the output of that command

[Jordi Puigsegur (jordi-puigsegur)]

The computer now runs Hardy and I am doing all tests related to this bug from a Jaunty live CD, so I don't know how to proceed.
Is it possible to do what you suggest from a Jaunty live CD ?

[manu (eallaud-gmail)]

I would like to add my own experience here:I have a g33 based MB with the same problem on Karmic: actually it does not even boot correctly with KMS as it cannot find a screen as it thinks VGA is disconnected. All details (with a patch that forces ddc probing instead of hotplug detection) are here:https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/467841

Let me know if I can post some more logs to help.

[Michael Fu (michael-fu-intel)]

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 212e227..e505144 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -262,8 +262,8 @@ static bool intel_crt_detect_hotplug(struct drm_connector *connector)
   } while (time_after(timeout, jiffies));
  }

- if ((I915_READ(PORT_HOTPLUG_STAT) & CRT_HOTPLUG_MONITOR_MASK) ==
- CRT_HOTPLUG_MONITOR_COLOR)
+ if ((I915_READ(PORT_HOTPLUG_STAT) & CRT_HOTPLUG_MONITOR_MASK) !=
+ CRT_HOTPLUG_MONITOR_NONE)
   return true;

  return false;

I post zhenyu's patch here that works for manu. Jordi, would you please have a try?

Note this is a patch against KMS driver, i.e. kernel.

[Jordi Puigsegur (jordi-puigsegur)]

The bug upstream has a new patch to test. Should we test it?

[Geir Ove Myhr (gomyhr)]

> The bug upstream has a new patch to test. Should we test it?

Yes, that would be nice. Note however that this is a patch to the
kernel and not the intel driver, since for a while now, screen
detection is done in the kernel. A kernel cannot be easily tested
using a LiveCD as far as I know, so you would have to have an
installed system, preferably Karmic or Lucid.

There are some instructions for how to test patches to the i915 kernel
module at https://wiki.ubuntu.com/KernelCustomBuild . See Martin
Pitt's answer to the first question on that page.

[Jordi Puigsegur (jordi-puigsegur)]

I've been told that it is not possible to test a kernel patch using a live CD. The computer is now being used with a Ubuntu Hardy and I cannot format it. If there is no other way to test it I am afraid it won't be possible.

[Jesse Barnes (jbarnes-virtuousgeek)]

If we can't get testing, I guess we can't fix this one. Hopefully it got fixed anyway.

[Geir Ove Myhr (gomyhr)]

Following upstream and closing since patches can't be tested.

[Jordi Puigsegur (jordi-puigsegur)]

I just tested a new Ubuntu 10.04 live CD and seems to work perfectly. So after all it seems it got solved.

Thanks,
Jordi.

[Jordi Puigsegur (jordi-puigsegur)]

I just tested a new Ubuntu 10.04 live CD and seems to work perfectly.