Re: [gpm] hal.systems.formfactor

[Danny Kukawka <danny kukawka web de>]

On Sunday 23 April 2006 23:41, Richard Hughes wrote:
> On Sun, 2006-04-23 at 23:29 +0200, Danny Kukawka wrote:
[...]
> 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.

And? Read 2.) !

> > 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.

Nobody say changing the ACPI logic in HAL. In fact currently (since HAL 
v0.5.5) if there is in the machine a ACPI/APM/PMU battery bay detected (or a 
LID button) HAL also change system.formfactor to 'laptop'. Hence, if the 
property is 'unknown' there is _more_ than _one_ problem or reason why this 
value is incorrect. 

> > 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?

Are you serious?

1.) Ask for the HAL version and if needed check for releated changes since 
this version.
2.) If needed propose a HAL update.
3.) If this is already a actual HAL version check if there is a battery bay or 
a LID button detected. If so: check the code, If not try to find out why.

Cheers,

Danny