Removing the watch_all

Hi,

libhal.c and libhal.h define a function libhal_device_property_watch_all()
allowing a callback on any device changed.  There is not a corresponding
remove function that I could find.  I was triggering a resource fault
(too many watches not surprisingly) in network manager by continually
restarting hal.  I added the function shown below and ensured that the
hal_deinit() function in network manager called this and that seemed to
resolve the issue.

Comments?  Is there an easier way to do this?

Drew

Signed-off-by: Drew Moseley <dmoseley <at> mvista.com>

diff --git a/libhal/libhal.c b/libhal/libhal.c
index 9e4b99f..c9d9f74 100644
--- a/libhal/libhal.c
+++ b/libhal/libhal.c
 <at>  <at>  -3196,6 +3196,22  <at>  <at>  libhal_device_property_watch_all (LibHalContext *ctx, DBusError *error)
 }

 
+dbus_bool_t
+libhal_device_property_remove_watch_all (LibHalContext *ctx, DBusError *error)
+{
+	LIBHAL_CHECK_LIBHALCONTEXT(ctx, FALSE);
+
+	dbus_bus_remove_match (ctx->connection,

volume label parsing regression

Hello all,

https://launchpad.net/bugs/347370 reported a regression in volume
labels in hal. Spaces are now mangled to '_'.

I tracked this down to 79b92dbdf65b8c978d5a8f6fb2b421aac83c3de3 and
committed a fix:

  Not probing volumes ourselves and reading from the udev db (commit
  79b92dbdf65b8c978d5a8f6fb2b421aac83c3de3) caused a regression:
  udevadm info's ID_FS_LABEL is mangled, e. g. spaces appear as '_'.
  Use ID_FS_LABEL_ENC instead and use a new hal/util.c function
  hal_util_decode_escape() to decode those. 

  http://cgit.freedesktop.org/hal/commit/?id=97b023f94f1d79a19bc0489c0d167bdaebb765fd

It works well for me, but I always appreciate a second pair of eyes.

Thank you!

Martin
--

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Hello all,

https://launchpad.net/bugs/347370 reported a regression in volume
labels in hal. Spaces are now mangled to '_'.

"pre-exec" support for addons?

i believe the answer is "no", but just in case:  does hal have
explicit support for "pre-" or "post-" actions when starting or
stopping an addon daemon?  in my case, i have an addon which
needs to have the uinput module loaded before it starts. 
a previous version of this daemon was managed by upstart, where a
"pre-start exec modprobe uinput" in the event.d file took care of
it.

i can obviously move the modprobe into the daemon startup itself,
but if there's another preferred method, i'd use it instead.

paul
=---------------------
 paul fox, pgf <at> laptop.org

BUG wrong values for battery

Hi,

hal sets wrong values for the battery on my laptop.

my Configuration:
- gentoo-sources
- hal version 0.5.12_rc1 with the USE-Flags "X acpi crypt kernel_linux 
laptop".
- "sysfs" is activated in kernel

These variables are wrong:

battery.charge_level.percentage
battery.charge_level.rate
battery.reporting.rate

It seems to me the percentage is calculated by the following formula on 
my system:

battery.charge_level.percentage = battery.charge_level.current / 
battery.charge_level.design * 100

This is the reason why I get 65 % as maximum percentage.

The *.rate variables have a maximum value of 2500 if I compile 
something. This cause a remaining time >20 hours.

Regards,
Andrwe

Property 'bluetooth_hci.address' not reliable?

Good afternoon :)

I'm using HAL to find any Bluetooth devices attached to my computer in
order to get (amongst other things) their MAC address. I've found the
'bluetooth_hci.address' property to be no reliable way to do this.

For example: I have two Bluetooth devices, one internal and one attached
via USB. The output of this code:

#!/usr/bin/python

import dbus

dbus_systembus = dbus.SystemBus()
hal_obj = dbus_systembus.get_object('org.freedesktop.Hal',
'/org/freedesktop/Hal/Manager')
dbus_hal = dbus.Interface(hal_obj, 'org.freedesktop.Hal.Manager')

for item in dbus_hal.FindDeviceByCapability('bluetooth_hci'):
    device_obj = dbus_systembus.get_object('org.freedesktop.Hal', item)
    device = dbus.Interface(device_obj, 'org.freedesktop.Hal.Device')
    print hex(device.GetProperty('bluetooth_hci.address'))

gives me:

0x1a7d0ac265L
0x0L

As you can see, the first is the correct MAC address of the external
device, but the address of the internal device is 0. The output of

Re: Property 'bluetooth_hci.address' not reliable?

On Sat, 2009-04-04 at 16:56 +0200, Roel Huybrechts wrote:
> Good afternoon :)
> 
> 
> I'm using HAL to find any Bluetooth devices attached to my computer in
> order to get (amongst other things) their MAC address. I've found the
> 'bluetooth_hci.address' property to be no reliable way to do this.

