livecd not started in 1440x900, but in 1024x768 [dapper,feisty]

console output of the "xresprobe nv" command

The contents of the /tmp/xprobe.7595 directory that goes with the previous xresprobe nv console output attachment.

Attachment contains generated
xorg.conf
xorg.log
xorg-stdout.log

thanks for separating it, please can you also add the generated xorg.conf and xorg.0.log ?

Fabio

oh if i did ask already for the info, sorry.. i just want to keep data of the same bug in the same place for the sake of my own mind sanity :)

Fabio

Hey, no problem.

I assume everything you want to know is correctly attached to this bug report?

If you want any extra information, just let me know.

Jeroen

Yes thanks. It seems there is everything.

Fabio

Oh meh.. I need the xorg.conf that is generated in /etc/X11/xorg.conf and the /var/log/Xorg.0.log when you boot the livecd.

The ones from xresprobe are not very useful since xresprobe is returning the correct resolution.

Thanks a lot
Fabio

Hi,

I attached the generated /etc/X11/xorg.conf and /var/log/Xorg.0.log from running the livecd (dapper live i386 - 9 May 2006 07:46).

Could you please do the following:

- boot the live cd, but add "break=bottom" to the kernel command line.
- once you get a shell, type:
 chroot /root mount /sys
 chroot /root mount /proc
 chroot /root xresprobe nv

and attach the output of xresprobe?

Thanks
Fabio

Hi,

Unfortunately I couldn't find an easy way to retrieve the logfiles from the initramfs environment, since I couldn't mount a usb-stick.. so I'll put all information I gathered below:

After "spawning shell within initramfs" I switched to terminal 8 and:

I set XRESPROBE_DEBUG to 1, since I wasn't getting usefull information

... did the chroot statements as described in request ...

"xresprobe nv" results in:
laptop: ; dcc: yes
id:
res:
freq:
display:

"xresprobe nv laptop" results in:
laptop: yes; dcc:
id:
res: 1400x1900
freq:
display: lcd/lvds

I did some tinkering in xresprobe to see what it actually does. If you don't pass 'laptop' (2nd parameter), it uses laptop-detect.

In xresprobe:
* which latop-detect results in the full path to laptop-detect (to stdout)
* laptop-detect results in NO output to stdout, although $? is set to 1 (I'm assuming this means laptop-detect detected a laptop)

adding some echo statements to xresprobe, it seems that it indeed finds laptop-detect, but the "if laptop-detect ..." constructuion does not result in LAPTOP=yes, which causes the remaining part of xresprobe to fail x detection.

I hope this helps pinpoint the problem. If I can do any further investigation, just let me know.

Hi,

Testing with todays livecd (20060513) with casper 1.52 this problem is still present.
I'm wondering if the problem isn't somewhere else, since I found the following in the X logging:

(--) NV(0): CRTC 0 is currently programmed for DFP
(II) NV(0): Using DFP on CRTC 0
(--) NV(0): Panel size is 1440 x 900
(II) NV(0): Panel is LVDS
(--) NV(0): VideoRAM: 131072 kBytes
(==) NV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) NV(0): Generic Monitor: Using hsync range of 28.00-51.00 kHz
(II) NV(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
(II) NV(0): Clock range: 12.00 to 400.00 MHz

And after that a bunch of statements on:

(II) NV(0): Not using default mode "xxxxx" (vrefresh out of range)

and

(II) NV(0): Not using default mode "xxxxx" (bad mode clock/interlace/doublescan)

Isn't the problem that a "Generic Monitor" is used, with certain hsync/vrefresh settings and those perhaps not match with my 1440 x 900 panel?

This was fixed a while ago as reported by the submitter.

Fabio

Hmm,

As far as I know it was not fixed yet (and I'm the submitter).
I can test on a more recent livecd, since I last test on 20060513?

I can confirm that this bug still exists in dapper-desktop-i386.iso 24-May-2006 21:38.

I can confirm this bug also.

Please test with Feisty Herd5 or the upcoming Beta.

Hi,

I tried booting the feisty desktop herd5 i386 cd, but I still got the same results (1024x768 resolution instead of 1440x900)

Attached is the Xorg logging showing this.

A lot of others have reported very similar issues. I'm grouping all of this together as dupes of 49827; if you disagree please let me know.

[Expired for xorg (Ubuntu) because there has been no activity for 60 days.]