I’ve been rather quiet lately, so time for the latest news:
1) The input part of acer_acpi (the keyboard quirks) has been accepted by Dmitry Torokhov (the input subsystem maintainer) into his tree. This will be going into 2.6.25 – this means that if you have one of the laptops that requires the old acerhk keyboard quirk to make the extra scancodes work, you won’t need acer_acpi just for this fro 2.6.25 onwards. (This code is not acer_acpi specific, so I’ve never been happy with it just sitting in acer_acpi).
2) No news on any other upstream front I’m afraid – wmi & acer-wmi (the upstream port of acer_acpi) are _still_ waiting to be reviewed by the ACPI maintainer (not that I’m getting a little irritated now after three months…)
3) acer_acpi 0.11 will hopefully be released soon – I’ve not had any word of the device autodetection code breaking horribly. Quite the contrary, reports so far indicate that it’s working quite well, so it’s almost time to inflict^^^^^^release it.
4) There appears to be a bug with OpenSuSE 10.3 and the wmi-acer/ wmi module –
https://bugzilla.novell.com/show_bug.cgi?id=352648
I’m aware of it – but currently have no clue as to why it doesn’t work on OpenSuSE, yet works on the same hardware with other distributions.
5 Responses to “acer_acpi – Latest news”
Post A Comment
You must be logged in to post a comment.
April 16th, 2009 at 8:26 am
hy
i need to contact you
mi interest is to comprehend how can I use your good work to create or compile without errors a good DSDT for my acer 5930g
is it possible?
in suse/ubuntu i have a dsdt.. but if i disassemble it with iasl.. i see a lot of redundant names.. and other errors then .. if i recompile it.. i have 60+ errors!
can you help me?
ciao
ugo
April 16th, 2009 at 9:01 am
To be honest with you – don’t bother.
Most DSDT’s are compiled with Microsoft’s own ASL compiler, which is a lot less strict than the Intel one. So any ‘errors’ are really the fact the Windows is a lot more liberal.
As per the ACPI maintainer, Linux is expected to simply deal with these ‘errors’ and just work. So if you have a specific problem, please file a bug on the kernel bugzilla. Otherwise, ‘fixing’ your DSDT won’t do anything for you.
April 16th, 2009 at 11:11 am
ah
ok
for me those problems are not for windows but for unix (or osx)
then.. iasl in bsd give me those errors
i have the dsdt.dsl in googlecode/acer acpi page, but for example there are no entry about HPET and I know that it must be fixet to run perfect with osx.
thanks
bye
April 16th, 2009 at 11:13 am
ah.. sorry I remember.. the second reason to mod the dsdt is to let linux/unix to use the typical buttons (ancer empowering.. bt button etc..) that are on a laptop. buttons that can be used in windows and not on linux/unix.
April 16th, 2009 at 11:19 am
1) The buttons aren’t affected by the DSDT – they just generate keycodes, which require software in userspace to handle the keypress to actuall do something.
2) Again, DSDT errors aren’t real ‘errors’ – there a difference in how Intel and Microsoft interpret the ACPI spec, and what they will let you get away with.
Most Unixes share the same ACPI core, and it should be able to handle any of these ‘errors’ (and if not, it’s a bug that needs to be fixed).
As for DSDT hacking and OSX – I can’t help you there. If your using Linux though and want to try to get the HPET working (assuming your chipset has one), booting the kernel with hpet=force is your best bet.