[Unknown 14] Hardware w/ 1600x900 LCD does not boot up using vesa

Bug #315588 reported by Mario Limonciello on 2009-01-09
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xserver-xorg-video-vesa (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-vesa

Some unreleased dell hardware that contains a 1600x900 LCD is unable to boot either the intrepid or the jaunty live disks. The hardware is not supported yet by the NV driver, so VESA is the only thing that would possibly work on a live disk.

Unfortunately X is not able to match the DDC modeline to any VESA modes.

This hardware *does* work w/ the VESA driver in hardy.

Mario Limonciello (superm1) wrote :
Mario Limonciello (superm1) wrote :
Bryce Harrington (bryce) wrote :

(II) VESA(0): h_active: 1600 h_sync: 1648 h_sync_end 1680 h_blank_end 1760 h_border: 0
(II) VESA(0): v_active: 900 v_sync: 903 v_sync_end 908 v_blanking: 926 v_border: 0
(WW) VESA(0): Unknown vendor-specific block 0
(II) VESA(0): G183JN140O6
(WW) VESA(0): Unknown vendor-specific block 0

Those warnings sound suspicious.

Anyway, the problem seems to be coming in at this line:

(WW) VESA(0): Unable to estimate virtual size

So my guess is that the monitor EDID is either wrong or not being parsed correctly by the X server.

Can you collect the following so we can get a better view of what's in the EDID?

  * ddcprobe
  * get-edid > edid.dat
  * get-edid | parse-edid
  * xrandr --verbose

The last one I think requires the X server to be running so may not be possible to get.

You should also try specifying the HorizSync and VertRefresh ranges explicitly in the xorg.conf, and perhaps the resolutions as well (it may be necessary to use the IgnoreEDID option, although I don't know if that option is available for vesa so may require some experimentation.)

Bryce Harrington (bryce) wrote :

Oh, if you can get -nvidia running on the hardware, then I think you can get xrandr --verbose from that session and it should be sufficient.

Changed in xserver-xorg-video-vesa:
importance: Undecided → High
status: New → Incomplete

Yes, -nvidia does work. I'll get those asked bits early next week.

Sent from my iPod Touch

On Jan 10, 2009, at 9:16, Bryce Harrington <email address hidden>
wrote:

> Oh, if you can get -nvidia running on the hardware, then I think you
> can
> get xrandr --verbose from that session and it should be sufficient.
>
>
> ** Changed in: xserver-xorg-video-vesa (Ubuntu)
> Importance: Undecided => High
> Status: New => Incomplete
>
> --
> Hardware w/ 1600x900 LCD does not boot up using vesa
> https://bugs.launchpad.net/bugs/315588
> You received this bug notification because you are a member of The
> Dell
> Team, which is subscribed to Dell Ubuntu Project.

Mario Limonciello (superm1) wrote :
Mario Limonciello (superm1) wrote :
Changed in xserver-xorg-video-vesa:
status: Incomplete → New
Bryce Harrington (bryce) wrote :

Hi superm1,

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

Changed in xserver-xorg-video-vesa:
status: New → Incomplete
Mario Limonciello (superm1) wrote :

I'm not going to be able to attach lspci as this is unreleased hardware. The above information should contain all necessary for fixing this..

Changed in xserver-xorg-video-vesa:
status: Incomplete → New
Changed in dell:
importance: Undecided → Medium
status: New → Confirmed

Created an attachment (id=22619)
Xorg log

I've got a few LCD panels available for a laptop that won't come up with the VESA driver as is. There was an old patch available in the F9 packages and Ubuntu 8.04 packages that allows it to work properly.

Created an attachment (id=22620)
patch from F9 & U8.04 that makes it work

more details should be available on the Ubuntu bug report, DDCprobe information, edid information.

Created an attachment (id=22622)
Xorg log with no xorg.conf

Mario Limonciello (superm1) wrote :

I've gone back and done a local build including "102-fedora-vesa-1.3.0-range-hack.patch" from the earlier hardy and intrepid bug that it was introduced. The driver builds fine with it still, and it *fixes* this problem for me on this hardware.

Changed in xserver-xorg-video-vesa:
status: New → Confirmed
Changed in xorg-server:
status: Unknown → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-vesa - 1:2.0.0-1ubuntu6

---------------
xserver-xorg-video-vesa (1:2.0.0-1ubuntu6) jaunty; urgency=low

  * 101_aggressive_mode_validation.patch: (LP: #315588)
    - Adds another fallback mode that used to exist in 8.04 & F9
      for looking at a range of hsync and vsync values.

 -- Mario Limonciello <email address hidden> Thu, 05 Feb 2009 11:25:16 -0600

Changed in xserver-xorg-video-vesa:
status: Confirmed → Fix Released
Changed in dell:
status: Confirmed → Fix Released
Changed in xorg-server:
status: Confirmed → Fix Released
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Changed in somerville:
importance: Undecided → Medium
status: New → Fix Released
no longer affects: dell
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1306085

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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