"Output LVDS is connected to pipe B" on a Mini-PC without LFP

Bug #233787 reported by Jumble on 2008-05-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
xserver-xorg-video-intel (Ubuntu)
Bryce Harrington
Bryce Harrington

Bug Description

Binary package hint: xserver-xorg-video-intel

After starting the Xserver the screen simply goes blank and shows nothing (w/o sync, display says: "no signal"). Switching to a console is not possible, the screen remains blank. However, the system responds to ctrl+alt+del and reboots. Here comes the data of my system:

Computer: Transtec Senyo 610 Mini-PC http://www.transtec.de/D/D/products/personal_computer/pc/mini_pc.html
Gfx: Intel x3100
Proc: Intel Core2 Duo (T5550)
Display: Old LCD with analog-input, connected via DVI to VGA-adaptor
OS: Ubuntu 8.04 with all updates applied.

lspci | grep VGA:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

The only way to make it work is to manually specify the VESA-driver.

xorg.conf and log will follow as attachments.

Jumble (trexity) wrote :
Jumble (trexity) wrote :
Jumble (trexity) wrote :

PS: It's the Ubuntu-8.04-AMD64 release.

Thanks for reporting this bug and attaching necessary files. Sounds like an X lockup. Please also collect a full backtrace on this issue - see http://wiki.ubuntu.com/X/Backtracing for directions on how to do this.

Changed in xserver-xorg-video-intel:
status: New → Incomplete
Jumble (trexity) wrote :

OK, here comes the backtrace (generated remotely):

#0 0x00007f49d3515d53 in select () from /lib/libc.so.6
No symbol table info available.
#1 0x0000000000561891 in WaitForSomething (pClientsReady=0x7fffdcf52930) at ../../os/WaitFor.c:236
        i = -587911792
        waittime = {tv_sec = 0, tv_usec = 644000}
        wt = (struct timeval *) 0x7fffdcf528d0
        timeout = <value optimized out>
        clientsReadable = {fds_bits = {0 <repeats 16 times>}}
        clientsWritable = {fds_bits = {8652032, 8675728, 1, 139955054300188, 1, 139955054300188, 140736900442128, 139951509340161,
    1, 5270350, 12233744, 139951509340160, 12637912, 5392956, 139955037433136, 139955057338848}}
        curclient = <value optimized out>
        selecterr = 12233744
        nready = <value optimized out>
        devicesReadable = {fds_bits = {12233744, 4532735, 8752480, 8313680, 8752304, 140736900442048, 12233744, 4532735, 12233744,
    140736900442088, 4196637, 4, 3221225474, 139955057338848, 12637912, 12637824}}
        now = 3707055504
        someReady = 0
#2 0x000000000044e85a in Dispatch () at ../../dix/dispatch.c:425
        clientReady = (int *) 0x100
        result = 0
        client = (ClientPtr) 0xbaac10
        nready = -1
        start_tick = <value optimized out>
#3 0x0000000000436b9d in main (argc=10, argv=0x7fffdcf52ee8, envp=<value optimized out>) at ../../dix/main.c:452
        i = 1
        error = 0
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

I've used another xorg.conf for that. The funny thing is if I manually specify the intel-driver, switching to a console is possible. All other symptoms are the same.

The xorg.conf and log follow in a few minutes.

Jumble (trexity) wrote :
Jumble (trexity) wrote :
Jumble (trexity) wrote :

I noticed the following in the log:

(II) intel(0): Pipe B is on
(II) intel(0): Display plane B is now enabled and connected to pipe B.
(II) intel(0): Output LVDS is connected to pipe B

In my mini-pc is a laptop-chipset,but it has no built-in display. Is my X-session perhaps displayed on an inexisting display?

Jumble (trexity) wrote :


1. Switching to a console works (to escape from the blank screen) if there has been a running x-session with the vesa-driver before, otherwise not. (regardless if the intel-driver was specified manually as stated above)

