Re: [gpm] hal.systems.formfactor
- From: Richard Hughes <hughsient gmail com>
- To: Danny Kukawka <danny kukawka web de>
- Cc: gnome-power-manager-list gnome org
- Subject: Re: [gpm] hal.systems.formfactor
- Date: Sun, 23 Apr 2006 22:41:12 +0100
On Sun, 2006-04-23 at 23:29 +0200, Danny Kukawka wrote:
> On Sunday 23 April 2006 21:06, Richard Hughes wrote:
> > Try adding the attached fdi file
> > to /usr/share/hal/fdi/information/10freedesktop/ and restarting hal, and
> > then doing
> >
> > lshal | grep system.formfactor
> >
> > If that works, then we need to add this to upstream HAL.
>
> I say it here, before I need to say it at the HAL mailinglist: Sorry, but this
> is bulls*** (adding the fdi upstream).
>
> My reasons for this statement:
> 1.) You never asked for the HAL version he use (There was e.g. a fix in 0.5.7
> and if he use a older version ... no comment.)
Erm.. I only needed the dmidecode output, from that I could see the dmi
data was set to Unknown, rather than one of the dmi defined standard
types.
> 2.) You didn't try to fix or to debug the real problem. Not only the result of
> dmidecode is a place, where hal change/set the value of system.formfactor.
> The value is also set on machines with a ACPI/APM/PMU battery (bay) or a LID
> button to 'laptop'. If there is a bug, fix the real bug.
I asked Fabian to update the BIOS, but it's the latest version. I'm not
sure what you mean by changing the ACPI logic in HAL.
> 3.) A fdi file is the last place to fix such issues, you should only fix
> something via a fdi-file if there is no other way. Sorry, but I really hate
> ppl trying always to fix 'problems' with adding a new fdi-file instead of
> research the reason for the problem. This maybe is a fast workaround, but
> never a fix.
>
> Hence: try to find and fix the bug.
So, how exactly do you think we should fix this bug then?
Richard.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]