wistron_btns: Implement RF-Kill support for some Acer and no-name systems

Bug #346586 reported by TJ
6
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Wishlist
linux (Ubuntu)
Fix Released
Low
TJ

Bug Description

Two previous bug reports have been trying to solve the issue of losing the state of the RF Kill switch after suspend/resume on a "Prestigio 157" laptop that uses a wireless button (not a switch) and relies on the system to save the button state whilst the device is suspended.

It uses the unmaintained acerhk driver to handle the buttons but that driver does not support the RF Kill API.

The user found that the wistron_btns module can be used to handle the system's buttons and does seem to support the RF Kill API, but doesn't 'know' the wireless button so cannot link it to the RF Kill system.

It seems possible that adding some form of recognition of the model to this driver would allow the button to be linked to the RF Kill API and solve the user's problem.

Tags: resume
TJ (tj)
summary: - winstron_btns: Implement RF-Kill support for some Acer and no-name
+ wistron_btns: Implement RF-Kill support for some Acer and no-name
systems
tags: added: resume
Revision history for this message
TomasHnyk (sup) wrote :

TJ: the problem is that the driver know about the wireless button (it is mapped correctly), but somehow it does not work, which seems to me to be a bug in wistron_btns. wistron_btns does have explicit support for my model: Prestigio 157 is identical to aopen 1557 (OEM name). This notebook is impossible to recognize softwarewise - it does not output any info to dmidecode and other similar tools.

Anyway, how can this be forwared to upstream? The kernel bugzilla says they accept only reports on vanilla kernels, I will try that since Ubuntu now offers them packaged and report back, if it also does not work, I guess I will fill a report to kernel bugzilla.

Revision history for this message
TomasHnyk (sup) wrote :

If anybody is interested, the reports in question are
https://bugs.launchpad.net/bugs/53953
https://bugs.launchpad.net/bugs/53310

Changed in linux:
status: Unknown → Confirmed
Revision history for this message
TJ (tj) wrote :

Tomas, can you attach the result of running the attached script which will collect the system's dmidecode and ACPI DSDT?

sudo collect-dmi-dsdt

Revision history for this message
TJ (tj) wrote :

Do you know which key-code is reported for the WiFi button? According to the driver...

/*
 * If your machine is not here (which is currently rather likely), please send
 * a list of buttons and their key codes (reported when loading this module
 * with force=1) and the output of dmidecode to $MODULE_AUTHOR.
 */

I've created a DKMS package containing a modified module for you to try but I need to know which key-code invokes the WiFi action.

Revision history for this message
TomasHnyk (sup) wrote :

file attached as requested.

I think I know the keycodes and I think they are the same as keycodes in the driver for ms2141. I do not know how to extract them with wistron button, but acerhk has got some nice debugging switches, so dmesg says:

I pressed wifi button:
[16913.628291] acerhk: received key code 0x30
[16913.628305] acerhk: translated acer key code 0x30 to key name 0x8
[16913.628526] acerhk: wbutton2 = 0x9610
[16913.628533] acerhk: translated acer key name 0x8 to input key 0x93
mail button
[16861.628297] acerhk: received key code 0x31
[16861.628313] acerhk: translated acer key code 0x31 to key name 0x7
[16861.628322] acerhk: translated acer key name 0x7 to input key 0x9b
webbrowser button
[16862.228296] acerhk: received key code 0x36
[16862.228310] acerhk: translated acer key code 0x36 to key name 0x6
[16862.228319] acerhk: translated acer key name 0x6 to input key 0x96
programmable button 1
[16862.828295] acerhk: received key code 0x11
[16862.828310] acerhk: translated acer key code 0x11 to key name 0x3
[16862.828319] acerhk: translated acer key name 0x3 to input key 0x94
programmable button 2
[16863.228298] acerhk: received key code 0x12
[16863.228313] acerhk: translated acer key code 0x12 to key name 0x4
[16863.228321] acerhk: translated acer key name 0x4 to input key 0x95

I have only 5 buttons (named KEY_PROG1,KEY_PROG2, KEY_MAIL,KEY_WWW and unname KE_WIFI in the source code) on my laptop (I lack the audio panel that ms2141 has got), but otherwise it corresponds to keycodes for ms2141:

static struct key_entry keymap_wistron_ms2141[] __initdata = {
 { KE_KEY, 0x11, {KEY_PROG1} },
 { KE_KEY, 0x12, {KEY_PROG2} },
 { KE_WIFI, 0x30 },
 { KE_KEY, 0x22, {KEY_REWIND} },
 { KE_KEY, 0x23, {KEY_FORWARD} },
 { KE_KEY, 0x24, {KEY_PLAYPAUSE} },
 { KE_KEY, 0x25, {KEY_STOPCD} },
 { KE_KEY, 0x31, {KEY_MAIL} },
 { KE_KEY, 0x36, {KEY_WWW} },
 { KE_END, 0 }
};

Hope this helps and thanks for your effort, that is really great.

Revision history for this message
TJ (tj) wrote : Re: [Bug 346586] Re: wistron_btns: Implement RF-Kill support for some Acer and no-name systems

I've uploaded a DKMS source package to my PPA. I've test-installed it on
a 32-bit PC here and it builds and installs correctly (the module is
32-bit only because it calls into the BIOS which is not possible using
64-bit OS).

Load it using:

sudo modprobe wistron_btns force=1 keymap=prestigio

See also: man wistron_btns

Revision history for this message
TomasHnyk (sup) wrote :

Tried it with the same results as before with keymap=1557/MS2141 - the buttons work, turning wifi on and off does not. I have no idea why. There must be something that acerhk does differently from wistron_btns in order to make turning on and off the wifi work. I have got to load acerhk with parametr autowlan=1, maybe something similar would be needed for wistron buttons. Sources for acerhk are here: https://launchpad.net/ubuntu/intrepid/+source/acerhk/0.5.35-3

Revision history for this message
TJ (tj) wrote :

Tomas, *don't* use keymap=1557/MS2141 - use keymap=prestigio

Revision history for this message
TJ (tj) wrote :

Hang on, did I misunderstand your sentence "Tried it with the same results as before with keymap=1557/MS2141" ?

I read that to mean that was the test you applied, but it could also be read as meaning the same results occurred using keymap=prestigio as with keymap=1557/MS2141.

Revision history for this message
TJ (tj) wrote :

OK, I suspect this new package will do it. I've just uploaded to PPA. version ends ~tj~ppa2i.

Revision history for this message
TomasHnyk (sup) wrote :

Yep, I meant that it yielded the same results, sorry for unclear statemant.

In other news, now it works, even with suspend: thank you very much. Will it get into jaunty and upstream kernel?

Revision history for this message
TJ (tj) wrote :

On Tue, 2009-03-24 at 23:33 +0000, TomasHnyk wrote:

> In other news, now it works, even with suspend: thank you very much.
> Will it get into jaunty and upstream kernel?

I'll email the patch over the listed maintainer of wistron_btns,
Miloslav Trmac.

TJ (tj)
Changed in linux (Ubuntu):
importance: Undecided → Low
status: New → In Progress
assignee: nobody → intuitivenipple
Revision history for this message
Tim Gardner (timg-tpi) wrote :
Changed in linux (Ubuntu):
milestone: none → ubuntu-9.04
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.5 KiB)

This bug was fixed in the package linux - 2.6.28-11.38

