new Linux/ACPI home page
Len Brown
reviewerThe home page for the Linux/ACPI project is moving here:
http://www.lesswatts.org/projects/acpi/
(Thank you to the lesswatts project for supplying webmaster
and hosting resources for us:-)
I conjured up most of the content -- so please send any feedback on content to me.
Don't sweat the formatting issues right now - the ink is only a few hours old at this point and the webmaster is actively fixing the obvious formatting glitches.
I've marked a couple of sections as TBD b/c I havn't written them yet. If you want to volunteer to help, please let me know.
Re: http://acpi.sourceforge.net/
When the lesswatts page is solid, I'd like to delete duplicate/stale content from sf -- as two copies of the truth always leads to trouble,
and much of the sf content is stale now anyway. However, I'd like to leave two things on sf.net that will not be moving to lesswatts -- the documentation of the /proc/acpi/ interfaces (which are becoming legacy and going away), and the DSDT databse -- which I believe is also somewhat of a historical artifact.
thanks,
-Len
Quoted 2 lines · Len Brown
and going away), and the DSDT databse -- which I believe is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful, if could be searched for particular feature -- absence of EC, use of SBS, etc.
Alex.
Len Brown
reviewerQuoted 7 lines · Alexey Starikovskiy
Quoted 2 lines · Len Brown
and going away), and the DSDT databse -- which I believe is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful, if could be searched for particular feature -- absence of EC, use of SBS, etc.
True.
I don't like the original DSDT database -- it was from an era when people thought that it was a good idea to hack a DSDT to workaround Linux failures and share the hacked DSDT with others. That was a bad strategy and it should be abandoned. DSDT hacking is for Linux debugging only -- Linux should always be made to work with an un-modified DSDT.
yes, acpidump would be more useful than just the DSDT -- as we get all kinds of issues with all the tables.
One problem is that shipping around BIOS images, particularly modified ones, is sort of a touchy area. This is the code of the manufacturer, who may or may not be happy that the community is hacking their code. If any of those manufactureres got mad at Intel for mucking with their BIOS code, that would be a bad day for we Intel employees.
lesswatts.org is hosted by Intel. So we'd need to sort though this issue before adding an acpidump database.
thanks,
-Len
Quoted 9 lines · Len Brown
Quoted 7 lines · Alexey Starikovskiy
Quoted 2 lines · Len Brown
and going away), and the DSDT databse -- which I believe is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful, if could be searched for particular feature -- absence of EC, use of SBS, etc.
Quoted 8 lines
True.
I don't like the original DSDT database -- it was from an era when people thought that it was a good idea to hack a DSDT to workaround Linux failures and share the hacked DSDT with others. That was a bad strategy and it should be abandoned. DSDT hacking is for Linux debugging only -- Linux should always be made to work with an un-modified DSDT.
What about plain _crap_ DSDT's like some (mine at least) from HP where there are problems which just can't be fixed without bypassing the DSDT functionality (e.g. lid switches, video extension) and writing a driver specific to that machine's chipset?
Even then, some of the issues are in SMI, so can't be fixed, but at least with a hacked DSDT, I can get things mostly working with the new user space. A BIOS would be the _right_ solution, but as the machine is old, that isn't going to happen.
Quoted 9 lines
yes, acpidump would be more useful than just the DSDT -- as we get all kinds of issues with all the tables.
One problem is that shipping around BIOS images, particularly modified ones, is sort of a touchy area. This is the code of the manufacturer, who may or may not be happy that the community is hacking their code. If any of those manufactureres got mad at Intel for mucking with their BIOS code, that would be a bad day for we Intel employees.
Aren't most of the BIOS codes based on reference implementations from chipset vendors anyway? If so, I think Intel take the lead here and make their reference BIOS code available publicly. It could be debugged by the community at large, and perhaps we'd end up with derivative works (OEM BIOS) of better quality.
Climbing down from the soap box now.
Best wishes
Peter
(who'd reverse engineer and patch his HP BIOS if only he had the assembler-fu to do so).
Signature · 10 lines
Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!)
Quoted 9 lines · Len Brown
Quoted 7 lines · Alexey Starikovskiy
Quoted 2 lines · Len Brown
and going away), and the DSDT databse -- which I believe is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful, if could be searched for particular feature -- absence of EC, use of SBS, etc.
Quoted 8 lines
True.
I don't like the original DSDT database -- it was from an era when people thought that it was a good idea to hack a DSDT to workaround Linux failures and share the hacked DSDT with others. That was a bad strategy and it should be abandoned. DSDT hacking is for Linux debugging only -- Linux should always be made to work with an un-modified DSDT.
I violently agree.
Quoted 10 lines
yes, acpidump would be more useful than just the DSDT -- as we get all kinds of issues with all the tables.
One problem is that shipping around BIOS images, particularly modified ones, is sort of a touchy area. This is the code of the manufacturer, who may or may not be happy that the community is hacking their code. If any of those manufactureres got mad at Intel for mucking with their BIOS code, that would be a bad day for we Intel employees.
Quoted 2 lines
lesswatts.org is hosted by Intel. So we'd need to sort though this issue before adding an acpidump database.
Well, we have suspend.sf.net and the acpidump database can safely be put in there, I think. ;-)
Greetings,
Rafael
Hi!
Quoted 10 lines
Quoted 10 lines
yes, acpidump would be more useful than just the DSDT -- as we get all kinds of issues with all the tables.
One problem is that shipping around BIOS images, particularly modified ones, is sort of a touchy area. This is the code of the manufacturer, who may or may not be happy that the community is hacking their code. If any of those manufactureres got mad at Intel for mucking with their BIOS code, that would be a bad day for we Intel employees.
Quoted 5 lines
Quoted 2 lines
lesswatts.org is hosted by Intel. So we'd need to sort though this issue before adding an acpidump database.
Well, we have suspend.sf.net and the acpidump database can safely be put in there, I think. ;-)
Agreed.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html