G73 and asus-wmi linux driver.... I need *your* help

Hello G73 users. I just got my G73SW last week and was pretty frustrated (if not unsurprised) to find that it was not supported in Linux via the asus-laptop kernel module.

I disassembled and examined my ACPI DSDT and found that the G73SW only exposes the hotkeys and other ACPI-related machine specifics (wifi led, keyboard backlight, etc) through the WMI interface. There is rudimentary WMI remapping in the linux kernel, but no clear support for ASUS laptops.

I'm going to write a kernel driver to support the hotkeys and initially I hope to target as many ASUS-WMI enabled G73s as I can.


If you're willing, please go here and download the iasl binary:
ACPICA

From there you can download the file, unzip it, and run a command prompt. cd to the directory of the unzipped iasl.exe and run:
iasl.exe -g

It should produce a few files, I'm mainly interested in DSDT_Notebook.dat and dsdt_notebook.dsl. If you would, zip those up and attach them to the thread. I should only need one dat/dsl file per model, but having a few from the same would never hurt. If you do post one up though, please specify which model you are using.

NOTE: You are at no risk of damaging your laptop by doing this and it will not expose any of your personal information. It is just dumping your ACPI DSDT for me to examine. For more info on ACPI see here. For more info on DSDTs see here. The ACPI4Asus project is here but I am not (yet?) affiliated with them... they are just inspiration.

Thanks, here's to hoping for complete linux support for these bad boys in the near future!
-Nate


