vbetool autoconfig fails to set 915resolution config

I can confirm this bug as well. X no longer starts in the correct resolution either. Setting the MODE, XRESO, and YRESO explicitly in /etc/default/915resolution still works of course.

The vbetool error mentioned comes from the fact that /etc/init.d/915resolution runs 'vbetool vbecall panelsize'. There is not argument called vbecall. The proper way to query the panel size is 'vbetool vbefp panelsize'.

However, fixing /etc/init.d/915resolution to call vbetool properly still doesn't fix the problem.

I got the same result:
$ sudo /etc/init.d/915resolution start
Starting 915resolution: /usr/sbin/vbetool: Usage /usr/sbin/vbetool...or install 'vbetool'.

I do have the latest version (0.6-1) installed.

I also see this bug. Unlike for Bradley, fixing the init.d script to do "vbefp panelsize" makes it correctly automatically detect my panel and make it work at the right resolution (1280x800) with MODE=auto. (Perhaps Bradley is the victim of another bug as well?)

I have a Dell Inspiron 630m laptop, with a "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)".

Indeed... it seems the AUTO mode of 915resolution replaces my VESA text mode. Here's a diff from 915resolution -l when configured manually and automatically:

--- 915resolution-l.manual 2006-05-24 09:35:42.000000000 +0200
+++ 915resolution-l.auto 2006-05-24 09:32:33.000000000 +0200
@@ -13 +13 @@
-Mode 3c : 1280x800, 8 bits/pixel
+Mode 3c : 1920x1440, 8 bits/pixel
@@ -19 +19 @@
-Mode 4d : 1280x800, 16 bits/pixel
+Mode 4d : 1920x1440, 16 bits/pixel
@@ -25,4 +25,4 @@
-Mode 5c : 1280x800, 32 bits/pixel
-Mode 60 : 512x771, 8 bits/pixel
-Mode 61 : 512x771, 16 bits/pixel
-Mode 62 : 512x771, 32 bits/pixel
+Mode 5c : 1920x1440, 32 bits/pixel
+Mode 60 : 1280x800, 8 bits/pixel
+Mode 61 : 1280x800, 16 bits/pixel
+Mode 62 : 1280x800, 32 bits/pixel

I think this is correct given the description of AUTO mode:
# With 'auto' detection, the panel-size will be fetched from the VBE
# BIOS if possible and the highest-numbered mode in each bit-depth
# will be overwritten with the detected panel-size.

If you think THIS is a bug, please file a new bug report. Because this one is only about vbecall not called correctly/at all.

This was a "D'oh" on my part. I had the 'vbetool' package installed for testing (of the same version number) before I did an upload to Debian. In the mean time this was changed from 'vbecall' to 'vbefp' for "Flat-Panel extensions.

 915resolution (0.5-1ubuntu6) dapper; urgency=low
 .
   * Call 'vbetool' with 'vbefp' instead of 'vbecall'; this was
     changed before uploading to Debian.

Michael: can you file a separate bug please. If you read the text in:

  /etc/init.d/915resolution

This is currently:

    # For want of a better approach to selecting modelines for stealing;...
    # this expression grabs us the highest *numbered* mode in each
    # bit-depth that the BIOS already lists.
    #
    # An argument for using the highest mode-number, rather than the
    # highest resolution is that if we've already reprogrammed the
    # mode to be a lower resolution it will no longer be the highest.

I'm certainly welcome to suggestions (BTW, this problem will have disappeared by Dapper+1 because Intel have donated code to Xorg to be able to program the modes, rather than going through the BIOS.