The address of the device will be 00:00:00:00:00:00 before it's been
powered up. HAL probably gets the property before the device is fully
setup, or the Bluetooth netlink kernel code isn't telling HAL the
address changed. Either way, use the BlueZ D-Bus interface instead.

Cheers

Re: BUG wrong values for battery

Dear Andrwe,

Am Samstag, den 04.04.2009, 15:22 +0200 schrieb Andrwe Lord Weber:

> hal sets wrong values for the battery on my laptop.
> 
> my Configuration:
> - gentoo-sources
> - hal version 0.5.12_rc1 with the USE-Flags "X acpi crypt kernel_linux 
> laptop".
> - "sysfs" is activated in kernel
> 
> These variables are wrong:
> 
> battery.charge_level.percentage
> battery.charge_level.rate
> battery.reporting.rate
> 
> It seems to me the percentage is calculated by the following formula on 
> my system:
> 
> battery.charge_level.percentage = battery.charge_level.current / 
> battery.charge_level.design * 100
> 
> This is the reason why I get 65 % as maximum percentage.
> 
> The *.rate variables have a maximum value of 2500 if I compile 
> something. This cause a remaining time >20 hours.

As far as I know HAL just reports the values from the Linux kernel(?)

Re: BUG wrong values for battery

Dear Paul,

Paul Menzel wrote:
> Dear Andrwe,
>
>
> Am Samstag, den 04.04.2009, 15:22 +0200 schrieb Andrwe Lord Weber:
>
>    
>> hal sets wrong values for the battery on my laptop.
>>
>> my Configuration:
>> - gentoo-sources
>> - hal version 0.5.12_rc1 with the USE-Flags "X acpi crypt kernel_linux
>> laptop".
>> - "sysfs" is activated in kernel
>>
>> These variables are wrong:
>>
>> battery.charge_level.percentage
>> battery.charge_level.rate
>> battery.reporting.rate
>>
>> It seems to me the percentage is calculated by the following formula on
>> my system:
>>
>> battery.charge_level.percentage = battery.charge_level.current /
>> battery.charge_level.design * 100
>>
>> This is the reason why I get 65 % as maximum percentage.

[PATCH] Fix typo in hald/linux/osspec.c: SUSBSYSTEM->SUBSYSTEM

SUSBSYSTEM should be SUBSYSTEM in hald/linux/osspec.c

Signed-off-by: Ozan Çağlayan <ozan <at> pardus.org.tr>
---
 hald/linux/osspec.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hald/linux/osspec.c b/hald/linux/osspec.c
index 56e3b65..f721b98 100644
--- a/hald/linux/osspec.c
+++ b/hald/linux/osspec.c
 <at>  <at>  -227,7 +227,7  <at>  <at>  hald_udev_data (GIOChannel *source, GIOCondition condition, gpointer user_data)
 		goto invalid;
 	}
 	if (hotplug_event->sysfs.subsystem[0] == '\0') {
-		HAL_INFO (("missing SUSBSYSTEM"));
+		HAL_INFO (("missing SUBSYSTEM"));
 		goto invalid;
 	}

--

-- 
1.6.2

_______________________________________________
hal mailing list
hal <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

Strange mounting issue with ext3

Hi,

Kernel: 2.6.25.20
Desktop: KDE 4.2
OS: Pardus
hal: 20090304
hal-info: 20090330

I was just bumping hal and hal-info to their latest snapshots and I've detected a strange issue.

I'm creating a new ext3 partition on my USB stick:

# mkfs.ext3 -L "somelabel" /dev/sdb1

And then when I insert it HAL mounts it correctly into /media/somelabel but with wrong permissions:

# ls -l /media
drwxr-xr-x  3 root  root  4096  Apr  6  16:20  somelabel

So a normal user which clicks on Dolphin's notification on its desktop, isn't able at all to write
onto the usb stick. But HAL insists that it mounts it on behalf of uid 1001:

..
Apr  6 16:21:54 laptop hald: mounted /dev/sdb1 on behalf of uid 1001
Apr  6 16:21:54 laptop hald[12956]: 16:21:54.440 [I] osspec.c:298: /proc/mounts tells, that the mount
has tree changed
Apr  6 16:21:54 laptop hald[12956]: 16:21:54.440 [I] device.c:1894: Removing locks from ':1.859'
Apr  6 16:21:54 laptop hald[12956]: 16:21:54.440 [I] hald_dbus.c:4086: No more methods in queue
Apr  6 16:21:54 laptop hald[12956]: 16:21:54.440 [D] hotplug.c:453: events queued = 0, events in progress
= 0