DPMS cannot suspend monitor in Gutsy

Bug #152999 reported by Dan Lenski
12
Affects Status Importance Assigned to Milestone
xorg-server (Fedora)
New
Undecided
Unassigned
xorg-server (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-vesa

I have an "ATI Technologies Inc RS482 [Radeon Xpress 200]" on-motherboard display adapter. I have to run it with the VESA driver rather than the ATI driver, due to various problems with the ATI driver that prevent it from using resolutions above 640x480 with my monitor.

Under Feisty, DPMS worked fine... the monitor would suspend itself according to the settings in the GNOME Power Management applet.

Under Gutsy, DPMS does not work. The monitor never suspends itself, and it fails even when explicitly activating DPMS from the command line:

$ xset dpms force off # nothing happens!
$ xset q
...
DPMS (Energy Star):
  Standby: 0 Suspend: 0 Off: 0
  DPMS is Enabled
  Monitor is On
...

*HOWEVER*, I *can* activate DPMS using vbetool which directly accesses the BIOS:
$ sudo vbetool dpms off # monitor suspends!
$ sudo vebtool dpms on # monitor turns back on!

So I believe this is a problem with the VESA driver. Here are the relevant portions of my /etc/X11/xorg.conf:

Section "Device"
        Identifier "ATI Technologies Inc RS482 [Radeon Xpress 200]"
        Driver "vesa"
        BusID "PCI:1:5:0"
EndSection

Section "Monitor"
        Identifier "DELL P991"
        Option "DPMS"
        HorizSync 30-107
        VertRefresh 48-120
EndSection

Section "Screen"
        Identifier "Default Screen"
        Device "ATI Technologies Inc RS482 [Radeon Xpress 200]"
        Monitor "DELL P991"
        DefaultDepth 24
        SubSection "Display"
                Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier "Default Layout"
        Screen "Default Screen"
        InputDevice "Generic Keyboard"
        InputDevice "Configured Mouse"

# Uncomment if you have a wacom tablet
# InputDevice "stylus" "SendCoreEvents"
# InputDevice "cursor" "SendCoreEvents"
# InputDevice "eraser" "SendCoreEvents"
EndSection

Related branches

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Dan,

Since you can trigger the bug using xset, it sounds like a bug in the server rather than in -vesa, so I'm re-filing against the server.
Also, can you let us know if this is still happening with Hardy?

Changed in xserver-xorg-video-vesa:
status: New → Incomplete
Revision history for this message
Dan Lenski (lenski) wrote :

Bryce,

I wouldn't say that xset "triggers" this bug, since the bug is due to a lack of behavior, rather than its presence.

Also, with the -ati driver running, xset and DPMS work fine... so I do NOT think the problem is with the server. I am downloading the Hardy packages right now, the mirrors are a bit overloaded but I'll be sure to update on its status under Hardy.

Revision history for this message
Dan Lenski (lenski) wrote :

Bryce,

I've got Hardy running now, and the bug still recurs :-( Now the ATI driver works, but only at 1280x1024 and below...

Bryce Harrington (bryce)
Changed in xorg-server:
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
selim ok (selimok) wrote :

This Bug appears also in our computers, which works with fedora 9.
The graphic cards are the same as reported above. Problem appears only when we select vesa driver.

Used packages:
xorg-x11-drv-vesa-2.0.0-1.fc9.i386
xorg-x11-server-Xorg-1.5.0-2.fc9.i386

Revision history for this message
Brian Harkness (maestro-bwh) wrote :

I can't win in intrepid. I have an intek 945 M card. The intel driver doesn't work properly and x crashes (known bug). I can use vesa, but then my screen stays on.

Revision history for this message
Brian Harkness (maestro-bwh) wrote :

intel 945M

Revision history for this message
gam3 (gam3-launchpad) wrote :

Have the same problem with and en8500.

vbetool works but vesa driver does not.
The nVidia driver (from nVidia) works as well.

I would also like to point out the the vgacon driver (drivers/video/console/vgacon.c) in the 2.6.30 kernel also fails to "suspend" the monitor.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.9 KiB)

