Re: Laptop Power Management and 2.6.24+

2008-04-23 Thread Leo L. Schwab
 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+

2008-04-22 Thread Leo L. Schwab
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

2008-04-20 Thread Leo L. Schwab
 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

2006-10-04 Thread Leo L. Schwab
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

2006-10-02 Thread Leo L. Schwab
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

2006-09-21 Thread Leo L. Schwab
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

2006-09-20 Thread Leo L. Schwab
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

2005-08-01 Thread Leo L. Schwab
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

2005-07-31 Thread Leo L. Schwab
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]