David Zeuthen | 1 Nov 01:00 2006
Picon

Re: [patch] Fixing ACPI to ignore the special 'Ones' value

On Sat, 2006-10-28 at 22:46 +0100, Richard Hughes wrote:
> As discovered in : http://bugzilla.gnome.org/show_bug.cgi?id=348201
> 
> ACPI gives out the special 'Ones' value for rate when it's unable to
> calculate the true rate.
> 
> We should set the rate zero, and wait for the BIOS to stabilise for the
> few BIOS's that give 0xffff as the very first entry after an AC state
> change.
> 
> Patch attached. It's tested to work by Pierre Ossman, so is this okay to
> commit?

Yea, please do. Thanks.

     David

David Zeuthen | 1 Nov 01:04 2006
Picon

Re: i18n support for tools

On Mon, 2006-10-30 at 02:02 +0200, S.Çağlar Onur wrote:
> Hi;
> 
> Currently, KDE uses hal's methods for mount/umount operations, but if any 
> error occurs it just shows the message written to stderr by hal in a dialog 
> box.
> 
> So for example in while KDE is Turkish, KDE shows unlocalized messages 
> like "hal-storage-fixed-mount-all-options refused uid 1002" to users.
> 
> Attached patch is initial i18n support for tools/hal-storage-{un}mount.c. As a 
> starting point i just converted the user visible strings but if you want i 
> can start to add i18n support to others strings/tools.

Uh, no thanks, in fact I'd like to get rid of the i18n framework we
currently have. Only deprecated functions use it right now. 

I think the right fix is for the GNOME and KDE's of the world to just
interpret the detailed exception name we throw (which is part of the
ABI).. and then provide the right message. 

    David

David Zeuthen | 1 Nov 01:07 2006
Picon

Re: [BUG] : hdd led blinks constantly

On Tue, 2006-10-31 at 14:31 +0100, Sjoerd Simons wrote:
> On Tue, Oct 31, 2006 at 09:18:17AM +0100, neologix <at> free.fr wrote:
> > Hi.
> > Well, the fact is that Redmond's OS, for example, doesn't do that.
> > So it must be a hal issue, not an hardware one.

Don't rule out the (Linux) kernel. It does some pretty funky stuff.

> Uhm, no. There a things Windows typically does and things that hal/linux 
> typically do. The fact that hal/linux does something different doesn't mean
> it's buggy or an issue. It just means that your hardware might behave different
> then what your used to on Windows.
> 
> Now one thing that hal does and Windows doesn't is that it checks if your cdrom
> eject button was pressed. Which might cause the blink on your system. 

Yea, and if it does... it's either something broken with the kernel
and/or the hardware. If it's not a kernel bug we can consider adding
some quirk properties to prevent HAL from issuing the "check for eject
pressed" raw SCSI command. And then also carry whitelist / blacklist for
these.

> My TODO includes making a small program which does the checking the same way as
> hal so i can check this theory.  If someone wants to beat me to it, please do,
> i'm rather short on time these days :)

It would be useful to store small utilities like this in the HAL tree.

    David

(Continue reading)

Trond Husø | 1 Nov 13:35 2006
Picon
Picon

Re: VS: Welcome to the "hal" mailing list (Digest mode)

This error also occures on ubuntu (DD)-release.

-trond-

On Tue, 2006-10-31 at 22:05 +0000, Richard Hughes wrote:
> On Tue, 2006-10-31 at 20:08 +0100, Trond Husoe wrote:
> > Hi List,
> > 
> > My old Compaq Evo N160 is causing some problems for the Gnome Power
> > Manager and here is one line that caused some concern for the
> > developer of the program:
> > 
> > battery.charge_level.design = -1 (0xffffffff) (int)
> 
> That would be me. ;-)
> 
> > Bug occured in FC6 the release that was released late october.
> 
> This is another "Ones" value (32 bit this time) we need to ignore.
> 
> Richard.
> 
> 
> 

Richard Hughes | 2 Nov 09:53 2006
Picon

Re: SPAM: Re: Add support for /sys/class/backlight

On Wed, 2006-10-11 at 12:27 -0400, David Zeuthen wrote:
> Well. That only works if we add sysfs objects before ACPI objects.
> Which
> I think might work actually. Otherwise we can always change that.

Holger, how are you getting on? Have you hit any problems, or am I just
being impatient? :-)

Thanks,

Richard.

Holger Macht | 2 Nov 19:10 2006
Picon

Re: Add support for /sys/class/backlight

On Thu 02. Nov - 08:53:02, Richard Hughes wrote:
> On Wed, 2006-10-11 at 12:27 -0400, David Zeuthen wrote:
> > Well. That only works if we add sysfs objects before ACPI objects.
> > Which
> > I think might work actually. Otherwise we can always change that.
> 
> Holger, how are you getting on? Have you hit any problems, or am I just
> being impatient? :-)

Yes, you are impatient :-) No, it's still on my TODO and I hope I'll have
some time the next days, at the latest at the weekend. It should just be a
oneliner or the like, no? So if you like to do it, go ahead ;-)

