| === cpaelzer__ is now known as cpaelzer | ||
| === lotus|i5 is now known as lotuspsychje | ||
| letterrip | is there a way to disable my WLAN hardware switch? | 17:57 |
|---|---|---|
| letterrip | it is currently mapped to keycode 246 = XF86WLAN NoSymbol XF86WLAN | 17:57 |
| letterrip | i try and change its state with rfkill, but that is ignored | 17:57 |
| TJ- | letterrip: just came in, saw your last 2 messages. having trouble with soft or hard block on wifi? is it an Acer or Asus system? | 17:59 |
| letterrip | TJ- Sony VAIO | 17:59 |
| letterrip | hard block | 17:59 |
| letterrip | it fails intermittently - can be 'fixed' sometimes by pressing on the case | 18:00 |
| lordcirth_ | letterrip, if it's bound to a keycode, could you unbind it in your keymap? | 18:00 |
| TJ- | which Vaio model? I have one I don't use now but that had the same kind of issue - I had to resolder and/or adjust the physical switch | 18:01 |
| TJ- | I found if I 'rammed' the switch to the enable position it was fine for a long time but it would eventually disengage and I'd have to repeatedly push it back n forward roughly to get it to re-enagage, so I took it apart and fixed it permanently | 18:02 |
| letterrip | TJ- VGN-AR320E - i think it is the same as one of hte older Acer/Asus - I could potentially disable the system and fix the physical switch - but if possible would prefer a kernel/software method | 18:02 |
| TJ- | letterrip: if a hard block is happening there's nothing you can do in software | 18:02 |
| letterrip | TJ- it is a hardware switch, but I think the kernel can ignore it | 18:03 |
| letterrip | ie it isn't interrupting the powersupply to the wifi - the kernel just 'knows' it is supposed to turn the wifi off/on | 18:03 |
| TJ- | letterrip: do you know if on that model the sony-laptop module controls rfkill function? | 18:03 |
| letterrip | using rfkill doesn't work | 18:04 |
| TJ- | looking at the kernel's rfkill module, it only has 1 param, master_switch_mode and that only controls the effect of SW_RFKILL_ALL | 18:06 |
| letterrip | TJ- ah | 18:07 |
| letterrip | TJ- I've read elsewhere that 'disabling the sony_laptop' module has worked for others to disable the hardware switch | 18:08 |
| letterrip | on related models | 18:09 |
| TJ- | sony-laptop.c has a lot of code handling rfkill too so looks like the signals come in via ACPI, where it calls sony_call_snc_handle() to get the switch state | 18:09 |
| TJ- | letterrip: it might do, yes | 18:09 |
| TJ- | you may also lose other functionality too | 18:09 |
| letterrip | ok - will look at the source, and maybe make a local modification | 18:11 |
| letterrip | thanks for the help | 18:11 |
| TJ- | letterrip: I did some exhaustive analysis of the ACPI of a range of Vaio models some time back, I'm trying to find where I left it so you can take a look | 18:13 |
| letterrip | ah cool | 18:13 |
| TJ- | Grrr... took me ages, had to remember how to map a directory from an old expired domain to a new domain! https://iam.tj/projects/snc/ -- it's analysis of the ACPI methods of a large number of models which we used to develop the sony-laptop module functions | 18:27 |
| letterrip | TJ- greatly appreciated | 18:28 |
| TJ- | I'm struggling to remember which method dealt with rfkill... it may have been GWDP | 18:28 |
| letterrip | k | 18:29 |
| TJ- | it may also have had some involvement of the methods dealing with extended key scan-code ... I don't have my original notes any more... I was wondering/hoping this data might point to a way to selectively disable hardware kill... but the easy way of course is to try it with sony-laptop unloaded | 18:30 |
| TJ- | blimey, that brings back memories - those tables were all auto-generated using awk scripts | 18:31 |
| letterrip | TJ- yeppers | 18:33 |
| letterrip | thanks for the pointer | 18:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!