Re: [gpm] hal.systems.formfactor

[Richard Hughes <hughsient gmail com>]

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.