This bug was fixed in the package xorg-server - 2:1.6.4-2ubuntu1

---------------
xorg-server (2:1.6.4-2ubuntu1) karmic; urgency=low

  * Merge from Debian unstable. (LP: #447010)
    Remaining Ubuntu changes:
    - debian/control:
      + set Conflicts: xkb-data (<< 0.9), since xkb-path is
        different from previous releases
      + do not Conflict with xserver-xorg-video
      + xvfb Depends on xauth, xfonts-base
      + Set Maintainer to Ubuntu Core Developers
    - debian/rules:
      + build using -fno-stack-protector
      + --with-os-vendor=Ubuntu
    - debian/xserver-xorg-core.install:
      + Add ioport, pcitweak, scanpci scripts & man pages
    - debian/patches:
      + 101_fedora_xserver-1.3.0-document-fontpath-correctly.patch:
        Specify correct paths to fonts
      + 102_ubuntu_sharevts_load_cpu.patch:
        close console fd only when ShareVTs
      + 103_psb_auto.patch:
        Autodetect poulsbo devices (but use -vesa since -psb is broken)
      + 110_fedora_no_move_damage.patch:
        further aiglx support
      + 121_only_switch_vt_when_active.diff:
        Add a check to prevent the X server from changing the VT when killing
        GDM from the console.
      + 135_rethrow_signals.patch:
        When aborting, re-raise signals for apport
      + 140_quell_acpi_errmsgs.patch:
        Avoid generating extraneous warnings when acpi is missing
      + 153_make_dmx_compile.patch:
        Change xcalloc -> calloc, so that dmx compiles.
      + 156_exevents_copykeyclass_nullptrcheck.patch,
        157_check_null_modes.patch, 162_null_crtc_in_rotation.patch,
        166_nullptr_xinerama_keyrepeat.patch, 167_nullptr_xisbread.patch
        169_mipointer_nullptr_checks.patch,
        172_cwgetbackingpicture_nullptr_check.patch:
        Fix various segfaults in xserver by checking pointers for NULL
        values before dereferencing them.
      + 164_trap-aspect-ratios.patch:
        Correct monitor EDIDs that have misreported aspect ratios.
      + 165_man_xorg_conf_no_device_ident.patch
        Correct man page
      + 168_glibc_trace_to_stderr.patch:
        Report abort traces to stderr instead of terminal
      + 174_set_bg_pixmap_of_cow_to_none.patch:
        Set background pixmap of composite overlay window to no background
      + 177_animated_cursor_change_master.patch:
        Don't create animated cursors for slave devices
      + 180_fedora_no_synaptics_mouse_synthesis.patch:
        Don't synthesize a mouse section if a synaptics device is found
      + 181_fedora_log_proc_cmdline.patch:
        Dump /proc/cmdline in the log file too
      + 184_virtual_devices_autodetect.patch:
        Use vesa for qemu device, which is not supported by cirrus
      + 185_dix_badwindow.patch:
        Don't return BadMatch from GetProperty if window isn't actually a window
      + 186_autoconfig_geode.patch
        Perform autodetection correctly for various geode devices
  * Update 184_virtual_devices_autodetect.patch to only include inserting
    cirrus, since vbox is covered by the new fedora patch.
  * Drop patches already included upstream:
    - 187_lastdeviceeventtime-no-reset.patch
    - 178_glx_flush_cache.patch
  ...

Read more...

Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Jason K (jas-cse) wrote :

I'm running the latest xorg server under karmic, with Intel 945G Integrated graphics, and xset dpms force off only causes the monitor to blank, and while vbetool can turn it off, it can't turn it back on! I have to reboot! (It's an all-in-one).

Revision history for this message
rabin-hood (spam71) wrote :

You don't have to reboot. Just type blindly: "sudo xset dpms force on" and the screen will turn on.

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

Other bug subscribers

Remote bug watches

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