Regards,
	Holger

John (J5) Palmieri | 3 Nov 03:56 2006
Picon

Hal issues with the new D-Bus

I was doing a D-Bus release today and ran into issues with hal
0.5.8.1-4.  It seems that gnome-power-manager was segfaulting hald.  I
was unable to track down the segfault but am holding off releasing the
new D-Bus until I can make sure it is not a problem with libdbus itself.
A couple of things I did notice was that   dbus_connection_close was
called a few times in these files

tools/hal-device.c
tools/lshal.c
hald/linux/addons/addon-cpufreq.c

You are only supposed to close connections you own otherwise you are
just supposed to unref shared connections.  Older versions of D-Bus
would just throw a warning.  The newer one asserts.  Please take these
out if they do not belong.

There is also an issue with libhal_device_add_capability in
libhal/libhal.c.  hald/linux/addons/addon-cpufreq.c asserts in
dbus_init.  This is because you send in a NULL for error and then in
libhal_device_add_capability check dbus_error_is_set (error) which will
assert if error == NULL.  You can either pass error objects to the API
or check if error == NULL before calling dbus_error_is_set.

Also not related to D-Bus, but I get a lot of Warning: Error while wite
r->input () to stdin_v.  There is a typo s/wite/write and should I be
getting these?

Attached is the output of running hald --daemon=no --verbose=yes, when
running gnome-power-manager it crashes.

(Continue reading)

Danny Kukawka | 3 Nov 09:49 2006
Picon

Re: Hal issues with the new D-Bus

On Friday 03 November 2006 03:56, John (J5) Palmieri wrote:
> I was doing a D-Bus release today and ran into issues with hal
> 0.5.8.1-4.  It seems that gnome-power-manager was segfaulting hald.  I
> was unable to track down the segfault but am holding off releasing the
> new D-Bus until I can make sure it is not a problem with libdbus itself.
> A couple of things I did notice was that   dbus_connection_close was
> called a few times in these files
>
> tools/hal-device.c
> tools/lshal.c
> hald/linux/addons/addon-cpufreq.c
>
> You are only supposed to close connections you own otherwise you are
> just supposed to unref shared connections.  Older versions of D-Bus
> would just throw a warning.  The newer one asserts.  Please take these
> out if they do not belong.

There is already a patch commited to git HEAD:
http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c85e02d58d6503b494bb4c8584a7c44ac6923208

> There is also an issue with libhal_device_add_capability in
> libhal/libhal.c.  hald/linux/addons/addon-cpufreq.c asserts in
> dbus_init.  This is because you send in a NULL for error and then in
> libhal_device_add_capability check dbus_error_is_set (error) which will
> assert if error == NULL.  You can either pass error objects to the API
> or check if error == NULL before calling dbus_error_is_set.

Should be easy to fix. We should put a macro to libhal to check always if 
error != NULL before use the related D-Bus functions.

(Continue reading)

Timo Hoenig | 3 Nov 09:49 2006
Picon

Re: Hal issues with the new D-Bus

Hi,

On Thu, 2006-11-02 at 21:56 -0500, John (J5) Palmieri wrote:

> I was doing a D-Bus release today and ran into issues with hal
> 0.5.8.1-4.  It seems that gnome-power-manager was segfaulting hald.  I
> was unable to track down the segfault but am holding off releasing the
> new D-Bus until I can make sure it is not a problem with libdbus itself.
> A couple of things I did notice was that   dbus_connection_close was
> called a few times in these files
> 
> tools/hal-device.c
> tools/lshal.c

Those two are already fixed, see

http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c85e02d58d6503b494bb4c8584a7c44ac6923208

> hald/linux/addons/addon-cpufreq.c

Holger can comment on that.

<snip>

> Can someone grab the D-Bus sources from CVS and help debug this?
> Thanks.

The development releases of OpenSUSE currently ship with D-Bus 0.94 and
HAL 0.5.8_git20061027.  We did not see severe problems.  If time allows
I will give D-Bus CVS HEAD a try in order to see what breaks.
(Continue reading)

Holger Macht | 3 Nov 09:58 2006
Picon

Re: Hal issues with the new D-Bus

On Fri 03. Nov - 09:49:26, Timo Hoenig wrote:
> Hi,
> 
> On Thu, 2006-11-02 at 21:56 -0500, John (J5) Palmieri wrote:
> 
> > I was doing a D-Bus release today and ran into issues with hal
> > 0.5.8.1-4.  It seems that gnome-power-manager was segfaulting hald.  I
> > was unable to track down the segfault but am holding off releasing the
> > new D-Bus until I can make sure it is not a problem with libdbus itself.
> > A couple of things I did notice was that   dbus_connection_close was
> > called a few times in these files
> > 
> > tools/hal-device.c
> > tools/lshal.c
> 
> Those two are already fixed, see
> 
> http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c85e02d58d6503b494bb4c8584a7c44ac6923208
> 
> > hald/linux/addons/addon-cpufreq.c
> 
> Holger can comment on that.

Fix committed two miniutes ago.

Regards,
	Holger


Gmane