From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060223 Fedora/1.5.0.1-5 Firefox/1.5.0.1 Description of problem: gnome-power-manager thinks my MX-1000 cordless mouse is not charged, but it is. Detecting a 0% charge seems to have helped lead to the crash in bug #183127 (see Richard Hughes' comment #4). Version-Release number of selected component (if applicable): gnome-power-manager-2.13.92-3 How reproducible: Always Steps to Reproduce: 1. note charge level reported by gnome-power-manager 2. 3. Actual Results: 0% charge reported Expected Results: correct charge level should be reported Additional info: This version of gnome-power-manager is from bug #183127, comment #8.
Created attachment 125558 [details] notification Notification that the battery is at 0%
Created attachment 125559 [details] gnome-power-manager verbose output
"Error: No property battery.charge_level.percentage on device with id /org/freedesktop/Hal/devices/usb_device_46d_c50e_noserial" Looks like HAL isn't setting the right properties. Reassigning to HAL componenet...
>Looks like HAL isn't setting the right properties. Not really, battery.charge_level.percentage is optional. What does lshal |grep battery report?
[bjohnson@localhost ~]$ lshal | grep battery info.capabilities = {'battery'} (string list) battery.command_interface = 'csr' (string) info.category = 'battery' (string) battery.charge_level.last_full = 7 (0x7) (int) battery.charge_level.design = 7 (0x7) (int) battery.present = true (bool) battery.csr.is_dual = false (bool) battery.csr.has_sms = false (bool) battery.csr.has_res = false (bool) battery.is_rechargeable = true (bool) battery.type = 'mouse' (string)
So its fully charged... hmm. Give me 5 minutes.
I get this: info.capabilities = {'battery'} (string list) battery.charge_level.percentage = 42 (0x2a) (int) battery.charge_level.current = 3 (0x3) (int) battery.command_interface = 'csr' (string) info.category = 'battery' (string) battery.charge_level.last_full = 7 (0x7) (int) battery.charge_level.design = 7 (0x7) (int) battery.present = true (bool) battery.csr.is_dual = false (bool) battery.csr.has_sms = false (bool) battery.csr.has_res = false (bool) battery.is_rechargeable = true (bool) battery.type = 'mouse' (string) Notice that your `lshal | grep battery` does not include battery.charge_level.current which is why g-p-m cannot compute a percentage from the device. This smells like a HAL problem, i.e. a problem with the CSR addon -- is it running, i.e. what does: ps -fA |grep csr return?
[bjohnson@localhost ~]$ ps -fA | grep csr root 3785 2090 0 03:22 ? 00:00:00 /usr/libexec/hald-addon-usb-csr bjohnson 3825 3804 0 03:23 pts/1 00:00:00 grep csr
what about if you do (as root): /sbin/service haldaemon stop /usr/sbin/hald --daemon=no --verbose=yes &> /tmp/hald.txt /sbin/service haldaemon start and then attach /tmp/hald.txt Thanks, Richard.
Created attachment 125587 [details] haldaemon verbose output as requested
So it gets it wrong first, 3934: 03:32:34.859: addon-usb-csr.c:149: Charge level: 0->5 And gets it right a few moments after. 3934: 03:33:04.871: addon-usb-csr.c:149: Charge level: 5->5 Please disconnect your mouse, and restart haldaemon. then run "lshal -m" in one open window then plug it in and wait a few moments. What does that give? Thanks. Richard.
[root@localhost ~]# service haldaemon restart Stopping HAL daemon: [ OK ] Starting HAL daemon: [ OK ] [root@localhost ~]# lshal -m Start monitoring devicelist: ------------------------------------------------- usb_device_46d_c50e_noserial added usb_device_46d_c50e_noserial property battery.present = true (new) usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new) usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new) usb_device_46d_c50e_noserial property info.category = 'battery' (new) usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new) usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new) usb_device_46d_c50e_noserial capability battery added usb_device_46d_c50e_noserial_if0 added usb_device_46d_c50e_noserial_usbraw added usb_device_46d_c50e_noserial_if0_logicaldev_input added
That is very odd. Are you running dbus 0.61 by any chance? Could you try downgrading to 0.60 and see if that fixes the lshal -m output to include battery.charge_level.current. I have a hunch this might work. Richard.
Since this was a fully updated rawhide system, the dbus version was dbus-0.61-3. I downgraded dbus (and dependencies) to dbus-0.60-7.2. The results appear to be the same: [root@localhost ~]# service haldaemon restart Stopping HAL daemon: [ OK ] Starting HAL daemon: [ OK ] [root@localhost ~]# lshal -m Start monitoring devicelist: ------------------------------------------------- usb_device_46d_c50e_noserial added usb_device_46d_c50e_noserial property battery.present = true (new) usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new) usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new) usb_device_46d_c50e_noserial property info.category = 'battery' (new) usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new) usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new) usb_device_46d_c50e_noserial capability battery added usb_device_46d_c50e_noserial_if0 added usb_device_46d_c50e_noserial_if0_logicaldev_input added usb_device_46d_c50e_noserial_usbraw added
Have you tried turning off selinux? Do you get any avc denied messages in your logs?
I have tried putting selinux in permissive mode with the same result as enforcing mode. I do get a couple of avc: denied messages in both cases. Would there be any reason to turn off selinux rather than just use permissive mode?? Audit messages produced by plugging in the mouse: type=AVC msg=audit(1141674754.524:41): avc: denied { read write } for pid=2584 comm="hald-addon-usb-" name="003" dev=tmpfs ino=3791 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.524:41): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.524:41): cwd="/usr/libexec" type=PATH msg=audit(1141674754.524:41): item=0 name="/dev/bus/usb/001/003" flags=101 inode=3791 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:02 type=AVC msg=audit(1141674754.524:42): avc: denied { read } for pid=2584 comm="hald-addon-usb-" name="003" dev=tmpfs ino=3791 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.524:42): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.524:42): cwd="/usr/libexec" type=PATH msg=audit(1141674754.524:42): item=0 name="/dev/bus/usb/001/003" flags=101 inode=3791 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:02 type=AVC msg=audit(1141674754.524:43): avc: denied { read write } for pid=2584 comm="hald-addon-usb-" name="002" dev=tmpfs ino=3504 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.524:43): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.524:43): cwd="/usr/libexec" type=PATH msg=audit(1141674754.524:43): item=0 name="/dev/bus/usb/001/002" flags=101 inode=3504 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:01 type=AVC msg=audit(1141674754.524:44): avc: denied { read } for pid=2584 comm="hald-addon-usb-" name="002" dev=tmpfs ino=3504 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.524:44): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.524:44): cwd="/usr/libexec" type=PATH msg=audit(1141674754.524:44): item=0 name="/dev/bus/usb/001/002" flags=101 inode=3504 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:01 type=AVC msg=audit(1141674754.528:45): avc: denied { read write } for pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3474 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.528:45): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.528:45): cwd="/usr/libexec" type=PATH msg=audit(1141674754.528:45): item=0 name="/dev/bus/usb/001/001" flags=101 inode=3474 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:00 type=AVC msg=audit(1141674754.528:46): avc: denied { read } for pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3474 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.528:46): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.528:46): cwd="/usr/libexec" type=PATH msg=audit(1141674754.528:46): item=0 name="/dev/bus/usb/001/001" flags=101 inode=3474 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:00 type=AVC msg=audit(1141674754.528:47): avc: denied { read write } for pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3418 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.528:47): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.528:47): cwd="/usr/libexec" type=PATH msg=audit(1141674754.528:47): item=0 name="/dev/bus/usb/002/001" flags=101 inode=3418 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:80 type=AVC msg=audit(1141674754.528:48): avc: denied { read } for pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3418 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1141674754.528:48): arch=40000003 syscall=5 success=no exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-" exe="/usr/libexec/hald-addon-usb-csr" type=CWD msg=audit(1141674754.528:48): cwd="/usr/libexec" type=PATH msg=audit(1141674754.528:48): item=0 name="/dev/bus/usb/002/001" flags=101 inode=3418 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:80
Might be worth disabling it completely and seeing if that does the trick.
permissive mode `setenforce 0` should turn off se-linux but still get you log messages so if it doesn't work with permissive mode it won't work even if you shut se-linux off. That being said the logs do show some issues with usb.
I just noticed that if I boot with selinux=0 or permissive mode, the gnome-power-manager applet does not appear until after I unplug the mouse and plug it back in. In enforcing mode, it appears right away. I don't know if that's helpful or not.
I'm seeing the same problems; same mouse with the same selinux errors. Setting permissive mode, restarting hal, restarting gnome-power-manager, and replugging the mouse don't seem to fix anything. I'm running current rawhide.
I should add: zero> lshal | grep battery battery.charge_level.percentage = 100 (0x64) (int) battery.charge_level.current = 7 (0x7) (int) info.capabilities = {'battery'} (string list) battery.command_interface = 'csr' (string) info.category = 'battery' (string) battery.charge_level.last_full = 7 (0x7) (int) battery.charge_level.design = 7 (0x7) (int) battery.present = true (bool) battery.csr.is_dual = false (bool) battery.csr.has_sms = false (bool) battery.csr.has_res = false (bool) battery.is_rechargeable = true (bool) battery.type = 'mouse' (string) zero>
I went ahead and filed bug #184431 against selinux-policy-targeted. It doesn't appear to specifically cause this problem, but once this is resolved, it likely won't work without a policy update either.
I was just noticing in comment #21 that Thomas has battery.charge_level.percentage, so I decided to investigate further. As it turns out, there is definately a selinux problem when in enforcing mode. Here is the output differences from lshal in enforcing and permissive mode: [bjohnson@localhost ~]$ diff -u enforcing permissive --- enforcing 2006-03-08 12:22:11.000000000 -0700 +++ permissive 2006-03-08 12:23:45.000000000 -0700 @@ -1,4 +1,6 @@ info.capabilities = {'battery'} (string list) + battery.charge_level.percentage = 100 (0x64) (int) + battery.charge_level.current = 7 (0x7) (int) battery.command_interface = 'csr' (string) info.category = 'battery' (string) battery.charge_level.last_full = 7 (0x7) (int) So I went ahead and checked 'lshal -m' as I plugged in the mouse. It is different in enforcing mode. In permissive mode, the last two lines appear about 10-15 seconds after the device is plugged in. [bjohnson@localhost ~]$ lshal -m Start monitoring devicelist: ------------------------------------------------- usb_device_46d_c50e_noserial added usb_device_46d_c50e_noserial property battery.present = true (new) usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new) usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new) usb_device_46d_c50e_noserial property info.category = 'battery' (new) usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new) usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new) usb_device_46d_c50e_noserial capability battery added usb_device_46d_c50e_noserial_if0 added usb_device_46d_c50e_noserial_usbraw added usb_device_46d_c50e_noserial_if0_logicaldev_input added usb_device_46d_c50e_noserial property battery.charge_level.current = 7 (0x7) (new) usb_device_46d_c50e_noserial property battery.charge_level.percentage = 100 (0x64) (new) It does not, however, change the problem with the charge level being properly displayed in gnome-power-manager.
Created attachment 125831 [details] gnome-power-manager verbose output (permissive mode)
Now that my device is showing charge percentage, I did try to go back and try the old version of dbus as suggested in comment #13 again. Last time I tried it, I basically got the same results as with 0.61. Now I can't run it at all: gnome-power-manager: symbol lookup error: gnome-power-manager: undefined symbol: dbus_g_type_get_struct
Yes, there was an issue with dbus-0.61 and g-p-m in the glib bindings since now the glib bindings have a struct type. The newwer g-p-m was patched to use the new struct type and in only compatable with 0.61. We should up the Requires line for the new dbus verion in the g-p-m spec. If you upgrade to the latest stuff it might fix the battery issue or may not. Try it out.
After todays updates, avc messages are gone but so is the gnome-power-manager icon. It's running but doesn't report about the mouse at all.
Thomas Once your desktop is loaded, try unplugging your mouse and plugging it back in. On my system, that brings up gnome-power-manager.
That does indeed make it show up but it still incorrectly reports the mouse status. I'm guessing it should also come up on its own too.
FYI Richard, I was looking at the Ubuntu 5.10 live CD and it has the exact same behaviour (ie. requires unplugging and the plugging back in to get g-p-m to display, and then once displayed, it can't detect the mouse charge).
I've just added this to CVS HEAD: 2006-04-03 Richard Hughes <richard> * src/gpm-hal-monitor.c (watch_device_properties_modified): Don't switch round the removed and added booleans, the order is "added" then "removed". * src/gpm-hal-monitor.c (watch_device_property_modified): Emit the signal for modified *or* new keys, not just modified keys. This fixes the problem where HAL is slow creating the keys, which can happen with the CSR mouse and keyboard addon. This is a HAL bug, but there's no reason we can't make the mice work after a little delay. As the problem has just happened to me. I'll work on a HAL fix, but this patch should mean that you get a few seconds of the "low mouse icon" and when HAL sorts itself out, then the proper values can be processed. Richard.
Will this patch (gpm) be pushed into FC5-updates or FC5-updates-testing soon?
It will be part of 2.14.1, so when that is released (today or tomorrow) then yes.
Richard- Is there a bugzilla id associated with the HAL bug referenced in Comment #31?
Bernard, no, not yet. The issue is the Logitech mouse saying it's "busy" when we do the initial "fillup" of values, and then we have to wait for the next polled refresh. I'm really busy at the moment, but it's still on my TODO list.
This appears to be resolved in FC6.
Closing as this is fixed.