[Feisty] Wide screen not correctly detected (16/10)

Bug #67369 reported by Stéphane Graber on 2006-10-21
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Bryce Harrington
Nominated for Feisty by Ramsees R.

Bug Description

Binary package hint: xorg

I have two widescreen display, one with my laptop (1280x800 and ati card) and one with my desktop (1440x900 and nvidia card).

My laptop's screen is detected correctly and the right resolution is selected.
For my desktop it's not the case and I have a stretched 1280x1024 (4/3) resolution which is hard to read.

Tested with Edgy Eft on both computers. (Daily build of today)

Stéphane Graber (stgraber) wrote :

This issue is still the same with the final Edgy.
It would be nice to have a correct widescreen detection in Feisty. (Maybe update this bugreport from Undecided to Wishlist)

Same issue with Feisty Herd1.

Card : Nvidia Geforce FX5500
Driver : vesa ?? (should be nv)
Monitor : Acer AL1916W (Widescreen 16/10 1440x900)
Resolution : 1280x1024

And no widescreen resolution in any of the mode lines.
As these resolutions are becoming usual if think it should be good to make them detected correctly.

Filip Palm (filip) wrote :

I have a similar problem, i'll write about it here because its unnecessary to write up a new bugreport about it.

I have an Acer AL1916W widescreen TFT display and it should be set to 1440x900 but its set to 1440x1440 every time i install Ubuntu Dapper/Edgy.

Card: Nvidia GeForce 6150
Driver: vesa (should be nv)
Monitor : Acer AL1916W
Resolution : 1440x1440 (should be 1440x900)

Ramsees R. (ramsees-79) wrote :

I have the same problem:

Card: ATI 9800
Driver: ATI open source driver
Monitor : Acer AL1916W
Resolution : 1280x1024 (should be 1440x900)

Please, fix it before the next release, this is a mayor show stopper.

Stéphane Graber (stgraber) wrote :

seems related to that Acer monitor, all of us have that 1916W thing.

Stéphane Graber (stgraber) wrote :

Two other people with the same issue, moving to confirmed.

Changed in xorg:
status: Unconfirmed → Confirmed
Stéphane Graber (stgraber) wrote :

This issue is still present in the Herd 2

Ramsees R. (ramsees-79) wrote :

Confirmed, still present in Herd 2

Václav Šmilauer (eudoxos) wrote :

The first post isn't entirely clear whether it's the card that is in bad video mode or the LCD displaying incorrectly. In the former case, it is not a showstopper (although still an issue) since you can update xorg.conf by hand; in the latter, it is the manufacturer issue.

The reason I'm asking is that I've also bought Acer AL1916W and it has buggy firmware (says acer support) - even if the video card correctly switches to 1440x900, the LCD switches to non-native 1152x900 and interpolates 1440x900 (VGA) → 1152x900 (internal display) → 1440x900 (physical display).

Stéphane Graber (stgraber) wrote :

In my case, Ubuntu has detected 1280x1024 as resolution for my monitor and set it in xorg.conf and the monitor correctly shows this 1280x1024 resolution. (except it's not the right one)

Of course I can manually update the xorg.conf and change the value to 1440x900 and it will work perfectly but I think as these monitor are becoming more and more common it should be great to have this monitor correctly detected.

Ramsees R. (ramsees-79) wrote :

@Václav Šmilauer: Fedora and linspire don't show this problem, And the last time I tried to fix it editing manually I messed up X, Im talking in the name of those users who doesn't have the skill to edit xorg.conf.

Changed in xorg:
importance: Undecided → Medium
Stéphane Graber (stgraber) wrote :

Confirmed on Feisty Herd4.

Nick Marsh (nxemail) wrote :

Also happens on a Dell Latitude D620 on Feisty Herd4.

lspci|grep -i nvidia
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1)

Manually adding 1440x900 to xorg.conf resolves the problem.

Jerone Young (jerone) wrote :

The script "xresprobe" may possibly be at falut here. What does the command "ddcprobe" output. Also what does the command "xresprobe" output?

If you don't have it just install xresprobe via apt, or just run it as root from the live cd.

Nick Marsh (nxemail) wrote :

$ sudo ddcprobe
vbe: VESA 3.0 detected.
vendor: NVIDIA Corporation
product: G72 Board - travis1 Chip Rev
memory: 65536kb
mode: 640x400x256
mode: 640x480x256
mode: 800x600x16
mode: 800x600x256
mode: 1024x768x16
mode: 1024x768x256
mode: 320x200x64k
mode: 320x200x16m
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
mode: 1024x768x64k
mode: 1024x768x16m

Stéphane Graber (stgraber) wrote :
Adilson Oliveira (agoliveira) wrote :