(I've attached a zip of the files from my laptop so you know what they look like. This is from a G73SW-A1)

 

I would do this for you but I have a G73JH and I'm 99.9% sure that the JH, JW, and SW have identical ACPI information. I'm 90% sure that the G53, G51, and G71 will also be identical. They all use the ATK package and the ATK for all of them are interchangable. I have an old first generation eePC but it has XUbuntu on it, not windows.

If a dump of a machine extremely similar to yours would be helpful, I can dump ACPI data for a JH?

 

Yup, I would expect the ATK interface exposed through WMI via the DSDT will prove pretty darn similar across G73 models, but it is prudent to make sure.

If you've got the time the data couldn't hurt.

 

Try booting with the acpi_osi=Linux boot parameter. That should expose the acpi hotkeys (hopefully) instead of using wmi.

I had to modify eeepc-wmi.c recently, you might be able to get away with some cheaphax on that. Here's what I did: [all variants] asus 1015pem - Page 2 - Ubuntu Forums

@Jody: the SW must be different, the other models use ACPI by default not WMI.

 

I've been hacking away at the eeepc-wmi driver, actually. Added some printks to see what I could expose, but there is plenty of work to do.

acpi_osi=Linux (or acpi_osi=!Windows 2009) doesn't have an effect on the G73SW.

 

When you acpi_listen there's no difference at all with acpi_osi=Linux on any of the hotkeys? You don't get any events?

 

I will be getting a g53jw here shortly, and i use linux as my main os so I will dump those for you for this model

 

Another thought besides what I previously asked about acpi_listen (still waiting for your answer on that)...

Try toggling EFI/UEFI in the BIOS setup, if you can (previous models have the option). It may change the behavior of the hotkeys.

 

I am currently locked into UEFI mode because I have my disks setup using GPTs and windows booting through UEFI.

I boot into linux under BIOS mode w/ grub2 installed on the GPT partition marked bios_grub. GRUB2/2.6.38-rc3 refuse to boot when loaded via UEFI. Not sure what's going wrong as I have no serial port to get early kernel panic messages from, but I just hang after initrd. :\


Thanks jamezelle. The maintainer of the current asus-laptop and eeepc-wmi kernel drivers has gotten in touch with me and is developing pretty heavily right now. Hopefully in a little while there will be nice WMI-backed hotkey support for general ASUS laptops as that seems to be the sole direction ASUS is heading with the newer models.

 

Are you getting anything from acpi_listen? If you don't even get Fn+F5 and F6, that's a new configuration for ASUS. If you have more details about this, or have posted anywhere else, please post links, since there isn't any mention of this that I can find elsewhere.

 

I do not get FnF4 or FnF5. So far the only hotkeys dumping events out of the hacked up eeepc-wmi driver through the WMI GUID associated with such (from wmidump) are the keyboard backlight keys.

I've built a kernel with verbose acpi debug messaging but there's no clear problem... though there are a few different variables affecting things IME. If I'm correct I believe the nouveau driver is interfering with the screen brightness hotkeys.... but I have to investigate further later. I have also noticed when coming back into windows from linux, sometimes wifi is turned off. Pressing the hotkey to turn it back on does so, but then Bluetooth turns off... it takes toggling it once or twice to get the two back in sync. This leads me to believe linux is probing and interacting with things incorrectly in the WMI interface.

I posted a bug report to the acpi4asus bug tracker here:
acpi4asus - Feature #144: Asus G73SW-A1 support request - dev.iksaif.net

I've been corresponding with the developer via email as well. I've also been posting about the UEFI boot issues here:
https://bbs.archlinux.org/viewtopic.php?id=111327

 

OK, thanks for posting the links, I'll take a look.

I was specifically asking about acpi_listen because the backlight brightness controls had (until now) usually been ACPI, even when WMI is used for the rest.

 

Yeah, I switched back into linux... absolutely nothing emitted from acpi_listen.

Perhaps more telling, heres tree /proc/acpi:

Code:

root@nate-G73SW:/# tree /proc/acpi/
/proc/acpi/
├── ac_adapter
│ └── AC0
│     └── state
├── battery
│ └── BAT0
│     ├── alarm
│     ├── info
│     └── state
├── button
│ ├── lid
│ │ └── LID
│ │     ├── info
│ │     └── state
│ ├── power
│ │ └── PWRF
│ │     └── info
│ └── sleep
│     └── SLPB
│         └── info
├── event
└── wakeup

I'm banging around on /sys/module/acpi/parameters/debug_* to see if I can trace where ACPI is breaking down.

 

Actually mine looks mostly the same except for the processor:

Code:

/proc/acpi
├── ac_adapter
│   └── AC0
│       └── state
├── battery
│   └── BAT0
│       ├── alarm
│       ├── info
│       └── state
├── button
│   ├── lid
│   │   └── LID
│   │       ├── info
│   │       └── state
│   ├── power
│   │   └── PWRF
│   │       └── info
│   └── sleep
│       └── SLPB
│           └── info
├── event
├── processor
│   ├── CPU0
│   │   └── throttling
│   └── CPU1
│       └── throttling
└── wakeup

That's from a U20A, which has no WMI hotkeys.

My 1015PEM which does use WMI shows ACPI scancodes on Fn + F1, F5 and F6.

If the hotkeys are exclusively via WMI, then it's going to definitely require a modified eeepc-wmi -- keep us posted here.

 

Bit of a bump. I could still really use some DSDT dumps for users of other G series ASUS laptops.

Did a "live" session with Corentin ssh'd into my notebook at midnight (6am in France) and we were (really, he was) able to probe debugfs and get keyboard backlighting to respond, LCD backlighting to respond, as well as some cursory thermal management and state information.

There are some discrepancies between what my DSDT is reporting and what is actually available/happening on my notebook, so it would be beneficial to get a larger sample to inspect if ASUS is simply cloning DSDTs and leaving unused/dead paths in some notebooks.

It's only a matter of time now until an asus-wmi driver is finished, but some community help with DSDTs would be great.

Cheers!
-Nate

 

Here's the Jh DSDT.

 

Thanks for the DSDT.

I have just submitted my patches to Corentin (the dev) for driver-based keyboard backlight control. No more bash scripts, it works just like in widows... out of the box.

Corentin has put a lot of work into this and I'm trying to get feedback and patches back to him as quickly as possible. The goal is to finish up before the 2.6.39 merge window closes. I'm currently very happy with the state of things: as far as I can tell every single hotkey is working and all functionality is there.

The last thing we're working on is synchronous rfkill. Currently bluetooth and wlan are flip/flopping when we need them to be in the same state.

 

Nice, I see a new asus-nb-wmi driver in git. I'll check that out later.

I wrote a small program that's a handler for the backlight, it got shot down pretty hard in favor of the acpid scripts. I hope you have better luck with your approach.

 

Despite my best attempts acpid wasn't getting events from the WMI handler like I expected. I figured I would just forget that and make the calls directly. If accepted Corentin is probably going to want to add a module option to defeat that behavior.

I've been building against an up to date snapshot of Linus' tree, so you may wish to do the same. I've attached my patch, though it hasn't yet been accepted by Corentin and thus shouldn't be taken as official.

 

It'll be nice to have the option here!

I love linux (for school and work), but I can't see any reason to use it on my windows gaming laptop