Re: Laptop Power Management and 2.6.24+
Are there any generic daemons out there using the new event facilities that serve as a reasonable replacement for 'laptop-mode-tools' and/or 'acpi-support', and which work without X running? After grovelling around in a bunch of config files, I've partially answered my question. 'gnome-power-manager' is built on top of HAL, and performs all its actions through the org.freedesktop.Hal.Device.SystemPowerManagement interface. So, digging around through the HAL files, I found the scripts -- conveniently enough in /usr/lib/hal/scripts -- that are actually invoked to perform the actions. These scripts are themselves clients of 'pm-utils' (indeed 'hal' lists 'pm-utils' as a dependency). And 'pm-utils' has (just barely) the functionality needed to unload and reload flaky kernel modules on suspend and hibernate. It doesn't yet have the ability to specify a list of services to stop/restart, but the infrastructure's there. Now all I need is a non-GUI daemon to drive the whole thing. Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Laptop Power Management and 2.6.24+
My apologies for the saga appearing below, but I'm starting to get confused about where Debian is going vis a vis power management for laptops, and hoped to beg some advice. I currently have 'laptop-mode-tools', 'acpi-support', and 'hibernate' installed, which have served me well in the past. I selected them because: - 'laptop-mode-tools' appears to be the best maintained tool for flipping in and out of power saving modes when the mains are unplugged; - 'hibernate' has facilities for stopping and restarting services and unloading/reloading kernel modules that don't behave well. 'acpi-support' recently grew something similar to this, but from reading the scripts, it looked like 'acpi-support' and 'hibernate' could have a fight over who does what, and it wasn't clear who would or should win. So I stuck with 'hibernate'; - I don't, as a rule, use GNOME or KDE, and prefer all the little daemons running around to be universal and work no matter which window manager (*cough*WindowMaker*cough*) I happen to be using, including none at all. Anyhoo, I recently grabbed 2.6.24 and compiled my own copy. I always grovel through almost the entire config space, and found this somewhat imperious declaration for ACPI_PROC_EVENT: A user-space daemon, acpi, typically read /proc/acpi/event and handled all ACPI sub-system generated events. These events are now delivered to user-space via either the input layer, or as netlink events. This build option enables the old code for legacy user-space implementation. After some time, this will be moved under CONFIG_ACPI_PROCFS, and then deleted. Say Y here to retain the old behaviour. Say N if your user-space is newer than kernel 2.6.23 (September 2007). I keep my userspace pretty much pegged to 'unstable', which seems to me to be newer than September 2007. Yet when I turned on CONFIG_ACPI_PROCFS, things started breaking. 'acpid' won't run at all, since /proc/acpi/event no longer exists. Okay, fair enough, except that this causes 'laptop-mode-tools' to do essentially nothing, since ACPI events are no longer generated to drive it, and it doesn't appear to have grown support for the input layer or netlink events. After some Googling around, it seems there's a movement afoot to have all power-related stuff go through dbus. The only thing I've located so far that handles this is 'gnome-power-manager', which seems to lack the flexibility of 'acpi-support' and 'laptop-mode-tools', and it seems (unconfirmed) to demand an X server be running. I can turn CONFIG_ACPI_PROCFS back on in the meantime, I suppose, but I was wondering where things were headed with this. Are there any generic daemons out there using the new event facilities that serve as a reasonable replacement for 'laptop-mode-tools' and/or 'acpi-support', and which work without X running? Thanks in advance. Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Urgent: upgrading ipw3945 to 2.6.24
I tried the stock Debian kernel 2.6.24 plus firmware-iwlwifi from Sid but although the wireless card does seem to be recognized it doesn't connect. I spent several days wrestling with it but gave up in the end and stayed with the older kernel. iwl3945 works differently (read: not as well) from ipw3945. The wacky part is that you have to up the interface before you can associate to an AP. The sequence that seems to work reliably for me is: # ifconfig wlan0 up # iwconfig wlan0 essid linksys-netgear-belkin # ifup wlan0 Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Odd ACPI/Battery Behavior
I have a Sony Vaio VGN-S150 laptop that has been displaying odd behavior in reporting available battery power. While left charging, the system sometimes reports low or no energy remaining in the battery until it's fully charged, then reports 100%. Today I had occasion to run the battery to zero. I then plugged in the AC adapter and freshly cold-booted the machine. The ACPI meter persistently reported zero percent power available for well over an hour before it finally jumped to 100%, after the battery was fully charged. It seems to indulge in this strange behavior when the battery is drained to about 30% or lower. Here's a copy of an 'acpitool' report while it was empty but charging: [EMAIL PROTECTED]:~$ acpitool -e Kernel version : 2.6.17 -ACPI version : 20060127 --- Battery #1 : present Remaining capacity : 0 mWh, 0.00%, 05:34:55 Design capacity: 53280 mWh Last full capacity : 41580 mWh, 78.0% of design capacity Capacity loss : 22.0% Present rate : 7449 mW Charging state : charging Battery type : non-recharge, LION AC adapter : on-line Fan: not available CPU type : Intel(R) Pentium(R) M processor 1.60GHz CPU speed : 600.000 MHz Cache size : 2048 KB Bogomips : 1198.35 Processor ID : 0 Bus mastering control : yes Power management : yes Throttling control : yes Limit interface: yes Active C-state : C2 C-states (incl. C0): 3 Usage of state C1 : 10 (0.0 %) Usage of state C2 : 3216278 (100.0 %) T-state count : 8 Active T-state : T0 Thermal zone 1 : ok, 42 C Trip points : - critical (S5): 100 C passive: 90 C: tc1=1 tc2=2 tsp=50 devices=0xc1479620 Device Sleep state Status --- 1. PWRB 4* enabled 2. PCIB 3disabled 3. LANC 3disabled 4. EC0 5disabled 5. USB0 3disabled 6. USB1 3disabled 7. USB2 3disabled 8. USB7 3disabled 9. MODM 3disabled I'd replace the battery, but the prices for Sony-branded batteries are particularly usurious (and, with even OEM batteries exploding left and right, I'm not at all interested in going aftermarket). Has anyone seen anything like this before? Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Degraded i810/i915 Rendering Performance After Xorg 7 Upgrade
An update to my previous post: Today I updated a ton of Xorg components, and rendering performance for the i915 is now back to previous levels. Everything seems to be running as fast as before, including GL. I updated a *lot* of Xorg components, but my suspicion is that 'xserver-xorg-video-i810' was that one that did it (upgraded from 1:1.0.1.5-2 to 1:1.2.0-3). Others experiencing rendering performance issues with Intel integrated graphics may care to upgrade to the latest versions in unstable. Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Degraded i810/i915 Rendering Performance After Xorg 7 Upgrade
On Wed, Sep 20, 2006 at 09:34:31AM -0400, Andrew Perrin wrote: Your xorg.conf looks much like mine, and I've been having generally similar problems. Are you actually getting direct rendering? On my machine (same Intel chip), I get: direct rendering: No from glxinfo. Yes, 'glxinfo' reports direct rendering is working, and all the GL apps and screensavers run as well as they did before. But some of the ordinary screensavers are slower. In particular, FontGlide and FiberLamp have taken a big hit. Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Degraded i810/i915 Rendering Performance After Xorg 7 Upgrade
Yesterday I finally made the long-delayed upgrade from xorg 6.9 to 7. It required a lot of changes, including a kernel update from 2.6.12 to 2.6.17. After some fiddling with xorg.conf and a lot of visits to the Xorg69to7 Wiki, I now have a working xorg 7 desktop. However, rendering performance seems to have degraded somewhat. In particular, rendering operations requiring large copy blits are much slower than when using xorg 6.9. Screen savers that used to animate smoothly are now quite slow and/or stuttery. Ironically, accelerated OpenGL seems to work just great (I snagged Mesa 6.5, which just got placed in 'unstable' yesterday). The graphics chip is an Intel 945G Integrated Graphics Controller. Attached is a copy of my xorg.conf file. Does anyone have any suggestions as to what tweaks I might make? Thanks in advance. Schwab # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loaddbe # Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 EndSection Section Device Identifier Intel i915 Driver i810 BusID PCI:0:2:0 EndSection Section Monitor Identifier Generic Monitor Option DPMS # HorizSync 30-75 Doesn't work with Dell panel HorizSync 31-80 # VertRefresh 50-85 Doesn't work with Dell panel VertRefresh 56-76 Option DPMS Option NoDDC EndSection Section Screen Identifier Default Screen Device Intel i915 Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1600x1200 1280x1024 1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen
Re: X.org Troubles: XMMS Errors Out, GnuCash Rendering Slow
On Sun, Jul 31, 2005 at 08:59:58PM -0700, ewhac wrote: Everything seemed to work fine, and life went on. However, some time later, I noted that XMMS would no longer launch. The error message is: bash$ xmms Message: device: default Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 171 error_code 8 request_code 2 minor_code 0 [ ... ] I've also noted another issue with GnuCash: It's repainting its UI very slowly, as if it's using CPU-based rendering for everything. Everything seems to work fine; it's just really slow. If I had to guess, I'd say that one of the library upgrades left certain apps unable to find a compatible X visual mode, [ ... ] Found it! It turns out I was almost right. It wasn't the libs, it was the composite extension in X.org which adds new visuals to the reported list. Some apps don't deal with this very well. Solution: Prevent X from enumerating the additional visuals. This is done by setting the environment variable XLIB_SKIP_ARGB_VISUALS to 1. Thus, 'xmms' could be launched by saying: bash$ XLIB_SKIP_ARGB_VISUALS=1 xmms The same approach gets GnuCash running at full speed, too. Original reference: http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency#Enabling_shadows_and_real_transparency (near the bottom) Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X.org Troubles: XMMS Errors Out, GnuCash Rendering Slow
I tried upgrading my Debian unstable system to X.org, as described here: http://www.debian-administration.org/articles/185 Everything seemed to work fine, and life went on. However, some time later, I noted that XMMS would no longer launch. The error message is: bash$ xmms Message: device: default Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 171 error_code 8 request_code 2 minor_code 0 (The serial value changes with each invocation attempt.) Clearly I upgraded something to an incompatible version, and broke the app. I've tried downgrading selected libraries and uninstalling all visualizer plugins, to no avail. So far, XMMS is the only thing I've found that won't actually launch. I've also noted another issue with GnuCash: It's repainting its UI very slowly, as if it's using CPU-based rendering for everything. Everything seems to work fine; it's just really slow. If I had to guess, I'd say that one of the library upgrades left certain apps unable to find a compatible X visual mode, and they either abort (XMMS) or fall back to unaccelerated rendering (GnuCash), depending on the underlying libs. Any hints on getting at least XMMS running again would be greatly appreciated. Thanks in advance. Schwab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