2. The intel-driver won't work with an LCD connected via DVI-D-cable.

3. This is perhaps not relevant (or something is wrong with the VESA-BIOS): The vesa-driver produces a blurred image with the DVI-D-connected LCD even in its native resolution (1680x1050@60).

Jumble (trexity) wrote :

By fiddeling around with the X-config for 2 full days, I finally made it work with my new Samsung Syncmaster T200. The LVDS has to explicitly turned off.

unggnu (unggnu) wrote :

It looks like a quirk is needed to disable LVDS I guess. Which monitor connectors have your computer?

Jumble (trexity) wrote :

It has the following video-connectors:

1 x DVI-I
1x TV Port (S-Video)

Only the DVI-port is in use here.

unggnu (unggnu) wrote :

At first please post a current Xorg.0.log with your new xorg.conf to see the difference.
It is the best to report it upstream I guess but could you please check if this issue still happens with the unofficial package http://people.ubuntu.com/~bryce/Testing/intel/hardy-amd64/xserver-xorg-video-intel_2.3.1-1ubuntu1~bwh3_amd64.deb of a newer -intel driver.

To install it you have to remove the old i810 driver before.
sudo apt-get remove xserver-xorg-video-i810 xserver-xorg-video-all

And please regenerate your xorg.conf just to be sure.
sudo dpkg-reconfigure xserver-xorg

If you want to reset everything do the follow commands.
sudo apt-get remove xserver-xorg-video-intel
sudo apt-get install xserver-xorg-video-all

Of course you have to uncomment your current xorg.conf options before X restart.

Jumble (trexity) wrote :

Here comes the X-log for the above posted config. I'll check for the testing-server in a few days (this is a productivity-system)...

unggnu (unggnu) wrote :

Pipe dealing looks similar for me. Please regenerate your xorg.conf with the command >>sudo dpkg-reconfigure xserver-xorg<< after installing the new driver.

Pierre Dinh-van (dinhvan) wrote :

Some infos which could be usefull.

This computer is sold from transtec with a SuSE Enteprise Desktop 10. I downloaded a trial version to see how the graphic chip worked and I took some infos.

First of all, it works properly :). 3D works fine.

I made a rpm -qa to get the installed versions of the stuff related to xorg/intel :


SuSE Linux Enterprise Desktop uses Xorg 6.9 and configures the x3100 with a i810 driver. It also uses 915resolution in the boot process.

I tried to import the xorg.conf directly onto Ubuntu Hardy, but it didn't worked and the symptoms are staying the same (black screen).

I tried the actual intel driver without success.

Are the patches used in SuSE packages available somewhere ?

Jumble (trexity) wrote :

