R3000Z Laptop Status

[Astrodog]

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

Something that came up originally, when this issue was first noticed,
was trying to figure out what, if any platforms, would have problems
if this was made to apply to all AMD64 machines, and use the flag to
drive an opt-out. In as far as I'm aware, no AMD64-based machines are
effected if you just "break" the keyboard test functionality, though
I'm not certain this is a path worth looking at, since its still a bit
ugly.