ACPI/PMU procfs HAL test program. Version 003.

[Richard Hughes]

Paul Ionescu <i_p_a_u_l <at> yahoo.com> writes:
> Cool

Yes, hopefully we can get this standalone program into a more suitable state,
and add more properties, and then merge it back into HAL proper.
 
> on my laptop i have:
> 
> [13]capability  system.battery
> [13]set_string  info.bus,       unknown
> [13]set_string  info.udi,       /org/freedesktop/Hal/devices/battery_0
> [13]capability  linux.acpi
> [13]set_string  linux.acpi.procfs_path, /proc/acpi/battery/BAT1
> [13]set_string  info.product,   Battery
> [13]set_bool    system.battery.present, FALSE
> * callout_device *
> * new_device *
> [14]capability  system.battery
> [14]set_string  info.bus,       unknown
> [14]set_string  info.udi,       /org/freedesktop/Hal/devices/battery_1
> [14]capability  linux.acpi
> [14]set_string  linux.acpi.procfs_path, /proc/acpi/battery/BAT0
> [14]set_string  info.product,   Battery
> [14]set_bool    system.battery.present, TRUE
> [14]set_bool    system.battery.is_rechargable,  TRUE
> [14]set_string  system.battery.serial,  1681
> [14]set_string  system.battery.model,   IBM-08K8193
> [14]set_string  system.battery.type,    LION
> [14]set_string  system.battery.vendor,  SANYO
> [14]set_bool    system.battery.rechargeable.is_charging,        FALSE

David, does this look about right from a calling order PoV?
 
> Two things:
> 
> Dealing with end-users here, IMO would be better to start counting from 1
> not from 0 (as programmers do), so we will have .../battery_1 and
> .../battery_2

All the other udi's I have seen start at 0. Users (should) never see the UDI
value, and so I don't think this is important.

> And the order in hal should try to match the order in system, ie bat0
> whould be .../battery_1 and bat1 should be ..../battery_2. Right now, on
> my system, they are in reverse order, as you can see above.

Yes I see. I'm using g_dir_open, which opens the directory in file-system order,
which I didn't know. What I'll do is use half my approach using a linked list
loader function to buffer, and half Sergey's approach using:

list = g_list_sort (list, (GCompareFunc)strcmp);

And then access the strings through the linked list.

I'm also working on replacing buffer to be a GString:

/* Parse information */
if ( procfs_getvalue(listbuffer, "driver", buffer) )
	hal_device_property_set_string(d, "....version", buffer);

To avoid having to declare a fixed sized char array "buffer" - good idea?

Richard.


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