@Pierre: Have you tried the unofficial testing-server mentioned above? (Then I don't have to... ;) )

Pierre Dinh-van (dinhvan) wrote :

I thought it did the same with the newest driver, but it was actually my xorg.conf which wasn't OK. I just tried with the xorg.conf of comment #10 and it works better.

For the moment, I don't get any GLX extensions but I hope I can fix it by myself with a little work.

I attach my Xorg.0.log file in case this GLX problem is not due to my misconfiguration

Jumble (trexity) wrote :

The appropriate RPMs for the SUSE-distro are packaged under
It also contains an URL-file under which the sources kann be found.

Pierre Dinh-van (dinhvan) wrote :

I removed all packages related to nvidia (but I guess just nvidia-glx was usefull to remove). And I can get some 3D now.

But DRI is not activated using libgl1-mesa-glx and I still didn't found why. I'll try the diverses variants and if none works, I'll try to compile the last mesa revision. Is there somewhere some testing packages from mesa-glx ?

Pierre Dinh-van (dinhvan) wrote :

I found on this page : http://ubuntuforums.org/showthread.php?t=843052 that I had to remove libglitz1 to get dri activated.

It works now pretty well (enought for the 3D features I needed). I still have some times problems to switch from X to console (screen stays black, but Ctrl+Alt+F7 give it back), but I'm satisfied with the result :). Have to test on a fresh install and document it.

I have the same hardware with a Philips Brilliance 151AX monitor. I had to install with "safe graphics mode" and now only have a screen resolution of 800x600 (instead of 1024x768).

I tried to install a newer version of the X server from http://people.ubuntu.com/~bryce/Testing/intel/hardy-i386/xserver-xorg-video-intel_2.3.1-1ubuntu1~bwh3_i386.deb, but it failed with an error.

How should I proceed?

Hm, I managed to install http://people.ubuntu.com/~bryce/Testing/intel/hardy-i386/xserver-xorg-video-i810_2.3.1-1ubuntu1~bwh3_all.deb, rebooted and still have the same resolution (800x600). I changed the Driver to "i810" and to "intel" but this doesn't seem to make a difference. Come to think of it maybe it is is running in failsafe mode as my keyboard seems to have us layout all of a sudden.

Attached also the log file

I installed the unofficial package as mentioned in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/233787/comments/13

sudo apt-get remove xserver-xorg-video-i810 xserver-xorg-video-all

Then install http://people.ubuntu.com/~bryce/Testing/intel/hardy-i386/xserver-xorg-video-intel_2.3.1-1ubuntu1~bwh3_i386.deb. This time it installs without a problem.

sudo dpkg-reconfigure xserver-xorg

It still says the driver is vesa and the resolution is still 800x600. If I change the driver to "intel" or "i810" I can hear the prompt sound from gdm, but the screen remains black. I have to move to a console to fix xorg.conf.

unggnu (unggnu) wrote :

Please regenerate your xorg.conf with >>sudo dpkg-reconfigure xserver-xorg<<. Confirm every question with enter. After this please add the line >>Option "ForceEnablePipeA" "true"<< to your xorg.conf device section and restart X. It should look like this?

Section "Device"
    Option "ForceEnablePipeA" "true"

If the issue still appears attach your current /var/log/Xorg.0.log and the output of dmesg and >>xrandr --verbose<<.

The original problem seems related to this one:


Thanks ungnu for your help

I regenerated my xorg.conf with "sudo dpkg-reconfigure xserver-xorg" and confirmed all questions. It regenerates xorg.conf with Driver "vesa" in the Device section btw. Added the Option "ForceEnablePipeA" "true" to the device section.

Restart X and still have a resolution of 800X600.

If I change the Driver to "intel" I can hear the login sound of gdm but I get a blank screen. Cannot even switch to console anymore (C-M-F1) as I did before without ForceEnablePipeA. Same with "i810" as the driver.

Attaching the requested files

Output of xrandr --verbose:

Screen 0: minimum 640 x 480, current 800 x 600, maximum 800 x 600
default connected 800x600+0+0 (0x47) normal (normal) 0mm x 0mm
 Identifier: 0x46
 Timestamp: 2153637
 Subpixel: unknown
 CRTC: 0
 CRTCs: 0
  800x600 (0x47) 29.3MHz
        h: width 800 start 0 end 0 total 800 skew 0 clock 36.6KHz
        v: height 600 start 0 end 0 total 600 clock 61.0Hz
  640x480 (0x48) 18.4MHz
        h: width 640 start 0 end 0 total 640 skew 0 clock 28.8KHz
        v: height 480 start 0 end 0 total 480 clock 60.0Hz

unggnu (unggnu) wrote :

Thanks for the information. Could you please attach the Xorg.0.log when you specified the intel driver?
Just copy the Xorg.0.log after you have heard the Gdm sound to your home directory or something like that and upload it afterwards.

Do you mean after regenerating xorg.conf the vesa driver is used or really listed under Device section in your new xorg.conf?

Could everyone please attach the output of "lspci -vvnn" too so we can check that the hardware is equal since the some times the -intel driver is used per default and some times -vesa. First one is of course correct.

I am going to move this issue upstream anyway.

unggnu (unggnu) wrote :

Btw. does anyone using this computer with a digital DVI device? If I understand your reports correctly everyone is using the VGA-Adapter? This looks like the problem since VGA has no attached Pipe according to Xorg.0.log.

Jumble (trexity) wrote :

The vesa-driver gets automatically specified by "dpkg-reconfigure xserver-xorg" if the system has been installed in "safe graphics mode". The vesa-line has to be removed from xorg.conf to archieve the "native" behaviour. My display is now connected via a digital DVI cable and it behaves exactly the same as with an analogue one.

Changed in xserver-xorg-video-intel:
status: Incomplete → Confirmed
unggnu (unggnu) wrote :

Hi, I've forwarded your bug upstream to Xorg for their assistance with this issue. Would you mind please subscribing to the upstream bug report in case they have questions or need you to test something? Then you can provide the info directly without me slowing down the process.

Changed in xserver-xorg-video-intel:
status: New → Unknown
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2008-07-17
Changed in xserver-xorg-video-intel:
status: Confirmed → Triaged
importance: Undecided → High
unggnu (unggnu) wrote :

From upstream:
"So the problem is intel driver always assumes LVDS connected on mobile chipset.
And in this case there's no local flat panel on this machine with 965GM.

We can work around it with adding a quirk. But I'm wondering if we can do
better to completely resolve this kind of issues with adding LVDS detection
code in the driver.

For now I suggest users to work around it by explicitly disable LVDS in
1) Add
        Option "monitor-LVDS" "LVDS"