Same problem using a LG L203WT. The default resolution is 1680x1050 but it goes down to 1280x1024.
Xorg log says:
(WW) NVIDIA(0): No valid modes for "1680x1050"; removing.
(WW) NVIDIA(0): No valid modes for "1440x900"; removing.
(II) NVIDIA(0): Validated modes:
(II) NVIDIA(0): "1280x1024"
(II) NVIDIA(0): "1280x960"
(II) NVIDIA(0): "1024x768"
(II) NVIDIA(0): "800x600"
(II) NVIDIA(0): "640x480"
(II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024
(==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
Adding the modeline manually does not work.

Adilson Oliveira (agoliveira) wrote :

I found a workaround to this problem. I didn't have the time to dig out exactly how to solve this but this should do the trick.
Looks like Xorg, unlike the XFree, by default don't trust modes that can't be confirmed by probing the hardware so, if you use this:
Option "ModeValidation" "NoDFPNativeResolutionCheck"
in session Device.
It will just accept whatever modes you indicated in the Screen session.
In my case I didn't need even to create a modeline. Just the defaults worked fine.

I hope this helps.

Jerone Young (jerone) wrote :

This is a problem that looks like it really is not going to be solved in Feisty. Though there is an effort to resolve it POST Feisty:


My Samsung 243T has an issue as well, but it mainly has to do with xrespose. I have a bug here about it:

This SimpleXModeSelection with the use of XRandR should hopefully resolve issues like this in future Ubuntu verisons.

Jelle de Jong (jelledejong) wrote :

I got a Samsung SyncMaster 940bw (1440x900) with the same problems and more

The resolution problem was not that big of a problem for me.

I created a modeline with this command: gtf 1440 900 60 -x
I looked for the correct monitor freq range with this command: sudo ddcprobe
some extra command for info: sudo xresprobe via
I added the required data to my xorg monitor section and got my tft working

The big problems are with the fonts dpi resolution:

Tho gather the info form your xsession resolution and the desktop environment resolution use these commands:
xdpyinfo | grep resolution
xrdb -q | grep Xft
They should generate the same dpi values, if not you can have fonts problems, fussy fonts with firefox, openoffice etcetera.

In edgy and dapper i solved this by adding a DisplaySize option to my monitor section but this does not work with feisty.

This calculation I used for the DisplaySize (96 dpi and 25.4 stands for converting inches)
1440/96*25.4 and 900/96*25.4 =
DisplaySize 381 238

1024/96*25.4 and 768/96*25.4 =
DisplaySize 270.93 195.2

This was the text i added in my feisty herd5 test report but i did not received any response on this subject yet:

21: There is a font displaying resolution problem in the Ubuntu distributions.
The commands: xdpyinfo | grep resolution and xrdb -q | grep Xft should give the same resolution (DPI) but they are way off, resulting in blurry fonts in some applications, like in openoffice.org. Normally I was able to solve this by calculate and adding a DisplaySize option in the xorg.conf monitor section. But that does not work with feisty!

So I would like a working solution to set the xorg dpi settings sot both commands generate the same info.

I also added a how-to report over the font problem that i made some time ago:

Will Daniels (wdaniels) wrote :

Confirmed on Fiesty Beta (Acer AL1916W, resolution got set to 1400x1050 instead of 1440x900)

Bryce Harrington (bryce) wrote :

Bumping up priority

Changed in xorg:
importance: Medium → High
Kyle Meadows (darktyco) wrote :

I have always had problems with widescreen detection on my Acer laptop since I first installed Ubuntu on it (I think it was Hoary at the time.) I believe it is a problem with the Intel video chipset, I've had to use the 855resolution program to set the correct mode. I can get exact hardware details if it is relevant.

Philip Kent (lsproc) wrote :

I can confirm this, Acer 1916W, and im on the livecd. Feisty x86.

Peter Ryan (peter-peterryan) wrote :

I have resolved this issue on a Dell D620 with a 1440x900 display with a GForce 7 Series graphics card in kubuntu / feisty

aptitude install nvidia-glx-new

restarted X-Server

with the d620 the 16x9 display is not properly detected. under system settings / monitor + display / administrator mode / hardware / monitor #1 I manually selected Generic / "Flat Panel 1440x900" and Image Format to Widescreen 16:9.

Apply Changes / restart X Server

Under System settings / monitor + display the resolution for 1440x900 was selected. i restarted my x server again and the resolution worked great.

I used the following link for the basis for this: http://thoughtworker.in/2007/04/24/kubuntu-704-feisty-fawn-getting-right-resolution/

however i had to install the nvidia-glx-new driver to get this to work.

Stéphane Graber (stgraber) wrote :

Will be fixed with Gutsy and the Xorg auto-detection (it works with my Acer 1440x900 monitor and all the others I tried with)
It's not the current default behaviour (as of Tribe-1), if you want to test it, simply remove your /etc/X11/xorg.conf (or move it somewhere else), then restart X.
I keep this bug opened as it's not fixed by default at the moment, but it'll most likely be closed with Gutsy release.

M. O. (marcusoverhagen) wrote :

I can confirm that the workaround of deleting xorg.conf works. I was able to swith from 1024*768 to the proper 1920*1200 with a HP LP2465.

Jerone Young (jerone) wrote :

xrespose is still being used in gusty Tribe-2 . When is this program going to disappear ? It appears Xorg (and randr) are doing a much better job at detecting then xrespose is.

Bryce Harrington (bryce) wrote :

The program will disappear after we have a high degree of confidence that xorg's detection is able to detect all scenarios that xresprobe can detect. I.e., we may want to hang onto xresprobe as a fallback.

However, I'm planning to discuss strategies for relying less on xresprobe at the distro sprint this next week. Hopefully by tribe-3 we'll have new code in here.

huy tran (novo2809) wrote :

Same here, Nvidia 6600, HANNS-G HW191D 19" Widescreen

omicron (linktodevnull) wrote :

The same problem for me using:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

And using an "Acer AL1916W" (19" 1440x900 Widescreen)


I am also encountering this bug.

dugger5688 (dugger) wrote :

Bug is still present in Gutsy tribe 5.

Bryce Harrington (bryce) wrote :

For Gutsy, I've tested and verified the use of the new Screens and Graphics admin tool for widescreen setting. Indeed, this configuration was my primary test case for the tool. So I know that provides an adequate way of dealing with this bug.

However, I'm leaving this bug open because the ultimate goal is to have this configuration auto-detected as it is on laptops. The plan here is, once Hardy is started, to make the installer stop configuring the monitor, and just leave it to xorg henceforth. The situations where xorg would get it wrong but the installer would get it right are growing vanishingly small and can probably be better dealt with by displayconfig-gtk post-install anyway, and we can arrange to fold those fixes in directly back to xorg.

Changed in xorg:
assignee: nobody → bryceharrington
Bryce Harrington (bryce) wrote :
Download full text (3.6 KiB)

Hi all,

The confirmers in this bug report are all seeing a variety of different bugs. Let me break things out:

1. Stéphane Graber and several others, I believe you may be seeing bug 27667. 27667 shows up for LCDs that ddcprobe reports as having "analog" connections. (In your case it is saying "input: sync on green, analog signal.") When you run xresprobe, it shows the monitor as a "crt" and returns a list of resolutions missing the correct (preferred) one. Generally, if simply adding the correct resolution for your LCD to xorg.conf by hand fixes it, then that's a good sign it's 27667 at work. Good news is I have a fix for 27667, so you should all be in good shape for Gutsy.

Because of this, I am marking this bug a dupe. However some of the confirmers are reporting different issues, and I'd like to address each of these, because they're unrelated:

2. Filip, the 1440x1440 detection is really wild, but you're not alone; it's bug 115220. I'm not sure what's going on here but it's probably something that can be sorted out. Please add details about your situation to that bug so we can investigate it further.

3. Václav Šmilauer, what you describe sounds different from the prior two cases. Buggy firmware is certainly not unique, however I'd want to doublecheck it's not just #1 first. If the solution for 27667 doesn't solve the issue for you, then I'd like you to open a new bug with as many details as possible (output from ddcprobe, xresprobe, lspci -vvnn, uname -a, Xorg.0.log, and xorg.conf).

4. Nick Marsh, your "edidfail" issue is distinct from the prior three, but also not uncommon. It is bug #94994. I don't know what's up with this one. Anyone experiencing this issue, please add as much info as possible to 94994. Like, is it an LCD? Is it connected via VGA or DVI, or some other way? If it's DVI, then if you use a DVI->VGA connector, does ddcprobe detect it properly? Does it get detected properly with other Linux or Windows operating systems? If you install the read-edid package, then what does `get-edid | parse-edid` say?

5. Adilson Oliveira, your issue sounds distinct from 1-2, because you cannot simply manually add the resolution but must add an option. I'm not sure whether its related to 3 or 4; I'd need to see your output from ddcprobe to be sure. But my guess is you're seeing an independent bug particular to your hardware models.

6. Jelle de Jong, your issue is more to do with dpi's. These are well reported elsewhere, but I don't know offhand which matches your case. Certainly part of that issue is that the resolutions and display sizes are incorrect, but in general that issue is separate from this particular one.

7. Will Daniels, your issue is a sub-bug of 27667. In the CRT resolution selection logic, aside from being a poor design, it also had a couple bugs in its implementation, including a sorting error that can result in x900 being preferred over x1050. (In fact, for me, that bug plus the main bug in 27667 canceled each other out, resulting in me getting the right default resolution, but for the wrong reason!) Good news is that removal of the CRT logic in the 27667 fix, also fixes this issue as w...


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers