ACPI - how to get into contact with the developers ?
Lars Erdmann
after much fuzzing around and reading the ACPI documentation I finally
have a stable boot with ACPI (version 3.16) on my eCS/WinXP system. I
eventually had to dump/deassemble the ACPI tables on my system, modify
the DSDT table, compile into binary form and load the modified DSDT
table via the acpi.cfg FILE directive (plus I had to add a LINK
directive to assign an IRQ to LNKE).
Is there another way apart from the ACPI bugreporting in svn to get into
contact with the ACPI developers and exchanging information ? I would
like to share a few thoughts with them but bugreporting is not the
appropriate place for that.
Lars
Percival P. Cassidy
Peter Brown
Lars Erdmann wrote:
> Hallo,
>
> after much fuzzing around and reading the ACPI documentation I finally
> have a stable boot with ACPI (version 3.16) on my eCS/WinXP system. I
> eventually had to dump/deassemble the ACPI tables on my system, modify
> the DSDT table, compile into binary form and load the modified DSDT
> table via the acpi.cfg FILE directive (plus I had to add a LINK
> directive to assign an IRQ to LNKE).
>
You don't fancy putting together a "How To" on the above activity? I
have often wondered if acpi problems here are related to the HPET ACPI
table mentioned in the mainboard BIOS setup.
> Is there another way apart from the ACPI bugreporting in svn to get into
> contact with the ACPI developers and exchanging information ? I would
> like to share a few thoughts with them but bugreporting is not the
> appropriate place for that.
>
>
> Lars
I think you need to get their attention in the bug tracker and maybe
move on to a more private/convenient method by agreement.
I must admit that I am not "over shy" about sharing some thoughts with
acpi developers within the forum after yet another attempt to use the
latest acpi ends in (mainly) failure but I do try to keep it polite :-)
Regards
Pete
Lars Erdmann
> Hi Lars
>
> Lars Erdmann wrote:
>> Hallo,
>>
>> after much fuzzing around and reading the ACPI documentation I finally
>> have a stable boot with ACPI (version 3.16) on my eCS/WinXP system. I
>> eventually had to dump/deassemble the ACPI tables on my system, modify
>> the DSDT table, compile into binary form and load the modified DSDT
>> table via the acpi.cfg FILE directive (plus I had to add a LINK
>> directive to assign an IRQ to LNKE).
>>
>
>
> You don't fancy putting together a "How To" on the above activity? I
> have often wondered if acpi problems here are related to the HPET ACPI
> table mentioned in the mainboard BIOS setup.
Good point. Can you think of a good place where to put it ? Putting it
here will not make much sense or does it ?
Lars
Peter Brown
You could submit an article to os2world.com via the User Menu (left of
page), Submit Material.
I feel sure that I am not the only person who would find it of interest
- and possibly helpful if it is not "over technical" :-)
Regards
Pete
Paul Smedley
On Sat, 7 Nov 2009 09:40:12 UTC, Lars Erdmann <lars.e...@arcor.de>
wrote:
irc.ecomstation.com channel #ecolabs
--
Cheers,
Paul.
Allan
> Is there another way apart from the ACPI bugreporting in svn to get into
> contact with the ACPI developers and exchanging information ? I would
> like to share a few thoughts with them but bugreporting is not the
> appropriate place for that.
There is a closed ACPI developers mail list.
Contact Mensys and ask for access
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Allan
> Good point. Can you think of a good place where to put it ? Putting it
> here will not make much sense or does it ?
Very little sense. This is OS/2 newsgroups. ACPI is licensed only
for use with eComStation - it would be illegal to use it on OS/2 :-)
I think eComStation users would look to other sources for this
kind of info - ex ecomstation.* groups (@Mensys)
Besides that - this kind of info is of no use for any users -
they should never need to go into this kind of 'hacking' -
and if they ever tried, it will only hurt them badly.
I think the acpi dev mail list mentioned in the other post
might be the better place for this.
Doug Bissett
wrote:
> Besides that - this kind of info is of no use for any users -
> they should never need to go into this kind of 'hacking' -
> and if they ever tried, it will only hurt them badly.
Now that is a silly statement. True, it could "hurt them badly", and
true, a user should never have to do that sort of thing, but those who
are warned, and choose to continue, may just develop something that
will make a LOT more systems work with ACPI. It is obvious that the
ACPI developers are well over their heads, and it can't hurt much more
if users start to do some 'hacking' to make ACPI work for them. Some
guidance of how to do it should be forthcoming from the developers,
but since that hasn't happened, it may help if a user gives some
guidance, after (I am sure) spending many hours of work to try to sort
this mess out by himself.
I am really getting upset with the general assumption that OS2/eCS
users can't contribute to projects like ACPI, or GENMAC. The
developers are simply cutting their own throats by taking that
attitude, and the whole OS2/eCS community are suffering because of it.
There are many competent people who use OS2/eCS, and with a little
guidance, they could contribute to many of these projects, but,
without some guidance of where to put their efforts, they hesitate to
get involved (mostly because they have no idea what to do).
Wake up folks, there isn't a lot of time left. If these projects don't
succeed, OS2/eCS is as dead as IBM wants it to be.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Mentore
> On Mon, 9 Nov 2009 01:13:22 UTC, "Allan" <all...@warpspeed.dyndns.dk>
> wrote:
>
> > Besides that - this kind of info is of no use for any users -
> > they should never need to go into this kind of 'hacking' -
> > and if they ever tried, it will only hurt them badly.
>
> Now that is a silly statement. True, it could "hurt them badly", and
> true, a user should never have to do that sort of thing, but those who
> are warned, and choose to continue, may just develop something that
> will make a LOT more systems work with ACPI. It is obvious that the
> ACPI developers are well over their heads, and it can't hurt much more
> if users start to do some 'hacking' to make ACPI work for them. Some
> guidance of how to do it should be forthcoming from the developers,
> but since that hasn't happened, it may help if a user gives some
> guidance, after (I am sure) spending many hours of work to try to sort
> this mess out by himself.
I would like to ask a question which could be relevant to me, having
read and translated in Italian the complete ACPI/APM documentation...
I seem to see there's a big need for some kind of ACPI configuration
system. Something maybe able to:
1 - configure an ACPI basic installation, maybe using some sort of
internal database for what regards configuration switches, ACPID.CFG
and ACPI.CFG files and so on;
2 - help reporting bugs and problems;
3 - allow for ACPI tweaking, with optional backup;
and many other things.
IMHO it shouldn't be so hard to develop a similar application. I would
like to ask you all, what the requirements for a similar application
could be?
Mentore
m...@privacy.net
11/08/2009
>and many other things.
I would think there should certainly be a debugging tool available to scan
the motherboard configuration, including ACPI, and produce some sort of
report/dump/etc that perhaps could be of use to the user but can certainly
be of use to the developers. Maybe this could be used to build a database
of motherboard-level/BIOS-level mapping to ACPI settinga appropriate for
eCS 2 to operate with. Given the diversity of implementations of ACPI by
manufacturers this may be the only way to broaden the systems that will
work with eCS 2 "out of the box" as those interested in trying it for the
first time.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
Doug Bissett
I think that is what the ACPI Wizard (in eCS 2.0 RCx) is supposed to
do. It does allow the user to select what parameters they want.
Unfortunately, it is not "smart", and does not attempt to assist the
user to select what might work for them. Of course, you really can't
do that, until the basic program works properly in most cases.
> I would think there should certainly be a debugging tool available to scan
> the motherboard configuration, including ACPI, and produce some sort of
> report/dump/etc that perhaps could be of use to the user but can certainly
> be of use to the developers. Maybe this could be used to build a database
> of motherboard-level/BIOS-level mapping to ACPI settinga appropriate for
> eCS 2 to operate with. Given the diversity of implementations of ACPI by
> manufacturers this may be the only way to broaden the systems that will
> work with eCS 2 "out of the box" as those interested in trying it for the
> first time.
That is what the ACPI Logs Collector kludge is supposed to do. It does
collect a lot of information (mostly unusable by the user), for the
developers. Doesn't seem to help them much though, and they have been
ignoring any AMD processors. As for building a database of settings
etc. that could become just as unusable as the documentation. For
instance, it may be necessary to have an entry for each motherboard,
and each BIOS version available for that motherboard. The average user
just isn't likely to spend the time to try to figure it out.
Unfortunately, it seems that the developers do have to figure that
out, and try to incorporate the differences, for each variation, in
the program. The bottom line is, that if it takes the developers 20
minutes to figure out the changes required (probably very optimistic),
and 1000 users send them the logs, that is 20,000 minutes of work.
Meanwhile, 200 of those machines have been upgraded to a new BIOS, and
another 500 have been replaced by new models. So, they start over on
700 of them, and another 800 people have sent in new logs for machines
that haven't been reported before. It is a losing proposition.
Then, of course, you have the users who have no idea what any of this
is all about, who just sit back waiting (hoping) for something to
happen. If they happen to have an identical machine to someone who has
submitted the information, and the developers do get around to
supporting that machine, their machine *may* also start to work. If
they have a different machine, it may never work, unless something
else happens that accidentally makes it work, and that can also break
it when something else changes.
I am convinced that the developers are trying to make ACPI work as it
is supposed to work. Unfortunately, nobody else is doing it that way,
and every manufacturer interprets the specs in a different way, then
tries to correct their errors (making more), with each BIOS that they
develop. The main problem with the current ACPI seems to be that it
needs to be tweaked for each, and every, machine that is out there,
and that is a lifetime project for more than one person.
Hendrik Schmieder
Lars Erdmann schrieb:
- comp.os.os2.ecomstation
- http://forum.ecomstation.ru/viewforum.php?f=6
- contact Eugene Gorbunoff
eugenegorbunoff
at
mail
dot
ru
Hendrik