Hello Developers,
I'm sorry for not cc:ing to relevant people and other lists, I just encountered
a situation I wanted to share.
On Acer Aspire One, A150 Aw, sold to me with Linpus but then rooted up and
installed Ubuntu Karmic (yes, 9.10) and updated the BIOS to 3309 (latest). This
however isn't Ubuntu-specific (actually if I googled correctly, only one
distribution got it right, the original Linpus Lite...)
The issue I am talking about is : the killswitch for the wireless adaptor.
The Internet is almost 'flooded' with reports of this not working on various
distributions, that's why decided to go a level higher.
I have actually found that pushing this button repeatedly, produces 2 scancodes
: showkey reports keycode 238 pressed and keycode 238 released; in -s mode
reports 0xe0 0xf3 and 0xe0 0x73.
Also I think the firmware (BIOS) reports these only when the operation on the
WIFI card has been done, i.e. when it successfully toggled it, because when
pushing the button too often (too small gap between pushes)
As this netbook gives a completely unusable WMI interface (found out by Carlos
Corbacho, the acer-wmi developer) there is no other way the rfkill
infrastructure can be aware of the hard-lock status;
The killswitch itself is a mono-stable sliding button, not a bi-stable slider;
so I think this might also be related to some people's problems with
(de)activating wifi hardware on laptops that have just a Fn+wifi toggle;
This is why I think this might be a more generic issue, and why I decided to
post here.
Apologies, if it really really doesn't belong here.
Lukasz
Lukasz Sokol <el.es.cr <at> gmail.com> writes:
Sorry, didn't finish a sentence :
>
> Also I think the firmware (BIOS) reports these only when the operation on the
> WIFI card has been done, i.e. when it successfully toggled it, because when
> pushing the button too often (too small gap between pushes)
>
... then it only reports one scancode (0xe0 0xf3)
(but then that might be because of some polling interval issues and/or the fact
I was doing it from a virtual console under X).
>
> Lukasz
>
>
Lukasz
On Thu, Dec 17, 2009 at 11:47:00AM +0000, Lukasz Sokol wrote:
> On Acer Aspire One, A150 Aw, sold to me with Linpus but then rooted up and
> installed Ubuntu Karmic (yes, 9.10) and updated the BIOS to 3309 (latest). This
> however isn't Ubuntu-specific (actually if I googled correctly, only one
> distribution got it right, the original Linpus Lite...)
>
> The issue I am talking about is : the killswitch for the wireless adaptor.
>
> The Internet is almost 'flooded' with reports of this not working on various
> distributions, that's why decided to go a level higher.
What do you mean by "not working"? You don't really explain what the
issue you're seeing is.
--
Matthew Garrett | [email protected]
Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:
> > The Internet is almost 'flooded' with reports of this not working on various
> > distributions, that's why decided to go a level higher.
>
> What do you mean by "not working"? You don't really explain what the
> issue you're seeing is.
>
Hello Matthew,
I define "not working" in this case by "it switches hardware on/off without the
software knowing".
i.e. the rfkill does not know, and the 'problem' is only noticed when the wifi
disassociates (but Network Manager tries on to reconnect). On the other hand,
invoking /sbin/rfkill [un]block wifi blocks/unblocks wifi comfortably.
(Please keep me Cc:ed - linux-kernel is high enough traffic that it's
easy to lose track otherwise)
On Thu, Dec 17, 2009 at 03:17:51PM +0000, Lukasz Sokol wrote:
> I define "not working" in this case by "it switches hardware on/off without the
> software knowing".
>
> i.e. the rfkill does not know, and the 'problem' is only noticed when the wifi
> disassociates (but Network Manager tries on to reconnect). On the other hand,
> invoking /sbin/rfkill [un]block wifi blocks/unblocks wifi comfortably.
What does ls -l /sys/class/rfkill look like? What driver are you using
for your wireless card?
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> (Please keep me Cc:ed - linux-kernel is high enough traffic that it's
Ok, sorry, I was posting through gmane's web interface, I like it quite, but it is stupid
in the sense that it does not keep cc:s...
>> i.e. the rfkill does not know, and the 'problem' is only noticed when the wifi
>> disassociates (but Network Manager tries on to reconnect). On the other hand,
>> invoking /sbin/rfkill [un]block wifi blocks/unblocks wifi comfortably.
>
> What does ls -l /sys/class/rfkill look like? What driver are you using
> for your wireless card?
>
lrwxrwxrwx 1 root root 0 2009-12-17 20:30 rfkill0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0
lukasz@workhorse:~$ lsmod |grep 802
mac80211 181140 1 ath5k
cfg80211 93052 3 ath5k,mac80211,ath
rfkill is built in (i.e. not a module) in this kernel, I heard somewhere.
Lukasz
On Fri, Dec 18, 2009 at 08:52:06AM +0000, Lukasz Sokol wrote:
> lrwxrwxrwx 1 root root 0 2009-12-17 20:30 rfkill0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0
Ok. You have no platform rfkill interface. ath5k needs to notice that
it's been killed and update its rfkill state accordingly.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Fri, Dec 18, 2009 at 08:52:06AM +0000, Lukasz Sokol wrote:
>
>> lrwxrwxrwx 1 root root 0 2009-12-17 20:30 rfkill0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0
>
> Ok. You have no platform rfkill interface. ath5k needs to notice that
> it's been killed and update its rfkill state accordingly.
>
So it is up to the ath5k driver developers then ? :)
Lukasz
On Fri, Dec 18, 2009 at 02:28:09PM +0000, Lukasz Sokol wrote:
> Matthew Garrett wrote:
> > On Fri, Dec 18, 2009 at 08:52:06AM +0000, Lukasz Sokol wrote:
> >
> >> lrwxrwxrwx 1 root root 0 2009-12-17 20:30 rfkill0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0
> >
> > Ok. You have no platform rfkill interface. ath5k needs to notice that
> > it's been killed and update its rfkill state accordingly.
> >
> So it is up to the ath5k driver developers then ? :)
Yup.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Fri, Dec 18, 2009 at 02:28:09PM +0000, Lukasz Sokol wrote:
>> Matthew Garrett wrote:
>>> On Fri, Dec 18, 2009 at 08:52:06AM +0000, Lukasz Sokol wrote:
>>>
>>>> lrwxrwxrwx 1 root root 0 2009-12-17 20:30 rfkill0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0
>>> Ok. You have no platform rfkill interface. ath5k needs to notice that
>>> it's been killed and update its rfkill state accordingly.
>>>
>> So it is up to the ath5k driver developers then ? :)
>
> Yup.
Thanks Matthew, will see if somebody shows up :)
Lukasz