R3000Z Laptop Status

[Jung-uk Kim]

On Monday 21 March 2005 11:18 am, Scott Long wrote:
> Jung-uk Kim wrote:
> > On Monday 21 March 2005 11:07 am, Scott Long wrote:
> >>Jung-uk Kim wrote:
> >>>On Monday 21 March 2005 08:36 am, Astrodog wrote:
> >>>>I was wondering if the R3000Z fixes have been committed to the
> >>>>RELENG_5 branch, I don't see anything on the lists about it.
> >>>>Should I expect 5.4 to work with the R3000 line?
> >>>
> >>>Yes.  hint.atkbd.0.flags="0x9" is all you need now.  Try the
> >>>latest snapshot and let us know.
> >>>
> >>>Thanks,
> >>>
> >>>Jung-uk Kim
> >>
> >>Is there any way that these systems can be detected at runtime
> >> and have the work-arounds be automatically activated?
> >
> > I believe DMI-based quirk table is the only way but we don't want
> > to do that, right?
> >
> > Jung-uk Kim
> >
> >>Scott
>
> Well, it's gross, but it's not impossible to do.  Is there a
> technical reason why we wouldn't want this?

The only technical reason that I can think of is some systems (e. g., 
IBM e345 and e346 Opteron servers) have DMI structures in ACPI NVS 
area, which is not accessible from early stage.  If you want to do 
something like that, you will have to add gross hack in pmap.c to 
temporarily map it, I think.

> Are there any alternatives, like detecting a signature in ACPI,
> either a text string or a certain bit of ASL bytecode?

We already have the quirk for this broken BIOS.  However, keyboard 
probing happens way earlier to use this quirk. :-(

Jung-uk Kim

> Scott