Re: [PATCH] hal_util_get_string_from_file

David Zeuthen <david <at> fubar.dk>
2005-02-01 05:53:49 GMT

On Sun, 2005-01-30 at 20:02 +0100, Pierre Ossman wrote:
> I was missing this function for the mmc bus so I might a slight
> modification =)
>
I committed this, but changed the signature to
gchar *hal_util_get_string_from_file (const gchar *directory, const
gchar *file)
Cheers,
David

Re: [PATCH] MMC bus support

David Zeuthen <david <at> fubar.dk>
2005-02-01 06:01:23 GMT

On Sun, 2005-01-30 at 20:04 +0100, Pierre Ossman wrote:
> Basic MMC bus support. Reads out all the information currently available.
> I also need to add a mapping between vendor id:s an names, but I don't
> currently have a list to base it upon.
>
I committed this with a trivial change to how the hal_util_string_set_
from_file function is used , thanks. So, when I add the support for
block devices such card readers should "just work", right?
Cheers,
David

Re: [PATCH] pnp.ids

David Zeuthen <david <at> fubar.dk>
2005-02-01 06:04:43 GMT

On Sun, 2005-01-30 at 18:26 +0100, Pierre Ossman wrote:
> Here is the promised change of using a pnp.ids file.
> I've used the same matching system as in the kernel including wild cards
> support.
> The included pnp.ids file has nothing new except wild card matches taken
> from http://www.plasma-online.de/english/identify/serial/pnp_id_pnp.html.
>
Hmm, I'm not totally happy about this because not all distros have
a pnp.ids file. At least I can't find one on Fedora. I also think
that this file will not grow (as everything is PCI/AGP/≤something
newer> based, so what's wrong with the static list we already have?
Also, if we need to patch the list we can always just use device
information files instead of yet another non-extensible format.
Cheers.
David

Re: [patch] hal-spec.xml.in

David Zeuthen <david <at> fubar.dk>
2005-02-01 06:14:10 GMT

On Sat, 2005-01-29 at 21:11 +0000, Richard Hughes wrote:
> Patch:
>
> * makes battery into system.battery and moves it into the correct place.
We're also going to support batteries from e.g. wireless mice; there's
still a patch from Sergey that I'm going to merge soon. So it should
just be called battery.
> * adds all the new properties that are about to be merged into head...
Those are added; I didn't like this one
> -
<entry><literal>battery.rechargeable.is_charging</literal>
(bool)</entry>
> + <entry><literal>system.battery.rechargeable.charging_state</literal> (string)</entry>
> <entry></entry>
> - <entry>Only if <literal>battery.is_rechargeable</literal> is TRUE</entry>
> + <entry>Only if <literal>system.battery.is_rechargeable</literal> is TRUE</entry>
so now it's battery.rechargable.is_charging (bool) and
battery.rechargable.is_discharging (bool). The reason for this,
in my view, is that it's easier to deal with two bools than three
string values. See the patch I committed also.
> * makes {acpi|pmu}_version into acpi.version and pmu.*_version so we I add
> new acpi. properties:
I've only added one new, namely linux.acpi_path. See the patch

Re: [PATCH] MMC bus support

Pierre Ossman <drzeus-list <at> drzeus.cx>
2005-02-01 06:36:56 GMT

David Zeuthen wrote:
>On Sun, 2005-01-30 at 20:04 +0100, Pierre Ossman wrote:
>
>
>>Basic MMC bus support. Reads out all the information currently available.
>>I also need to add a mapping between vendor id:s an names, but I don't
>>currently have a list to base it upon.
>>
>>
>>
>
>I committed this with a trivial change to how the hal_util_string_set_
>from_file function is used , thanks. So, when I add the support for
>block devices such card readers should "just work", right?
>
>
Hopefully. They do need some kind of hack to set the drive_type based on
the bus of the parent (bus.type == mmc).
Rgds
Pierre

Re: [PATCH] pnp.ids

Pierre Ossman <drzeus-list <at> drzeus.cx>
2005-02-01 06:45:26 GMT

David Zeuthen wrote:
>On Sun, 2005-01-30 at 18:26 +0100, Pierre Ossman wrote:
>
>
>>Here is the promised change of using a pnp.ids file.
>>I've used the same matching system as in the kernel including wild cards
>>support.
>>The included pnp.ids file has nothing new except wild card matches taken
>>from http://www.plasma-online.de/english/identify/serial/pnp_id_pnp.html.
>>
>>
>>
>
>Hmm, I'm not totally happy about this because not all distros have
>a pnp.ids file. At least I can't find one on Fedora. I also think
>that this file will not grow (as everything is PCI/AGP/≤something
>newer> based, so what's wrong with the static list we already have?
>
>Also, if we need to patch the list we can always just use device
>information files instead of yet another non-extensible format.
>
>
>
Well, none probably have it as I created it for this patch. The point
was to avoid redundant arrays kept out of sync. As an intial step the
file can be distributed together with hal.
And these ID:s seem to be in more use than one would expect. LPC-stuff
is still very common and will probably continue to be for some time. And
those devices almost always use PNP ID:s. So an external file is

Re: [patch] hal-spec.xml.in

> We're also going to support batteries from e.g. wireless mice; there's
> still a patch from Sergey that I'm going to merge soon. So it should
> just be called battery.
Actually, I was wondering myself - what was the point to make
system.battery? I don't particularly mind this change - but there
should be some rationale, shouldn't it?
Sergey

fstab-sync feature request

Sabin Iacob <iacobs <at> gmail.com>
2005-02-01 09:50:43 GMT

Hi, list!
I wrote an app that updates a rox panel when fstab-sync creates a
mount moint, and I had to write a replacement for fstab-sync, because
the one I got with hal didn't do much (actually, it didn't do
anything), and the people from rox said that would be a problem in
shared rox - gnome systems, as each one needs a different fstab
updating thing. I agree with them, and hence I have 2 wishes about
fstab-sync:
1. to actually work
2. to emit a signal on dbus when it does something
Do you think it's possible? I tried to add the functionality to
fstab-sync myself, but I got kind of lost :)
My replacement is written in python
(http://exotic4.nipne.ro/~iacobs/devwatch/fstab-sync.py), and
currently relies on a remote object to emit the signal (when the app
starts, it also registers a service on the system bus, and fstab-sync
uses it to emit the signal). It would be nice if there was a similar
object provided by the org.freedesktop.Hal service. Also, right now it
doesn't have all the functionality it should provide, but that's not
hard to add (it lacks cleaning and verbose operation, as I didn't need
them).
--
--
Life is a sexually transmitted disease with 100% mortality.