headers
David Zeuthen | 1 Feb 2005 06:41
Picon
Gravatar

Re: acpi updates

On Sun, 2005-01-30 at 14:40 +0000, Richard Hughes wrote:
> Okay, I know the initial patch hasn't even been merged yet, but I've
> been working more on the code...(*)
> 
> Patch to HEAD (assuming nobody has committed anything yet...) is here:
> 
> http://hughsie.no-ip.com/write/hal/hal-patch-procfs-compile3.patch
> 

Hi,

So I had a look at this today and tonight. Some general comments

 o Missing CVSID: $Id$ in files.

 o Missing #ifndef guards for header files

 o Header files shouldn't include config.h. Source files should
   indeed include config.h (with HAVE_CONFIG_H guards)

 o Please use named parameters in header file prototypes, e.g.

    void foo (const char *someParam, int someOtherParam)

   rather than

    void foo (const char *, int)

 o Coding standards; basically
(Continue reading)

Permalink | Reply | 14 comments |
headers
David Zeuthen | 1 Feb 2005 06:53
Picon
Gravatar

Re: [PATCH] hal_util_get_string_from_file

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
Permalink | Reply | 0 comments |
headers
David Zeuthen | 1 Feb 2005 07:01
Picon
Gravatar

Re: [PATCH] MMC bus support

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
Permalink | Reply | 1 comment |
headers
David Zeuthen | 1 Feb 2005 07:04
Picon
Gravatar

Re: [PATCH] pnp.ids

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
Permalink | Reply | 3 comments |
headers
David Zeuthen | 1 Feb 2005 07:14
Picon
Gravatar

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

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pierre Ossman | 1 Feb 2005 07:36

Re: [PATCH] MMC bus support

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
Permalink | Reply | 0 comments |
headers
Pierre Ossman | 1 Feb 2005 07:45

Re: [PATCH] pnp.ids

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Hughes | 1 Feb 2005 09:15
Picon
Favicon

Re: acpi updates

On Tue, 01 Feb 2005 00:41:10 -0500, David Zeuthen wrote:
> So I had a look at this today and tonight. Some general comments
> 
>  o Missing CVSID: $Id$ in files.

Never used this before... Do I just update the time and date
manually in each patch? Or leave it all to cvs?

>  o Missing #ifndef guards for header files

Oops.

>  o Header files shouldn't include config.h. Source files should
>    indeed include config.h (with HAVE_CONFIG_H guards)

Oops again.

>  o Please use named parameters in header file prototypes, e.g.
> 
>     void foo (const char *someParam, int someOtherParam)
> 
>    rather than
> 
>     void foo (const char *, int)

CodingStyle I guess... I'll play it your way.

>  o Coding standards; basically
> 
>     - if ( foo ) should be if (foo); and
(Continue reading)

Permalink | Reply | 13 comments |
headers
Sergey Udaltsov | 1 Feb 2005 10:37
Picon

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
Permalink | Reply | 1 comment |
headers
Sabin Iacob | 1 Feb 2005 10:50
Picon
Gravatar

fstab-sync feature request

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.
Permalink | Reply | 1 comment |

Gmane