in Device section
Section "Monitor"
        Identifier "LVDS"
        Option "Ignore" "True"

Could somebody confirm this?

Jumble (trexity) wrote :

Yes, that exactly fixed this issue here.

unggnu (unggnu) wrote :

I have created a patch against the driver. I am not sure if it is working but it is easy to test.

The easiest way to compile the driver is with apt-src.
Install the packages apt-src and fakeroot.
After that run "apt-src install xserver-xorg-video-intel". It downloads the sources and all dependencies to compile it. Afterwards change the directory to xserver-xorg-video-intel-2.2.1 and run the command "patch -p1<~/quirk_transtec_senyo_610.patch" where ~ is the placeholder for your home directory. If the patch is saved on your desktop the path would look like ~/Desktop/quirk_transtec_senyo_610.patch .
After applying the patch the driver can be compiled with "fakeroot dpkg-buildpackage" which creates the -intel driver deb package. This should be installed, the workaround xorg.conf lines removed and then X restarted.

unggnu (unggnu) wrote :

Should I upload a deb package of the compiled driver or hasn't anybody tried to compile it yet? If it is confirmed it will most likely be integrated in a newer Hardy -intel driver soon.

Pierre Dinh-van (dinhvan) wrote :

I applied the patch on the default 2.2.1 driver and built the package with it. It works well without the xorg.conf workaround.

I still need the Modeline for my monitor but I have to test further. It's already an improvement.

unggnu (unggnu) wrote :

Thanks for testing. Uploading the driver patch on its own.

Changed in xserver-xorg-video-intel:
assignee: nobody → bryceharrington

Thanks ungnu

I compiled and tested as specified in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/233787/comments/36. It works now, I get the proper resolution.

There is something fishy with the ratio but that's probably another problem


Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
Bryce Harrington (bryce) on 2008-07-29
Changed in xserver-xorg-video-intel:
importance: Undecided → Medium
status: New → Triaged
importance: Medium → High
unggnu (unggnu) wrote :

Is anything else needed to make this a SRU candidate? It is just a simple quirk.

Caysho (caysho) wrote :

I've just acquired an Asus Eee Box (B202) and after some investigation found this bug.
Doing the fix described in the upstream suggestion fixes this problem and my LCD monitor is correctly identified via the DVI connection.

