Bug 15167
Summary: | Lenovo Ideapad line support in acer_wmi? | ||
---|---|---|---|
Product: | Drivers | Reporter: | Michał Witkowski (neuro) |
Component: | Platform | Assignee: | Carlos Corbacho (carlos) |
Status: | CLOSED CODE_FIX | ||
Severity: | enhancement | CC: | alan, jlee, rui.zhang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | kernel26-rc | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 56331 | ||
Attachments: |
Lenovo Idepad U330 DSDT
Lenovo Ideapad U330 patch for acer_wmi |
Description
Michał Witkowski
2010-01-28 22:20:18 UTC
re-assign to Carlos. ping Carlos... ping Carlos, :p Michal, does the problem still exist in the latest upstream kernel, say 2.6.34-rc1? It's not that much of a problem, as I've blacklisted the module. It's only that I think that acer_wmi could be extended to support the Ideapad line. Ok, a bit of a success right now, which proves that acer_wmi IS the way to go. I've edited and compiled acer-wmi.c from: 577 /* 578 * On laptops with this strange GUID (non Acer), normal probing doesn't 579 * work. 580 */ 581 if (wmi_has_guid(AMW0_GUID2)) { 582 interface->capability |= ACER_CAP_WIRELESS; 583 return AE_OK; 584 } to 577 /* 578 * On laptops with this strange GUID (non Acer), normal probing doesn't 579 * work. 580 */ 581 if (wmi_has_guid(AMW0_GUID2)) { 582 interface->capability |= ACER_CAP_WIRELESS | ACER_CAP_BLUETOOTH; 583 return AE_OK; 584 } I only forced the bluetooth capability. And guess what! I've now got bluetooth RFKILL which WORKS! I know it's a dirty little hack and that Lenovo Ideapad U330 support could be nicely detected, but I'm no kernel hacker and I don't (yet) know how to do it. Created attachment 26075 [details]
Lenovo Ideapad U330 patch for acer_wmi
This patch adds the following:
1. Support for forced bluetooth from quirks
2. Bluetooth rfkill for Ideapad U330
3. Working _reading_ of wireless rfkill state. Writing worked, reading always showed 0
Please note, 3. fixes problem with wireless rfkill being off after suspend.
The DMI_MATCH part is a bit tricky, because U330 has it's identification in version not model parts of DMI.
The above patch adds the most needed functionality: rfkill. However there is one more critical feature: being able to disable/enable the camera. I've used the acer_ec.pl [1] script to toy around. In the DSDT (attached before) I found the following: Offset (0x54), CAPR, 1, So I did: root@hermes:~$ ./acer_ec.pl +f 0x54 0x01 REG[0x54] == 0x60 REG[0x54] := 0x61 REG[0x54] == 0x61 to turn off the onboard camera and the following to turn it off: root@hermes:~$ ./acer_ec.pl -f 0x54 0x01 REG[0x54] == 0x61 REG[0x54] := 0x60 REG[0x54] == 0x60 It works really really well. However, I don't know how to add an entry in the /sys interface to expose this functionality. Could someone guide me how to do it? Moreover, I found that touchpad state is available at 0x74 with flag 0x08. [1] http://code.google.com/p/aceracpi/wiki/EmbeddedController Could anyone comment on the above patch? I just asked my friend who has a Lenovo Ideapad Y550 whether or not his machine is similar. Will post later on. Apart from that, had anyone looked into the patch yet? It's not really intrusive and I'd like it to be included in the vanilla kernel, so that other owners of Lenovo hardware can take advantage of it. The patch looks fine to me; though I'd prefer to work out how to do autodetection on these Lenovo's, as I don't really want to start building up a list of DMI quirks just to make these laptops work (but for this kind of WMI interface, which is just a glorified wrapper for direct BIOS calls, this non trivial - last time I did it involved fiddling with the Windows Kernel Debugger to trace ACPI). I'm aware that the touchpad state is available from the EC, but it's not terribly useful (you can't change it, and there's nothing that can really read it or cares about it), so I don't think it's worth exposing. The camera state is more interesting, though I'm not aware of any subsystem through which to expose that, and if it can be controlled via some other mechanism, then it may not be that useful to expose it either. Just look at Michał's DSDT, there have VPC2004 device in DSDT, that means it must support by ideapad laptop driver. My plan is add a patch to acer-wmi to check if ther ehave VPC2004 device, then ignore it and leave it to handle by ideapad laptop driver. Please try Ike's patch on acer-wmi, it avoid acer-wmi driver generate rfkill on Lenovo machines: From: Ike Panhc <ike.pan@canonical.com> Date: Fri, 3 Feb 2012 16:46:39 +0800 Subject: [PATCH] acer-wmi: No wifi rfkill on Lenovo machines Git-commit: 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a Patch-mainline: v3.3-rc8 References: bnc#745236 We have several reports which says acer-wmi is loaded on ideapads and register rfkill for wifi which can not be unblocked. Since ideapad-laptop also register rfkill for wifi and it works reliably, it will be fine acer-wmi is not going to register rfkill for wifi once VPC2004 is found. Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no wifi rfkill capability, there are reports which says acer-wmi also block wireless on Thinkpad E520/E420. |