After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 93875 - acpi support shouldn't query "info" every second, only "state".
acpi support shouldn't query "info" every second, only "state".
Status: RESOLVED DUPLICATE of bug 88553
Product: gnome-applets
Classification: Other
Component: battery
unspecified
Other other
: Normal normal
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-09-22 11:22 UTC by Erich Schubert
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Erich Schubert 2002-09-22 11:24:40 UTC
Package: gnome-applets
Severity: normal
Version: 2.0.3
Synopsis: acpi support shouldn't query "info" every second, only "state".
Bugzilla-Product: gnome-applets
Bugzilla-Component: battery

Description:
Description of Problem:
Mouse moves choppy, as the machine is blocked once a second for a few
usecs.

Steps to reproduce the problem:
1. use the battery applet to monitor the battery on my Dell Inspiron
8100
2. watch how the mouse moves with and without the applet

Actual Results:
Mouse moves choppy, not smooth

Expected Results:
gkacpi doesn't disturb by mouse.

How often does this happen?
every second.

Additional Information:
This most probably is Hardware, BIOS and acpi-kernel-version dependant.
The machine is an Dell Inspiron 8100, with the A12 Bios, and acpi
version 20020503

Running
  while true; do cat /proc/acpi/battery/BAT1/state; sleep 1; done
doesn't give me this problem, but running
  while true; do cat /proc/acpi/battery/BAT1/info; sleep 1; done
does exhibit it.
The first file, "state" contains all information that changes (such as
current battery capacity), whereas "info" also contains the
manufacturer, battery type, serial number, model number...
Querying "info" once for each battery should be enough. (the battery
then needs to detect when a new battery is inserted though)




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-09-22 07:24 -------

Reassigning to the default owner of the component, gnome-applets-maint@bugzilla.gnome.org.

Comment 1 Erich Schubert 2002-09-25 11:40:31 UTC
http://lists.debian.org/debian-laptop/2002/debian-laptop-200209/msg00460.html
(untested patch)

This patch is expected to fix this issue; but i think it will only
detect my secondary battery socket (named BAT0) not the one i use for
my battery; it needs multi-battery support.

But it certainly is an improvement to the current situation that makes
the applet unuseable for me - the patch should make it working and
useable when i put the battery in the other socket.
Comment 2 mjs 2002-11-10 23:47:10 UTC
Is this likely to be the same issue as described in
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74645?  The system
clock on my Dell Latitude C610 loses about 10 sec/hour.  It has been
reported that disabling the battery applet cures the problem.  

This issue for me is with the stock Red Hat kernel, so it is APM
rather than ACPI, but based on some discussion in
psyche-list@redhat.com, it sounds like the same thing (clock
interrupts lost when battery applet updates).
Comment 3 Kevin Vandersloot 2002-12-06 21:28:43 UTC

*** This bug has been marked as a duplicate of 88553 ***