---------------
linux (2.6.28-11.38) jaunty; urgency=low

  [ Brad Figg ]

  * When AppArmor is configured, securityfs must be as well.
    - LP: #344370
  * ARM: Enable AA with SECURITYFS for imx51
    - LP: #344370

  [ Bryan Wu ]

  * Add 3 missing files to prerm remove file list
    - LP: #345623

  [ Daniel T Chen ]

  * SAUCE: (drop after 2.6.28) Don't trust hw-ptr blindly
    - LP: #330814
  * SAUCE: (drop after 2.6.28) Apply further pcm_lib updates for hw_ptr
    - LP: #330814

  [ Ike Panhc ]

  * Copy header files for various kernel media driver
    - LP: #322732

  [ Tim Gardner ]

  * Revert "Fix the VFP handling on the Feroceon CPU"
    Only applied to mv78xx0 ARM flavour.
  * Enabled drivers/staging/at76_usb
    - LP: #152626

  [ <email address hidden> ]

  * SAUCE: ipw2200: Enable LED by default
    - LP: #21367
  * SAUCE: wistron_btns: support Prestigio Wifi RF kill button over suspend
    - LP: #346586

  [ Upstream Kernel Changes ]

  * Build fix for __early_pfn_to_nid() undefined link error
  * Fix misreporting of #cores as #hyperthreads for Q9550
  * eventfd: remove fput() call from possible IRQ context
  * S390: __div64_31 broken for CONFIG_MARCH_G5
  * ALSA: Fix vunmap and free order in snd_free_sgbuf_pages()
  * ALSA: mixart, fix lock imbalance
  * ALSA: pcm_oss, fix locking typo
  * ALSA: hda - Fix DMA mask for ATI controllers
  * ALSA: hda - Workaround for buggy DMA position on ATI controllers
  * ALSA: opl3sa2 - Fix NULL dereference when suspending snd_opl3sa2
  * nfsd: nfsd should drop CAP_MKNOD for non-root
  * NFSD: provide encode routine for OP_OPENATTR
  * dm ioctl: validate name length when renaming
  * dm io: respect BIO_MAX_PAGES limit
  * dm crypt: fix kcryptd_async_done parameter
  * dm crypt: wait for endio to complete before destruction
  * ata_piix: add workaround for Samsung DB-P70
  * V4L/DVB (10218): cx23885: Fix Oops for mixed install of analog and
    digital only cards
  * thinkpad-acpi: fix module autoloading for older models
  * Add '-fwrapv' to gcc CFLAGS
  * Move cc-option to below arch-specific setup
  * USB: storage: Unusual USB device Prolific 2507 variation added
  * USB: Add Vendor/Product ID for new CDMA U727 to option driver
  * USB: option.c: add ZTE 622 modem device
  * USB: Add device id for Option GTM380 to option driver
  * USB: Option: let cdc-acm handle Sony Ericsson F3507g / Dell 5530
  * USB: Updated unusual-devs entry for USB mass storage on Nokia 6233
  * USB: unusual_devs: Add support for GI 0431 SD-Card interface
  * USB: serial: add FTDI USB/Serial converter devices
  * USB: serial: ftdi: enable UART detection on gnICE JTAG adaptors
    blacklist interface0
  * USB: serial: new cp2101 device id
  * USB: usbtmc: fix stupid bug in open()
  * USB: usbtmc: add protocol 1 support
  * USB: usbfs: keep async URBs until the device file is closed
  * USB: EHCI: expedite unlinks when the root hub is suspended
  * USB: EHCI: Fix isochronous URB leak
  * powerpc: Remove extra semicolon in fsl_soc.c
  * menu: fix embedded menu snafu
  * Linux 2.6.28.9
  * Add '-fwrapv' to gcc CFLAGS
    - LP: #348015
  * Move cc-option to below arch-s...

Read more...

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
TomasHnyk (sup) wrote :

TJ: did this got into the mainstream? AFAIK it did not - is it possible to resend it (maybe directly to LKML) - original maintainer seems to be unresponsive.

Revision history for this message
legolas558 (legolas558) wrote :

I am sending another patch which fixes this problem for my notebook (Maxdata Pro 7000X).

Finally, after 3 years...I fixed this problem!

Thanks for the pointers!

Revision history for this message
legolas558 (legolas558) wrote :

the patch for my notebook (Maxdata 7000X) has been accepted upstream and should be available with the next stable kernel; I propose for other people to follow the same path

Revision history for this message
TomasHnyk (sup) wrote :

Legolas558: and where did you send it? Directly to lkml or elsewhere? I tried mailing the maintainer several times but without response.

Revision history for this message
legolas558 (legolas558) wrote :

Firstly, you should create a patch which is conforming to the kernel rules (you can read about that in the Documentation directory of the kernel source).

Next you can send it to kernel-input mailing list and CC the same mail (with inline patch) to D. Torokhov (he is specified between authors/mantainers).

If you have already contacted them with a properly submitted patch, be patient: I am sure they have a big load of work!! I got a reply after re-sending it but if you send it as I specified you will not have delays.

P.S. always be polite with developers! ;)

Revision history for this message
TJ (tj) wrote :

I've submitted my patch directly upstream. For some reason the CC to this bug-report reply address doesn't seem to have come through.

Revision history for this message
TomasHnyk (sup) wrote :

Great, I see it has been accepted into 2.6.31, thanks a lot for your help.

Changed in linux:
status: Confirmed → Fix Released
Changed in linux:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.