Hello, thank you very much for testing. On Monday 22 December 2014 08:27:57 Alex Hung wrote: > = Testing = > > I tested six Dell systems for two sets of patches for dell > radio button - two system with radio slider and four with > radio hotkey. There are also two systems with working ARBT > method. > > == Basic Information == > Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2] > > Patches: > 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3] > 2. dell-rbtn [4] > > Method: > 1. run "rfkill list" and press hotkey / toggle slider during > runtime 2. run "rfkill list" and toggle slider during S3 > If there is problem with my patch series which does not reflect correct state after resume from S3, I can add pm hook which will try to re-read rfkill state (via GRBT) after system wake up from S3. > == Results == > > I summarized the tests in Google sheet as below. Please advise > if anyone has problem reading it. > > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG_ > _UAO2qfZ829CkJLPo06aI/edit?usp=sharing > > PS. The document will stay as long as possible for future > references. > > == Summary == > > 1. I did not observed a duplicated event. However, keycode 240 > (unknown) is generated on many UUT. It is not issued by > dell-laptop or del-wmi. I am suspecting it is the other event > Pali observes but it can be the result of different distro. > It comes from i8042 bus via internal AT keyboard (not from WMI). In userspace you can assign correct keycode (e.g. KEY_WLAN or KEY_RFKILL) so it does not show as unknown. Its scancode is 136 (0x88) and default keycode 240 (0xF0). Some other distributions or other software automatically map this unknown 240 keycode to some key, so you will see duplicate event even in X applications. > 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can > also be used toggle wireless state but this can also be > distro-dependent. This scancode does nothing on Ubuntu 14.10. > I would suggest you to use program input-events for reading pressed keys as it show all key events from kernel and it is working per input device (so it is possible to check if event comes from AT keyboard, WMI or other driver). If there is problem with WMI driver (it reports both key press and BIOS do some change) we can patch WMI driver to prevent another looping problem... > 2. There are two systems with working ARBT (XPS 13 9333 and > Inspiron 7447). Calling ARBT(1) changes BIOS behaviours, and > this matches to Dell's document. We should include it in the > patch for maximum capability. > How it change BIOS behaviour? > > [1] dell-wireless is only tested 3.16. > [2] dell-rbtn is tested on 3.16 and 3.18, but no differences > are observed. [3] > http://people.canonical.com/~alexhung/dell-wireless/ [4] > http://people.canonical.com/~alexhung/dell-rbtn/ > Next I would suggest you to test clean system without fanny software like NetworkManager. Previously we saw that NetworkManager change state of network devices and rfkill softstates so it can interact with kernel. I think that new driver in kernel should work also without NetworkManager and also there are people who use alternative software (and not NetworkManager). I know that Ubuntu has installed & enabled NetworkManager by default, so some results in your table could have values changed by NetworkManager and not by kernel. And I have one question: Does Inspirion 5721 have ACPI DELRBTN device (instead DELLABCE). -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