caysho@minipc:~$ lspci -vvnn
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:1252]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at ec80 [size=8]
 Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at feb40000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: <access denied>

00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:1252]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0
 Region 0: Memory at fea80000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>

Using ubuntu 8.04.1 with xserver-xorg-video-intel version 2:2.2.1-1ubuntu13.6.

jwishnie (jeff-wishnie) wrote :

I am seeing the same problem on my Asus EeeBox.

I tried the transtec_sanyo patch without success.

Can someone tell me what the struct members are in the i830_quirks.c quirks list?

Looking at the transtec one from the patch:
{ PCI_CHIP_I965_GM, 0x1509, 0x2f15, quirk_ignore_lvds },

I ASSUME the 2nd and 3rd members are some sort of vendor ID that I need to change for the ASUS box.

Can someone explain so I can make the patch for ASUS EeeBox as well?


Try the upstream workaround (https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/233787/comments/34).. and please tell me if it works with eee box and if it's possibile to use 16:9 ratio.
Have anyone try this workaround with a DVI->VGA adapter or with a DVI->HDMI one?

Caysho (caysho) wrote :

The work around does fix the problem.
With the work around in place, using the DVI>VGA adapter and VGA cable to the monitor, the display does work but the correct resolution for my monitor (1280x1024) is not chosen.
In the Ubuntu resolution utility, both pipelines are being found but the monitors are not being identified correctly. I see 1280x768 being selected for display 1 and 2 (see attached).
I don't have a widescreen so I can't test for this.

unggnu (unggnu) wrote :

You can get the needed IDs amongst others from your Xorg.0.log. Search for "(II) PCI: PCI scan (all values are in hex)". In the case of Transtec PCI 00:02:0 is used so the relevant part is "(II) PCI: 00:02:0: chip 8086,2a02 card 1509,2f15 rev 03 class 03,00,00 hdr 80". It should be easier to test the upstream xorg.conf workaround described above at first.

Your monitor issue looks like a different problem. Please open a new bug report for this issue with your Xorg.0.log and xorg.conf.

Bryce Harrington (bryce) wrote :

Hi Guys,

I wrote up about the LVDS quirking here: https://wiki.ubuntu.com/X/Quirks#Ignore%20LVDS%20Output%20Quirk

To answer the question about the structure { PCI_CHIP_I965_GM, 0x1509, 0x2f15, quirk_ignore_lvds }, the 2nd and 3rd fields are the subsystem vendor PCI ID's. If you run `lspci -vvnn | grep -A1 "VGA compat"` it prints the chip PCI ID and the subsystem vendor PCI ID. You can also obtain it from the Xorg.0.log in the PCI scan section, but the lspci approach is probably simpler for most people. :-)

@Jumble, looks like the patch for your system has already gone upstream. And thanks for working with unggnu on this - seeing your bug actually helped me sort out the same issue on a different machine. :-) I will work on getting a Hardy SRU in for it, in due course.

@Caysho, you've provided enough info and I'm adding this quirk for you too:

    /* Asus Eee PC B202 (See LP: #233787) */
    { PCI_CHIP_I945_GME, 0x1043, 0x1252, quirk_ignore_lvds },

If anyone else has similar symptoms, please file as new bugs so it's easier for us to track patches and such. Reference the above X Quirks page and follow the directions on it.

Caysho (caysho) wrote :

@Bryce Harrington
Thanks for that.
The quirk comment should make reference to "Asus Eee Box B202", as Asus do market it separately from the Eee PC, even though it's part of the same line.
Would this quirk cause problems with the other Eee PC machines with embedded LCD screens using the same chipset ?

I did the DVI>VGA converter test for Lorenzo Z.; I have no need for the converter, but I know other people do.
I'll submit a new bug with the logs using the workaround for this bug.

Caysho (caysho) wrote :

