Hi Pete,
However: If we all follow that line then I guess when the acpi developers get no response to test builds they will surmise that all works properly rather than no-one is testing...
Exactly!
I think we can only hope that the acpi guys do get a few more capable people involved and thus speed up development of the acpi driver package.
I don't even think they need more developers. What they need is a "lab team" that collects detailed information about why a specific chipset perhaps works while another doesn't. If they need a developer for this, ok, let it be more developers.
I am afraid that at the moment, there is 1 guy sitting far away from Mensys and is being paid to "do ACPI". The problem is that if this is true, most of his work is... guesswork. I don't think he has a dozen multicore machines and two dozen of laptops sitting in his living room and waiting to be tested.
But then again, as we have already pointed out - only THEY know what information THEY need to investigate a chipset/mainboard. So either they sit down and create somehting for dummies like us or there will be no change. Even with 12 developers - where is the difference if you don't have the testbed allowing a good coverage of hardware? If it was about porting linux stuff, then 1 developer would have been sufficient (looking at the time consumned til now).
I even tend to believe that an ACPI "driver" is something where the less people involved, the better.

Talking about "reference machines" unfortunately is a waste of time as well, at least when it comes to ACPI. Todays "contemporary, top-notch" reference system will be outdated in about two weeks and we'll see the next non-compatible ACPI implementation coming up in the stores. Heck, it might even happen to you to buy the same parts and they don't work because in the meanwhile, the board manufacturer changed the revision in order to use chips that would save him 0.1 cents a piece.
What is the bottom line?
ACPI will never be finished, since there will always be new boards coming up. We might see the effort decrease once a stable code base is established, but don't expect them to deliver "the ACPI driver". I admit that they perhaps weren't THAT lucky in preserving previously successful codes thru more than 1 release, but that also shows how difficult that whole thing is.
Perhaps it would make sense to not write a "1-code-fits-all" driver, but rather have a couple of "specialized" ACPI drivers that differ in what chipset they're "tuned" to. Not sure if there is a drawback with that idea. (Heck, not even sure if there is an advantage with it

).
Cheers,
Thomas