Pipeline bug workaround with screen detection problem using DVI>VGA converter reported, bug #268529

Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in xserver-xorg-video-intel:
status: Triaged → Fix Committed

And with a DVI-D>HDMI converter? i read that there are some problem with DVI-D cable... so i think also with DVI-D>HDMI converter

Bryce Harrington (bryce) wrote :

Caysho, it shouldn't be a problem; the quirks include a subsys vendor id number that is particular to the exact hardware, so this quirk will only apply to Asus Eee Box B202 devices.

This LVDS bug is one that's going to be common for any laptop/mobile graphics chips that get repurposed to desktop type systems with no LVDS. I hope upstream comes up with a better solution than quirking... but for now at least we can quirk them as they show up.

Note I did not include the Asus Eee Box B202 quirk in the Hardy upload; I felt this one could probably benefit from more testing and pushing upstream before we consider it for Hardy. But if you find it works well and feel it should be targeted to Hardy as well, please open a new bug with the request and propose it for hardy.

Caysho (caysho) wrote :

@Lorenzo Z.
I don't have an DVI-D>HDMI converter, so I can't test this.

@Bryce Harrington
Ok. I ask because I gather the hardware is essentially identical to the Eee PC 1000H, minus the embedded LCD screen; I have no evidence though, without an lspci dump.
I presume I would need to compile the source to get the quirk ? I'm reluctant to try that given this is my main box.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.4.1-1ubuntu4

xserver-xorg-video-intel (2:2.4.1-1ubuntu4) intrepid; urgency=low

  * 23_quirks_studiohybrid_eeepc_and_w251u.patch:
    - Fix blank screen on startup on Asus Eee PC due to LVDS
      misconfiguration (LP: #233787)
    - Fix blank screen on startup on Dell Studio Hybrid due to LVDS
      misconfiguration (LP: #267945)
    - Fix crash on lid close on Gigabyte W251U - pipeA quirk (LP: #244242)

 -- Bryce Harrington <email address hidden> Fri, 12 Sep 2008 00:53:01 +0000

Changed in xserver-xorg-video-intel:
status: Triaged → Fix Released

On Fri, Sep 12, 2008 at 12:15:59AM -0000, Caysho wrote:
> @Lorenzo Z.
> I don't have an DVI-D>HDMI converter, so I can't test this.
> @Bryce Harrington
> Ok. I ask because I gather the hardware is essentially identical to the Eee PC 1000H, minus the embedded LCD screen; I have no evidence though, without an lspci dump.

Well, I guess anything's possible but I seriously doubt that they'd have
the same subsystem pci id's; that'd be pretty irregular. However, it's
easy enough to doublecheck. Here's your PCI ID:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device [1043:1252]

From http://forum.eeeuser.com/viewtopic.php?id=16555:

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) (prog-if 00 [VGA])
    Subsystem: ASUSTeK Computer Inc. Unknown device 82d9

 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 830f

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 830f

That first one isn't even the same chip. But the latter two look like
they're probably the same. But the subsys device ID's are 0x830f,
whereas yours is 0x1252. So we seem to be safe.

In fact, if you google for "EEE PC lspci 1252", pretty much the only
thing that pops up is this bug report. :-)

> I presume I would need to compile the source to get the quirk ? I'm reluctant to try that given this is my main box.

Yes, but functionally it'll be identical to how you turned off LVDS in
your xorg.conf so if it's just for your box and you don't want to
upgrade to Intrepid, then just use the xorg.conf workaround. I'll push
this out to hardy next time I do quirk syncs, when we're closer to the
intrepid release.


Martin Pitt (pitti) wrote :

Anyone who can test the package in hardy-proposed?

Jumble (trexity) wrote :

Yes, tested here and works well.

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in xserver-xorg-video-intel:
status: Fix Committed → Fix Released
Changed in xserver-xorg-video-intel:
importance: Unknown → Wishlist
Changed in xserver-xorg-video-intel:
importance: Wishlist → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.