* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
@ 2011-03-10 22:02 Joey Lee
2011-03-11 20:21 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-10 22:02 UTC (permalink / raw)
To: oldium.pro; +Cc: Joey Lee, linux-acpi, platform-driver-x86
於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> Hi all,
>
> This is about Acer WMI driver and bluetooth support. I hope I'm at the right
> place with my question :-)
>
> I tried to use bluetooth again on my Acer TravelMate 5730G and discovered a
> usability problem. I've checked 2.6.38-rc7:
>
> 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is blocked.
Yes, this is right behavior.
Because have a acer-wmi patch in 2.6.38 to sync the connection devices
(wlan, bluetooth, 3G) status with BIOS.
Acer BIOS fills-in the device initial states in SMBIOS when system boot,
then acer-wmi dirver sync this states with killswitch. By default, Acer
BIOS set the bluetooth to off.
> 1. I have to enable the HW bluetooth switch to get the bluetooth LED running
> (USB device appears in lsusb). The acer-bluetooth SW rfkill is unblocked, the
> SW rfkill of hci0 is blocked.
Yes, this is also right behavior, because acer-wmi driver will maintain
the killswitch status with BIOS.
> 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill unblock
> <number of hci0>`.
> 3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
>
About 2. - 3.
I thought the above behavior causes by rfkill-input reverse the hci0's
killswitch when you pressed HW bluetooth, the HW bluetooth send out a
KEY_BLUETHOOTH keycode then rfkill-input capture it to do hci0's status
reverse.
I suggest leave userland application to do killswitch, don't use
rfkill-input.
You can do:
- Use rfkill unblock acer-bluetooth SW killswitch, don't use HW bluetooth switch.
- If you still want to use HW bluetooth switch, then I suggest disable your rfkill-input.
Have 2 way:
+ Use urfkill daemon: http://www.freedesktop.org/wiki/Software/urfkill
This is a userland daemon can lock the rfkill-input to disable it temporarily.
+ Direct set CONFIG_RFKILL_INPUT=N in kernel, but you will need to rebuild kernel.
After set rfkill-input disable, you need control killswitch from userland.
You can control it by rfkill tool or also try urfkill daemon.
We are adding more feature in urfkill daemon, I and Gary's plan is use urfkill daemon to replace
the rfkill-input in kernel.
> How is this supposed to work? I tried to use "rfkill.default_state=1" on
> kernel command line, but without any success.
>
Yes, rfkill default_state doesn't help, because acer-wmi driver will
sync the devices status from BIOS, it's right behavior.
> When I boot into 2.6.37, the bluetooth LED goes ON automatically and hciconfig
> shows the hci0 as UP.
>
Yes, that because acer-wmi didn't sync the bluetooth status with BIOS
when system boot in 2.6.37 kernel.
> Thanks.
>
> Best regards,
> Oldřich.
Thank's
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-10 22:02 acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37 Joey Lee
@ 2011-03-11 20:21 ` Oldřich Jedlička
2011-03-11 20:34 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-11 20:21 UTC (permalink / raw)
To: Joey Lee; +Cc: linux-acpi, platform-driver-x86
Hi Joey Lee,
On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
>
> > Hi all,
> >
> > This is about Acer WMI driver and bluetooth support. I hope I'm at the
> > right place with my question :-)
> >
> > I tried to use bluetooth again on my Acer TravelMate 5730G and discovered
> > a usability problem. I've checked 2.6.38-rc7:
> >
> > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is
> > blocked.
>
> Yes, this is right behavior.
>
> Because have a acer-wmi patch in 2.6.38 to sync the connection devices
> (wlan, bluetooth, 3G) status with BIOS.
> Acer BIOS fills-in the device initial states in SMBIOS when system boot,
> then acer-wmi dirver sync this states with killswitch. By default, Acer
> BIOS set the bluetooth to off.
>
> > 1. I have to enable the HW bluetooth switch to get the bluetooth LED
> > running (USB device appears in lsusb). The acer-bluetooth SW rfkill is
> > unblocked, the SW rfkill of hci0 is blocked.
>
> Yes, this is also right behavior, because acer-wmi driver will maintain
> the killswitch status with BIOS.
>
> > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill unblock
> > <number of hci0>`.
> > 3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
>
> About 2. - 3.
> I thought the above behavior causes by rfkill-input reverse the hci0's
> killswitch when you pressed HW bluetooth, the HW bluetooth send out a
> KEY_BLUETHOOTH keycode then rfkill-input capture it to do hci0's status
> reverse.
> I suggest leave userland application to do killswitch, don't use
> rfkill-input.
>
> You can do:
> - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW bluetooth
> switch. - If you still want to use HW bluetooth switch, then I suggest
> disable your rfkill-input. Have 2 way:
> + Use urfkill daemon:
http://www.freedesktop.org/wiki/Software/urfkill
> This is a userland daemon can lock the rfkill-input to disable it
> temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you will
> need to rebuild kernel. After set rfkill-input disable, you need control
> killswitch from userland. You can control it by rfkill tool or also try
> urfkill daemon.
Actually this doesn't work. When I unblock the SW switch by
calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the SW
killswitch, the bluetooth LED goes up, the hci0 shows-up (USB device and
killswitch), but initial state of hci0's killswitch is "blocked". So I still
need to unblock it manually. I would preffer to don't be forced to do step 2,
also for the HW switch (which should do the same job I think).
Cheers,
Oldřich.
>
> We are adding more feature in urfkill daemon, I and Gary's plan is use
> urfkill daemon to replace the rfkill-input in kernel.
>
> > How is this supposed to work? I tried to use "rfkill.default_state=1" on
> > kernel command line, but without any success.
>
> Yes, rfkill default_state doesn't help, because acer-wmi driver will
> sync the devices status from BIOS, it's right behavior.
>
> > When I boot into 2.6.37, the bluetooth LED goes ON automatically and
> > hciconfig shows the hci0 as UP.
>
> Yes, that because acer-wmi didn't sync the bluetooth status with BIOS
> when system boot in 2.6.37 kernel.
>
> > Thanks.
> >
> > Best regards,
> > Oldřich.
>
> Thank's
> Joey Lee
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 20:21 ` Oldřich Jedlička
@ 2011-03-11 20:34 ` Joey Lee
2011-03-11 20:54 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-11 20:34 UTC (permalink / raw)
To: oldium.pro; +Cc: Al Cho, linux-acpi, linux-bluetooth, platform-driver-x86
於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> >
> > > Hi all,
> > >
> > > This is about Acer WMI driver and bluetooth support. I hope I'm at the
> > > right place with my question :-)
> > >
> > > I tried to use bluetooth again on my Acer TravelMate 5730G and discovered
> > > a usability problem. I've checked 2.6.38-rc7:
> > >
> > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is
> > > blocked.
> >
> > Yes, this is right behavior.
> >
> > Because have a acer-wmi patch in 2.6.38 to sync the connection devices
> > (wlan, bluetooth, 3G) status with BIOS.
> > Acer BIOS fills-in the device initial states in SMBIOS when system boot,
> > then acer-wmi dirver sync this states with killswitch. By default, Acer
> > BIOS set the bluetooth to off.
> >
> > > 1. I have to enable the HW bluetooth switch to get the bluetooth LED
> > > running (USB device appears in lsusb). The acer-bluetooth SW rfkill is
> > > unblocked, the SW rfkill of hci0 is blocked.
> >
> > Yes, this is also right behavior, because acer-wmi driver will maintain
> > the killswitch status with BIOS.
> >
> > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill unblock
> > > <number of hci0>`.
> > > 3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
> >
> > About 2. - 3.
> > I thought the above behavior causes by rfkill-input reverse the hci0's
> > killswitch when you pressed HW bluetooth, the HW bluetooth send out a
> > KEY_BLUETHOOTH keycode then rfkill-input capture it to do hci0's status
> > reverse.
> > I suggest leave userland application to do killswitch, don't use
> > rfkill-input.
> >
> > You can do:
> > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW bluetooth
> > switch. - If you still want to use HW bluetooth switch, then I suggest
> > disable your rfkill-input. Have 2 way:
> > + Use urfkill daemon:
> http://www.freedesktop.org/wiki/Software/urfkill
> > This is a userland daemon can lock the rfkill-input to disable it
> > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you will
> > need to rebuild kernel. After set rfkill-input disable, you need control
> > killswitch from userland. You can control it by rfkill tool or also try
> > urfkill daemon.
>
> Actually this doesn't work. When I unblock the SW switch by
> calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the SW
> killswitch, the bluetooth LED goes up, the hci0 shows-up (USB device and
> killswitch), but initial state of hci0's killswitch is "blocked". So I still
> need to unblock it manually. I would preffer to don't be forced to do step 2,
> also for the HW switch (which should do the same job I think).
>
> Cheers,
> Oldřich.
That's weird!
Because acer-wmi driver only maintain the killswitch on by itself and
will not touch hci driver's killswitch. I don't know why hci's
killswitch initial state is 0, need to check hci driver and rfkill
staff.
Could you please share your bluetooth device to us?
Please send out "lsusb" result when bluetooth device available.
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 20:34 ` Joey Lee
@ 2011-03-11 20:54 ` Oldřich Jedlička
2011-03-11 21:25 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-11 20:54 UTC (permalink / raw)
To: Joey Lee; +Cc: Al Cho, linux-acpi, linux-bluetooth, platform-driver-x86
Hi again,
On Friday 11 March 2011 21:34:24 Joey Lee wrote:
> 於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
>
> > Hi Joey Lee,
> >
> > On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> > >
> > > > Hi all,
> > > >
> > > > This is about Acer WMI driver and bluetooth support. I hope I'm at
> > > > the right place with my question :-)
> > > >
> > > > I tried to use bluetooth again on my Acer TravelMate 5730G and
> > > > discovered a usability problem. I've checked 2.6.38-rc7:
> > > >
> > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is
> > > > blocked.
> > >
> > > Yes, this is right behavior.
> > >
> > > Because have a acer-wmi patch in 2.6.38 to sync the connection devices
> > > (wlan, bluetooth, 3G) status with BIOS.
> > > Acer BIOS fills-in the device initial states in SMBIOS when system
> > > boot, then acer-wmi dirver sync this states with killswitch. By
> > > default, Acer BIOS set the bluetooth to off.
> > >
> > > > 1. I have to enable the HW bluetooth switch to get the bluetooth LED
> > > > running (USB device appears in lsusb). The acer-bluetooth SW rfkill
> > > > is unblocked, the SW rfkill of hci0 is blocked.
> > >
> > > Yes, this is also right behavior, because acer-wmi driver will maintain
> > > the killswitch status with BIOS.
> > >
> > > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill
> > > > unblock <number of hci0>`.
> > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
> > >
> > > About 2. - 3.
> > > I thought the above behavior causes by rfkill-input reverse the hci0's
> > > killswitch when you pressed HW bluetooth, the HW bluetooth send out a
> > > KEY_BLUETHOOTH keycode then rfkill-input capture it to do hci0's status
> > > reverse.
> > > I suggest leave userland application to do killswitch, don't use
> > > rfkill-input.
> > >
> > > You can do:
> > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW
> > > bluetooth
> > >
> > > switch. - If you still want to use HW bluetooth switch, then I suggest
> > >
> > > disable your rfkill-input. Have 2 way:
> > > + Use urfkill daemon:
> > http://www.freedesktop.org/wiki/Software/urfkill
> >
> > > This is a userland daemon can lock the rfkill-input to
disable it
> > >
> > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you will
> > > need to rebuild kernel. After set rfkill-input disable, you need
> > > control killswitch from userland. You can control it by rfkill tool or
> > > also try urfkill daemon.
> >
> > Actually this doesn't work. When I unblock the SW switch by
> > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the SW
> > killswitch, the bluetooth LED goes up, the hci0 shows-up (USB device and
> > killswitch), but initial state of hci0's killswitch is "blocked". So I
> > still need to unblock it manually. I would preffer to don't be forced to
> > do step 2, also for the HW switch (which should do the same job I
> > think).
> >
> > Cheers,
> > Oldřich.
>
> That's weird!
> Because acer-wmi driver only maintain the killswitch on by itself and
> will not touch hci driver's killswitch. I don't know why hci's
> killswitch initial state is 0, need to check hci driver and rfkill
> staff.
>
> Could you please share your bluetooth device to us?
> Please send out "lsusb" result when bluetooth device available.
Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
dmesg shows the following:
[ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and address 3
[ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101
[ 2422.528223] usb 8-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 2422.528231] usb 8-2: Product: Acer Module
[ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp
`rfkill list` shows the following
1) Before I enable the SW killswitch:
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2) After I run `rfkill unblock 1`:
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
6: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
I've repeated it several times, so hci0 has number 6 now.
Thanks for help,
Oldřich.
>
> Thank's a lot!
> Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 20:54 ` Oldřich Jedlička
@ 2011-03-11 21:25 ` Joey Lee
2011-03-11 21:34 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-11 21:25 UTC (permalink / raw)
To: oldium.pro
Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
Hi Oldřich,
於 五，2011-03-11 於 21:54 +0100，Oldřich Jedlička 提到：
> Hi again,
>
> On Friday 11 March 2011 21:34:24 Joey Lee wrote:
> > 於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
> >
> > > Hi Joey Lee,
> > >
> > > On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > > > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> > > >
> > > > > Hi all,
> > > > >
> > > > > This is about Acer WMI driver and bluetooth support. I hope I'm at
> > > > > the right place with my question :-)
> > > > >
> > > > > I tried to use bluetooth again on my Acer TravelMate 5730G and
> > > > > discovered a usability problem. I've checked 2.6.38-rc7:
> > > > >
> > > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is
> > > > > blocked.
> > > >
> > > > Yes, this is right behavior.
> > > >
> > > > Because have a acer-wmi patch in 2.6.38 to sync the connection devices
> > > > (wlan, bluetooth, 3G) status with BIOS.
> > > > Acer BIOS fills-in the device initial states in SMBIOS when system
> > > > boot, then acer-wmi dirver sync this states with killswitch. By
> > > > default, Acer BIOS set the bluetooth to off.
> > > >
> > > > > 1. I have to enable the HW bluetooth switch to get the bluetooth LED
> > > > > running (USB device appears in lsusb). The acer-bluetooth SW rfkill
> > > > > is unblocked, the SW rfkill of hci0 is blocked.
> > > >
> > > > Yes, this is also right behavior, because acer-wmi driver will maintain
> > > > the killswitch status with BIOS.
> > > >
> > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill
> > > > > unblock <number of hci0>`.
> > > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
> > > >
> > > > About 2. - 3.
> > > > I thought the above behavior causes by rfkill-input reverse the hci0's
> > > > killswitch when you pressed HW bluetooth, the HW bluetooth send out a
> > > > KEY_BLUETHOOTH keycode then rfkill-input capture it to do hci0's status
> > > > reverse.
> > > > I suggest leave userland application to do killswitch, don't use
> > > > rfkill-input.
> > > >
> > > > You can do:
> > > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW
> > > > bluetooth
> > > >
> > > > switch. - If you still want to use HW bluetooth switch, then I suggest
> > > >
> > > > disable your rfkill-input. Have 2 way:
> > > > + Use urfkill daemon:
> > > http://www.freedesktop.org/wiki/Software/urfkill
> > >
> > > > This is a userland daemon can lock the rfkill-input to
> disable it
Did you mean you direct set CONFIG_RFKILL_INPUT=N in kernel and rebuild
kernel? or you used userland app like urfkill to send out ioctl to
disable rfkill-input?
> > > >
> > > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you will
> > > > need to rebuild kernel. After set rfkill-input disable, you need
> > > > control killswitch from userland. You can control it by rfkill tool or
> > > > also try urfkill daemon.
> > >
> > > Actually this doesn't work. When I unblock the SW switch by
> > > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the SW
> > > killswitch, the bluetooth LED goes up, the hci0 shows-up (USB device and
> > > killswitch), but initial state of hci0's killswitch is "blocked". So I
> > > still need to unblock it manually. I would preffer to don't be forced to
> > > do step 2, also for the HW switch (which should do the same job I
> > > think).
> > >
> > > Cheers,
> > > Oldřich.
> >
> > That's weird!
> > Because acer-wmi driver only maintain the killswitch on by itself and
> > will not touch hci driver's killswitch. I don't know why hci's
> > killswitch initial state is 0, need to check hci driver and rfkill
> > staff.
> >
> > Could you please share your bluetooth device to us?
> > Please send out "lsusb" result when bluetooth device available.
>
> Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
>
> dmesg shows the following:
>
> [ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and address 3
> [ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101
> [ 2422.528223] usb 8-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 2422.528231] usb 8-2: Product: Acer Module
> [ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp
>
> `rfkill list` shows the following
>
> 1) Before I enable the SW killswitch:
>
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: yes
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
>
> 2) After I run `rfkill unblock 1`:
>
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: yes
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 6: hci0: Bluetooth
> Soft blocked: yes
> Hard blocked: no
>
> I've repeated it several times, so hci0 has number 6 now.
>
> Thanks for help,
> Oldřich.
Thank's for your test result.
Want to double confirm with you...
The above result is base on CONFIG_RFKILL_INPUT=N ?
I just simply check the rfkill stuff,
I found when CONFIG_RFKILL_INPUT set to enable and there have any driver
call rfkill_init_sw_state before register rfkill object, then rfkill
will sync this state to all killswitch that have the same type and also
will set the same initial state to new killswitch have the same type.
Looks like rfkill will sync the state for the same type killswitch if
used rfkill_init_sw_state, I will do more detail debug and trace for
rfkill stuff, then find out solution.
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 21:25 ` Joey Lee
@ 2011-03-11 21:34 ` Oldřich Jedlička
2011-03-11 21:45 ` Joey Lee
2011-03-11 22:00 ` Oldřich Jedlička
0 siblings, 2 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-11 21:34 UTC (permalink / raw)
To: Joey Lee; +Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
Hi Joey Lee,
On Friday 11 March 2011 22:25:37 Joey Lee wrote:
> Hi Oldřich,
>
> 於 五，2011-03-11 於 21:54 +0100，Oldřich Jedlička 提到：
>
> > Hi again,
> >
> > On Friday 11 March 2011 21:34:24 Joey Lee wrote:
> > > 於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
> > >
> > > > Hi Joey Lee,
> > > >
> > > > On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > > > > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > This is about Acer WMI driver and bluetooth support. I hope I'm
> > > > > > at the right place with my question :-)
> > > > > >
> > > > > > I tried to use bluetooth again on my Acer TravelMate 5730G and
> > > > > > discovered a usability problem. I've checked 2.6.38-rc7:
> > > > > >
> > > > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill
> > > > > > is blocked.
> > > > >
> > > > > Yes, this is right behavior.
> > > > >
> > > > > Because have a acer-wmi patch in 2.6.38 to sync the connection
> > > > > devices (wlan, bluetooth, 3G) status with BIOS.
> > > > > Acer BIOS fills-in the device initial states in SMBIOS when system
> > > > > boot, then acer-wmi dirver sync this states with killswitch. By
> > > > > default, Acer BIOS set the bluetooth to off.
> > > > >
> > > > > > 1. I have to enable the HW bluetooth switch to get the bluetooth
> > > > > > LED running (USB device appears in lsusb). The acer-bluetooth SW
> > > > > > rfkill is unblocked, the SW rfkill of hci0 is blocked.
> > > > >
> > > > > Yes, this is also right behavior, because acer-wmi driver will
> > > > > maintain the killswitch status with BIOS.
> > > > >
> > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill
> > > > > > unblock <number of hci0>`.
> > > > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0
> > > > > > up`.
> > > > >
> > > > > About 2. - 3.
> > > > > I thought the above behavior causes by rfkill-input reverse the
> > > > > hci0's killswitch when you pressed HW bluetooth, the HW bluetooth
> > > > > send out a KEY_BLUETHOOTH keycode then rfkill-input capture it to
> > > > > do hci0's status reverse.
> > > > > I suggest leave userland application to do killswitch, don't use
> > > > > rfkill-input.
> > > > >
> > > > > You can do:
> > > > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW
> > > > > bluetooth
> > > > >
> > > > > switch. - If you still want to use HW bluetooth switch, then I
> > > > > suggest
> > > > >
> > > > > disable your rfkill-input. Have 2 way:
> > > > > + Use urfkill daemon:
> > > > http://www.freedesktop.org/wiki/Software/urfkill
> > > >
> > > > > This is a userland daemon can lock the rfkill-input to
> >
> > disable it
>
> Did you mean you direct set CONFIG_RFKILL_INPUT=N in kernel and rebuild
> kernel? or you used userland app like urfkill to send out ioctl to
> disable rfkill-input?
>
> > > > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you
> > > > > will need to rebuild kernel. After set rfkill-input disable, you
> > > > > need control killswitch from userland. You can control it by
> > > > > rfkill tool or also try urfkill daemon.
> > > >
> > > > Actually this doesn't work. When I unblock the SW switch by
> > > > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the
> > > > SW killswitch, the bluetooth LED goes up, the hci0 shows-up (USB
> > > > device and killswitch), but initial state of hci0's killswitch is
> > > > "blocked". So I still need to unblock it manually. I would preffer
> > > > to don't be forced to do step 2, also for the HW switch (which
> > > > should do the same job I think).
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > That's weird!
> > > Because acer-wmi driver only maintain the killswitch on by itself and
> > > will not touch hci driver's killswitch. I don't know why hci's
> > > killswitch initial state is 0, need to check hci driver and rfkill
> > > staff.
> > >
> > > Could you please share your bluetooth device to us?
> > > Please send out "lsusb" result when bluetooth device available.
> >
> > Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
> >
> > dmesg shows the following:
> >
> > [ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and
> > address 3 [ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c,
> > idProduct=2101 [ 2422.528223] usb 8-2: New USB device strings: Mfr=1,
> > Product=2, SerialNumber=0
> > [ 2422.528231] usb 8-2: Product: Acer Module
> > [ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp
> >
> > `rfkill list` shows the following
> >
> > 1) Before I enable the SW killswitch:
> >
> > 0: acer-wireless: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 1: acer-bluetooth: Bluetooth
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > 2: acer-threeg: Wireless WAN
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > 3: phy0: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 2) After I run `rfkill unblock 1`:
> >
> > 0: acer-wireless: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 1: acer-bluetooth: Bluetooth
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 2: acer-threeg: Wireless WAN
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > 3: phy0: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 6: hci0: Bluetooth
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > I've repeated it several times, so hci0 has number 6 now.
> >
> > Thanks for help,
> > Oldřich.
>
> Thank's for your test result.
> Want to double confirm with you...
> The above result is base on CONFIG_RFKILL_INPUT=N ?
No, that was just a formatting problem of a "reply" to a mail. That wasn't my
reaction, it was just a word from the previous line. I'm still using
CONFIG_RFKILL_INPUT=Y.
Oldřich.
> I just simply check the rfkill stuff,
> I found when CONFIG_RFKILL_INPUT set to enable and there have any driver
> call rfkill_init_sw_state before register rfkill object, then rfkill
> will sync this state to all killswitch that have the same type and also
> will set the same initial state to new killswitch have the same type.
>
> Looks like rfkill will sync the state for the same type killswitch if
> used rfkill_init_sw_state, I will do more detail debug and trace for
> rfkill stuff, then find out solution.
>
>
> Thank's a lot!
> Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 21:34 ` Oldřich Jedlička
@ 2011-03-11 21:45 ` Joey Lee
[not found] ` <4D7B32B10200002300029B5E-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
2011-03-11 22:00 ` Oldřich Jedlička
1 sibling, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-11 21:45 UTC (permalink / raw)
To: oldium.pro
Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
Hi Oldřich,
於 五，2011-03-11 於 22:34 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> On Friday 11 March 2011 22:25:37 Joey Lee wrote:
> > Hi Oldřich,
> >
> > 於 五，2011-03-11 於 21:54 +0100，Oldřich Jedlička 提到：
> >
> > > Hi again,
> > >
> > > On Friday 11 March 2011 21:34:24 Joey Lee wrote:
> > > > 於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
> > > >
> > > > > Hi Joey Lee,
> > > > >
> > > > > On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > > > > > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > This is about Acer WMI driver and bluetooth support. I hope I'm
> > > > > > > at the right place with my question :-)
> > > > > > >
> > > > > > > I tried to use bluetooth again on my Acer TravelMate 5730G and
> > > > > > > discovered a usability problem. I've checked 2.6.38-rc7:
> > > > > > >
> > > > > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill
> > > > > > > is blocked.
> > > > > >
> > > > > > Yes, this is right behavior.
> > > > > >
> > > > > > Because have a acer-wmi patch in 2.6.38 to sync the connection
> > > > > > devices (wlan, bluetooth, 3G) status with BIOS.
> > > > > > Acer BIOS fills-in the device initial states in SMBIOS when system
> > > > > > boot, then acer-wmi dirver sync this states with killswitch. By
> > > > > > default, Acer BIOS set the bluetooth to off.
> > > > > >
> > > > > > > 1. I have to enable the HW bluetooth switch to get the bluetooth
> > > > > > > LED running (USB device appears in lsusb). The acer-bluetooth SW
> > > > > > > rfkill is unblocked, the SW rfkill of hci0 is blocked.
> > > > > >
> > > > > > Yes, this is also right behavior, because acer-wmi driver will
> > > > > > maintain the killswitch status with BIOS.
> > > > > >
> > > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill
> > > > > > > unblock <number of hci0>`.
> > > > > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0
> > > > > > > up`.
> > > > > >
> > > > > > About 2. - 3.
> > > > > > I thought the above behavior causes by rfkill-input reverse the
> > > > > > hci0's killswitch when you pressed HW bluetooth, the HW bluetooth
> > > > > > send out a KEY_BLUETHOOTH keycode then rfkill-input capture it to
> > > > > > do hci0's status reverse.
> > > > > > I suggest leave userland application to do killswitch, don't use
> > > > > > rfkill-input.
> > > > > >
> > > > > > You can do:
> > > > > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW
> > > > > > bluetooth
> > > > > >
> > > > > > switch. - If you still want to use HW bluetooth switch, then I
> > > > > > suggest
> > > > > >
> > > > > > disable your rfkill-input. Have 2 way:
> > > > > > + Use urfkill daemon:
> > > > > http://www.freedesktop.org/wiki/Software/urfkill
> > > > >
> > > > > > This is a userland daemon can lock the rfkill-input to
> > >
> > > disable it
> >
> > Did you mean you direct set CONFIG_RFKILL_INPUT=N in kernel and rebuild
> > kernel? or you used userland app like urfkill to send out ioctl to
> > disable rfkill-input?
> >
> > > > > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but you
> > > > > > will need to rebuild kernel. After set rfkill-input disable, you
> > > > > > need control killswitch from userland. You can control it by
> > > > > > rfkill tool or also try urfkill daemon.
> > > > >
> > > > > Actually this doesn't work. When I unblock the SW switch by
> > > > > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks the
> > > > > SW killswitch, the bluetooth LED goes up, the hci0 shows-up (USB
> > > > > device and killswitch), but initial state of hci0's killswitch is
> > > > > "blocked". So I still need to unblock it manually. I would preffer
> > > > > to don't be forced to do step 2, also for the HW switch (which
> > > > > should do the same job I think).
> > > > >
> > > > > Cheers,
> > > > > Oldřich.
> > > >
> > > > That's weird!
> > > > Because acer-wmi driver only maintain the killswitch on by itself and
> > > > will not touch hci driver's killswitch. I don't know why hci's
> > > > killswitch initial state is 0, need to check hci driver and rfkill
> > > > staff.
> > > >
> > > > Could you please share your bluetooth device to us?
> > > > Please send out "lsusb" result when bluetooth device available.
> > >
> > > Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
> > >
> > > dmesg shows the following:
> > >
> > > [ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and
> > > address 3 [ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c,
> > > idProduct=2101 [ 2422.528223] usb 8-2: New USB device strings: Mfr=1,
> > > Product=2, SerialNumber=0
> > > [ 2422.528231] usb 8-2: Product: Acer Module
> > > [ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp
> > >
> > > `rfkill list` shows the following
> > >
> > > 1) Before I enable the SW killswitch:
> > >
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 3: phy0: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2) After I run `rfkill unblock 1`:
> > >
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 3: phy0: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 6: hci0: Bluetooth
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > I've repeated it several times, so hci0 has number 6 now.
> > >
> > > Thanks for help,
> > > Oldřich.
> >
> > Thank's for your test result.
> > Want to double confirm with you...
> > The above result is base on CONFIG_RFKILL_INPUT=N ?
>
> No, that was just a formatting problem of a "reply" to a mail. That wasn't my
> reaction, it was just a word from the previous line. I'm still using
> CONFIG_RFKILL_INPUT=Y.
>
> Oldřich.
>
That's make sense now!
Thank's for your bug report, I am tracing and try to find out solution.
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-11 21:34 ` Oldřich Jedlička
2011-03-11 21:45 ` Joey Lee
@ 2011-03-11 22:00 ` Oldřich Jedlička
1 sibling, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-11 22:00 UTC (permalink / raw)
To: Joey Lee; +Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
On Friday 11 March 2011 22:34:42 Oldřich Jedlička wrote:
> Hi Joey Lee,
>
> On Friday 11 March 2011 22:25:37 Joey Lee wrote:
> > Hi Oldřich,
> >
> > 於 五，2011-03-11 於 21:54 +0100，Oldřich Jedlička 提到：
> >
> > > Hi again,
> > >
> > > On Friday 11 March 2011 21:34:24 Joey Lee wrote:
> > > > 於 五，2011-03-11 於 21:21 +0100，Oldřich Jedlička 提到：
> > > >
> > > > > Hi Joey Lee,
> > > > >
> > > > > On Thursday 10 March 2011 23:02:27 Joey Lee wrote:
> > > > > > 於 四，2011-03-10 於 19:37 +0100，Oldřich Jedlička 提到：
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > This is about Acer WMI driver and bluetooth support. I hope I'm
> > > > > > > at the right place with my question :-)
> > > > > > >
> > > > > > > I tried to use bluetooth again on my Acer TravelMate 5730G and
> > > > > > > discovered a usability problem. I've checked 2.6.38-rc7:
> > > > > > >
> > > > > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW
> > > > > > > rfkill is blocked.
> > > > > >
> > > > > > Yes, this is right behavior.
> > > > > >
> > > > > > Because have a acer-wmi patch in 2.6.38 to sync the connection
> > > > > > devices (wlan, bluetooth, 3G) status with BIOS.
> > > > > > Acer BIOS fills-in the device initial states in SMBIOS when
> > > > > > system boot, then acer-wmi dirver sync this states with
> > > > > > killswitch. By default, Acer BIOS set the bluetooth to off.
> > > > > >
> > > > > > > 1. I have to enable the HW bluetooth switch to get the
> > > > > > > bluetooth LED running (USB device appears in lsusb). The
> > > > > > > acer-bluetooth SW rfkill is unblocked, the SW rfkill of hci0
> > > > > > > is blocked.
> > > > > >
> > > > > > Yes, this is also right behavior, because acer-wmi driver will
> > > > > > maintain the killswitch status with BIOS.
> > > > > >
> > > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to
> > > > > > > `rfkill unblock <number of hci0>`.
> > > > > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0
> > > > > > > up`.
> > > > > >
> > > > > > About 2. - 3.
> > > > > > I thought the above behavior causes by rfkill-input reverse the
> > > > > > hci0's killswitch when you pressed HW bluetooth, the HW bluetooth
> > > > > > send out a KEY_BLUETHOOTH keycode then rfkill-input capture it to
> > > > > > do hci0's status reverse.
> > > > > > I suggest leave userland application to do killswitch, don't use
> > > > > > rfkill-input.
> > > > > >
> > > > > > You can do:
> > > > > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW
> > > > > > bluetooth
> > > > > >
> > > > > > switch. - If you still want to use HW bluetooth switch, then I
> > > > > > suggest
> > > > > >
> > > > > > disable your rfkill-input. Have 2 way:
> > > > > > + Use urfkill daemon:
> > > > > http://www.freedesktop.org/wiki/Software/urfkill
> > > > >
> > > > > > This is a userland daemon can lock the rfkill-input to
> > >
> > > disable it
> >
> > Did you mean you direct set CONFIG_RFKILL_INPUT=N in kernel and rebuild
> > kernel? or you used userland app like urfkill to send out ioctl to
> > disable rfkill-input?
> >
> > > > > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but
> > > > > > you will need to rebuild kernel. After set rfkill-input disable,
> > > > > > you need control killswitch from userland. You can control it by
> > > > > > rfkill tool or also try urfkill daemon.
> > > > >
> > > > > Actually this doesn't work. When I unblock the SW switch by
> > > > > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks
> > > > > the SW killswitch, the bluetooth LED goes up, the hci0 shows-up
> > > > > (USB device and killswitch), but initial state of hci0's
> > > > > killswitch is "blocked". So I still need to unblock it manually. I
> > > > > would preffer to don't be forced to do step 2, also for the HW
> > > > > switch (which should do the same job I think).
> > > > >
> > > > > Cheers,
> > > > > Oldřich.
> > > >
> > > > That's weird!
> > > > Because acer-wmi driver only maintain the killswitch on by itself and
> > > > will not touch hci driver's killswitch. I don't know why hci's
> > > > killswitch initial state is 0, need to check hci driver and rfkill
> > > > staff.
> > > >
> > > > Could you please share your bluetooth device to us?
> > > > Please send out "lsusb" result when bluetooth device available.
> > >
> > > Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
> > >
> > > dmesg shows the following:
> > >
> > > [ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and
> > > address 3 [ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c,
> > > idProduct=2101 [ 2422.528223] usb 8-2: New USB device strings: Mfr=1,
> > > Product=2, SerialNumber=0
> > > [ 2422.528231] usb 8-2: Product: Acer Module
> > > [ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp
> > >
> > > `rfkill list` shows the following
> > >
> > > 1) Before I enable the SW killswitch:
> > >
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 3: phy0: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2) After I run `rfkill unblock 1`:
> > >
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 3: phy0: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 6: hci0: Bluetooth
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > I've repeated it several times, so hci0 has number 6 now.
> > >
> > > Thanks for help,
> > > Oldřich.
> >
> > Thank's for your test result.
> > Want to double confirm with you...
> > The above result is base on CONFIG_RFKILL_INPUT=N ?
>
> No, that was just a formatting problem of a "reply" to a mail. That wasn't
> my reaction, it was just a word from the previous line. I'm still using
> CONFIG_RFKILL_INPUT=Y.
>
> Oldřich.
>
> > I just simply check the rfkill stuff,
> > I found when CONFIG_RFKILL_INPUT set to enable and there have any driver
> > call rfkill_init_sw_state before register rfkill object, then rfkill
> > will sync this state to all killswitch that have the same type and also
> > will set the same initial state to new killswitch have the same type.
> >
> > Looks like rfkill will sync the state for the same type killswitch if
> > used rfkill_init_sw_state, I will do more detail debug and trace for
> > rfkill stuff, then find out solution.
I've added dump_trace() into hci_rfkill_set_block and the result is this:
[ 85.180724] hci_rfkill_set_block: f36bb800 name hci0 blocked 1
[ 85.180734] Pid: 8, comm: kworker/1:0 Not tainted 2.6.38-drm+ #106
[ 85.180740] Call Trace:
[ 85.180758] [<c080ae7b>] ? hci_rfkill_set_block+0x3b/0x60
[ 85.180769] [<c08a9b58>] ? rfkill_set_block+0x68/0xe0
[ 85.180778] [<c08a9e36>] ? rfkill_sync_work+0x26/0x40
[ 85.180791] [<c027e851>] ? process_one_work+0x121/0x370
[ 85.180802] [<c0263a0b>] ? get_parent_ip+0xb/0x40
[ 85.180810] [<c08a9e10>] ? rfkill_sync_work+0x0/0x40
[ 85.180820] [<c027ee3c>] ? worker_thread+0x11c/0x3b0
[ 85.180831] [<c027ed20>] ? worker_thread+0x0/0x3b0
[ 85.180840] [<c0282144>] ? kthread+0x74/0x80
[ 85.180849] [<c02820d0>] ? kthread+0x0/0x80
[ 85.180859] [<c022f1f6>] ? kernel_thread_helper+0x6/0x10
It goes from rfkill_sync_work. That is all I can do now, I guess you will be
faster than me in finding the solution :-)
Cheers,
Oldřich.
> >
> >
> > Thank's a lot!
> > Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <4D7B32B10200002300029B5E-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
@ 2011-03-15 11:11 ` Joey Lee
[not found] ` <4D7FE4260200002300029D70-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-15 11:11 UTC (permalink / raw)
To: oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw
Cc: Al Cho, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Oldřich,
於 五，2011-03-11 於 14:45 -0700，Joey Lee 提到：
> Hi Oldřich,
> > > > > > >
> > > > > > > > 1. I have to enable the HW bluetooth switch to get the bluetooth
> > > > > > > > LED running (USB device appears in lsusb). The acer-bluetooth SW
> > > > > > > > rfkill is unblocked, the SW rfkill of hci0 is blocked.
> > > > > > >
> > > > > > > Yes, this is also right behavior, because acer-wmi driver will
> > > > > > > maintain the killswitch status with BIOS.
> > > > > > >
> > > > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill
> > > > > > > > unblock <number of hci0>`.
> > > > > > > > 3. Last I have to enable the HCI by the call to `hciconfig hci0
> > > > > > > > up`.
> > > > >
> > > > `rfkill list` shows the following
> > > >
> > > > 1) Before I enable the SW killswitch:
> > > >
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > 3: phy0: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2) After I run `rfkill unblock 1`:
> > > >
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > 3: phy0: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 6: hci0: Bluetooth
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > I've repeated it several times, so hci0 has number 6 now.
> > > >
> > > > Thanks for help,
> > > > Oldřich.
> > >
> > > Thank's for your test result.
> > > Want to double confirm with you...
> > > The above result is base on CONFIG_RFKILL_INPUT=N ?
> >
> > No, that was just a formatting problem of a "reply" to a mail. That wasn't my
> > reaction, it was just a word from the previous line. I'm still using
> > CONFIG_RFKILL_INPUT=Y.
> >
> > Oldřich.
> >
>
> That's make sense now!
>
> Thank's for your bug report, I am tracing and try to find out solution.
> Joey Lee
>
After trace rfkill-input stuff, I thought this is rfkill-input's normal
behavior but not a bug.
Unfortunately, I didn't find any workaround way when a driver need to
call rfkill_init_sw_state, e.g. acer-wmi driver.
The rfkill-input will sync the rfkill state to all killswitchs that have
the same type. For example, acer-wmi set the initial software switch to
_BLOCK_ when driver initial, then rfkill-input will also set any new
bluetooth killswitch state to _BLOCK_ .
Acer's BIOS default setup bluetooth's state is disable when system cold
boot, and BIOS also can save the connection devices' state when system
reboot. Currently, acer-wmi driver have right behavior to sync the state
with BIOS.
Face to your situation, my suggestion is:
- Use userland application to correct killswitch state.
highly suggest You can try urfkill daemon: http://www.freedesktop.org/wiki/Software/urfkill
or
write a startup script to enable bluetooth when system boot.
- Disable rfkill-input module if you didn't real use it.
The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
enable bluetooth killswitch.
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <4D7FE4260200002300029D70-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
@ 2011-03-16 6:32 ` Oldřich Jedlička
2011-03-16 8:59 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-16 6:32 UTC (permalink / raw)
To: Joey Lee
Cc: Al Cho, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Joey Lee,
On Tuesday 15 March 2011 12:11:50 Joey Lee wrote:
> Hi Oldřich,
>
> 於 五，2011-03-11 於 14:45 -0700，Joey Lee 提到：
>
> > Hi Oldřich,
> >
> > > > > > > > > 1. I have to enable the HW bluetooth switch to get the
> > > > > > > > > bluetooth LED running (USB device appears in lsusb). The
> > > > > > > > > acer-bluetooth SW rfkill is unblocked, the SW rfkill of
> > > > > > > > > hci0 is blocked.
> > > > > > > >
> > > > > > > > Yes, this is also right behavior, because acer-wmi driver
> > > > > > > > will maintain the killswitch status with BIOS.
> > > > > > > >
> > > > > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to
> > > > > > > > > `rfkill unblock <number of hci0>`.
> > > > > > > > > 3. Last I have to enable the HCI by the call to `hciconfig
> > > > > > > > > hci0 up`.
> > > > >
> > > > > `rfkill list` shows the following
> > > > >
> > > > > 1) Before I enable the SW killswitch:
> > > > >
> > > > > 0: acer-wireless: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 1: acer-bluetooth: Bluetooth
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > > >
> > > > > 2: acer-threeg: Wireless WAN
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > > >
> > > > > 3: phy0: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 2) After I run `rfkill unblock 1`:
> > > > >
> > > > > 0: acer-wireless: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 1: acer-bluetooth: Bluetooth
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 2: acer-threeg: Wireless WAN
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > > >
> > > > > 3: phy0: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 6: hci0: Bluetooth
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > > >
> > > > > I've repeated it several times, so hci0 has number 6 now.
> > > > >
> > > > > Thanks for help,
> > > > > Oldřich.
> > > >
> > > > Thank's for your test result.
> > > > Want to double confirm with you...
> > > > The above result is base on CONFIG_RFKILL_INPUT=N ?
> > >
> > > No, that was just a formatting problem of a "reply" to a mail. That
> > > wasn't my reaction, it was just a word from the previous line. I'm
> > > still using CONFIG_RFKILL_INPUT=Y.
> > >
> > > Oldřich.
> >
> > That's make sense now!
> >
> > Thank's for your bug report, I am tracing and try to find out solution.
> > Joey Lee
>
> After trace rfkill-input stuff, I thought this is rfkill-input's normal
> behavior but not a bug.
>
> Unfortunately, I didn't find any workaround way when a driver need to
> call rfkill_init_sw_state, e.g. acer-wmi driver.
>
> The rfkill-input will sync the rfkill state to all killswitchs that have
> the same type. For example, acer-wmi set the initial software switch to
> _BLOCK_ when driver initial, then rfkill-input will also set any new
> bluetooth killswitch state to _BLOCK_ .
The rfkill_sync_work syncs with rfkill_global_states, which is set during
intitialization or by rfkill_switch_all, if I read it correctly. This should
be independent to acer-bluetooth state. The rfkill_global_states[BLUETOOTH]
should be unblocked initially, I need to verify it.
There is some magic in rfkill/input.c that plays with global states, but I
don't know if or how that one is used in my case.
> Acer's BIOS default setup bluetooth's state is disable when system cold
> boot, and BIOS also can save the connection devices' state when system
> reboot. Currently, acer-wmi driver have right behavior to sync the state
> with BIOS.
>
> Face to your situation, my suggestion is:
>
> - Use userland application to correct killswitch state.
> highly suggest You can try urfkill daemon:
> http://www.freedesktop.org/wiki/Software/urfkill or
> write a startup script to enable bluetooth when system boot.
>
> - Disable rfkill-input module if you didn't real use it.
> The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> enable bluetooth killswitch.
I didn't have time to look at the problem more deeply to identify who is
setting the global state to "blocked" or what really happens. Anyway, I did
some testing with pressing the HW bluetooth switch and I saw the following
immediately _after_ pressing the HW switch to enable bluetooth:
oldium ~ # rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
I had this output 3 times immediately after each other. I'm using keyboard
"up" and "enter" to repeat the last shell command, so this is a relatively
slow operation. So the state when the acer-bluetooth was unblocked stayed for
relatively long time before hci0 appeared in rfkill. Afterwards I saw:
oldium ~ # rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: yes
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
5: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
So it looks like the hci0 went blocked even when the acer-bluetooth switch was
unblocked. So it looks like the hci0 state is independent on the initial acer-
bluetooth state.
Hopefully I have some time this evening (CET timezone) to add some stack
traces and logs to see what really happens on my system.
Cheers,
Oldřich.
>
> Thank's a lot!
> Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-16 6:32 ` Oldřich Jedlička
@ 2011-03-16 8:59 ` Joey Lee
2011-03-20 20:09 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-16 8:59 UTC (permalink / raw)
To: oldium.pro
Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
Hi Oldřich,
於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > After trace rfkill-input stuff, I thought this is rfkill-input's normal
> > behavior but not a bug.
> >
> > Unfortunately, I didn't find any workaround way when a driver need to
> > call rfkill_init_sw_state, e.g. acer-wmi driver.
> >
> > The rfkill-input will sync the rfkill state to all killswitchs that have
> > the same type. For example, acer-wmi set the initial software switch to
> > _BLOCK_ when driver initial, then rfkill-input will also set any new
> > bluetooth killswitch state to _BLOCK_ .
>
> The rfkill_sync_work syncs with rfkill_global_states, which is set during
> intitialization or by rfkill_switch_all, if I read it correctly. This should
> be independent to acer-bluetooth state. The rfkill_global_states[BLUETOOTH]
> should be unblocked initially, I need to verify it.
>
Yes!
Ideally, killswitch state should be independent to different driver,
even the killswitch type is the same.
But,
If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will replicate
state for each killswitch that have the same type:
vi net/rfkill/core.c
int __must_check rfkill_register(struct rfkill *rfkill)
{
...
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
} else { /* if rfkill->persistent then set the state to all the same type */
#ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = Y */
bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
if (!atomic_read(&rfkill_input_disabled))
__rfkill_switch_all(rfkill->type, soft_blocked); /* here call switch all to sync state */
#endif
}
When any driver call rfkill_init_sw_state for set the initial state to
killswitch, this rfkill->persistent will set to true:
void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* acer-wmi driver used it to set inital killswitch state */
{
....
spin_lock_irqsave(&rfkill->lock, flags);
__rfkill_set_sw_state(rfkill, blocked);
rfkill->persistent = true /* persistent set to true */
That's why acer-wmi bluetooth killswitch's state was been replicate to
hci_core's killswitch state.
When CONFIG_RFKILL_INPUT set to Y, and any driver call
rfkill_init_sw_state before register rfkill, then rfkill_register will
try to sync state to the same killswitch type like the above.
It's make sense,
because rfkill-input only can block/unblock the same killswitch type at
the same time, before rfkill-input active, it want all the same type's
state is full the same.
And,
rfkill-input also suppose user only can use keycode (maybe Fn key) to
control killswitch state, so, direct use rkill tool or echo state to
killswitch for change the state will cause killswitchs' state lost link.
It like we do.
> There is some magic in rfkill/input.c that plays with global states, but I
> don't know if or how that one is used in my case.
>
Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
code. You will see the new bluetooth killswitch will be unblock when it
created.
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 0198191..0dec078 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill *rfkill)
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
- } else {
-#ifdef CONFIG_RFKILL_INPUT
- bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
-
- if (!atomic_read(&rfkill_input_disabled))
- __rfkill_switch_all(rfkill->type, soft_blocked);
-#endif
- }
+ } //else {
+//#ifdef CONFIG_RFKILL_INPUT
+// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
+//
+// if (!atomic_read(&rfkill_input_disabled))
+// __rfkill_switch_all(rfkill->type, soft_blocked);
+//#endif
+// }
rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > Acer's BIOS default setup bluetooth's state is disable when system cold
> > boot, and BIOS also can save the connection devices' state when system
> > reboot. Currently, acer-wmi driver have right behavior to sync the state
> > with BIOS.
> >
> > Face to your situation, my suggestion is:
> >
> > - Use userland application to correct killswitch state.
> > highly suggest You can try urfkill daemon:
> > http://www.freedesktop.org/wiki/Software/urfkill or
> > write a startup script to enable bluetooth when system boot.
> >
> > - Disable rfkill-input module if you didn't real use it.
> > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> > enable bluetooth killswitch.
>
> I didn't have time to look at the problem more deeply to identify who is
> setting the global state to "blocked" or what really happens. Anyway, I did
> some testing with pressing the HW bluetooth switch and I saw the following
> immediately _after_ pressing the HW switch to enable bluetooth:
>
> oldium ~ # rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: yes
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
>
> I had this output 3 times immediately after each other. I'm using keyboard
> "up" and "enter" to repeat the last shell command, so this is a relatively
> slow operation. So the state when the acer-bluetooth was unblocked stayed for
> relatively long time before hci0 appeared in rfkill. Afterwards I saw:
>
> oldium ~ # rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: yes
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 5: hci0: Bluetooth
> Soft blocked: yes
> Hard blocked: no
>
My Acer machine have no HW bluetooth key but only have one HW WLAN key
that emit KEY_WLAN.
Please use lshal to monitor your HW bluetooth key and make sure it emit
KEY_BLUETOOTH.
> So it looks like the hci0 went blocked even when the acer-bluetooth switch was
> unblocked. So it looks like the hci0 state is independent on the initial acer-
> bluetooth state.
>
> Hopefully I have some time this evening (CET timezone) to add some stack
> traces and logs to see what really happens on my system.
>
> Cheers,
> Oldřich.
>
Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill tool
to set acer-wmi bluetooth killswitch for test, must have different
result.
Thank's
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-16 8:59 ` Joey Lee
@ 2011-03-20 20:09 ` Oldřich Jedlička
2011-03-21 11:26 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-20 20:09 UTC (permalink / raw)
To: Joey Lee; +Cc: Al Cho, mjg59, linux-acpi, linux-bluetooth, platform-driver-x86
Hi Joey Lee,
Finally I've got little time to expriment.
On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> Hi Oldřich,
>
> 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
>
> > > After trace rfkill-input stuff, I thought this is rfkill-input's normal
> > > behavior but not a bug.
> > >
> > > Unfortunately, I didn't find any workaround way when a driver need to
> > > call rfkill_init_sw_state, e.g. acer-wmi driver.
> > >
> > > The rfkill-input will sync the rfkill state to all killswitchs that
> > > have the same type. For example, acer-wmi set the initial software
> > > switch to _BLOCK_ when driver initial, then rfkill-input will also set
> > > any new bluetooth killswitch state to _BLOCK_ .
> >
> > The rfkill_sync_work syncs with rfkill_global_states, which is set during
> > intitialization or by rfkill_switch_all, if I read it correctly. This
> > should be independent to acer-bluetooth state. The
> > rfkill_global_states[BLUETOOTH] should be unblocked initially, I need to
> > verify it.
>
> Yes!
> Ideally, killswitch state should be independent to different driver,
> even the killswitch type is the same.
>
> But,
> If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will replicate
> state for each killswitch that have the same type:
>
> vi net/rfkill/core.c
>
> int __must_check rfkill_register(struct rfkill *rfkill)
> {
> ...
> if (!rfkill->persistent || rfkill_epo_lock_active) {
> schedule_work(&rfkill->sync_work);
> } else { /* if rfkill->persistent then set the state to all
the
> same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = Y */
> bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
>
> if (!atomic_read(&rfkill_input_disabled))
> __rfkill_switch_all(rfkill->type, soft_blocked); /*
> here call switch all to sync state */ #endif
> }
>
> When any driver call rfkill_init_sw_state for set the initial state to
> killswitch, this rfkill->persistent will set to true:
>
> void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* acer-
wmi
> driver used it to set inital killswitch state */ {
> ....
> spin_lock_irqsave(&rfkill->lock, flags);
> __rfkill_set_sw_state(rfkill, blocked);
> rfkill->persistent = true /* persistent set to true */
>
>
> That's why acer-wmi bluetooth killswitch's state was been replicate to
> hci_core's killswitch state.
>
> When CONFIG_RFKILL_INPUT set to Y, and any driver call
> rfkill_init_sw_state before register rfkill, then rfkill_register will
> try to sync state to the same killswitch type like the above.
>
> It's make sense,
> because rfkill-input only can block/unblock the same killswitch type at
> the same time, before rfkill-input active, it want all the same type's
> state is full the same.
>
> And,
> rfkill-input also suppose user only can use keycode (maybe Fn key) to
> control killswitch state, so, direct use rkill tool or echo state to
> killswitch for change the state will cause killswitchs' state lost link.
> It like we do.
>
> > There is some magic in rfkill/input.c that plays with global states, but
> > I don't know if or how that one is used in my case.
>
> Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> code. You will see the new bluetooth killswitch will be unblock when it
> created.
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 0198191..0dec078 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> *rfkill)
>
> if (!rfkill->persistent || rfkill_epo_lock_active) {
> schedule_work(&rfkill->sync_work);
> - } else {
> -#ifdef CONFIG_RFKILL_INPUT
> - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> -
> - if (!atomic_read(&rfkill_input_disabled))
> - __rfkill_switch_all(rfkill->type, soft_blocked);
> -#endif
> - }
> + } //else {
> +//#ifdef CONFIG_RFKILL_INPUT
> +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> +//
> +// if (!atomic_read(&rfkill_input_disabled))
> +// __rfkill_switch_all(rfkill->type, soft_blocked);
> +//#endif
> +// }
>
> rfkill_send_events(rfkill, RFKILL_OP_ADD);
Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
is working bluetooth HW switch.
> > > Acer's BIOS default setup bluetooth's state is disable when system cold
> > > boot, and BIOS also can save the connection devices' state when system
> > > reboot. Currently, acer-wmi driver have right behavior to sync the
> > > state with BIOS.
> > >
> > > Face to your situation, my suggestion is:
> > >
> > > - Use userland application to correct killswitch state.
> > >
> > > highly suggest You can try urfkill daemon:
> > > http://www.freedesktop.org/wiki/Software/urfkill or
> > >
> > > write a startup script to enable bluetooth when system boot.
> > >
> > > - Disable rfkill-input module if you didn't real use it.
> > >
> > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> > > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> > > enable bluetooth killswitch.
> >
> > I didn't have time to look at the problem more deeply to identify who is
> > setting the global state to "blocked" or what really happens. Anyway, I
> > did some testing with pressing the HW bluetooth switch and I saw the
> > following immediately _after_ pressing the HW switch to enable
> > bluetooth:
> >
> > oldium ~ # rfkill list
> > 0: acer-wireless: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 1: acer-bluetooth: Bluetooth
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 2: acer-threeg: Wireless WAN
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > 3: phy0: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > I had this output 3 times immediately after each other. I'm using
> > keyboard "up" and "enter" to repeat the last shell command, so this is a
> > relatively slow operation. So the state when the acer-bluetooth was
> > unblocked stayed for relatively long time before hci0 appeared in
> > rfkill. Afterwards I saw:
> >
> > oldium ~ # rfkill list
> > 0: acer-wireless: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 1: acer-bluetooth: Bluetooth
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 2: acer-threeg: Wireless WAN
> >
> > Soft blocked: yes
> > Hard blocked: no
> >
> > 3: phy0: Wireless LAN
> >
> > Soft blocked: no
> > Hard blocked: no
> >
> > 5: hci0: Bluetooth
> >
> > Soft blocked: yes
> > Hard blocked: no
>
> My Acer machine have no HW bluetooth key but only have one HW WLAN key
> that emit KEY_WLAN.
> Please use lshal to monitor your HW bluetooth key and make sure it emit
> KEY_BLUETOOTH.
`lshal -m` outputs this:
<bluetooth key pressed>
20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = bluetooth
20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
killswitch.state = 1 (0x1)
20:45:54.678: usb_device_a5c_2101_noserial added
...
<bluetooth key pressed again>
20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = brightness-up
20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
killswitch.state = 0 (0x0)
20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
...
Strange is "brightness-up" key, somebody is wrong here.
> > So it looks like the hci0 went blocked even when the acer-bluetooth
> > switch was unblocked. So it looks like the hci0 state is independent on
> > the initial acer- bluetooth state.
> >
> > Hopefully I have some time this evening (CET timezone) to add some stack
> > traces and logs to see what really happens on my system.
> >
> > Cheers,
> > Oldřich.
>
> Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill tool
> to set acer-wmi bluetooth killswitch for test, must have different
> result.
Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
net/rfkill and there is a line "default y if !EXPERT" which means (I think)
that it would be enabled by default for anybody not enabling expert options.
So other non-expert users would have the same troubles as I have.
I've tried `rfkill unblock <acer-bluetooth number>` with my second test
(enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some degree,
because enabling the config switch changes bluetooth HW/SW switch from working
to not-fully-working.
Cheers,
Oldřich.
>
>
> Thank's
> Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-20 20:09 ` Oldřich Jedlička
@ 2011-03-21 11:26 ` Joey Lee
2011-03-21 11:43 ` Johannes Berg
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-21 11:26 UTC (permalink / raw)
To: oldium.pro
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and
Gary Lin
Hi Oldřich,
於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> Finally I've got little time to expriment.
>
Thank's for you also reserve time to trace it. And, I also add comment
on bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=31002
> On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > Hi Oldřich,
> >
> > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> >
> > > > After trace rfkill-input stuff, I thought this is rfkill-input's normal
> > > > behavior but not a bug.
> > > >
> > > > Unfortunately, I didn't find any workaround way when a driver need to
> > > > call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > >
> > > > The rfkill-input will sync the rfkill state to all killswitchs that
> > > > have the same type. For example, acer-wmi set the initial software
> > > > switch to _BLOCK_ when driver initial, then rfkill-input will also set
> > > > any new bluetooth killswitch state to _BLOCK_ .
> > >
> > > The rfkill_sync_work syncs with rfkill_global_states, which is set during
> > > intitialization or by rfkill_switch_all, if I read it correctly. This
> > > should be independent to acer-bluetooth state. The
> > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I need to
> > > verify it.
> >
> > Yes!
> > Ideally, killswitch state should be independent to different driver,
> > even the killswitch type is the same.
> >
> > But,
> > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will replicate
> > state for each killswitch that have the same type:
> >
> > vi net/rfkill/core.c
> >
> > int __must_check rfkill_register(struct rfkill *rfkill)
> > {
> > ...
> > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > schedule_work(&rfkill->sync_work);
> > } else { /* if rfkill->persistent then set the state to all
> the
> > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = Y */
> > bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> >
> > if (!atomic_read(&rfkill_input_disabled))
> > __rfkill_switch_all(rfkill->type, soft_blocked); /*
> > here call switch all to sync state */ #endif
> > }
> >
> > When any driver call rfkill_init_sw_state for set the initial state to
> > killswitch, this rfkill->persistent will set to true:
> >
> > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* acer-
> wmi
> > driver used it to set inital killswitch state */ {
> > ....
> > spin_lock_irqsave(&rfkill->lock, flags);
> > __rfkill_set_sw_state(rfkill, blocked);
> > rfkill->persistent = true /* persistent set to true */
> >
> >
> > That's why acer-wmi bluetooth killswitch's state was been replicate to
> > hci_core's killswitch state.
> >
> > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > rfkill_init_sw_state before register rfkill, then rfkill_register will
> > try to sync state to the same killswitch type like the above.
> >
> > It's make sense,
> > because rfkill-input only can block/unblock the same killswitch type at
> > the same time, before rfkill-input active, it want all the same type's
> > state is full the same.
> >
> > And,
> > rfkill-input also suppose user only can use keycode (maybe Fn key) to
> > control killswitch state, so, direct use rkill tool or echo state to
> > killswitch for change the state will cause killswitchs' state lost link.
> > It like we do.
> >
> > > There is some magic in rfkill/input.c that plays with global states, but
> > > I don't know if or how that one is used in my case.
> >
> > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> > code. You will see the new bluetooth killswitch will be unblock when it
> > created.
> >
> > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > index 0198191..0dec078 100644
> > --- a/net/rfkill/core.c
> > +++ b/net/rfkill/core.c
> > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> > *rfkill)
> >
> > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > schedule_work(&rfkill->sync_work);
> > - } else {
> > -#ifdef CONFIG_RFKILL_INPUT
> > - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > -
> > - if (!atomic_read(&rfkill_input_disabled))
> > - __rfkill_switch_all(rfkill->type, soft_blocked);
> > -#endif
> > - }
> > + } //else {
> > +//#ifdef CONFIG_RFKILL_INPUT
> > +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > +//
> > +// if (!atomic_read(&rfkill_input_disabled))
> > +// __rfkill_switch_all(rfkill->type, soft_blocked);
> > +//#endif
> > +// }
> >
> > rfkill_send_events(rfkill, RFKILL_OP_ADD);
>
> Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
> enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
> is working bluetooth HW switch.
>
Yes, that because the following patch introduce
driver with persistent state will affect the global state only if rfkill-input
is enabled:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
to any new bluetooth killswitch.
It's not make sense.
> > > > Acer's BIOS default setup bluetooth's state is disable when system cold
> > > > boot, and BIOS also can save the connection devices' state when system
> > > > reboot. Currently, acer-wmi driver have right behavior to sync the
> > > > state with BIOS.
> > > >
> > > > Face to your situation, my suggestion is:
> > > >
> > > > - Use userland application to correct killswitch state.
> > > >
> > > > highly suggest You can try urfkill daemon:
> > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > >
> > > > write a startup script to enable bluetooth when system boot.
> > > >
> > > > - Disable rfkill-input module if you didn't real use it.
> > > >
> > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> > > > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> > > > enable bluetooth killswitch.
> > >
> > > I didn't have time to look at the problem more deeply to identify who is
> > > setting the global state to "blocked" or what really happens. Anyway, I
> > > did some testing with pressing the HW bluetooth switch and I saw the
> > > following immediately _after_ pressing the HW switch to enable
> > > bluetooth:
> > >
> > > oldium ~ # rfkill list
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> > >
> > > 3: phy0: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > I had this output 3 times immediately after each other. I'm using
> > > keyboard "up" and "enter" to repeat the last shell command, so this is a
> > > relatively slow operation. So the state when the acer-bluetooth was
> > > unblocked stayed for relatively long time before hci0 appeared in
> > > rfkill. Afterwards I saw:
> > >
> > > oldium ~ # rfkill list
> > > 0: acer-wireless: Wireless LAN
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 1: acer-bluetooth: Bluetooth
> > >
> > > Soft blocked: no
> > > Hard blocked: no
> > >
> > > 2: acer-threeg: Wireless WAN
> > >
> > > Soft blocked: yes
> > > Hard blocked> > >
> > > 5: hci0: Bluetooth
> > >
> > > Soft blocked: yes
> > > Hard blocked: no
> >
> > My Acer machine have no HW bluetooth key but only have one HW WLAN key
> > that emit KEY_WLAN.
> > Please use lshal to monitor your HW bluetooth key and make sure it emit
> > KEY_BLUETOOTH.
>
> `lshal -m` outputs this:
>
> <bluetooth key pressed>
> 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
> ButtonPressed = bluetooth
> 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> killswitch.state = 1 (0x1)
> 20:45:54.678: usb_device_a5c_2101_noserial added
> ...
> <bluetooth key pressed again>
> 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
> ButtonPressed = brightness-up
> 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> killswitch.state = 0 (0x0)
> 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> ...
>
> Strange is "brightness-up" key, somebody is wrong here.
>
Yes, brightness-up key is another story, maybe you can enable acpi debug
to look at montior which acpi method or _Q event method used:
echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
echo 0xF >/sys/module/acpi/parameters/debug_level
But, this is not related to our current killswitch issue, let us skip
it.
> > > So it looks like the hci0 went blocked even when the acer-bluetooth
> > > switch was unblocked. So it looks like the hci0 state is independent on
> > > the initial acer- bluetooth state.
> > >
> > > Hopefully I have some time this evening (CET timezone) to add some stack
> > > traces and logs to see what really happens on my system.
> > >
> > > Cheers,
> > > Oldřich.
> >
> > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill tool
> > to set acer-wmi bluetooth killswitch for test, must have different
> > result.
>
> Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
> net/rfkill and there is a line "default y if !EXPERT" which means (I think)
> that it would be enabled by default for anybody not enabling expert options.
> So other non-expert users would have the same troubles as I have.
>
I agreed your point, and I don't think rfkill-input need enable for all
non-Expert user because it sometimes have conflict with EC or userland
behavior.
I still suggest you can disable rfkill-input then please try Gary Lin's
urfkill daemon, it can do what does rfkill-input do and more
flexibility.
> I've tried `rfkill unblock <acer-bluetooth number>` with my second test
> (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
>
> Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some degree,
> because enabling the config switch changes bluetooth HW/SW switch from working
> to not-fully-working.
>
> Cheers,
> Oldřich.
>
The root cause is what I said in the above, it's hard to fix in kernel
module because user only can choice enable/disable rfkill-input in
Kconfig and even cann't choice it when system boot.
I thought we need:
- set rfkill-input to EXPERT, remove !EXPERT
- add a kernel option to rfkill for user can choice enable it or not
when system boot.
- Add comment in Documentation/rfkill.txt for remind user can use
urfkill daemon (or any other userland daemon) to replace rfkill-input.
Of course need rfkill experts' more professional comments for this
topic.
I will try to generate a patches to implement the above 3 things then
send out to rfkill experts for review.
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 11:26 ` Joey Lee
@ 2011-03-21 11:43 ` Johannes Berg
2011-03-21 13:57 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-21 11:43 UTC (permalink / raw)
To: Joey Lee
Cc: oldium.pro, davem, marcel, Al Cho, Gary Lin, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86, Alan Jenkins
[Add Alan, since you're discussing his patch why did you leave him out?]
On Mon, 2011-03-21 at 05:26 -0600, Joey Lee wrote:
> > > -#ifdef CONFIG_RFKILL_INPUT
> > > - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > -
> > > - if (!atomic_read(&rfkill_input_disabled))
> > > - __rfkill_switch_all(rfkill->type, soft_blocked);
> > > -#endif
> > > - }
> > > + } //else {
> > > +//#ifdef CONFIG_RFKILL_INPUT
> > > +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > +//
> > > +// if (!atomic_read(&rfkill_input_disabled))
> > > +// __rfkill_switch_all(rfkill->type, soft_blocked);
> > > +//#endif
> > > +// }
> > >
> > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> >
> > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
> > enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
> > is working bluetooth HW switch.
> >
>
> Yes, that because the following patch introduce
> driver with persistent state will affect the global state only if rfkill-input
> is enabled:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> to any new bluetooth killswitch.
>
> It's not make sense.
I think the reason is that rfkill-input only has a global concept of
per-device states. The alternative would be to force a newly registered
rfkill device to the state that was set by rfkill-input.
Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
event?
> > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
> > net/rfkill and there is a line "default y if !EXPERT" which means (I think)
> > that it would be enabled by default for anybody not enabling expert options.
> > So other non-expert users would have the same troubles as I have.
>
> I agreed your point, and I don't think rfkill-input need enable for all
> non-Expert user because it sometimes have conflict with EC or userland
> behavior.
I don't think this makes sense. Until distros routinely ship an rfkill
daemon, we absolutely need rfkill-input.
> The root cause is what I said in the above, it's hard to fix in kernel
> module because user only can choice enable/disable rfkill-input in
> Kconfig and even cann't choice it when system boot.
>
> I thought we need:
> - set rfkill-input to EXPERT, remove !EXPERT
> - add a kernel option to rfkill for user can choice enable it or not
> when system boot.
> - Add comment in Documentation/rfkill.txt for remind user can use
> urfkill daemon (or any other userland daemon) to replace rfkill-input.
>
> Of course need rfkill experts' more professional comments for this
> topic.
> I will try to generate a patches to implement the above 3 things then
> send out to rfkill experts for review.
I disagree -- let's discuss more first.
What really happens on Acer machines when the user presses a button?
Does it generate more than one event?
johannes
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 11:43 ` Johannes Berg
@ 2011-03-21 13:57 ` Joey Lee
2011-03-21 14:35 ` Johannes Berg
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-21 13:57 UTC (permalink / raw)
To: johannes
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Johannes,
於 一，2011-03-21 於 12:43 +0100，Johannes Berg 提到：
> [Add Alan, since you're discussing his patch why did you leave him out?]
>
First, I am sorry for I forgot to add Alan and also a bit of late to add
Cc. you and other rfkill experts, and thank's for your response.
I will keep it in mind to remember add Cc to patch contributor in the
future.
> On Mon, 2011-03-21 at 05:26 -0600, Joey Lee wrote:
>
> > > > -#ifdef CONFIG_RFKILL_INPUT
> > > > - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > > -
> > > > - if (!atomic_read(&rfkill_input_disabled))
> > > > - __rfkill_switch_all(rfkill->type, soft_blocked);
> > > > -#endif
> > > > - }
> > > > + } //else {
> > > > +//#ifdef CONFIG_RFKILL_INPUT
> > > > +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > > +//
> > > > +// if (!atomic_read(&rfkill_input_disabled))
> > > > +// __rfkill_switch_all(rfkill->type, soft_blocked);
> > > > +//#endif
> > > > +// }
> > > >
> > > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > >
> > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
> > > enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
> > > is working bluetooth HW switch.
> > >
> >
> > Yes, that because the following patch introduce
> > driver with persistent state will affect the global state only if rfkill-input
> > is enabled:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
>
> > It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> > bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> > to any new bluetooth killswitch.
> >
> > It's not make sense.
>
> I think the reason is that rfkill-input only has a global concept of
> per-device states. The alternative would be to force a newly registered
> rfkill device to the state that was set by rfkill-input.
>
Yes
> Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
> event?
>
Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea
if there have any userland daemon to listen the keycode.
I am trying to remove rfkill_init_sw_state then workaround this issue
in .set_block by maintain a driver initial flag in acer-wmi.
> > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
> > > net/rfkill and there is a line "default y if !EXPERT" which means (I think)
> > > that it would be enabled by default for anybody not enabling expert options.
> > > So other non-expert users would have the same troubles as I have.
> >
> > I agreed your point, and I don't think rfkill-input need enable for all
> > non-Expert user because it sometimes have conflict with EC or userland
> > behavior.
>
> I don't think this makes sense. Until distros routinely ship an rfkill
> daemon, we absolutely need rfkill-input.
>
> > The root cause is what I said in the above, it's hard to fix in kernel
> > module because user only can choice enable/disable rfkill-input in
> > Kconfig and even cann't choice it when system boot.
> >
> > I thought we need:
> > - set rfkill-input to EXPERT, remove !EXPERT
> > - add a kernel option to rfkill for user can choice enable it or not
> > when system boot.
Does it possible we add this rfkill module option for user can control
disable rfkill-input when rfkill driver probed?
Because, distro was shipped with different company's machine, like: Acer
or MSI, different machines almost have different wifi/bluetooth/wwan key
use case.
Sometimes, we want to use rfkill-input, but sometimes we have userland
GUI application to provide rfkill control panel to end user. We already
used urfkill daemon to disable rfkill-input by ioctl way, but like this
issue, it was happen on driver probe.
> > - Ad> > urfkill daemon (or any other userland daemon) to replace rfkill-input.
> >
> > Of course need rfkill experts' more professional comments for this
> > topic.
> > I will try to generate a patches to implement the above 3 things then
> > send out to rfkill experts for review.
>
> I disagree -- let's discuss more first.
>
> What really happens on Acer machines when the user presses a button?
> Does it generate more than one event?
Different acer machine have different behavior, but I don't know have
Acer machine emit more then one key event in function key. I know have
some MSI netbook emit more then one key event.
But,
this bluetooth killswitch state issue is not relate to emit more then
one event.
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 13:57 ` Joey Lee
@ 2011-03-21 14:35 ` Johannes Berg
2011-03-21 16:25 ` Joey Lee
2011-03-21 19:27 ` Oldřich Jedlička
0 siblings, 2 replies; 48+ messages in thread
From: Johannes Berg @ 2011-03-21 14:35 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi,
> > > It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> > > bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> > > to any new bluetooth killswitch.
> > >
> > > It's not make sense.
> >
> > I think the reason is that rfkill-input only has a global concept of
> > per-device states. The alternative would be to force a newly registered
> > rfkill device to the state that was set by rfkill-input.
>
> Yes
I don't know if that works though. Does it make more sense? I'm not
sure. Why bother with "persistent" then anyway? I think the logic as we
had it was meant to make things follow the persistent state you had
before you shut down and that was saved in the BIOS or whatever.
> > Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
> > event?
>
> Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea
> if there have any userland daemon to listen the keycode.
>
> I am trying to remove rfkill_init_sw_state then workaround this issue
> in .set_block by maintain a driver initial flag in acer-wmi.
No I mean ... it seems that the BIOS reports both a hotkey and an rfkill
event. Could those be clashing?
It seems that what happens is roughly this:
1) at boot, all BT is set to soft-killed due to the way the BIOS
started up
2) when you press the button, it's a toggle, so rfkill-input toggles
all BT rfkill instances (acer and hci0)
3) now acer _also_ reports, via rfkill_set_sw_state(), that the acer BT
rfkill instance is not soft-blocked
Then again, even that should work fine? Clearly I don't understand the
issue yet.
> Does it possible we add this rfkill module option for user can control
> disable rfkill-input when rfkill driver probed?
>
> Because, distro was shipped with different company's machine, like: Acer
> or MSI, different machines almost have different wifi/bluetooth/wwan key
> use case.
Well, I don't think we should require a config to work "out of the box",
so I'm not sure that makes sense.
> Sometimes, we want to use rfkill-input, but sometimes we have userland
> GUI application to provide rfkill control panel to end user. We already
> used urfkill daemon to disable rfkill-input by ioctl way, but like this
> issue, it was happen on driver probe.
Yeah but when urfkill starts up, it could just force the status it
thinks things have. Since it can simply override the current status
there doesn't seem to be a need for disabling the logic first.
Still though I don't understand how we arrive at the issue at all.
Oldřich, can you run "rfkill event" while you press the button with a
stock kernel that shows the problem and no patches?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 14:35 ` Johannes Berg
@ 2011-03-21 16:25 ` Joey Lee
[not found] ` <4D881693020000230002A2FC-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
2011-03-21 19:27 ` Oldřich Jedlička
1 sibling, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-21 16:25 UTC (permalink / raw)
To: johannes
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Johannes,
於 一，2011-03-21 於 15:35 +0100，Johannes Berg 提到：
> Hi,
>
> > > > It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> > > > bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> > > > to any new bluetooth killswitch.
> > > >
> > > > It's not make sense.
> > >
> > > I think the reason is that rfkill-input only has a global concept of
> > > per-device states. The alternative would be to force a newly registered
> > > rfkill device to the state that was set by rfkill-input.
> >
> > Yes
>
> I don't know if that works though. Does it make more sense? I'm not
> sure. Why bother with "persistent" then anyway? I think the logic as we
> had it was meant to make things follow the persistent state you had
> before you shut down and that was saved in the BIOS or whatever.
>
Sorry for I didn't really capture what your mean. Please then me
introduce the issue's background:
For the beginning, I added this patch to acer-wmi driver:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=466449cfe797b8a5d82d25d0e0e08426d8dfba19
Because Acer notebook's BIOS can keep the devices state when system
reboot, so, the above patch add the logic when acer-wmi driver initial
to query the devices state by wmi method then set soft-block to
acer-wmi's killswitch, including wlan, bluetooth and wwan.
The acer-wmi used rfkill_init_sw_state to set the initial state before
rfkill register.
There have source code in rfkill_init_sw_state to set rfkill to
persistent, then rfkill/core.c replicate acer-wmi's bluetooth state to
the same type's rfkill.
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
} else {
#ifdef CONFIG_RFKILL_INPUT
bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
if (!atomic_read(&rfkill_input_disabled)) //when rfkill-input enable
__rfkill_switch_all(rfkill->type, soft_blocked); //set sw block state to the same type
#endif
}
> > > Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
> > > event?
> >
> > Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea
> > if there have any userland daemon to listen the keycode.
> >
> > I am trying to remove rfkill_init_sw_state then workaround this issue
> > in .set_block by maintain a driver initial flag in acer-wmi.
>
> No I mean ... it seems that the BIOS reports both a hotkey and an rfkill
> event. Could those be clashing?
>
No, BIOS only emit acpi notify when user press function key, acer-wmi
driver emit KEY_WLAN to userland after receive the acpi notify. Of
course at this moment, acer-wmi driver need to maintain rfkill state to
sync with real device state.
> It seems that what happens is roughly this:
> 1) at boot, all BT is set to soft-killed due to the way the BIOS
> started up
Yes, acer BIOS's default value is bluetooth disabled. So, when system
boot, there only have acer-wmi's bluetooth killswitch:
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes # default is sw block
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: no
Hard blocked: no
4: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
There have no hci0's killswtich, because BT device power off by BIOS
when system cold boot.
> 2) when you press the button, it's a toggle, so rfkill-input toggles
> all BT rfkill instances (acer and hci0)
Per Oldřich's report, he press bluetooth hardware key then see like the
following:
4: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
6: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
7: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
8: acer-threeg: Wirele Hard blocked: no
9: hci0: Bluetooth
Soft blocked: yes # create hci0 rfkill but default is soft blocked
Hard blocked: no
I didn't have bluetooth HW key on my Acer machine, but I can unblock acer-wmi bluetooth
rfkill manually to reproduce this issue.
> 3) now acer _also_ reports, via rfkill_set_sw_state(), that the acer BT
> rfkill instance is not soft-blocked
>
> Then again, even that should work fine? Clearly I don't understand the
> issue yet.
>
If only use bluetooth HW key to control the rfkill, then it should be
fine. But, Oldřich report still have problem cann't enable bluetooth
after he press HW key because hci0's bluetooth default set to soft
blocked.
> > Does it possible we add this rfkill module option for user can control
> > disable rfkill-input when rfkill driver probed?
> >
> > Because, distro was shipped with different company's machine, like: Acer
> > or MSI, different machines almost have different wifi/bluetooth/wwan key
> > use case.
>
> Well, I don't think we should require a config to work "out of the box",
> so I'm not sure that makes sense.
>
If we want to remove rfkill-input, then we need re-compiler kernel. Why
don't add a option for enable/disable it ?
> > Sometimes, we want to use rfkill-input, but sometimes we have userland
> > GUI application to provide rfkill control panel to end user. We already
> > used urfkill daemon to disable rfkill-input by ioctl way, but like this
> > issue, it was happen on driver probe.
>
> Yeah but when urfkill starts up, it could just force the status it
> thinks things have. Since it can simply override the current status
> there doesn't seem to be a need for disabling the logic first.
>
Yes, fully agreed your point.
That's why I highly suggest Oldřich to use urfkill daemon to correct
this situation by userland.
> Still though I don't understand how we arrive at the issue at all.
>
Oldřich's point is current Kconfig for rfkill-input is set to !EXPERT,
that mean any normal user will mean the above problem: hci0's rfkill
default value is soft block. It didn't enable by acer'w HW bluetooth
key.
And, like you said, there still didn't have any distro include urfkill
daemon.
> Oldřich, can you run "rfkill event" while you press the button with a
> stock kernel that shows the problem and no patches?
>
> johannes
>
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 14:35 ` Johannes Berg
2011-03-21 16:25 ` Joey Lee
@ 2011-03-21 19:27 ` Oldřich Jedlička
[not found] ` <201103212027.01952.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
1 sibling, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-21 19:27 UTC (permalink / raw)
To: Johannes Berg
Cc: Joey Lee, davem, marcel, Al Cho, Gary Lin, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Johaness,
Just a small correction.
On Monday 21 March 2011 15:35:35 Johannes Berg wrote:
> Hi,
>
> > > > It maybe workaround another rfkill-input issue, but causes it
> > > > replicate acer-wmi's bluetooth killswitch initial state (or any
> > > > driver that used rfkill_init_sw_state) to any new bluetooth
> > > > killswitch.
> > > >
> > > > It's not make sense.
> > >
> > > I think the reason is that rfkill-input only has a global concept of
> > > per-device states. The alternative would be to force a newly registered
> > > rfkill device to the state that was set by rfkill-input.
> >
> > Yes
>
> I don't know if that works though. Does it make more sense? I'm not
> sure. Why bother with "persistent" then anyway? I think the logic as we
> had it was meant to make things follow the persistent state you had
> before you shut down and that was saved in the BIOS or whatever.
>
> > > Is it possible that acer-wmi reports both a hotkey event _and_ an
> > > rfkill event?
> >
> > Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea
> > if there have any userland daemon to listen the keycode.
> >
> > I am trying to remove rfkill_init_sw_state then workaround this issue
> > in .set_block by maintain a driver initial flag in acer-wmi.
>
> No I mean ... it seems that the BIOS reports both a hotkey and an rfkill
> event. Could those be clashing?
>
> It seems that what happens is roughly this:
> 1) at boot, all BT is set to soft-killed due to the way the BIOS
> started up
> 2) when you press the button, it's a toggle, so rfkill-input toggles
> all BT rfkill instances (acer and hci0)
> 3) now acer _also_ reports, via rfkill_set_sw_state(), that the acer BT
> rfkill instance is not soft-blocked
>
> Then again, even that should work fine? Clearly I don't understand the
> issue yet.
hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill switch
appears when you unblock SW rfkill or by pressing the HW switch. It disappears
when you block the switch again. hci0 is set to "blocked" when it appears,
because the acer-wmi driver have registered acpi-bluetooth rfkill switch
during boot, which was set to "blocked" initially with a call to
rfkill_init_sw_state. So what happens actually is this:
1) at boot, BIOS says the bluetooth is disabled, so the not-registered state
of acer-bluetooth rfkill is set to "blocked" (rfkill_init_sw_state, sets the
"persistent" bit). The acer-bluetooth is then registered, which forces the
global bluetooth state to go "blocked". No hci0 exists at this time.
2) when you press the button, hci0 appears and the rfkill is set to the global
bluetooth state (in rfkill_sync_work), which is "blocked".
From my understanding acer-wmi reports the change via acer_rfkill_update work
(executed every second). It just calls rfkill_set_sw_state, but that doesn't
update the global state. I don't know at which time that happens, but
generally I didn't find anything that could eventually enable hci0 state or
global state to "unblocked".
Cheers,
Oldřich.
>
> > Does it possible we add this rfkill module option for user can control
> > disable rfkill-input when rfkill driver probed?
> >
> > Because, distro was shipped with different company's machine, like: Acer
> > or MSI, different machines almost have different wifi/bluetooth/wwan key
> > use case.
>
> Well, I don't think we should require a config to work "out of the box",
> so I'm not sure that makes sense.
>
> > Sometimes, we want to use rfkill-input, but sometimes we have userland
> > GUI application to provide rfkill control panel to end user. We already
> > used urfkill daemon to disable rfkill-input by ioctl way, but like this
> > issue, it was happen on driver probe.
>
> Yeah but when urfkill starts up, it could just force the status it
> thinks things have. Since it can simply override the current status
> there doesn't seem to be a need for disabling the logic first.
>
> Still though I don't understand how we arrive at the issue at all.
>
> Oldřich, can you run "rfkill event" while you press the button with a
> stock kernel that shows the problem and no patches?
>
> johannes
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <201103212027.01952.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
@ 2011-03-23 11:58 ` Johannes Berg
2011-03-23 21:38 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-23 11:58 UTC (permalink / raw)
To: Oldřich Jedlička
Cc: Joey Lee, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
marcel-kz+m5ild9QBg9hUCZPvPmw, Al Cho, Gary Lin,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
On Mon, 2011-03-21 at 20:27 +0100, Oldřich Jedlička wrote:
> hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill switch
> appears when you unblock SW rfkill or by pressing the HW switch. It disappears
> when you block the switch again. hci0 is set to "blocked" when it appears,
> because the acer-wmi driver have registered acpi-bluetooth rfkill switch
> during boot, which was set to "blocked" initially with a call to
> rfkill_init_sw_state. So what happens actually is this:
>
> 1) at boot, BIOS says the bluetooth is disabled, so the not-registered state
> of acer-bluetooth rfkill is set to "blocked" (rfkill_init_sw_state, sets the
> "persistent" bit). The acer-bluetooth is then registered, which forces the
> global bluetooth state to go "blocked". No hci0 exists at this time.
>
> 2) when you press the button, hci0 appears and the rfkill is set to the global
> bluetooth state (in rfkill_sync_work), which is "blocked".
>
> From my understanding acer-wmi reports the change via acer_rfkill_update work
> (executed every second). It just calls rfkill_set_sw_state, but that doesn't
> update the global state. I don't know at which time that happens, but
> generally I didn't find anything that could eventually enable hci0 state or
> global state to "unblocked".
Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't
been updated yet, hence registering hci0 as blocked.
johannes
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <4D881693020000230002A2FC-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
@ 2011-03-23 12:17 ` Johannes Berg
[not found] ` <1300882647.3790.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-23 12:17 UTC (permalink / raw)
To: Joey Lee
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
[remove Alan, his email address no longer works]
Hi,
> Sorry for I didn't really capture what your mean. Please then me
> introduce the issue's background:
>
> For the beginning, I added this patch to acer-wmi driver:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=466449cfe797b8a5d82d25d0e0e08426d8dfba19
>
> Because Acer notebook's BIOS can keep the devices state when system
> reboot, so, the above patch add the logic when acer-wmi driver initial
> to query the devices state by wmi method then set soft-block to
> acer-wmi's killswitch, including wlan, bluetooth and wwan.
>
> The acer-wmi used rfkill_init_sw_state to set the initial state before
> rfkill register.
Yeah that seems reasonable.
> There have source code in rfkill_init_sw_state to set rfkill to
> persistent, then rfkill/core.c replicate acer-wmi's bluetooth state to
> the same type's rfkill.
>
> if (!rfkill->persistent || rfkill_epo_lock_active) {
> schedule_work(&rfkill->sync_work);
> } else {
> #ifdef CONFIG_RFKILL_INPUT
> bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
>
> if (!atomic_read(&rfkill_input_disabled)) //when rfkill-input enable
> __rfkill_switch_all(rfkill->type, soft_blocked); //set sw block state to the same type
> #endif
> }
But that's also required to actually make the persistent state have any
impact at all.
> No, BIOS only emit acpi notify when user press function key, acer-wmi
> driver emit KEY_WLAN to userland after receive the acpi notify. Of
> course at this moment, acer-wmi driver need to maintain rfkill state to
> sync with real device state.
So, I'm confused. Why does the driver not use the acer_wmi_notify
function to update the rfkill status too, but polls it every second?
> > It seems that what happens is roughly this:
> > 1) at boot, all BT is set to soft-killed due to the way the BIOS
> > started up
>
> Yes, acer BIOS's default value is bluetooth disabled. So, when system
> boot, there only have acer-wmi's bluetooth killswitch:
>
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes # default is sw block
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: no
> Hard blocked: no
> 4: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
>
> There have no hci0's killswtich, because BT device power off by BIOS
> when system cold boot.
Right -- I missed that part.
> > 2) when you press the button, it's a toggle, so rfkill-input toggles
> > all BT rfkill instances (acer and hci0)
>
> Per Oldřich's report, he press bluetooth hardware key then see like the
> following:
>
> 4: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 6: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 7: acer-bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 8: acer-threeg: Wirele Hard blocked: no
> 9: hci0: Bluetooth
> Soft blocked: yes # create hci0 rfkill but default is soft blocked
> Hard blocked: no
>
> I didn't have bluetooth HW key on my Acer machine, but I can unblock acer-wmi bluetooth
> rfkill manually to reproduce this issue.
Hmm, that I don't understand. Why would that reproduce the issue? Ah,
ok, that's because __rfkill_switch_all() will set global_states, and it
happens during init. So it gets registered with the global state, which
is still blocked since you just unblocked this single thing.
So, it seems that the design here only works if
a) the bios stores the last state
b) the driver only reports key inputs, no rfkill inputs
> If only use bluetooth HW key to control the rfkill, then it should be
> fine. But, Oldřich report still have problem cann't enable bluetooth
> after he press HW key because hci0's bluetooth default set to soft
> blocked.
Yeah that's because the BT hw key seems to generate the wrong event?
> If we want to remove rfkill-input, then we need re-compiler kernel. Why
> don't add a option for enable/disable it ?
Well I don't think we want to remove rfkill input, ever, because that
just leads to a mess where the user has to take action. I'd rather have
it work out of the box and be overridden by urfkill which should work
fine.
Of course, in this particular instance it _doesn't_ work out of the box,
but shouldn't we rather fix that?
But due the the behaviour you outlined earlier, I think your patch makes
sense... the BIOS doesn't actually seem to _store_ the rfkill state
anyway, since it's always off when you cold boot. So why bother using
that state as the default anyway?
That will work around the problem at hand by making the acer wmi enable
BT whenever it is loaded, but that doesn't seem so bad either.
As for the more generic problem, I'm not sure what to do. I really wish
people would just use urfkill.
johannes
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-23 11:58 ` Johannes Berg
@ 2011-03-23 21:38 ` Oldřich Jedlička
2011-03-24 8:36 ` Johannes Berg
0 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-23 21:38 UTC (permalink / raw)
To: Johannes Berg
Cc: Joey Lee, davem, marcel, Al Cho, Gary Lin, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Johaness,
On Wednesday 23 March 2011 12:58:08 Johannes Berg wrote:
> On Mon, 2011-03-21 at 20:27 +0100, Oldřich Jedlička wrote:
> > hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill
> > switch appears when you unblock SW rfkill or by pressing the HW switch.
> > It disappears when you block the switch again. hci0 is set to "blocked"
> > when it appears, because the acer-wmi driver have registered
> > acpi-bluetooth rfkill switch during boot, which was set to "blocked"
> > initially with a call to rfkill_init_sw_state. So what happens actually
> > is this:
> >
> > 1) at boot, BIOS says the bluetooth is disabled, so the not-registered
> > state of acer-bluetooth rfkill is set to "blocked"
> > (rfkill_init_sw_state, sets the "persistent" bit). The acer-bluetooth is
> > then registered, which forces the global bluetooth state to go
> > "blocked". No hci0 exists at this time.
> >
> > 2) when you press the button, hci0 appears and the rfkill is set to the
> > global bluetooth state (in rfkill_sync_work), which is "blocked".
> >
> > From my understanding acer-wmi reports the change via acer_rfkill_update
> > work (executed every second). It just calls rfkill_set_sw_state, but
> > that doesn't update the global state. I don't know at which time that
> > happens, but generally I didn't find anything that could eventually
> > enable hci0 state or global state to "unblocked".
>
> Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't
> been updated yet, hence registering hci0 as blocked.
No, that is not the case. I can play with `rfkill list` immediately after I
press the HW bluetooth switch and show that hci0 is not there (still
unregistered) while acer-bluetooth is already "unblocked" - I've tried to run
`rfkill list` repeatedly manually from console immediately after I pressed the
HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0
wasn't there. When hci0 appeared, it was "blocked".
As I wrote, I didn't find anything changing the global state, which is actually
used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It
looks like the global state is just "blocked" forever - and it is "blocked" as
a side-effect of the call to rfkill_init_sw_state (changes permanent=true) and
then call to rfkill_register from the acer-wmi driver. I can verify this in
the following days (that the global state stays the same all the time).
Cheers,
Oldřich.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <1300882647.3790.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2011-03-24 7:01 ` Joey Lee
2011-03-24 8:35 ` Johannes Berg
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-24 7:01 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Johannes,
於 三，2011-03-23 於 13:17 +0100，Johannes Berg 提到：
> [remove Alan, his email address no longer works]
>
> Hi,
>
> > Sorry for I didn't really capture what your mean. Please then me
> > introduce the issue's background:
> >
> > For the beginning, I added this patch to acer-wmi driver:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=466449cfe797b8a5d82d25d0e0e08426d8dfba19
> >
> > Because Acer notebook's BIOS can keep the devices state when system
> > reboot, so, the above patch add the logic when acer-wmi driver initial
> > to query the devices state by wmi method then set soft-block to
> > acer-wmi's killswitch, including wlan, bluetooth and wwan.
> >
> > The acer-wmi used rfkill_init_sw_state to set the initial state before
> > rfkill register.
>
> Yeah that seems reasonable.
>
Yes, use rfill_init_sw_state to set the initial state from BIOS to
killswitch is make sense.
But, it looks like have tricky effect when rfkill-input enabled.
> > There have source code in rfkill_init_sw_state to set rfkill to
> > persistent, then rfkill/core.c replicate acer-wmi's bluetooth state to
> > the same type's rfkill.
> >
> > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > schedule_work(&rfkill->sync_work);
> > } else {
> > #ifdef CONFIG_RFKILL_INPUT
> > bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> >
> > if (!atomic_read(&rfkill_input_disabled)) //when rfkill-input enable
> > __rfkill_switch_all(rfkill->type, soft_blocked); //set sw block state to the same type
> > #endif
> > }
>
> But that's also required to actually make the persistent state have any
> impact at all.
>
Yes, per Alan's patch, there have another issue need to workaround by
set the block state to global, and those code might need removed in the
future:
commit b3fa1329eaf2a7b97124dacf5b663fd51346ac19
Author: Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>
Date: Mon Jun 8 13:27:27 2009 +0100
....
Drivers with persistent state will affect the global state only if
rfkill-input is enabled. This is required, otherwise booting with
wireless soft-blocked and pressing the wireless-toggle key once would
have no apparent effect. This special case will be removed in future
along with rfkill-input, in favour of a more flexible userspace daemon
(see Documentation/feature-removal-schedule.txt).
But,
the above code replicate acer-wmi's initial state to global, then set to hci0's
BT initial state.
> > No, BIOS only emit acpi notify when user press function key, acer-wmi
> > driver emit KEY_WLAN to userland after receive the acpi notify. Of
> > course at this moment, acer-wmi driver need to maintain rfkill state to
> > sync with real device state.
>
> So, I'm confused. Why does the driver not use the acer_wmi_notify
> function to update the rfkill status too, but polls it every second?
>
I already have a patch to use acer-wmi_notify to set device state:
http://www.spinics.net/lists/platform-driver-x86/msg01645.html
It didn't accept, yet. But, even have this patch, there still have some
old acer machine need use polling way because those machines have no wmi
event notify.
> > > It seems that what happens is roughly this:
> > > 1) at boot, all BT is set to soft-killed due to the way the BIOS
> > > started up
> >
> > Yes, acer BIOS's default value is bluetooth disabled. So, when system
> > boot, there only have acer-wmi's bluetooth killswitch:
> >
> > 0: acer-wireless: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
> > 1: acer-bluetooth: Bluetooth
> > Soft blocked: yes # default is sw block
> > Hard blocked: no
> > 2: acer-threeg: Wireless WAN
> > Soft blocked: no
> > Hard blocked: no
> > 4: phy0: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
> >
> > There have no hci0'> > when system cold boot.
>
> Right -- I missed that part.
>
> > > 2) when you press the button, it's a toggle, so rfkill-input toggles
> > > all BT rfkill instances (acer and hci0)
> >
> > Per Oldřich's report, he press bluetooth hardware key then see like the
> > following:
> >
> > 4: phy0: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
> > 6: acer-wireless: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
> > 7: acer-bluetooth: Bluetooth
> > Soft blocked: no
> > Hard blocked: no
> > 8: acer-threeg: Wirele Hard blocked: no
> > 9: hci0: Bluetooth
> > Soft blocked: yes # create hci0 rfkill but default is soft blocked
> > Hard blocked: no
> >
> > I didn't have bluetooth HW key on my Acer machine, but I can unblock acer-wmi bluetooth
> > rfkill manually to reproduce this issue.
>
> Hmm, that I don't understand. Why would that reproduce the issue? Ah,
> ok, that's because __rfkill_switch_all() will set global_states, and it
> happens during init. So it gets registered with the global state, which
> is still blocked since you just unblocked this single thing.
>
I have no Bluetooth HW key on my machine, but Oldřich can reproduce this
issue by HW key.
> So, it seems that the design here only works if
The "the design" means call rfkill_init_sw_state before rfkill register?
> a) the bios stores the last state
This issue happen when "Bluetooth's initial state is disabled before
system boot.", maybe user choice disable bluetooth at last time reboot,
then BIOS keep BT disable.
> b) the driver only reports key inputs, no rfkill inputs
>
> > If only use bluetooth HW key to control the rfkill, then it should be
> > fine. But, Oldřich report still have problem cann't enable bluetooth
> > after he press HW key because hci0's bluetooth default set to soft
> > blocked.
>
> Yeah that's because the BT hw key seems to generate the wrong event?
>
No, BT HW key doesn't emit KEY_BLUETOOTH, it emit wmi event, then
acer-wmi driver transfer to KEY_BLUETOOTH. Then I think rfkill-input (if
enabled) also receive KEY_BLUETOOTH.
I thought maybe it's a race condition the hci0 rfkill generated before
rfkill-input key work for update the global state ?
> > If we want to remove rfkill-input, then we need re-compiler kernel. Why
> > don't add a option for enable/disable it ?
>
> Well I don't think we want to remove rfkill input, ever, because that
> just leads to a mess where the user has to take action. I'd rather have
> it work out of the box and be overridden by urfkill which should work
> fine.
>
So, we should remove the following statement in
Documentation/feature-removal-schedule.txt ?
What: CONFIG_RFKILL_INPUT
When: 2.6.33
Why: Should be implemented in userspace, policy daemon.
Who: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Of course, in this particular instance it _doesn't_ work out of the box,
> but shouldn't we rather fix that?
>
Yes, if we want to keep the CONFIG_RFKILL_INPUT is !EXPERT, then I
thought we should try to fix it.
>
>
> But due the the behaviour you outlined earlier, I think your patch makes
> sense... the BIOS doesn't actually seem to _store_ the rfkill state
> anyway, since it's always off when you cold boot. So why bother using
> that state as the default anyway?
>
It's tricky to me for use rfkill_init_sw_state.
When rfkill-input disabled, everything works fine, but if rfkill-input
enabled, then I need very careful to know it will change the global
state and causes the global state replicate to any new rfkill.
Honest, I don't know the rfkill_init_sw_state have the above condition
before I read rfkill source code.
> That will work around the problem at hand by making the acer wmi enable
> BT whenever it is loaded, but that doesn't seem so bad either.
>
Yes, it's not good idea, BIOS can save device states when system reboot,
I don't want erase the state.
> As for the more generiI agreed your point or the urfkill daemon, does it possible we add
urfkill daemon information to Kernel document?
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-24 7:01 ` Joey Lee
@ 2011-03-24 8:35 ` Johannes Berg
2011-03-24 12:55 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-24 8:35 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi Joey,
> Yes, per Alan's patch, there have another issue need to workaround by
> set the block state to global, and those code might need removed in the
> future:
>
> commit b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> Author: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Date: Mon Jun 8 13:27:27 2009 +0100
>
> ....
>
> Drivers with persistent state will affect the global state only if
> rfkill-input is enabled. This is required, otherwise booting with
> wireless soft-blocked and pressing the wireless-toggle key once would
> have no apparent effect. This special case will be removed in future
> along with rfkill-input, in favour of a more flexible userspace daemon
> (see Documentation/feature-removal-schedule.txt).
Well, right, that's just hinting that rfkill-input will be removed at
some point, hopefully!
> But,
> the above code replicate acer-wmi's initial state to global, then set to hci0's
> BT initial state.
Right.
> > Hmm, that I don't understand. Why would that reproduce the issue? Ah,
> > ok, that's because __rfkill_switch_all() will set global_states, and it
> > happens during init. So it gets registered with the global state, which
> > is still blocked since you just unblocked this single thing.
> >
>
> I have no Bluetooth HW key on my machine, but Oldřich can reproduce this
> issue by HW key.
Yeah but the hw key doesn't send key events?
> > So, it seems that the design here only works if
>
> The "the design" means call rfkill_init_sw_state before rfkill register?
I mean the whole notion of persistent rfkill state.
> > a) the bios stores the last state
>
> This issue happen when "Bluetooth's initial state is disabled before
> system boot.", maybe user choice disable bluetooth at last time reboot,
> then BIOS keep BT disable.
>
> > b) the driver only reports key inputs, no rfkill inputs
> >
> > > If only use bluetooth HW key to control the rfkill, then it should be
> > > fine. But, Oldřich report still have problem cann't enable bluetooth
> > > after he press HW key because hci0's bluetooth default set to soft
> > > blocked.
> >
> > Yeah that's because the BT hw key seems to generate the wrong event?
> >
>
> No, BT HW key doesn't emit KEY_BLUETOOTH, it emit wmi event, then
> acer-wmi driver transfer to KEY_BLUETOOTH. Then I think rfkill-input (if
> enabled) also receive KEY_BLUETOOTH.
But is this WMI event really intended to be a key event? But ok, that
just means the reason is what you said:
> I thought maybe it's a race condition the hci0 rfkill generated before
> rfkill-input key work for update the global state ?
Yeah, most likely.
> > Well I don't think we want to remove rfkill input, ever, because that
> > just leads to a mess where the user has to take action. I'd rather have
> > it work out of the box and be overridden by urfkill which should work
> > fine.
>
> So, we should remove the following statement in
> Documentation/feature-removal-schedule.txt ?
>
> What: CONFIG_RFKILL_INPUT
> When: 2.6.33
> Why: Should be implemented in userspace, policy daemon.
> Who: Johannes Berg <johannes@sipsolutions.net>
Ah, heh, no, although we've not been able to do this I think we still
want it. But until people do routinely use urfkill, I think we can't
remove it because otherwise things just won't work right.
> > But due the the behaviour you outlined earlier, I think your patch makes
> > sense... the BIOS doesn't actually seem to _store_ the rfkill state
> > anyway, since it's always off when you cold boot. So why bother using
> > that state as the default anyway?
> >
>
> It's tricky to me for use rfkill_init_sw_state.
>
> When rfkill-input disabled, everything works fine, but if rfkill-input
> enabled, then I need very careful to know it will change the global
> state and causes the global state replicate to any new rfkill.
>
> Honest, I don't know the rfkill_init_sw_state have the above condition
> before I read rfkill source code.
Right -- I've only come to understand the exact details during this
discussion myself. Alan probably modelled it on Wifi where the
disconnect issue doesn't typically appear.
> > That will work around the problem at hand by making the acer wmi enable
> > BT whenever it is loaded, but that doesn't seem so bad either.
> >
>
> Yes, it's not good idea, BIOS can save device states when system reboot,
> I don't want erase the state.
So it _does_ store the state? I thought you earlier said it didn't store
it, and when you cold rebooted it was always disabled?
> I agreed your point or the urfkill daemon, does it possible we add
> urfkill daemon information to Kernel document?
Yeah I guess we can do that, don't think it'll help much though :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-23 21:38 ` Oldřich Jedlička
@ 2011-03-24 8:36 ` Johannes Berg
[not found] ` <1300955793.3807.6.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-24 8:36 UTC (permalink / raw)
To: Oldřich Jedlička
Cc: Joey Lee, davem, marcel, Al Cho, Gary Lin, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Oldřich,
> > Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't
> > been updated yet, hence registering hci0 as blocked.
>
> No, that is not the case. I can play with `rfkill list` immediately after I
> press the HW bluetooth switch and show that hci0 is not there (still
> unregistered) while acer-bluetooth is already "unblocked" - I've tried to run
> `rfkill list` repeatedly manually from console immediately after I pressed the
> HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0
> wasn't there. When hci0 appeared, it was "blocked".
>
> As I wrote, I didn't find anything changing the global state, which is actually
> used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It
> looks like the global state is just "blocked" forever - and it is "blocked" as
> a side-effect of the call to rfkill_init_sw_state (changes permanent=true) and
> then call to rfkill_register from the acer-wmi driver. I can verify this in
> the following days (that the global state stays the same all the time).
Well the global state would be changed by the KEY_BLUETOOTH input event.
But like I said, it's tricky in this case because multiple events come
from the same event source and race against each other.
johannes
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-24 8:35 ` Johannes Berg
@ 2011-03-24 12:55 ` Joey Lee
2011-03-24 12:58 ` Johannes Berg
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-24 12:55 UTC (permalink / raw)
To: johannes
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi Johannes,
於 四，2011-03-24 於 09:35 +0100，Johannes Berg 提到：
>
> > > Hmm, that I don't understand. Why would that reproduce the issue? Ah,
> > > ok, that's because __rfkill_switch_all() will set global_states, and it
> > > happens during init. So it gets registered with the global state, which
> > > is still blocked since you just unblocked this single thing.
> > >
> >
> > I have no Bluetooth HW key on my machine, but Oldřich can reproduce this
> > issue by HW key.
>
> Yeah but the hw key doesn't send key events?
>
It's a good question need to check with Oldřich for his machine.
If talk about my Acer TravelMate 8572, NO! My machine only have wifi
hotkey, but either BIOS/EC raw mode or wmi mode, the key does not emit
any KEY_* keycode.
But, yes, thank's your remind, as I remember, in some Acer consumer
notebook, they also emit scancode when hotkey pressed, like you said,
maybe they emit both wmi event and scancode.
Not on my machine but need check Oldřich's machine.
> > > So, it seems that the design here only works if
> >
> > The "the design" means call rfkill_init_sw_state before rfkill register?
>
> I mean the whole notion of persistent rfkill state.
>
> > > a) the bios stores the last state
> >
> > This issue happen when "Bluetooth's initial state is disabled before
> > system boot.", maybe user choice disable bluetooth at last time reboot,
> > then BIOS keep BT disable.
> >
> > > b) the driver only reports key inputs, no rfkill inputs
> > >
> > > > If only use bluetooth HW key to control the rfkill, then it should be
> > > > fine. But, Oldřich report still have problem cann't enable bluetooth
> > > > after he press HW key because hci0's bluetooth default set to soft
> > > > blocked.
> > >
> > > Yeah that's because the BT hw key seems to generate the wrong event?
> > >
> >
> > No, BT HW key doesn't emit KEY_BLUETOOTH, it emit wmi event, then
> > acer-wmi driver transfer to KEY_BLUETOOTH. Then I think rfkill-input (if
> > enabled) also receive KEY_BLUETOOTH.
>
> But is this WMI event really intended to be a key event? But ok, that
> just means the reason is what you said:
>
Yes, the wmi event is must be a KEY_ event on linux platform, because it
was emited by user press hotkey.
> > I thought maybe it's a race condition the hci0 rfkill generated before
> > rfkill-input key work for update the global state ?
>
> Yeah, most likely.
>
> > > Well I don't think we want to remove rfkill input, ever, because that
> > > just leads to a mess where the user has to take action. I'd rather have
> > > it work out of the box and be overridden by urfkill which should work
> > > fine.
> >
> > So, we should remove the following statement in
> > Documentation/feature-removal-schedule.txt ?
> >
> > What: CONFIG_RFKILL_INPUT
> > When: 2.6.33
> > Why: Should be implemented in userspace, policy daemon.
> > Who: Johannes Berg <johannes@sipsolutions.net>
>
> Ah, heh, no, although we've not been able to do this I think we still
> want it. But until people do routinely use urfkill, I think we can't
> remove it because otherwise things just won't work right.
>
I thought still need time to promote urfkill.
> > > But due the the behaviour you outlined earlier, I think your patch makes
> > > sense... the BIOS doesn't actually seem to _store_ the rfkill state
> > > anyway, since it's always off when you cold boot. So why bother using
> > > that state as the default anyway?
> > >
> >
> > It's tricky to me for use rfkill_init_sw_state.
> >
> > When rfkill-input disabled, everything works fine, but if rfkill-input
> > enabled, then I need very careful to know it will change the global
> > state and causes the global state replicate to any new rfkill.
> >
> > Honest, I don't know the rfkill_init_sw_state have the above condition
> > before I read rfkill source code.
>
> Right -- I've only come to understand the exact details during this
> discussion myself. Alan probably modelled it o> > > That will work around the problem at hand by making the acer wmi enable
> > > BT whenever it is loaded, but that doesn't seem so bad either.
> > >
> >
> > Yes, it's not good idea, BIOS can save device states when system reboot,
> > I don't want erase the state.
>
> So it _does_ store the state? I thought you earlier said it didn't store
> it, and when you cold rebooted it was always disabled?
>
There have 2 different behavior on Acer BIOS:
- cold boot (shutdown then power on): BIOS will reset to raw state (WLAN on, BT off, WWAN on)
- warm boot (reboot): BIOS will keep last time's state
> > I agreed your point or the urfkill daemon, does it possible we add
> > urfkill daemon information to Kernel document?
>
> Yeah I guess we can do that, don't think it'll help much though :)
>
> johannes
>
I thought still have some engineer will look at kernel document, I will
send patch for add urfkill daemon information to kernel document and add
Cc. to you for review.
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-24 12:55 ` Joey Lee
@ 2011-03-24 12:58 ` Johannes Berg
2011-03-24 13:36 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Johannes Berg @ 2011-03-24 12:58 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi,
> > So it _does_ store the state? I thought you earlier said it didn't store
> > it, and when you cold rebooted it was always disabled?
> >
>
> There have 2 different behavior on Acer BIOS:
> - cold boot (shutdown then power on): BIOS will reset to raw state (WLAN on, BT off, WWAN on)
> - warm boot (reboot): BIOS will keep last time's state
Yeah but in that case I don't really see the point in making it
persistent. It's not really persistent anyway, warm reboot just means it
was stuck somewhere in memory I guess... I'd not call this persistent,
and making it not persistent also solves the problem, right?
johannes
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <1300955793.3807.6.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2011-03-24 13:13 ` Joey Lee
0 siblings, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-24 13:13 UTC (permalink / raw)
To: oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, johannes-cdvu00un1VgdHxzADdlk8Q,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Oldřich,
Sorry bother you again, but after discuss with Johannes, he remind me
one import thing: maybe your BT HW key emit scancode and wmi event at
the same time.
於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> Hi Oldřich,
>
> > > Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't
> > > been updated yet, hence registering hci0 as blocked.
> >
> > No, that is not the case. I can play with `rfkill list` immediately after I
> > press the HW bluetooth switch and show that hci0 is not there (still
> > unregistered) while acer-bluetooth is already "unblocked" - I've tried to run
> > `rfkill list` repeatedly manually from console immediately after I pressed the
> > HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0
> > wasn't there. When hci0 appeared, it was "blocked".
> >
> > As I wrote, I didn't find anything changing the global state, which is actually
> > used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It
> > looks like the global state is just "blocked" forever - and it is "blocked" as
> > a side-effect of the call to rfkill_init_sw_state (changes permanent=true) and
> > then call to rfkill_register from the acer-wmi driver. I can verify this in
> > the following days (that the global state stays the same all the time).
>
> Well the global state would be changed by the KEY_BLUETOOTH input event.
>
> But like I said, it's tricky in this case because multiple events come
> from the same event source and race against each other.
>
> johannes
My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
when press wifi key. But, as I remember, there have some acer consumer
notebook emit both scancode and wmi event.
New acer-wmi driver will transfer wmi event to keycode (e.g.
KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
receive the key events twice, that means:
global BT block (when system boot) -> BT unblock (from EC scancode) -> BT block (from acer-wmi)
Could you please help me to check?
- If your distro still have HAL, please run:
+ lshal -l -m
+ press BT HW key 1 time
then check does HAL receive KEY_BLUETOOTH twice?
- Or, please try the following patch, it removed
KEY_BLUETOOTH support in acer-wmi. If removed it but the BT killswitch
still can reserve when you press BT HW key, that means not just
acer-wmi emit KEY_BLUETOOTH:
Thank's a lot!
Joey Lee
>From 20b3b8ba26cb37c8a44d11645c2d8d1f5344cfd7 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Date: Thu, 24 Mar 2011 21:07:43 +0800
Subject: [PATCH] remove KEY_BLUETOOTH for testing
Signed-off-by: Lee, Chun-Yi <jlee-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
---
drivers/platform/x86/acer-wmi.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c978470..554ee12 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -102,7 +102,6 @@ enum acer_wmi_event_ids {
static const struct key_entry acer_wmi_keymap[] = {
{KE_KEY, 0x01, {KEY_WLAN} }, /* WiFi */
- {KE_KEY, 0x12, {KEY_BLUETOOTH} }, /* BT */
{KE_KEY, 0x21, {KEY_PROG1} }, /* Backup */
{KE_KEY, 0x22, {KEY_PROG2} }, /* Arcade */
{KE_KEY, 0x23, {KEY_PROG3} }, /* P_Key */
--
1.6.0.2
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
@ 2011-03-24 13:13 ` Joey Lee
0 siblings, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-24 13:13 UTC (permalink / raw)
To: oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, johannes-cdvu00un1VgdHxzADdlk8Q,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Oldřich,
Sorry bother you again, but after discuss with Johannes, he remind me
one import thing: maybe your BT HW key emit scancode and wmi event at
the same time.
於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> Hi Oldřich,
>
> > > Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't
> > > been updated yet, hence registering hci0 as blocked.
> >
> > No, that is not the case. I can play with `rfkill list` immediately after I
> > press the HW bluetooth switch and show that hci0 is not there (still
> > unregistered) while acer-bluetooth is already "unblocked" - I've tried to run
> > `rfkill list` repeatedly manually from console immediately after I pressed the
> > HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0
> > wasn't there. When hci0 appeared, it was "blocked".
> >
> > As I wrote, I didn't find anything changing the global state, which is actually
> > used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It
> > looks like the global state is just "blocked" forever - and it is "blocked" as
> > a side-effect of the call to rfkill_init_sw_state (changes permanent=true) and
> > then call to rfkill_register from the acer-wmi driver. I can verify this in
> > the following days (that the global state stays the same all the time).
>
> Well the global state would be changed by the KEY_BLUETOOTH input event.
>
> But like I said, it's tricky in this case because multiple events come
> from the same event source and race against each other.
>
> johannes
My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
when press wifi key. But, as I remember, there have some acer consumer
notebook emit both scancode and wmi event.
New acer-wmi driver will transfer wmi event to keycode (e.g.
KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
receive the key events twice, that means:
global BT block (when system boot) -> BT unblock (from EC scancode) -> BT block (from acer-wmi)
Could you please help me to check?
- If your distro still have HAL, please run:
+ lshal -l -m
+ press BT HW key 1 time
then check does HAL receive KEY_BLUETOOTH twice?
- Or, please try the following patch, it removed
KEY_BLUETOOTH support in acer-wmi. If removed it but the BT killswitch
still can reserve when you press BT HW key, that means not just
acer-wmi emit KEY_BLUETOOTH:
Thank's a lot!
Joey Lee
From 20b3b8ba26cb37c8a44d11645c2d8d1f5344cfd7 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Date: Thu, 24 Mar 2011 21:07:43 +0800
Subject: [PATCH] remove KEY_BLUETOOTH for testing
Signed-off-by: Lee, Chun-Yi <jlee-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
---
drivers/platform/x86/acer-wmi.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c978470..554ee12 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -102,7 +102,6 @@ enum acer_wmi_event_ids {
static const struct key_entry acer_wmi_keymap[] = {
{KE_KEY, 0x01, {KEY_WLAN} }, /* WiFi */
- {KE_KEY, 0x12, {KEY_BLUETOOTH} }, /* BT */
{KE_KEY, 0x21, {KEY_PROG1} }, /* Backup */
{KE_KEY, 0x22, {KEY_PROG2} }, /* Arcade */
{KE_KEY, 0x23, {KEY_PROG3} }, /* P_Key */
--
1.6.0.2
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-24 12:58 ` Johannes Berg
@ 2011-03-24 13:36 ` Joey Lee
0 siblings, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-24 13:36 UTC (permalink / raw)
To: johannes
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
於 四，2011-03-24 於 13:58 +0100，Johannes Berg 提到：
> Hi,
>
>
> > > So it _does_ store the state? I thought you earlier said it didn't store
> > > it, and when you cold rebooted it was always disabled?
> > >
> >
> > There have 2 different behavior on Acer BIOS:
> > - cold boot (shutdown then power on): BIOS will reset to raw state (WLAN on, BT off, WWAN on)
> > - warm boot (reboot): BIOS will keep last time's state
>
> Yeah but in that case I don't really see the point in making it
> persistent. It's not really persistent anyway, warm reboot just means it
OK, thank's, now I understand the definition to _persistent_.
> was stuck somewhere in memory I guess... I'd not call this persistent,
> and making it not persistent also solves the problem, right?
>
> johannes
>
>
Yes, if we don't set the default initial state to persistent, then can
workaround this issue, and it also can fix the issue when user only
control acer-wmi's state by userland application.
Just hope Oldřich can help to double check does his BT HW key also emit
scancode? I thought the success logic like the following:
After applied my solution + rfkill-input
(already confirm works fine by Oldřich):
initial scancode from EC from wmi event
------------------------------------------------------------------------------------------------------------------------------------------
acer-wmi BLOCK BLOCK(base on global) UNBLOCK
global UNBLOCK BLOCK UNBLOCK
Then it make sense for why Oldřich saw the hci0's killswitch is UNBLOCK.
After confirm that, I will send out patch to mainline and 2.6.38 kernel for
fix BKO#31002.
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <201103242234.03598.oldium.pro@seznam.cz>
@ 2011-03-25 6:29 ` Oldřich Jedlička
[not found] ` <201103242234.03598.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
1 sibling, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-25 6:29 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
My yesterday's e-mail probably didn't pass through the spam checks of mail
server. If anybody needs to look at the missing attachments, I've placed them
at
http://others-misc.oldium.net/attachments.tar.gz
Cheers,
Oldřich.
On Thursday 24 March 2011 22:34:03 Oldřich Jedlička wrote:
> Hi Joey Lee,
>
> I've done some experiments, here are the results.
>
> On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > Hi Oldřich,
> >
> > Sorry bother you again, but after discuss with Johannes, he remind me
> > one import thing: maybe your BT HW key emit scancode and wmi event at
> > the same time.
> >
> > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> >
> > > Hi Oldřich,
> > >
> > > > > Ah. So I guess when hci0 gets registered, the acer rfkill state
> > > > > hasn't been updated yet, hence registering hci0 as blocked.
> > > >
> > > > No, that is not the case. I can play with `rfkill list` immediately
> > > > after I press the HW bluetooth switch and show that hci0 is not there
> > > > (still unregistered) while acer-bluetooth is already "unblocked" -
> > > > I've tried to run `rfkill list` repeatedly manually from console
> > > > immediately after I pressed the HW BT switch and acer-bluetooth was
> > > > "unblocked" several runs while the hci0 wasn't there. When hci0
> > > > appeared, it was "blocked".
> > > >
> > > > As I wrote, I didn't find anything changing the global state, which
> > > > is actually used to "block" the newly appearing hci0 (in the
> > > > rfkill_sync_work method). It looks like the global state is just
> > > > "blocked" forever - and it is "blocked" as a side-effect of the call
> > > > to rfkill_init_sw_state (changes permanent=true) and then call to
> > > > rfkill_register from the acer-wmi driver. I can verify this in the
> > > > following days (that the global state stays the same all the time).
> > >
> > > Well the global state would be changed by the KEY_BLUETOOTH input
> > > event.
> > >
> > > But like I said, it's tricky in this case because multiple events come
> > > from the same event source and race against each other.
> > >
> > > johannes
> >
> > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
> > when press wifi key. But, as I remember, there have some acer consumer
> > notebook emit both scancode and wmi event.
> >
> > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
> >
> > receive the key events twice, that means:
> > global BT block (when system boot) -> BT unblock (from EC scancode) ->
> > BT
> >
> > block (from acer-wmi)
> >
> > Could you please help me to check?
> >
> > - If your distro still have HAL, please run:
> > + lshal -l -m
> > + press BT HW key 1 time
> > then check does HAL receive KEY_BLUETOOTH twice?
>
> I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> monitoring part) when I press once BT HW key is attached. I've also patched
> the kernel to have more debug logging (see the attached diff and log) and
> the result is that the handler method from rfkill/input.c is not called,
> the global state is once set to "blocked" and it keeps like that. I don't
> know why the rfkill_event isn't called when I press the HW BT switch, it
> could be part of my investigations in the following days.
>
> I've attached .config too, if you want to check that I missed something
> that is needed by Acer WMI.
>
> Cheers,
> Oldřich.
>
> > - Or, please try the following patch, it removed
> >
> > KEY_BLUETOOTH support in acer-wmi. If removed it but the BT killswitch
> > still can reserve when you press BT HW key, that means not just
> >
> > acer-wmi emit KEY_BLUETOOTH:
> > Thank's a lot!
> > Joey Lee
> >
> > >From 20b3b8ba26cb37c8a44d11645c2d8d1f5344cfd7 Mon Sep 17 00:00:00 2001
> >
> > From: Lee, Chun-Yi <jlee@novell.com>
> > Date: Thu, 24 Mar 2011 21:07:43 +0800
> > Subject: [PATCH] remove KEY_BLUETOOTH for testing
> >
> >
> > Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
> > ---
> >
> > drivers/platform/x86/acer-wmi.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/platform/x86/acer-wmi.c
> > b/drivers/platform/x86/acer-wmi.c index c978470..554ee12 100644
> > --- a/drivers/platform/x86/acer-wmi.c
> > +++ b/drivers/platform/x86/acer-wmi.c
> > @@ -102,7 +102,6 @@ enum acer_wmi_event_ids {
> >
> > static const struct key_entry acer_wmi_keymap[] = {
> >
> > {KE_KEY, 0x01, {KEY_WLAN} }, /* WiFi */
> >
> > - {KE_KEY, 0x12, {KEY_BLUETOOTH} }, /* BT */
> >
> > {KE_KEY, 0x21, {KEY_PROG1} }, /* Backup */
> > {KE_KEY, 0x22, {KEY_PROG2} }, /* Arcade */
> > {KE_KEY, 0x23, {KEY_PROG3} }, /* P_Key */
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <201103242234.03598.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
@ 2011-03-25 8:13 ` Joey Lee
2011-03-25 19:22 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-25 8:13 UTC (permalink / raw)
To: oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, johannes-cdvu00un1VgdHxzADdlk8Q,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Oldřich,
Per our log.
It's a interesting and weird situation.
Your log subvert my assumption, the BT HW key only emit one
KEY_BLUETOOTH from ec but not from acer-wmi.
於 四，2011-03-24 於 22:34 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> I've done some experiments, here are the results.
>
> On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > Hi Oldřich,
> >
> > Sorry bother you again, but after discuss with Johannes, he remind me
> > one import thing: maybe your BT HW key emit scancode and wmi event at
> > the same time.
> >
> > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> >
> > > Hi Oldřich,
> > >
> > > > > Ah. So I guess when hci0 gets registered, the acer rfkill state
> > > > > hasn't been updated yet, hence registering hci0 as blocked.
> > > >
> > > > No, that is not the case. I can play with `rfkill list` immediately
> > > > after I press the HW bluetooth switch and show that hci0 is not there
> > > > (still unregistered) while acer-bluetooth is already "unblocked" -
> > > > I've tried to run `rfkill list` repeatedly manually from console
> > > > immediately after I pressed the HW BT switch and acer-bluetooth was
> > > > "unblocked" several runs while the hci0 wasn't there. When hci0
> > > > appeared, it was "blocked".
> > > >
> > > > As I wrote, I didn't find anything changing the global state, which is
> > > > actually used to "block" the newly appearing hci0 (in the
> > > > rfkill_sync_work method). It looks like the global state is just
> > > > "blocked" forever - and it is "blocked" as a side-effect of the call
> > > > to rfkill_init_sw_state (changes permanent=true) and then call to
> > > > rfkill_register from the acer-wmi driver. I can verify this in the
> > > > following days (that the global state stays the same all the time).
> > >
> > > Well the global state would be changed by the KEY_BLUETOOTH input event.
> > >
> > > But like I said, it's tricky in this case because multiple events come
> > > from the same event source and race against each other.
> > >
> > > johannes
> >
> > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
> > when press wifi key. But, as I remember, there have some acer consumer
> > notebook emit both scancode and wmi event.
> >
> > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
> > receive the key events twice, that means:
> > global BT block (when system boot) -> BT unblock (from EC scancode) -> BT
> > block (from acer-wmi)
> >
> > Could you please help me to check?
> > - If your distro still have HAL, please run:
> > + lshal -l -m
> > + press BT HW key 1 time
> > then check does HAL receive KEY_BLUETOOTH twice?
>
> I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> monitoring part) when I press once BT HW key is attached. I've also patched
> the kernel to have more debug logging (see the attached diff and log) and the
> result is that the handler method from rfkill/input.c is not called, the
> global state is once set to "blocked" and it keeps like that. I don't know why
> the rfkill_event isn't called when I press the HW BT switch, it could be part
> of my investigations in the following days.
>
> I've attached .config too, if you want to check that I missed something that is
> needed by Acer WMI.
>
> Cheers,
> Oldřich.
>
Per your lshal log, looks like HAL only receive the key event from EC
but didn't have key event from acer-wmi:
*** 22:21:01.310: lshal: device_condition,
udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
condition_name=ButtonPressed
condition_details=bluetooth //it's from standard input
*** 22:21:02.076: lshal: property_modified,
udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetooth_bluetooth, key=killswitch.state
is_removed=false, is_added=false
*** new value: 1 (0x1) (int) //UNBLOCK when you press BT HW key
So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it. I thought your
machine didn't support Acer ACPI event GUIDs. Please dump the dsdt to me, thank's:
acpidump > acpidump.dat
Then, if there only have one KEY_BLUETOOTH, why the global BT state didn't change by
rfill-input? Technically, rfkill-input must receive this key then change global state:
your situation:
initial press HW key
acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
global BLOCK BLOCK (why didn't changed by rfkill-input?)
hci0 none BLOCK (replicate from global)
Like you said, the odd thing is:
"Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your machine?"
We need find out root cause, but I thought my last patch still works to fix your
situation and it make sense for Acer BIOS didn't really persistence devices state.
applied my patch:
initial press HW key
acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
global UNBLOCK UNBLOCK (didn't changed by rfkill-input?)
hci0 none UNBLOCK (replicate from global)
Conclusion...
please kindly help to provide the following information:
- Please provide DSDT to me
+ I want to double check your BIOS didn't support acer wmi event.
- Why rfkill-input didn't call by BT HW key?
+ please remember disable urfkill daemon, it might disabled rfkill-input!
+ please provide dmesg and messages log to me
Thank's a lot!
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-25 8:13 ` Joey Lee
@ 2011-03-25 19:22 ` Oldřich Jedlička
2011-03-25 22:35 ` Joey Lee
[not found] ` <201103252022.26766.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
0 siblings, 2 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-25 19:22 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Hi Joey Lee,
On Friday 25 March 2011 09:13:20 Joey Lee wrote:
> Hi Oldřich,
>
> Per our log.
> It's a interesting and weird situation.
>
> Your log subvert my assumption, the BT HW key only emit one
> KEY_BLUETOOTH from ec but not from acer-wmi.
>
> 於 四，2011-03-24 於 22:34 +0100，Oldřich Jedlička 提到：
>
> > Hi Joey Lee,
> >
> > I've done some experiments, here are the results.
> >
> > On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > > Hi Oldřich,
> > >
> > > Sorry bother you again, but after discuss with Johannes, he remind me
> > > one import thing: maybe your BT HW key emit scancode and wmi event at
> > > the same time.
> > >
> > > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> > >
> > > > Hi Oldřich,
> > > >
> > > > > > Ah. So I guess when hci0 gets registered, the acer rfkill state
> > > > > > hasn't been updated yet, hence registering hci0 as blocked.
> > > > >
> > > > > No, that is not the case. I can play with `rfkill list` immediately
> > > > > after I press the HW bluetooth switch and show that hci0 is not
> > > > > there (still unregistered) while acer-bluetooth is already
> > > > > "unblocked" - I've tried to run `rfkill list` repeatedly manually
> > > > > from console immediately after I pressed the HW BT switch and
> > > > > acer-bluetooth was "unblocked" several runs while the hci0 wasn't
> > > > > there. When hci0 appeared, it was "blocked".
> > > > >
> > > > > As I wrote, I didn't find anything changing the global state, which
> > > > > is actually used to "block" the newly appearing hci0 (in the
> > > > > rfkill_sync_work method). It looks like the global state is just
> > > > > "blocked" forever - and it is "blocked" as a side-effect of the
> > > > > call to rfkill_init_sw_state (changes permanent=true) and then
> > > > > call to rfkill_register from the acer-wmi driver. I can verify
> > > > > this in the following days (that the global state stays the same
> > > > > all the time).
> > > >
> > > > Well the global state would be changed by the KEY_BLUETOOTH input
> > > > event.
> > > >
> > > > But like I said, it's tricky in this case because multiple events
> > > > come from the same event source and race against each other.
> > > >
> > > > johannes
> > >
> > > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
> > > when press wifi key. But, as I remember, there have some acer consumer
> > > notebook emit both scancode and wmi event.
> > >
> > > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
> > >
> > > receive the key events twice, that means:
> > > global BT block (when system boot) -> BT unblock (from EC scancode)
->
> > > BT
> > >
> > > block (from acer-wmi)
> > >
> > > Could you please help me to check?
> > >
> > > - If your distro still have HAL, please run:
> > > + lshal -l -m
> > > + press BT HW key 1 time
> > > then check does HAL receive KEY_BLUETOOTH twice?
> >
> > I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> > monitoring part) when I press once BT HW key is attached. I've also
> > patched the kernel to have more debug logging (see the attached diff and
> > log) and the result is that the handler method from rfkill/input.c is
> > not called, the global state is once set to "blocked" and it keeps like
> > that. I don't know why the rfkill_event isn't called when I press the HW
> > BT switch, it could be part of my investigations in the following days.
> >
> > I've attached .config too, if you want to check that I missed something
> > that is needed by Acer WMI.
> >
> > Cheers,
> > Oldřich.
>
> Per your lshal log, looks like HAL only receive the key event from EC
> but didn't have key event from acer-wmi:
>
> *** 22:21:01.310: lshal: device_condition,
> udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_i
> nput condition_name=ButtonPressed
> condition_details=bluetooth //it's from standard
input
>
> *** 22:21:02.076: lshal: property_modified,
> udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetooth_bl
> uetooth, key=killswitch.state is_removed=false, is_added=false
> *** new value: 1 (0x1) (int) //UNBLOCK when you press BT HW
key
>
>
> So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it. I
> thought your machine didn't support Acer ACPI event GUIDs. Please dump the
> dsdt to me, thank's: acpidump > acpidump.dat
>
> Then, if there only have one KEY_BLUETOOTH, why the global BT state didn't
> change by rfill-input? Technically, rfkill-input must receive this key
> then change global state:
>
> your situation:
> initial press HW key
> acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> global BLOCK BLOCK (why didn't changed by rfkill-input?)
> hci0 none BLOCK (replicate from global)
>
> Like you said, the odd thing is:
> "Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your machine?"
>
> We need find out root cause, but I thought my last patch still works to fix
> your situation and it make sense for Acer BIOS didn't really persistence
> devices state.
>
> applied my patch:
> initial press HW key
> acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> global UNBLOCK UNBLOCK (didn't changed by rfkill-input?)
> hci0 none UNBLOCK (replicate from global)
>
>
> Conclusion...
> please kindly help to provide the following information:
>
> - Please provide DSDT to me
> + I want to double check your BIOS didn't support acer wmi event.
>
> - Why rfkill-input didn't call by BT HW key?
> + please remember disable urfkill daemon, it might disabled rfkill-input!
> + please provide dmesg and messages log to me
Here you are (dmesg, /var/log/messages, acpidump):
http://others-misc.oldium.net/dump.tar.gz
I hope this finally helps to find something :-)
Cheers,
Oldřich.
>
>
> Thank's a lot!
> Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-25 19:22 ` Oldřich Jedlička
@ 2011-03-25 22:35 ` Joey Lee
2011-03-27 17:09 ` Dmitry Torokhov
[not found] ` <201103252022.26766.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
1 sibling, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-25 22:35 UTC (permalink / raw)
To: dmitry.torokhov, oldium.pro
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-input, platform-driver-x86
Removed bluetooth kernel mail for this issue not actually related to
bluetooth.
Added Dmitry Torokhov and linux-input@vger.kernel.org
Hi Oldřich,
於 五，2011-03-25 於 20:22 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> On Friday 25 March 2011 09:13:20 Joey Lee wrote:
> > Hi Oldřich,
> >
> > Per our log.
> > It's a interesting and weird situation.
> >
> > Your log subvert my assumption, the BT HW key only emit one
> > KEY_BLUETOOTH from ec but not from acer-wmi.
> >
> > 於 四，2011-03-24 於 22:34 +0100，Oldřich Jedlička 提到：
> >
> > > Hi Joey Lee,
> > >
> > > I've done some experiments, here are the results.
> > >
> > > On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > > > Hi Oldřich,
> > > >
> > > > Sorry bother you again, but after discuss with Johannes, he remind me
> > > > one import thing: maybe your BT HW key emit scancode and wmi event at
> > > > the same time.
> > > >
> > > > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> > > >
> > > > > Hi Oldřich,
> > > > >
> > > > > > > Ah. So I guess when hci0 gets registered, the acer rfkill state
> > > > > > > hasn't been updated yet, hence registering hci0 as blocked.
> > > > > >
> > > > > > No, that is not the case. I can play with `rfkill list` immediately
> > > > > > after I press the HW bluetooth switch and show that hci0 is not
> > > > > > there (still unregistered) while acer-bluetooth is already
> > > > > > "unblocked" - I've tried to run `rfkill list` repeatedly manually
> > > > > > from console immediately after I pressed the HW BT switch and
> > > > > > acer-bluetooth was "unblocked" several runs while the hci0 wasn't
> > > > > > there. When hci0 appeared, it was "blocked".
> > > > > >
> > > > > > As I wrote, I didn't find anything changing the global state, which
> > > > > > is actually used to "block" the newly appearing hci0 (in the
> > > > > > rfkill_sync_work method). It looks like the global state is just
> > > > > > "blocked" forever - and it is "blocked" as a side-effect of the
> > > > > > call to rfkill_init_sw_state (changes permanent=true) and then
> > > > > > call to rfkill_register from the acer-wmi driver. I can verify
> > > > > > this in the following days (that the global state stays the same
> > > > > > all the time).
> > > > >
> > > > > Well the global state would be changed by the KEY_BLUETOOTH input
> > > > > event.
> > > > >
> > > > > But like I said, it's tricky in this case because multiple events
> > > > > come from the same event source and race against each other.
> > > > >
> > > > > johannes
> > > >
> > > > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
> > > > when press wifi key. But, as I remember, there have some acer consumer
> > > > notebook emit both scancode and wmi event.
> > > >
> > > > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > > > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
> > > >
> > > > receive the key events twice, that means:
> > > > global BT block (when system boot) -> BT unblock (from EC scancode)
> ->
> > > > BT
> > > >
> > > > block (from acer-wmi)
> > > >
> > > > Could you please help me to check?
> > > >
> > > > - If your distro still have HAL, please run:
> > > > + lshal -l -m
> > > > + press BT HW key 1 time
> > > > then check does HAL receive KEY_BLUETOOTH twice?
> > >
> > > I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> > > monitoring part) when I press once BT HW key is attached. I've also
> > > patched the kernel to have more debug logging (see the attached diff and
> > > log) and the result is that the handler method from rfkill/input.c is
> > > not called, the global state is once set to "blocked" and it keeps like
> > > that. I don't know why the rfkill_event isn't called when I press the HW
> > > BT switch, it could be part of my investigations in the following days.
> > >
> > > I've attached .config too, if you want to check that I missed something
> > > that is needed by Acer WMI.
> > >
> > > Cheers,
> > > Oldřich.
> >
> > Per your lshal log, looks like HAL only receive the key event from EC
> > but didn't have key event from acer-wmi:
> >
> > *** 22:21:01.310: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_i
> > nput condition_name=ButtonPressed
> > condition_details=bluetooth //it's from standard
> input
> >
> > *** 22:21:02.076: lshal: property_modified,
> > udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetooth_bl
> > uetooth, key=killswitch.state is_removed=false, is_added=false
> > *** new value: 1 (0x1) (int) //UNBLOCK when you press BT HW
> key
> >
> >
> > So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it. I
> > thought your machine didn't support Acer ACPI event GUIDs. Please dump the
> > dsdt to me, thank's: acpidump > acpidump.dat
> >
> > Then, if there only have one KEY_BLUETOOTH, why the global BT state didn't
> > change by rfill-input? Technically, rfkill-input must receive this key
> > then change global state:
> >
> > your situation:
> > initial press HW key
> > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > global BLOCK BLOCK (why didn't changed by rfkill-input?)
> > hci0 none BLOCK (replicate from global)
> >
> > Like you said, the odd thing is:
> > "Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your machine?"
> >
> > We need find out root cause, but I thought my last patch still works to fix
> > your situation and it make sense for Acer BIOS didn't really persistence
> > devices state.
> >
> > applied my patch:
> > initial press HW key
> > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > global UNBLOCK UNBLOCK (didn't changed by rfkill-input?)
> > hci0 none UNBLOCK (replicate from global)
> >
> >
> > Conclusion...
> > please kindly help to provide the following information:
> >
> > - Please provide DSDT to me
> > + I want to double check your BIOS didn't support acer wmi event.
> >
> > - Why rfkill-input didn't call by BT HW key?
> > + please remember disable urfkill daemon, it might disabled rfkill-input!
> > + please provide dmesg and messages log to me
>
> Here you are (dmesg, /var/log/messages, acpidump):
>
> http://others-misc.oldium.net/dump.tar.gz
>
> I hope this finally helps to find something :-)
>
> Cheers,
> Oldřich.
>
Thank's for your information, I will look at it.
Finally,
I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
situation.
The BAD thing is you are right,
I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
because rfkill-input registered input handler.
The BT HW key still works because acer-wmi have polling to sync the
state with EC and killswitch, and EC also take care the BT device power
off job.
But, I also found SOMETIMES after system reboot, rfkill-input can
capture the key event.
We need find out why input handle didn't receive KEY_* event.
Hi, Dmitry
Appreciate if you can give us any good suggestions!
Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
handler, can't capture it?
*** 06:32:42.972: lshal: device_condition,
udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
condition_name=ButtonPressed
condition_details=bluetooth
But, SOMETIMES after reboot system, rfkill-input can capture the key.
We are working on 2.6.38 kernel, and Acer notebook.
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-25 22:35 ` Joey Lee
@ 2011-03-27 17:09 ` Dmitry Torokhov
2011-03-28 8:51 ` Joey Lee
2011-03-31 5:23 ` Oldřich Jedlička
0 siblings, 2 replies; 48+ messages in thread
From: Dmitry Torokhov @ 2011-03-27 17:09 UTC (permalink / raw)
To: Joey Lee
Cc: oldium.pro, davem, marcel, Al Cho, Gary Lin, johannes, mjg59,
linux-acpi, linux-input, platform-driver-x86
On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
>
> Thank's for your information, I will look at it.
>
> Finally,
> I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> situation.
>
> The BAD thing is you are right,
> I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> because rfkill-input registered input handler.
>
> The BT HW key still works because acer-wmi have polling to sync the
> state with EC and killswitch, and EC also take care the BT device power
> off job.
>
> But, I also found SOMETIMES after system reboot, rfkill-input can
> capture the key event.
> We need find out why input handle didn't receive KEY_* event.
>
>
> Hi, Dmitry
>
> Appreciate if you can give us any good suggestions!
> Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> handler, can't capture it?
>
> *** 06:32:42.972: lshal: device_condition,
> udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
> condition_name=ButtonPressed
> condition_details=bluetooth
>
> But, SOMETIMES after reboot system, rfkill-input can capture the key.
> We are working on 2.6.38 kernel, and Acer notebook.
Hi Joey,
If you look in /proc/bus/input/devices do you see rfkill-input as
actually bound to the device that has KEY_BLUETOOTH?
Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
the default keymap I think you must be loading Acer-specific keymap via
udev or some other mechanism, and I guess stumbling upon a deficiency in
input layer: we do not re-match devices after changing keymap. So if
rfkill-input was loaded before keymap was altered, then it will not bind
to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
this is something that was on my TODO list for a while now...
Thaks.
--
Dmitry
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-27 17:09 ` Dmitry Torokhov
@ 2011-03-28 8:51 ` Joey Lee
2011-03-31 5:23 ` Oldřich Jedlička
1 sibling, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-28 8:51 UTC (permalink / raw)
To: dmitry.torokhov
Cc: davem, marcel, Al Cho, Gary Lin, oldium.pro, johannes, mjg59,
linux-acpi, linux-input, platform-driver-x86
Hi Dmitry,
於 日，2011-03-27 於 10:09 -0700，Dmitry Torokhov 提到：
> On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> >
> > Thank's for your information, I will look at it.
> >
> > Finally,
> > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> > situation.
> >
> > The BAD thing is you are right,
> > I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> > because rfkill-input registered input handler.
> >
> > The BT HW key still works because acer-wmi have polling to sync the
> > state with EC and killswitch, and EC also take care the BT device power
> > off job.
> >
> > But, I also found SOMETIMES after system reboot, rfkill-input can
> > capture the key event.
> > We need find out why input handle didn't receive KEY_* event.
> >
> >
> > Hi, Dmitry
> >
> > Appreciate if you can give us any good suggestions!
> > Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> > handler, can't capture it?
> >
> > *** 06:32:42.972: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
> > condition_name=ButtonPressed
> > condition_details=bluetooth
> >
> > But, SOMETIMES after reboot system, rfkill-input can capture the key.
> > We are working on 2.6.38 kernel, and Acer notebook.
>
> Hi Joey,
>
> If you look in /proc/bus/input/devices do you see rfkill-input as
> actually bound to the device that has KEY_BLUETOOTH?
>
Like you said, we fell into the trap:
Fail case:
linux-uy92:/proc/bus/input # vi devices
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
Success case:
linux-uy92:/proc/bus/input # vi devices
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0 rfkill
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
In fail case, rfkill didn't register to keyboard's Handlers. And, I also
checked the rfkill-input's .connect didn't call by input when system
boot:
Fail case:
[ 7.144252] rfkill: rfkill_handler_init
[ 7.144277] rfkill: rfkill_handler_init, start input_register_handler
Success case:
[ 7.580683] rfkill: rfkill_handler_init
[ 7.580714] rfkill: rfkill_handler_init, start input_register_handler
[ 7.580737] rfkill: doing input_register_handle
> Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
> the default keymap I think you must be loading Acer-specific keymap via
> udev or some other mechanism, and I guess stumbling upon a deficiency in
> input layer: we do not re-match devices after changing keymap. So if
> rfkill-input was loaded before keymap was altered, then it will not bind
> to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
> this is something that was on my TODO list for a while now...
>
> Thaks.
>
Yes,
this a race condition for rfkill-input register before udev set
Acer-specific keymap.
We didn't find it just because old acer-wmi driver hide the BIOS default
devices states and always set bluetooth state to enabled when system
boot.
Thank's
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <201103252022.26766.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
@ 2011-03-28 9:04 ` Joey Lee
2011-03-30 18:49 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-28 9:04 UTC (permalink / raw)
To: oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, marcel-kz+m5ild9QBg9hUCZPvPmw,
Al Cho, Gary Lin, johannes-cdvu00un1VgdHxzADdlk8Q,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Hi Oldřic,
於 五，2011-03-25 於 20:22 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> On Friday 25 March 2011 09:13:20 Joey Lee wrote:
> > Hi Oldřich,
> >
> > Per our log.
> > It's a interesting and weird situation.
> >
> > Your log subvert my assumption, the BT HW key only emit one
> > KEY_BLUETOOTH from ec but not from acer-wmi.
> >
> > 於 四，2011-03-24 於 22:34 +0100，Oldřich Jedlička 提到：
> >
> > > Hi Joey Lee,
> > >
> > > I've done some experiments, here are the results.
> > >
> > > On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > > > Hi Oldřich,
> > > >
> > > > Sorry bother you again, but after discuss with Johannes, he remind me
> > > > one import thing: maybe your BT HW key emit scancode and wmi event at
> > > > the same time.
> > > >
> > > > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> > > >
> > > > > Hi Oldřich,
> > > > >
> > > > > > > Ah. So I guess when hci0 gets registered, the acer rfkill state
> > > > > > > hasn't been updated yet, hence registering hci0 as blocked.
> > > > > >
> > > > > > No, that is not the case. I can play with `rfkill list` immediately
> > > > > > after I press the HW bluetooth switch and show that hci0 is not
> > > > > > there (still unregistered) while acer-bluetooth is already
> > > > > > "unblocked" - I've tried to run `rfkill list` repeatedly manually
> > > > > > from console immediately after I pressed the HW BT switch and
> > > > > > acer-bluetooth was "unblocked" several runs while the hci0 wasn't
> > > > > > there. When hci0 appeared, it was "blocked".
> > > > > >
> > > > > > As I wrote, I didn't find anything changing the global state, which
> > > > > > is actually used to "block" the newly appearing hci0 (in the
> > > > > > rfkill_sync_work method). It looks like the global state is just
> > > > > > "blocked" forever - and it is "blocked" as a side-effect of the
> > > > > > call to rfkill_init_sw_state (changes permanent=true) and then
> > > > > > call to rfkill_register from the acer-wmi driver. I can verify
> > > > > > this in the following days (that the global state stays the same
> > > > > > all the time).
> > > > >
> > > > > Well the global state would be changed by the KEY_BLUETOOTH input
> > > > > event.
> > > > >
> > > > > But like I said, it's tricky in this case because multiple events
> > > > > come from the same event source and race against each other.
> > > > >
> > > > > johannes
> > > >
> > > > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event
> > > > when press wifi key. But, as I remember, there have some acer consumer
> > > > notebook emit both scancode and wmi event.
> > > >
> > > > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > > > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will
> > > >
> > > > receive the key events twice, that means:
> > > > global BT block (when system boot) -> BT unblock (from EC scancode)
> ->
> > > > BT
> > > >
> > > > block (from acer-wmi)
> > > >
> > > > Could you please help me to check?
> > > >
> > > > - If your distro still have HAL, please run:
> > > > + lshal -l -m
> > > > + press BT HW key 1 time
> > > > then check does HAL receive KEY_BLUETOOTH twice?
> > >
> > > I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> > > monitoring part) when I press once BT HW key is attached. I've also
> > > patched the kernel to have more debug logging (see the attached diff and
> > > log) and the result is that the handler method from rfkill/input.c is
> > > not called, the global state is once set to "blocked" and it keeps like
> > > that. I don't know why the rfkill_event isn't called when I press the HW
> > > BT switch, it could be part of my investigations in the following days.
> > >
> > > I've attached .config too, if you want to check that I missed something
> > > that is needed by Acer WMI.
> > >
> > > Cheers,
> > > Oldřich.
> >
> > Per your lshal log, looks like HAL only receive the key event from EC
> > but didn't have key event from acer-wmi:
> >
> > *** 22:21:01.310: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_i
> > nput condition_name=ButtonPressed
> > condition_details=bluetooth //it's from standard
> input
> >
> > *** 22:21:02.076: lshal: property_modified,
> > udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetooth_bl
> > uetooth, key=killswitch.state is_removed=false, is_added=false
> > *** new value: 1 (0x1) (int) //UNBLOCK when you press BT HW
> key
> >
> >
> > So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it. I
> > thought your machine didn't support Acer ACPI event GUIDs. Please dump the
> > dsdt to me, thank's: acpidump > acpidump.dat
> >
> > Then, if there only have one KEY_BLUETOOTH, why the global BT state didn't
> > change by rfill-input? Technically, rfkill-input must receive this key
> > then change global state:
> >
> > your situation:
> > initial press HW key
> > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > global BLOCK BLOCK (why didn't changed by rfkill-input?)
> > hci0 none BLOCK (replicate from global)
> >
> > Like you said, the odd thing is:
> > "Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your machine?"
> >
> > We need find out root cause, but I thought my last patch still works to fix
> > your situation and it make sense for Acer BIOS didn't really persistence
> > devices state.
> >
> > applied my patch:
> > initial press HW key
> > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > global UNBLOCK UNBLOCK (didn't changed by rfkill-input?)
> > hci0 none UNBLOCK (replicate from global)
> >
> >
> > Conclusion...
> > please kindly help to provide the following information:
> >
> > - Please provide DSDT to me
> > + I want to double check your BIOS didn't support acer wmi event.
> >
> > - Why rfkill-input didn't call by BT HW key?
> > + please remember disable urfkill daemon, it might disabled rfkill-input!
> > + please provide dmesg and messages log to me
>
> Here you are (dmesg, /var/log/messages, acpidump):
>
> http://others-misc.oldium.net/dump.tar.gz
>
> I hope this finally helps to find something :-)
>
> Cheers,
> Oldřich.
>
I sand out patch to platform driver group for review:
0001-acer-wmi-does-not-set-persistence-state-by-rfkill_i.patch
And added comment on bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=31002#c12
Thank's
Joey Lee
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-28 9:04 ` Joey Lee
@ 2011-03-30 18:49 ` Oldřich Jedlička
0 siblings, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-30 18:49 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, alan-jenkins,
linux-acpi, linux-bluetooth, platform-driver-x86
Ho Joey Lee,
On Monday 28 March 2011 11:04:32 Joey Lee wrote:
> Hi Oldřic,
>
> 於 五，2011-03-25 於 20:22 +0100，Oldřich Jedlička 提到：
>
> > Hi Joey Lee,
> >
> > On Friday 25 March 2011 09:13:20 Joey Lee wrote:
> > > Hi Oldřich,
> > >
> > > Per our log.
> > > It's a interesting and weird situation.
> > >
> > > Your log subvert my assumption, the BT HW key only emit one
> > > KEY_BLUETOOTH from ec but not from acer-wmi.
> > >
> > > 於 四，2011-03-24 於 22:34 +0100，Oldřich Jedlička 提到：
> > >
> > > > Hi Joey Lee,
> > > >
> > > > I've done some experiments, here are the results.
> > > >
> > > > On Thursday 24 March 2011 14:13:29 Joey Lee wrote:
> > > > > Hi Oldřich,
> > > > >
> > > > > Sorry bother you again, but after discuss with Johannes, he remind
> > > > > me one import thing: maybe your BT HW key emit scancode and wmi
> > > > > event at the same time.
> > > > >
> > > > > 於 四，2011-03-24 於 09:36 +0100，Johannes Berg 提到：
> > > > >
> > > > > > Hi Oldřich,
> > > > > >
> > > > > > > > Ah. So I guess when hci0 gets registered, the acer rfkill
> > > > > > > > state hasn't been updated yet, hence registering hci0 as
> > > > > > > > blocked.
> > > > > > >
> > > > > > > No, that is not the case. I can play with `rfkill list`
> > > > > > > immediately after I press the HW bluetooth switch and show
> > > > > > > that hci0 is not there (still unregistered) while
> > > > > > > acer-bluetooth is already "unblocked" - I've tried to run
> > > > > > > `rfkill list` repeatedly manually from console immediately
> > > > > > > after I pressed the HW BT switch and acer-bluetooth was
> > > > > > > "unblocked" several runs while the hci0 wasn't there. When
> > > > > > > hci0 appeared, it was "blocked".
> > > > > > >
> > > > > > > As I wrote, I didn't find anything changing the global state,
> > > > > > > which is actually used to "block" the newly appearing hci0 (in
> > > > > > > the rfkill_sync_work method). It looks like the global state
> > > > > > > is just "blocked" forever - and it is "blocked" as a
> > > > > > > side-effect of the call to rfkill_init_sw_state (changes
> > > > > > > permanent=true) and then call to rfkill_register from the
> > > > > > > acer-wmi driver. I can verify this in the following days (that
> > > > > > > the global state stays the same all the time).
> > > > > >
> > > > > > Well the global state would be changed by the KEY_BLUETOOTH input
> > > > > > event.
> > > > > >
> > > > > > But like I said, it's tricky in this case because multiple events
> > > > > > come from the same event source and race against each other.
> > > > > >
> > > > > > johannes
> > > > >
> > > > > My Acer TravelMate 8572 is commercial notebook, it only emit wmi
> > > > > event when press wifi key. But, as I remember, there have some
> > > > > acer consumer notebook emit both scancode and wmi event.
> > > > >
> > > > > New acer-wmi driver will transfer wmi event to keycode (e.g.
> > > > > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input
> > > > > will
> > > > >
> > > > > receive the key events twice, that means:
> > > > > global BT block (when system boot) -> BT unblock (from EC
> > > > > scancode)
> >
> > ->
> >
> > > > > BT
> > > > >
> > > > > block (from acer-wmi)
> > > > >
> > > > > Could you please help me to check?
> > > > >
> > > > > - If your distro still have HAL, please run:
> > > > > + lshal -l -m
> > > > > + press BT HW key 1 time
> > > > > then check does HAL receive KEY_BLUETOOTH twice?
> > > >
> > > > I didn't uninstall hal yet, so the output of `lshal -l -m` (only the
> > > > monitoring part) when I press once BT HW key is attached. I've also
> > > > patched the kernel to have more debug logging (see the attached diff
> > > > and log) and the result is that the handler method from
> > > > rfkill/input.c is not called, the global state is once set to
> > > > "blocked" and it keeps like that. I don't know why the rfkill_event
> > > > isn't called when I press the HW BT switch, it could be part of my
> > > > investigations in the following days.
> > > >
> > > > I've attached .config too, if you want to check that I missed
> > > > something that is needed by Acer WMI.
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > Per your lshal log, looks like HAL only receive the key event from EC
> > > but didn't have key event from acer-wmi:
> > >
> > > *** 22:21:01.310: lshal: device_condition,
> > > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicald
> > > ev_i nput condition_name=ButtonPressed
> > >
> > > condition_details=bluetooth //it's from standard
> >
> > input
> >
> > > *** 22:21:02.076: lshal: property_modified,
> > > udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetoot
> > > h_bl uetooth, key=killswitch.state is_removed=false, is_added=false ***
> > > new value: 1 (0x1) (int) //UNBLOCK when you press BT HW
> >
> > key
> >
> > > So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it.
> > > I thought your machine didn't support Acer ACPI event GUIDs. Please
> > > dump the dsdt to me, thank's: acpidump > acpidump.dat
> > >
> > > Then, if there only have one KEY_BLUETOOTH, why the global BT state
> > > didn't change by rfill-input? Technically, rfkill-input must receive
> > > this key then change global state:
> > >
> > > your situation:
> > > initial press HW key
> > >
> > > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > > global BLOCK BLOCK (why didn't changed by rfkill-input?)
> > > hci0 none BLOCK (replicate from global)
> > >
> > > Like you said, the odd thing is:
> > > "Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your
> > > machine?"
> > >
> > > We need find out root cause, but I thought my last patch still works to
> > > fix your situation and it make sense for Acer BIOS didn't really
> > > persistence devices state.
> > >
> > > applied my patch:
> > > initial press HW key
> > >
> > > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling)
> > > global UNBLOCK UNBLOCK (didn't changed by rfkill-input?)
> > > hci0 none UNBLOCK (replicate from global)
> > >
> > >
> > > Conclusion...
> > >
> > > please kindly help to provide the following information:
> > > - Please provide DSDT to me
> > >
> > > + I want to double check your BIOS didn't support acer wmi event.
> > >
> > > - Why rfkill-input didn't call by BT HW key?
> > >
> > > + please remember disable urfkill daemon, it might disabled
> > > rfkill-input! + please provide dmesg and messages log to me
> >
> > Here you are (dmesg, /var/log/messages, acpidump):
> > http://others-misc.oldium.net/dump.tar.gz
> >
> > I hope this finally helps to find something :-)
> >
> > Cheers,
> > Oldřich.
>
> I sand out patch to platform driver group for review:
> 0001-acer-wmi-does-not-set-persistence-state-by-rfkill_i.patch
>
> And added comment on bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=31002#c12
Works for me, I've put a comment on the bugreport.
Cheers,
Oldřich.
> Thank's
> Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-27 17:09 ` Dmitry Torokhov
2011-03-28 8:51 ` Joey Lee
@ 2011-03-31 5:23 ` Oldřich Jedlička
[not found] ` <AANLkTi=QREK2r6zbvo6RyTNMG4=NCf+kCUWi52ZwjOhS@mail.gmail.com>
1 sibling, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-31 5:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Joey Lee, davem, marcel, Al Cho, Gary Lin, johannes, mjg59,
linux-acpi, linux-input, platform-driver-x86
Hi Dmitry,
On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > Thank's for your information, I will look at it.
> >
> > Finally,
> > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> > situation.
> >
> > The BAD thing is you are right,
> > I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> > because rfkill-input registered input handler.
> >
> > The BT HW key still works because acer-wmi have polling to sync the
> > state with EC and killswitch, and EC also take care the BT device power
> > off job.
> >
> > But, I also found SOMETIMES after system reboot, rfkill-input can
> > capture the key event.
> > We need find out why input handle didn't receive KEY_* event.
> >
> >
> > Hi, Dmitry
> >
> > Appreciate if you can give us any good suggestions!
> > Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> > handler, can't capture it?
> >
> > *** 06:32:42.972: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > _input
> >
> > condition_name=ButtonPressed
> > condition_details=bluetooth
> >
> > But, SOMETIMES after reboot system, rfkill-input can capture the key.
> > We are working on 2.6.38 kernel, and Acer notebook.
>
> Hi Joey,
>
> If you look in /proc/bus/input/devices do you see rfkill-input as
> actually bound to the device that has KEY_BLUETOOTH?
>
> Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
> the default keymap I think you must be loading Acer-specific keymap via
> udev or some other mechanism, and I guess stumbling upon a deficiency in
> input layer: we do not re-match devices after changing keymap. So if
> rfkill-input was loaded before keymap was altered, then it will not bind
> to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
> this is something that was on my TODO list for a while now...
Verified - I tried to compile rfkill as module as you recommended (on personal
e-mail). I had to reload rfkill after startup to have rfkill listening. So
this part looks clear on what happens.
@Joey Lee: There are other strange situations when I have rfkill as a module
and don't have acer-wmi loaded (every second try hci0 rfkill is blocked, the
other try it is unblocked) and more strange situation is when acer-wmi gets
loaded (accidentally I've tried it when the BT hci0 was up and running) - the
BT switch brings hci0 to light after the second press (no action on the first
one), next press switched it off. I was able to reproduce both "problems"
several times with no randomness in it.
Cheers,
Oldřich.
>
> Thaks.
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
[not found] ` <AANLkTi=QREK2r6zbvo6RyTNMG4=NCf+kCUWi52ZwjOhS@mail.gmail.com>
@ 2011-03-31 7:51 ` Joey Lee
2011-03-31 8:09 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-31 7:51 UTC (permalink / raw)
To: oldium.pro
Cc: davem, dmitry.torokhov, marcel, Al Cho, Gary Lin, johannes,
mjg59, linux-acpi, linux-input, platform-driver-x86
Hi Oldřich,
於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> Hi Dmitry,
>
> On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > > Thank's for your information, I will look at it.
> > >
> > > Finally,
> > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
> your
> > > situation.
> > >
> > > The BAD thing is you are right,
> > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> not make sense
> > > because rfkill-input registered input handler.
> > >
> > > The BT HW key still works because acer-wmi have polling to
> sync the
> > > state with EC and killswitch, and EC also take care the BT
> device power
> > > off job.
> > >
> > > But, I also found SOMETIMES after system reboot,
> rfkill-input can
> > > capture the key event.
> > > We need find out why input handle didn't receive KEY_*
> event.
> > >
> > >
> > > Hi, Dmitry
> > >
> > > Appreciate if you can give us any good suggestions!
> > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> registered input
> > > handler, can't capture it?
> > >
>
> > > *** 06:32:42.972: lshal: device_condition,
> > >
> udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > > _input
> > >
> > > condition_name=ButtonPressed
> > > condition_details=bluetooth
> > >
>
> > > But, SOMETIMES after reboot system, rfkill-input can
> capture the key.
> > > We are working on 2.6.38 kernel, and Acer notebook.
> >
> > Hi Joey,
> >
> > If you look in /proc/bus/input/devices do you see
> rfkill-input as
> > actually bound to the device that has KEY_BLUETOOTH?
> >
>
> > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> key is not in
> > the default keymap I think you must be loading Acer-specific
> keymap via
> > udev or some other mechanism, and I guess stumbling upon a
> deficiency in
> > input layer: we do not re-match devices after changing
> keymap. So if
> > rfkill-input was loaded before keymap was altered, then it
> will not bind
> > to the keyboard even if you add KE_BLUETOOTH at a later
> time. Fixing
> > this is something that was on my TODO list for a while
> now...
>
>
> Verified - I tried to compile rfkill as module as you
> recommended (on personal
> e-mail). I had to reload rfkill after startup to have rfkill
> listening. So
> this part looks clear on what happens.
>
> @Joey Lee: There are other strange situations when I have
> rfkill as a module
> and don't have acer-wmi loaded (every second try hci0 rfkill
> is blocked, the
> other try it is unblocked) and more strange situation is when
> acer-wmi gets
> loaded (accidentally I've tried it when the BT hci0 was up and
> running) - the
> BT switch brings hci0 to light after the second press (no
> action on the first
> one), next press switched it off. I was able to reproduce both
> "problems"
> several times with no randomness in it.
>
> Sorry, that was probably caused by the fact that the bluetooth
> on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> instead of bluetooth). I have the updated keymap already, but it
> doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> keymap later too.
>
> Cheers,
> Oldřich.
>
Yes, I just also simply try, the EC emit key priority is:
KEY_BLUETOOTH
KEY_BRIGHTNESSUP
KEY_BLUETOOTH
KEY_BLUETOOTH
You are right, maybe the keymaping have problem on speciall acer
notebook, I will also try.
Thank's
Joey Lee
> Cheers,
> Oldřich.
>
> >
> > Thaks.
>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-31 7:51 ` Joey Lee
@ 2011-03-31 8:09 ` Joey Lee
2011-03-31 9:10 ` Joey Lee
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-31 8:09 UTC (permalink / raw)
To: oldium.pro
Cc: davem, dmitry.torokhov, marcel, Al Cho, Gary Lin, johannes,
mjg59, linux-acpi, linux-input, platform-driver-x86
於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> Hi Oldřich,
>
> 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > Hi Joey Lee,
> >
> > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> > Hi Dmitry,
> >
> > On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > > > Thank's for your information, I will look at it.
> > > >
> > > > Finally,
> > > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
> > your
> > > > situation.
> > > >
> > > > The BAD thing is you are right,
> > > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> > not make sense
> > > > because rfkill-input registered input handler.
> > > >
> > > > The BT HW key still works because acer-wmi have polling to
> > sync the
> > > > state with EC and killswitch, and EC also take care the BT
> > device power
> > > > off job.
> > > >
> > > > But, I also found SOMETIMES after system reboot,
> > rfkill-input can
> > > > capture the key event.
> > > > We need find out why input handle didn't receive KEY_*
> > event.
> > > >
> > > >
> > > > Hi, Dmitry
> > > >
> > > > Appreciate if you can give us any good suggestions!
> > > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> > registered input
> > > > handler, can't capture it?
> > > >
> >
> > > > *** 06:32:42.972: lshal: device_condition,
> > > >
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > > > _input
> > > >
> > > > condition_name=ButtonPressed
> > > > condition_details=bluetooth
> > > >
> >
> > > > But, SOMETIMES after reboot system, rfkill-input can
> > capture the key.
> > > > We are working on 2.6.38 kernel, and Acer notebook.
> > >
> > > Hi Joey,
> > >
> > > If you look in /proc/bus/input/devices do you see
> > rfkill-input as
> > > actually bound to the device that has KEY_BLUETOOTH?
> > >
> >
> > > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> > key is not in
> > > the default keymap I think you must be loading Acer-specific
> > keymap via
> > > udev or some other mechanism, and I guess stumbling upon a
> > deficiency in
> > > input layer: we do not re-match devices after changing
> > keymap. So if
> > > rfkill-input was loaded before keymap was altered, then it
> > will not bind
> > > to the keyboard even if you add KE_BLUETOOTH at a later
> > time. Fixing
> > > this is something that was on my TODO list for a while
> > now...
> >
> >
> > Verified - I tried to compile rfkill as module as you
> > recommended (on personal
> > e-mail). I had to reload rfkill after startup to have rfkill
> > listening. So
> > this part looks clear on what happens.
> >
> > @Joey Lee: There are other strange situations when I have
> > rfkill as a module
> > and don't have acer-wmi loaded (every second try hci0 rfkill
> > is blocked, the
> > other try it is unblocked) and more strange situation is when
> > acer-wmi gets
> > loaded (accidentally I've tried it when the BT hci0 was up and
> > running) - the
> > BT switch brings hci0 to light after the second press (no
> > action on the first
> > one), next press switched it off. I was able to reproduce both
> > "problems"
> > several times with no randomness> > Sorry, that was probably caused by the fact that the bluetooth
> > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > instead of bluetooth). I have the updated keymap already, but it
> > doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> > keymap later too.
> >
> > Cheers,
> > Oldřich.
> >
>
> Yes, I just also simply try, the EC emit key priority is:
> KEY_BLUETOOTH
> KEY_BRIGHTNESSUP
> KEY_BLUETOOTH
> KEY_BLUETOOTH
>
> You are right, maybe the keymaping have problem on speciall acer
> notebook, I will also try.
>
>
> Thank's
> Joey Lee
>
Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
probe or not.
But, on my Acer AspireOne ZG8, there have no product name in
dmidecode...
Thank's
Joey Lee
> > Cheers,
> > Oldřich.
> >
> > >
> > > Thaks.
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-31 8:09 ` Joey Lee
@ 2011-03-31 9:10 ` Joey Lee
2011-03-31 20:27 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-31 9:10 UTC (permalink / raw)
To: oldium.pro
Cc: davem, dmitry.torokhov, marcel, Al Cho, Gary Lin, johannes,
mjg59, linux-acpi, linux-input, platform-driver-x86
Hi Oldřich,
於 四，2011-03-31 於 02:09 -0600，Joey Lee 提到：
> 於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> > Hi Oldřich,
> >
> > 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > > Hi Joey Lee,
> > >
> > > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> > > Hi Dmitry,
> > >
> > > On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > > > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > > > > Thank's for your information, I will look at it.
> > > > >
> > > > > Finally,
> > > > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
> > > your
> > > > > situation.
> > > > >
> > > > > The BAD thing is you are right,
> > > > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> > > not make sense
> > > > > because rfkill-input registered input handler.
> > > > >
> > > > > The BT HW key still works because acer-wmi have polling to
> > > sync the
> > > > > state with EC and killswitch, and EC also take care the BT
> > > device power
> > > > > off job.
> > > > >
> > > > > But, I also found SOMETIMES after system reboot,
> > > rfkill-input can
> > > > > capture the key event.
> > > > > We need find out why input handle didn't receive KEY_*
> > > event.
> > > > >
> > > > >
> > > > > Hi, Dmitry
> > > > >
> > > > > Appreciate if you can give us any good suggestions!
> > > > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> > > registered input
> > > > > handler, can't capture it?
> > > > >
> > >
> > > > > *** 06:32:42.972: lshal: device_condition,
> > > > >
> > > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > > > > _input
> > > > >
> > > > > condition_name=ButtonPressed
> > > > > condition_details=bluetooth
> > > > >
> > >
> > > > > But, SOMETIMES after reboot system, rfkill-input can
> > > capture the key.
> > > > > We are working on 2.6.38 kernel, and Acer notebook.
> > > >
> > > > Hi Joey,
> > > >
> > > > If you look in /proc/bus/input/devices do you see
> > > rfkill-input as
> > > > actually bound to the device that has KEY_BLUETOOTH?
> > > >
> > >
> > > > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> > > key is not in
> > > > the default keymap I think you must be loading Acer-specific
> > > keymap via
> > > > udev or some other mechanism, and I guess stumbling upon a
> > > deficiency in
> > > > input layer: we do not re-match devices after changing
> > > keymap. So if
> > > > rfkill-input was loaded before keymap was altered, then it
> > > will not bind
> > > > to the keyboard even if you add KE_BLUETOOTH at a later
> > > time. Fixing
> > > > this is something that was on my TODO list for a while
> > > now...
> > >
> > >
> > > Verified - I tried to compile rfkill as module as you
> > > recommended (on personal
> > > e-mail). I had to reload rfkill after startup to have rfkill
> > > listening. So
> > > this part looks clear on what happens.
> > >
> > > @Joey Lee: There are other strange situations when I have
> > > rfkill as a module
> > > and don't have acer-wmi loaded (every second try hci0 rfkill
> > > is blocked, the
> > > other try it is unblocked) and more strange situation is when
> > > acer-wmi gets
> > > loaded (accidentally I've tried it when the BT hci0 was up and
> > > r> > > BT switch brings hci0 to light after the second press (no
> > > action on the first
> > > one), next press switched it off. I was able to reproduce both
> > > "problems"
> > > several times with no randomness> > Sorry, that was probably caused by the fact that the bluetooth
> > > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > > instead of bluetooth). I have the updated keymap already, but it
> > > doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> > > keymap later too.
> > >
> > > Cheers,
> > > Oldřich.
> > >
> >
> > Yes, I just also simply try, the EC emit key priority is:
> > KEY_BLUETOOTH
> > KEY_BRIGHTNESSUP
> > KEY_BLUETOOTH
> > KEY_BLUETOOTH
> >
> > You are right, maybe the keymaping have problem on speciall acer
> > notebook, I will also try.
> >
> >
> > Thank's
> > Joey Lee
> >
>
> Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
> probe or not.
> But, on my Acer AspireOne ZG8, there have no product name in
> dmidecode...
>
OK, confirm acer-aspire_5720 keymap works fine on my ZG8. I added the
following rule to /lib/udev/rules.d/95-keymap.rules:
ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_serial}=="ZG8*", RUN+="keymap $name acer-aspire_5720"
I will send patch to udev group. But I am not sure acer-aspire_5720 keymap also works to you:
0x84 bluetooth # sent when bluetooth module missing, and key pressed
0x92 media # acer arcade
0xD4 bluetooth # bluetooth on
0xD9 bluetooth # bluetooth off
Do you need me help to send out patch to udev group for your machine?
Thank's
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-31 9:10 ` Joey Lee
@ 2011-03-31 20:27 ` Oldřich Jedlička
0 siblings, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-31 20:27 UTC (permalink / raw)
To: Joey Lee
Cc: davem, dmitry.torokhov, marcel, Al Cho, Gary Lin, johannes,
mjg59, linux-acpi, linux-input, platform-driver-x86
Hi Joey Lee,
On Thursday 31 March 2011 11:10:49 Joey Lee wrote:
> Hi Oldřich,
>
> 於 四，2011-03-31 於 02:09 -0600，Joey Lee 提到：
>
> > 於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> >
> > > Hi Oldřich,
> > >
> > > 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > >
> > > > Hi Joey Lee,
> > > >
> > > > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> > > >
> > > > Hi Dmitry,
> > > >
> > > > On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > > > > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > > > > > Thank's for your information, I will look at it.
> > > > > >
> > > > > > Finally,
> > > > > > I borrow a Acer Aspire one ZG8 from Gary, it can
> > > > > > reproduce
> > > >
> > > > your
> > > >
> > > > > > situation.
> > > > > >
> > > > > > The BAD thing is you are right,
> > > > > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> > > >
> > > > not make sense
> > > >
> > > > > > because rfkill-input registered input handler.
> > > > > >
> > > > > > The BT HW key still works because acer-wmi have polling
> > > > > > to
> > > >
> > > > sync the
> > > >
> > > > > > state with EC and killswitch, and EC also take care the
> > > > > > BT
> > > >
> > > > device power
> > > >
> > > > > > off job.
> > > > > >
> > > > > > But, I also found SOMETIMES after system reboot,
> > > >
> > > > rfkill-input can
> > > >
> > > > > > capture the key event.
> > > > > > We need find out why input handle didn't receive KEY_*
> > > >
> > > > event.
> > > >
> > > > > > Hi, Dmitry
> > > > > >
> > > > > > Appreciate if you can give us any good suggestions!
> > > > > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> > > >
> > > > registered input
> > > >
> > > > > > handler, can't capture it?
> > > > > >
> > > > > >
> > > > > > *** 06:32:42.972: lshal: device_condition,
> > > >
> > > > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_por
> > > > t_logicaldev
> > > >
> > > > > > _input
> > > > > >
> > > > > > condition_name=ButtonPressed
> > > > > > condition_details=bluetooth
> > > > > >
> > > > > > But, SOMETIMES after reboot system, rfkill-input can
> > > >
> > > > capture the key.
> > > >
> > > > > > We are working on 2.6.38 kernel, and Acer notebook.
> > > > >
> > > > > Hi Joey,
> > > > >
> > > > > If you look in /proc/bus/input/devices do you see
> > > >
> > > > rfkill-input as
> > > >
> > > > > actually bound to the device that has KEY_BLUETOOTH?
> > > > >
> > > > >
> > > > > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> > > >
> > > > key is not in
> > > >
> > > > > the default keymap I think you must be loading
> > > > > Acer-specific
> > > >
> > > > keymap via
> > > >
> > > > > udev or some other mechanism, and I guess stumbling upon a
> > > >
> > > > deficiency in
> > > >
> > > > > input layer: we do not re-match devices after changing
> > > >
> > > > keymap. So if
> > > >
> > > > > rfkill-input was loaded before keymap was altered, then it
> > > >
> > > > will not bind
> > > >
> > > > > to the keyboard even if you add KE_BLUETOOTH at a later
> > > >
> > > > time. Fixing
> > > >
> > > > > this is something that was on my TODO list for a while
> > > >
> > > > now...
> > > >
> > > >
> > > > Verified - I tried to compile rfkill as module as you
> > > > recommended (on personal
> > > > e-mail). I had to reload rfkill after startup to have rfkill
> > > > listening. So
> > > > this part looks clear on what happens.
> > > >
> > > > @Joey Lee: There are other strange situations when I have
> > > > rfkill as a module
> > > > and don't have acer-wmi loaded (every second try hci0 rfkill
> > > > is blocked, the
> > > > other try it is unblocked) and more strange situation is when
> > > > acer-wmi gets
> > > > loaded (accidentally I've tried it when the BT hci0 was up
> > > > and r> > > BT switch brings hci0 to light after the
> > > > second press (no action on the first
> > > > one), next press switched it off. I was able to reproduce
> > > > both "problems"
> > > > several times with no randomness> > Sorry, that was probably
> > > > caused by the fact that the bluetooth
> > > >
> > > > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > > > instead of bluetooth). I have the updated keymap already, but it
> > > > doesn't get loaded automatically cu> this was also the case during my
> > > > tests. I will try it with the correct keymap later too.
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > Yes, I just also simply try, the EC emit key priority is:
> > > KEY_BLUETOOTH
> > > KEY_BRIGHTNESSUP
> > > KEY_BLUETOOTH
> > > KEY_BLUETOOTH
> > >
> > > You are right, maybe the keymaping have problem on speciall acer
> > > notebook, I will also try.
> > >
> > >
> > > Thank's
> > > Joey Lee
> >
> > Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
> > probe or not.
> > But, on my Acer AspireOne ZG8, there have no product name in
> > dmidecode...
>
> OK, confirm acer-aspire_5720 keymap works fine on my ZG8. I added the
> following rule to /lib/udev/rules.d/95-keymap.rules:
>
> ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_serial}=="ZG8*",
> RUN+="keymap $name acer-aspire_5720"
>
> I will send patch to udev group. But I am not sure acer-aspire_5720 keymap
> also works to you:
>
> 0x84 bluetooth # sent when bluetooth module missing, and key pressed
> 0x92 media # acer arcade
> 0xD4 bluetooth # bluetooth on
> 0xD9 bluetooth # bluetooth off
Yes, that would work. I've sent already keymap to linux-hotplug mailing list
(with a note to update the meanings to be in-line with other keymaps):
0xD9 bluetooth # (toggle) off-to-on
0xF1 touchpad_on # (toggle) off-to-on
0xF2 touchpad_off # (toggle) on-to-off
0xF9 connect # Sync
0xEE screenlock # Lock
My keymap problem was caused by started `hald`, which reset the keymap to some
bad one. I've removed hald from startup and the keys are mapped well now. Also
the starting of bluetooth with BT HW button works as expected now.
> Do you need me help to send out patch to udev group for your machine?
Thanks, not necessary.
Cheers,
Oldřich.
>
> Thank's
> Joey Lee
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-22 2:32 ` Joey Lee
@ 2011-03-24 21:56 ` Oldřich Jedlička
0 siblings, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-24 21:56 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
[-- Attachment #1: Type: Text/Plain, Size: 18465 bytes --]
Hi Joey Lee,
On Tuesday 22 March 2011 03:32:01 Joey Lee wrote:
> 於 一，2011-03-21 於 21:44 +0100，Oldřich Jedlička 提到：
>
> > Hi Joey Lee,
> >
> > On Monday 21 March 2011 18:52:58 Joey Lee wrote:
> > > Hi Oldřich,
> > >
> > > 於 一，2011-03-21 於 05:26 -0600，Joey Lee 提到：
> > >
> > > > Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann
> > > > and Gary Lin
> > > >
> > > > Hi Oldřich,
> > > >
> > > > 於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> > > >
> > > > > Hi Joey Lee,
> > > > >
> > > > > Finally I've got little time to expriment.
> > > >
> > > > Thank's for you also reserve time to trace it. And, I also add
> > > > comment on bugzilla:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=31002
> > > >
> > > > > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > > > > > Hi Oldřich,
> > > > > >
> > > > > > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > > > > >
> > > > > > > > After trace rfkill-input stuff, I thought this is
> > > > > > > > rfkill-input's normal behavior but not a bug.
> > > > > > > >
> > > > > > > > Unfortunately, I didn't find any workaround way when a driver
> > > > > > > > need to call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > > > > > >
> > > > > > > > The rfkill-input will sync the rfkill state to all
> > > > > > > > killswitchs that have the same type. For example, acer-wmi
> > > > > > > > set the initial software switch to _BLOCK_ when driver
> > > > > > > > initial, then rfkill-input will also set any new bluetooth
> > > > > > > > killswitch state to _BLOCK_ .
> > > > > > >
> > > > > > > The rfkill_sync_work syncs with rfkill_global_states, which is
> > > > > > > set during intitialization or by rfkill_switch_all, if I read
> > > > > > > it correctly. This should be independent to acer-bluetooth
> > > > > > > state. The rfkill_global_states[BLUETOOTH] should be unblocked
> > > > > > > initially, I need to verify it.
> > > > > >
> > > > > > Yes!
> > > > > > Ideally, killswitch state should be independent to different
> > > > > > driver, even the killswitch type is the same.
> > > > > >
> > > > > > But,
> > > > > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will
> > > > > > replicate state for each killswitch that have the same type:
> > > > > >
> > > > > > vi net/rfkill/core.c
> > > > > >
> > > > > > int __must_check rfkill_register(struct rfkill *rfkill)
> > > > > > {
> > > > > > ...
> > > > > >
> > > > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > > > >
> > > > > > schedule_work(&rfkill->sync_work);
> > > > > >
> > > > > > } else { /* if rfkill->persistent then set the
state
> >
> > to all
> >
> > > > > the
> > > > >
> > > > > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when
> > > > > > CONFIG_RFKILL_INPUT = Y */
> > > > > >
> > > > > > bool soft_blocked = !!(rfkill->state &
> > > > > > RFKILL_BLOCK_SW);
> > > > > >
> > > > > > if (!atomic_read(&rfkill_input_disabled))
> > > > > >
> > > > > > __rfkill_switch_all(rfkill->type,
> > > > > > soft_blocked); /*
> > > > > >
> > > > > > here call switch all to sync state */ #endif
> > > > > >
> > > > > > }
> > > > > >
> > > > > > When any driver call rfkill_init_sw_state for set the initial
> > > > > > state to killswitch, this rfkill->persistent will set to true:
> > > > > >
> > > > > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked)
/*
> > > > > > acer-
> > > > >
> > > > > wmi
> > > > >
> > > > > > driver used it to set inital killswitch state */ {
> > > > > > ....
> > > > > >
> > > > > > spin_lock_irqsave(&rfkill->lock, flags);
> > > > > > __rfkill_set_sw_state(rfkill, blocked);
> > > > > > rfkill->persistent = true /* persistent set
to
> >
> > true */
> >
> > > > > > That's why acer-wmi bluetooth killswitch's state was been
> > > > > > replicate to hci_core's killswitch state.
> > > > > >
> > > > > > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > > > > > rfkill_init_sw_state before register rfkill, then rfkill_register
> > > > > > will try to sync state to the same killswitch type like the
> > > > > > above.
> > > > > >
> > > > > > It's make sense,
> > > > > > because rfkill-input only can block/unblock the same killswitch
> > > > > > type at the same time, before rfkill-input active, it want all
> > > > > > the same type's state is full the same.
> > > > > >
> > > > > > And,
> > > > > > rfkill-input also suppose user only can use keycode (maybe Fn
> > > > > > key) to control killswitch state, so, direct use rkill tool or
> > > > > > echo state to killswitch for change the state will cause
> > > > > > killswitchs' state lost link. It like we do.
> > > > > >
> > > > > > > There is some magic in rfkill/input.c that plays with global
> > > > > > > states, but I don't know if or how that one is used in my case.
> > > > > >
> > > > > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the
> > > > > > following code. You will see the new bluetooth killswitch will
> > > > > > be unblock when it created.
> > > > > >
> > > > > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > > > > > index 0198191..0dec078 100644
> > > > > > --- a/net/rfkill/core.c
> > > > > > +++ b/net/rfkill/core.c
> > > > > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct
> > > > > > rfkill *rfkill)
> > > > > >
> > > > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > > > >
> > > > > > schedule_work(&rfkill->sync_work);
> > > > > >
> > > > > > - } else {
> > > > > > -#ifdef CONFIG_RFKILL_INPUT
> > > > > > - bool soft_blocked = !!(rfkill->state &
> > > > > > RFKILL_BLOCK_SW); -
> > > > > > - if (!atomic_read(&rfkill_input_disabled))
> > > > > > - __rfkill_switch_all(rfkill->type,
> > > > > > soft_blocked); -#endif
> > > > > > - }
> > > > > > + } //else {
> > > > > > +//#ifdef CONFIG_RFKILL_INPUT
> > > > > > +// bool soft_blocked = !!(rfkill->state &
> > > > > > RFKILL_BLOCK_SW); +//
> > > > > > +// if (!atomic_read(&rfkill_input_disabled))
> > > > > > +// __rfkill_switch_all(rfkill->type,
> > > > > > soft_blocked); +//#endif
> > > > > > +// }
> > > > > >
> > > > > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > > > >
> > > > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second
> > > > > I've tried to enable CONFIG_RFKILL_INPUT, but remove the mentioned
> > > > > block of code. The result is working bluetooth HW switch.
> > > >
> > > > Yes, that because the following patch introduce
> > > > driver with persistent state will affect the global state only if
> > > > rfkill-input is enabled:
> > > >
> > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=co
> > > > mmit ;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> > > >
> > > > It maybe workaround another rfkill-input issue, but causes it
> > > > replicate acer-wmi's bluetooth killswitch initial state (or any
> > > > driver that used rfkill_init_sw_state) to any new bluetooth
> > > > killswitch.
> > > >
> > > > It's not make sense.
> > > >
> > > > > > > > Acer's BIOS default setup bluetooth's state is disable when
> > > > > > > > system cold boot, and BIOS also can save the connection
> > > > > > > > devices' state when system reboot. Currently, acer-wmi
> > > > > > > > driver have right behavior to sync the state with BIOS.
> > > > > > > >
> > > > > > > > Face to your situation, my suggestion is:
> > > > > > > >
> > > > > > > > - Use userland application to correct killswitch state.
> > > > > > > >
> > > > > > > > highly suggest You can try urfkill daemon:
> > > > > > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > > > > > >
> > > > > > > > write a startup script to enable bluetooth when system
> > > > > > > > boot.
> > > > > > > >
> > > > > > > > - Disable rfkill-input module if you didn't real use it.
> > > > > > > >
> > > > > > > > The TravelMate 5730G have wifi hotkey that only emit
> > > > > > > > KEY_WLAN, but doesn't emit KEY_BLUETOOTH, that means
> > > > > > > > rfkill-input cann't help you enab> > > > > > I didn't have
> > > > > > > > time to look at the problem more deeply to identify
> > > > > > >
> > > > > > > who is setting the global state to "blocked" or what really
> > > > > > > happens. Anyway, I did some testing with pressing the HW
> > > > > > > bluetooth switch and I saw the following immediately _after_
> > > > > > > pressing the HW switch to enable bluetooth:
> > > > > > >
> > > > > > > oldium ~ # rfkill list
> > > > > > > 0: acer-wireless: Wireless LAN
> > > > > > >
> > > > > > > Soft blocked: no
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > 1: acer-bluetooth: Bluetooth
> > > > > > >
> > > > > > > Soft blocked: no
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > 2: acer-threeg: Wireless WAN
> > > > > > >
> > > > > > > Soft blocked: yes
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > 3: phy0: Wireless LAN
> > > > > > >
> > > > > > > Soft blocked: no
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > I had this output 3 times immediately after each other. I'm
> > > > > > > using keyboard "up" and "enter" to repeat the last shell
> > > > > > > command, so this is a relatively slow operation. So the state
> > > > > > > when the
> > > > > > > acer-bluetooth was unbloc> > > >
> > > > > > > oldium ~ # rfkill list
> > > > > > > 0: acer-wireless: Wireless LAN
> > > > > > >
> > > > > > > Soft blocked: no
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > 1: acer-bluetooth: Bluetooth
> > > > > > >
> > > > > > > Soft blocked: no
> > > > > > > Hard blocked: no
> > > > > > >
> > > > > > > 2: acer-threeg: Wireless WAN
> > > > > > >
> > > > > > > Soft blocked: yes
> > > > > > > Hard blocked> > >
> > > > > > >
> > > > > > > 5: hci0: Bluetooth
> > > > > > >
> > > > > > > Soft blocked: yes
> > > > > > > Hard blocked: no
> > > > > >
> > > > > > My Acer machine have no HW bluetooth key but only have one HW
> > > > > > WLAN key that emit KEY_WLAN.
> > > > > > Please use lshal to monitor your HW bluetooth key and make sure
> > > > > > it emit KEY_BLUETOOTH.
> > > > >
> > > > > `lshal -m` outputs this:
> > > > >
> > > > > <bluetooth key pressed>
> > > > > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input
> > > > > condition ButtonPressed = bluetooth
> > > > > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > > > property killswitch.state = 1 (0x1)
> > > > > 20:45:54.678: usb_device_a5c_2101_noserial added
> > > > > ...
> > > > > <bluetooth key pressed again>
> > > > > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input
> > > > > condition ButtonPressed = brightness-up
> > > > > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > > > property killswitch.state = 0 (0x0)
> > > > > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> > > > > ...
> > > > >
> > > > > Strange is "brightness-up" key, somebody is wrong here.
> > > >
> > > > Yes, brightness-up key is another story, maybe you can enable acpi
> > > > debug to look at montior which acpi method or _Q event method used:
> > > >
> > > > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
> > > > echo 0xF >/sys/module/acpi/parameters/debug_level
> > > >
> > > > But, this is not related to our current killswitch issue, let us skip
> > > > it.
> > > >
> > > > > > > So it looks like the hci0 went blocked even when the
> > > > > > > acer-bluetooth switch was unblocked. So it looks like the hci0
> > > > > > > state is independent on the initial acer- bluetooth state.
> > > > > > >
> > > > > > > Hopefully I have some time this evening (CET timezone) to add
> > > > > > > some stack traces and logs to see what really happens on my
> > > > > > > system.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Oldřich.
> > > > > >
> > > > > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill
> > > > > > tool to set acer-wmi bluetooth killswitch for test, must have
> > > > > > different result.
> > > > >
> > > > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at
> > > > > Kconfig in net/rfkill and there is a line "default y if !EXPERT"
> > > > > which means (I think) that it would be enabled by default for
> > > > > anybody not troubles as I have.
> > > >
> > > > I agreed your point, and I don't think rfkill-input need enable for
> > > > all non-Expert user because it sometimes have conflict with EC or
> > > > userland behavior.
> > > >
> > > > I still suggest you can disable rfkill-input then please try Gary
> > > > Lin's urfkill daemon, it can do what does rfkill-input do and more
> > > > flexibility.
> > > >
> > > > > I've tried `rfkill unblock <acer-bluetooth number>` with my second
> > > > > test (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works
> > > > > perfectly.
> > > > >
> > > > > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some
> > > > > degree, because enabling the config switch changes bluetooth HW/SW
> > > > > switch from working to not-fully-working.
> > > > >
> > > > > Cheers,
> > > > > Oldřich.
> > > >
> > > > The root cause is what I said in the above, it's hard to fix in
> > > > kernel module because user only can choice enable/disable
> > > > rfkill-input in Kconfig and even cann't choice it when system boot.
> > > >
> > > > I thought we need:
> > > > - set rfkill-input to EXPERT, remove !EXPERT
> > > > - add a kernel option to rfkill for user can choice enable it or not
> > > >
> > > > when system boot.
> > > >
> > > > - Add comment in Documentation/rfkill.txt for remind user can use
> > > >
> > > > urfkill daemon (or any other userland daemon) to replace
> > > > rfkill-input.
> > > >
> > > > Of course need rfkill experts' more professional comments for this
> > > > topic.
> > > > I will try to gener> Thank's a lot!
> > > > Joey Lee
> > >
> > > Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited
> > > flag to workaround issue, please kindly help to test the following
> > > acer-wmi patch, it works fine to me on my acer travelmate 8572 machine.
>
> > > Maybe it will be our backup solution after you tested:
> I attached this workaround patch to bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=31002#c8
>
> > The patch works more than well - the bluetooth starts-up automatically
> > during boot. I don't know who does it, because it looks like the last
> > action done before any service gets started.
> >
> > ...
> > [ 4.434293] acer-wmi: Acer Laptop ACPI-WMI Extras
> > ...
> > [ 4.559937] acer-wmi: Brightness must be controlled by generic video
> > driver ...
> > [ 6.024186] usb 8-2: new full speed USB device using uhci_hcd and
> > address 2 [ 6.183561] usb 8-2: New USB device found, idVendor=0a5c,
> > idProduct=2101 ...
> > [ 9.763265] udev[1947]: starting version 164
> >
> > It looks like the sync work synchronizes the state to "unblocked". I
> > don't have more time to investigate the difference today, so maybe in
> > following days - if it is important.
> >
> > Regards,
> > Oldřich.
>
> That's good but odd, good is the patch fixed your issue, odd is the
> behavior is not what I want and not match with my TravelMate 8572.
The key is the global state. I've used the same patch as I sent today to get
the details, what is going on (log attached). The acer-bluetooth gets enabled
from the global bluetooth state (rfkill_sync_work), so the hci0 gets
automatically enabled afterwards too from the same global state.
Cheers,
Oldřich.
> Please then me clear up it. On my TravelMate 8572, the BIOS have 2
> different behavior for cold boot (shutdown then press HW power button),
> and warm boot (reboot). BIOS is:
> - Cold boot: back to default config is WLAN on, BT off, WWAN on
> - Warm boot: keep the devices state before last time reboot.
>
> So, you can see the above, on my machine when cold boot, the BT state is
> off, the rfkill list like following:
>
> linux-7y1r:~ # rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes # BIOS default value is disable when cold
boot
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: no
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
>
> Then I did rfkill unblock acer-bluetooth (sorry my machine have no BT HW
> key):
>
> linux-7y1r:~ # rfkill unblock 1
> linux-7y1r:~ # rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: no
> Hard blocked: no
> 2: acer-threeg: Wireless WAN
> Soft blocked: no
> Hard blocked: no
> 3: phy0: Wireless4: hci0: Bluetooth
> Soft blocked: no #fixed by my patch, hci0's rkfill state default
> is unblock Hard blocked: no
>
> I am not sure your TravelMate 5730G's behavior is fully the same with
> mine. Could you please find a bit time to look at rfkill state when
> system cold boot ?
>
> Of course, please enable rfkill-input and remove any other patch but
> only keep my workaround patch:
> 0001-acer-wmi-remove-rfkill_init_sw_state-to-workaround.patch
>
>
> Thank's a lot!
> Joey Lee
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: rfkill-patched.log --]
[-- Type: text/x-log, Size: 5042 bytes --]
[ 0.259380] rfkill_input: (rfkill_handler_init) registering rfkill_handler, returned 0
[ 4.711808] rfkill: (rfkill_register) registering wlan acer-wireless
[ 4.711984] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 4.711989] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 4.712115] rfkill: (rfkill_sync_work) syncing wlan acer-wireless to unblocked
[ 4.712119] rfkill: (rfkill_set_block) switching acer-wireless to unblocked
[ 4.774756] rfkill: (rfkill_register) registering bluetooth acer-bluetooth
[ 4.774921] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to blocked
[ 4.774926] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw blocked
[ 4.775114] rfkill: (rfkill_register) registering wwan acer-threeg
[ 4.775253] rfkill: (rfkill_set_sw_state) setting state of acer-threeg to blocked
[ 4.775258] rfkill: (__rfkill_set_sw_state) setting state of acer-threeg to sw blocked
[ 4.775332] rfkill: (rfkill_sync_work) syncing bluetooth acer-bluetooth to unblocked
[ 4.775337] rfkill: (rfkill_set_block) switching acer-bluetooth to unblocked
[ 4.871212] rfkill: (rfkill_sync_work) syncing wwan acer-threeg to unblocked
[ 4.871217] rfkill: (rfkill_set_block) switching acer-threeg to unblocked
[ 5.707612] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 5.707622] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 5.709096] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 5.709103] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 6.271996] rfkill: (rfkill_register) registering bluetooth hci0
[ 6.272428] rfkill: (rfkill_sync_work) syncing bluetooth hci0 to unblocked
[ 6.272434] rfkill: (rfkill_set_block) switching hci0 to unblocked
[ 6.707634] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 6.707645] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 6.709084] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 6.709139] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 7.707460] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 7.707470] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 7.708586] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 7.708593] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 8.707611] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 8.707621] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 8.709074] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 8.709082] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 9.707392] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 9.707403] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 9.708748] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 9.708755] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 10.707366] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 10.707376] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 10.708673] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 10.708680] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 10.877147] rfkill: (rfkill_set_hw_state) setting state of phy0 to hw unblocked
[ 10.877156] rfkill: (__rfkill_set_hw_state) switching phy0 to unblocked
[ 10.878092] rfkill: (rfkill_register) registering wlan phy0
[ 10.878311] rfkill: (rfkill_sync_work) syncing wlan phy0 to unblocked
[ 10.878317] rfkill: (rfkill_set_block) switching phy0 to unblocked
[ 11.707002] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 11.707025] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 11.708584] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 11.708591] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 12.707061] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 12.707072] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
[ 12.708924] rfkill: (rfkill_set_sw_state) setting state of acer-bluetooth to unblocked
[ 12.708931] rfkill: (__rfkill_set_sw_state) setting state of acer-bluetooth to sw unblocked
[ 13.708133] rfkill: (rfkill_set_sw_state) setting state of acer-wireless to unblocked
[ 13.708142] rfkill: (__rfkill_set_sw_state) setting state of acer-wireless to sw unblocked
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 20:44 ` Oldřich Jedlička
@ 2011-03-22 2:32 ` Joey Lee
2011-03-24 21:56 ` Oldřich Jedlička
0 siblings, 1 reply; 48+ messages in thread
From: Joey Lee @ 2011-03-22 2:32 UTC (permalink / raw)
To: oldium.pro
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
於 一，2011-03-21 於 21:44 +0100，Oldřich Jedlička 提到：
> Hi Joey Lee,
>
> On Monday 21 March 2011 18:52:58 Joey Lee wrote:
> > Hi Oldřich,
> >
> > 於 一，2011-03-21 於 05:26 -0600，Joey Lee 提到：
> >
> > > Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and
> > > Gary Lin
> > >
> > > Hi Oldřich,
> > >
> > > 於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> > >
> > > > Hi Joey Lee,
> > > >
> > > > Finally I've got little time to expriment.
> > >
> > > Thank's for you also reserve time to trace it. And, I also add comment
> > > on bugzilla:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=31002
> > >
> > > > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > > > > Hi Oldřich,
> > > > >
> > > > > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > > > >
> > > > > > > After trace rfkill-input stuff, I thought this is rfkill-input's
> > > > > > > normal behavior but not a bug.
> > > > > > >
> > > > > > > Unfortunately, I didn't find any workaround way when a driver
> > > > > > > need to call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > > > > >
> > > > > > > The rfkill-input will sync the rfkill state to all killswitchs
> > > > > > > that have the same type. For example, acer-wmi set the initial
> > > > > > > software switch to _BLOCK_ when driver initial, then
> > > > > > > rfkill-input will also set any new bluetooth killswitch state to
> > > > > > > _BLOCK_ .
> > > > > >
> > > > > > The rfkill_sync_work syncs with rfkill_global_states, which is set
> > > > > > during intitialization or by rfkill_switch_all, if I read it
> > > > > > correctly. This should be independent to acer-bluetooth state. The
> > > > > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I
> > > > > > need to verify it.
> > > > >
> > > > > Yes!
> > > > > Ideally, killswitch state should be independent to different driver,
> > > > > even the killswitch type is the same.
> > > > >
> > > > > But,
> > > > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will
> > > > > replicate state for each killswitch that have the same type:
> > > > >
> > > > > vi net/rfkill/core.c
> > > > >
> > > > > int __must_check rfkill_register(struct rfkill *rfkill)
> > > > > {
> > > > > ...
> > > > >
> > > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > > >
> > > > > schedule_work(&rfkill->sync_work);
> > > > >
> > > > > } else { /* if rfkill->persistent then set the state
> to all
> > > >
> > > > the
> > > >
> > > > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT =
> > > > > Y */
> > > > >
> > > > > bool soft_blocked = !!(rfkill->state &
> > > > > RFKILL_BLOCK_SW);
> > > > >
> > > > > if (!atomic_read(&rfkill_input_disabled))
> > > > >
> > > > > __rfkill_switch_all(rfkill->type,
> > > > > soft_blocked); /*
> > > > >
> > > > > here call switch all to sync state */ #endif
> > > > >
> > > > > }
> > > > >
> > > > > When any driver call rfkill_init_sw_state for set the initial state
> > > > > to killswitch, this rfkill->persistent will set to true:
> > > > >
> > > > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /*
> > > > > acer-
> > > >
> > > > wmi
> > > >
> > > > > driver used it to set inital killswitch state */ {
> > > > > ....
> > > > >
> > > > > spin_lock_irqsave(&rfkill->lock, flags);
> > > > > __rfkill_set_sw_state(rfkill, blocked);
> > > > > rfkill->persistent = true /* persistent set to
> true */
> > > > >
> > > > > That's why acer-wmi bluetooth killswitch's state was been replicate
> > > > > to hci_core's killswitch state.
> > > > >
> > > > > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > > > > rfkill_init_sw_state before register rfkill, then rfkill_register
> > > > > will try to sync state to the same killswitch type like the above.
> > > > >
> > > > > It's make sense,
> > > > > because rfkill-input only can block/unblock the same killswitch type
> > > > > at the same time, before rfkill-input active, it want all the same
> > > > > type's state is full the same.
> > > > >
> > > > > And,
> > > > > rfkill-input also suppose user only can use keycode (maybe Fn key) to
> > > > > control killswitch state, so, direct use rkill tool or echo state to
> > > > > killswitch for change the state will cause killswitchs' state lost
> > > > > link. It like we do.
> > > > >
> > > > > > There is some magic in rfkill/input.c that plays with global
> > > > > > states, but I don't know if or how that one is used in my case.
> > > > >
> > > > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> > > > > code. You will see the new bluetooth killswitch will be unblock when
> > > > > it created.
> > > > >
> > > > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > > > > index 0198191..0dec078 100644
> > > > > --- a/net/rfkill/core.c
> > > > > +++ b/net/rfkill/core.c
> > > > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> > > > > *rfkill)
> > > > >
> > > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > > >
> > > > > schedule_work(&rfkill->sync_work);
> > > > >
> > > > > - } else {
> > > > > -#ifdef CONFIG_RFKILL_INPUT
> > > > > - bool soft_blocked = !!(rfkill->state &
> > > > > RFKILL_BLOCK_SW); -
> > > > > - if (!atomic_read(&rfkill_input_disabled))
> > > > > - __rfkill_switch_all(rfkill->type,
> > > > > soft_blocked); -#endif
> > > > > - }
> > > > > + } //else {
> > > > > +//#ifdef CONFIG_RFKILL_INPUT
> > > > > +// bool soft_blocked = !!(rfkill->state &
> > > > > RFKILL_BLOCK_SW); +//
> > > > > +// if (!atomic_read(&rfkill_input_disabled))
> > > > > +// __rfkill_switch_all(rfkill->type,
> > > > > soft_blocked); +//#endif
> > > > > +// }
> > > > >
> > > > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > > >
> > > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've
> > > > tried to enable CONFIG_RFKILL_INPUT, but remove the mentioned block of
> > > > code. The result is working bluetooth HW switch.
> > >
> > > Yes, that because the following patch introduce
> > > driver with persistent state will affect the global state only if
> > > rfkill-input is enabled:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> > > ;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> > >
> > > It maybe workaround another rfkill-input issue, but causes it replicate
> > > acer-wmi's bluetooth killswitch initial state (or any driver that used
> > > rfkill_init_sw_state) to any new bluetooth killswitch.
> > >
> > > It's not make sense.
> > >
> > > > > > > Acer's BIOS default setup bluetooth's state is disable when
> > > > > > > system cold boot, and BIOS also can save the connection devices'
> > > > > > > state when system reboot. Currently, acer-wmi driver have right
> > > > > > > behavior to sync the state with BIOS.
> > > > > > >
> > > > > > > Face to your situation, my suggestion is:
> > > > > > >
> > > > > > > - Use userland application to correct killswitch state.
> > > > > > >
> > > > > > > highly suggest You can try urfkill daemon:
> > > > > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > > > > >
> > > > > > > write a startup script to enable bluetooth when system boot.
> > > > > > >
> > > > > > > - Disable rfkill-input module if you didn't real use it.
> > > > > > >
> > > > > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN,
> > > > > > > but doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't
> > > > > > > help you enab> > > > > > I didn't have time to look at the problem more deeply to identify
> > > > > > who is setting the global state to "blocked" or what really
> > > > > > happens. Anyway, I did some testing with pressing the HW bluetooth
> > > > > > switch and I saw the following immediately _after_ pressing the HW
> > > > > > switch to enable bluetooth:
> > > > > >
> > > > > > oldium ~ # rfkill list
> > > > > > 0: acer-wireless: Wireless LAN
> > > > > >
> > > > > > Soft blocked: no
> > > > > > Hard blocked: no
> > > > > >
> > > > > > 1: acer-bluetooth: Bluetooth
> > > > > >
> > > > > > Soft blocked: no
> > > > > > Hard blocked: no
> > > > > >
> > > > > > 2: acer-threeg: Wireless WAN
> > > > > >
> > > > > > Soft blocked: yes
> > > > > > Hard blocked: no
> > > > > >
> > > > > > 3: phy0: Wireless LAN
> > > > > >
> > > > > > Soft blocked: no
> > > > > > Hard blocked: no
> > > > > >
> > > > > > I had this output 3 times immediately after each other. I'm using
> > > > > > keyboard "up" and "enter" to repeat the last shell command, so this
> > > > > > is a relatively slow operation. So the state when the
> > > > > > acer-bluetooth was unbloc> > > >
> > > > > > oldium ~ # rfkill list
> > > > > > 0: acer-wireless: Wireless LAN
> > > > > >
> > > > > > Soft blocked: no
> > > > > > Hard blocked: no
> > > > > >
> > > > > > 1: acer-bluetooth: Bluetooth
> > > > > >
> > > > > > Soft blocked: no
> > > > > > Hard blocked: no
> > > > > >
> > > > > > 2: acer-threeg: Wireless WAN
> > > > > >
> > > > > > Soft blocked: yes
> > > > > > Hard blocked> > >
> > > > > >
> > > > > > 5: hci0: Bluetooth
> > > > > >
> > > > > > Soft blocked: yes
> > > > > > Hard blocked: no
> > > > >
> > > > > My Acer machine have no HW bluetooth key but only have one HW WLAN
> > > > > key that emit KEY_WLAN.
> > > > > Please use lshal to monitor your HW bluetooth key and make sure it
> > > > > emit KEY_BLUETOOTH.
> > > >
> > > > `lshal -m` outputs this:
> > > >
> > > > <bluetooth key pressed>
> > > > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > > > ButtonPressed = bluetooth
> > > > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > > property killswitch.state = 1 (0x1)
> > > > 20:45:54.678: usb_device_a5c_2101_noserial added
> > > > ...
> > > > <bluetooth key pressed again>
> > > > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > > > ButtonPressed = brightness-up
> > > > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > > property killswitch.state = 0 (0x0)
> > > > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> > > > ...
> > > >
> > > > Strange is "brightness-up" key, somebody is wrong here.
> > >
> > > Yes, brightness-up key is another story, maybe you can enable acpi debug
> > > to look at montior which acpi method or _Q event method used:
> > >
> > > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
> > > echo 0xF >/sys/module/acpi/parameters/debug_level
> > >
> > > But, this is not related to our current killswitch issue, let us skip
> > > it.
> > >
> > > > > > So it looks like the hci0 went blocked even when the acer-bluetooth
> > > > > > switch was unblocked. So it looks like the hci0 state is
> > > > > > independent on the initial acer- bluetooth state.
> > > > > >
> > > > > > Hopefully I have some time this evening (CET timezone) to add some
> > > > > > stack traces and logs to see what really happens on my system.
> > > > > >
> > > > > > Cheers,
> > > > > > Oldřich.
> > > > >
> > > > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill
> > > > > tool to set acer-wmi bluetooth killswitch for test, must have
> > > > > different result.
> > > >
> > > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at
> > > > Kconfig in net/rfkill and there is a line "default y if !EXPERT" which
> > > > means (I think) that it would be enabled by default for anybody not
> > > > troubles as I have.
> > >
> > > I agreed your point, and I don't think rfkill-input need enable for all
> > > non-Expert user because it sometimes have conflict with EC or userland
> > > behavior.
> > >
> > > I still suggest you can disable rfkill-input then please try Gary Lin's
> > > urfkill daemon, it can do what does rfkill-input do and more
> > > flexibility.
> > >
> > > > I've tried `rfkill unblock <acer-bluetooth number>` with my second test
> > > > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
> > > >
> > > > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some
> > > > degree, because enabling the config switch changes bluetooth HW/SW
> > > > switch from working to not-fully-working.
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > The root cause is what I said in the above, it's hard to fix in kernel
> > > module because user only can choice enable/disable rfkill-input in
> > > Kconfig and even cann't choice it when system boot.
> > >
> > > I thought we need:
> > > - set rfkill-input to EXPERT, remove !EXPERT
> > > - add a kernel option to rfkill for user can choice enable it or not
> > >
> > > when system boot.
> > >
> > > - Add comment in Documentation/rfkill.txt for remind user can use
> > >
> > > urfkill daemon (or any other userland daemon) to replace rfkill-input.
> > >
> > > Of course need rfkill experts' more professional comments for this
> > > topic.
> > > I will try to gener> Thank's a lot!
> > > Joey Lee
> >
> > Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited
> > flag to workaround issue, please kindly help to test the following
> > acer-wmi patch, it works fine to me on my acer travelmate 8572 machine.
> >
> > Maybe it will be our backup solution after you tested:
>
I attached this workaround patch to bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=31002#c8
> The patch works more than well - the bluetooth starts-up automatically during
> boot. I don't know who does it, because it looks like the last action done
> before any service gets started.
>
> ...
> [ 4.434293] acer-wmi: Acer Laptop ACPI-WMI Extras
> ...
> [ 4.559937] acer-wmi: Brightness must be controlled by generic video driver
> ...
> [ 6.024186] usb 8-2: new full speed USB device using uhci_hcd and address 2
> [ 6.183561] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101
> ...
> [ 9.763265] udev[1947]: starting version 164
>
> It looks like the sync work synchronizes the state to "unblocked". I don't
> have more time to investigate the difference today, so maybe in following days
> - if it is important.
>
> Regards,
> Oldřich.
>
That's good but odd, good is the patch fixed your issue, odd is the
behavior is not what I want and not match with my TravelMate 8572.
Please then me clear up it. On my TravelMate 8572, the BIOS have 2
different behavior for cold boot (shutdown then press HW power button),
and warm boot (reboot). BIOS is:
- Cold boot: back to default config is WLAN on, BT off, WWAN on
- Warm boot: keep the devices state before last time reboot.
So, you can see the above, on my machine when cold boot, the BT state is
off, the rfkill list like following:
linux-7y1r:~ # rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes # BIOS default value is disable when cold boot
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
Then I did rfkill unblock acer-bluetooth (sorry my machine have no BT HW key):
linux-7y1r:~ # rfkill unblock 1
linux-7y1r:~ # rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: acer-threeg: Wireless WAN
Soft blocked: no
Hard blocked: no
3: phy0: Wireless4: hci0: Bluetooth
Soft blocked: no #fixed by my patch, hci0's rkfill state default is unblock
Hard blocked: no
I am not sure your TravelMate 5730G's behavior is fully the same with
mine. Could you please find a bit time to look at rfkill state when
system cold boot ?
Of course, please enable rfkill-input and remove any other patch but
only keep my workaround patch:
0001-acer-wmi-remove-rfkill_init_sw_state-to-workaround.patch
Thank's a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
2011-03-21 17:52 ` Joey Lee
(?)
@ 2011-03-21 20:44 ` Oldřich Jedlička
2011-03-22 2:32 ` Joey Lee
-1 siblings, 1 reply; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-21 20:44 UTC (permalink / raw)
To: Joey Lee
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi Joey Lee,
On Monday 21 March 2011 18:52:58 Joey Lee wrote:
> Hi Oldřich,
>
> 於 一，2011-03-21 於 05:26 -0600，Joey Lee 提到：
>
> > Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and
> > Gary Lin
> >
> > Hi Oldřich,
> >
> > 於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> >
> > > Hi Joey Lee,
> > >
> > > Finally I've got little time to expriment.
> >
> > Thank's for you also reserve time to trace it. And, I also add comment
> > on bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=31002
> >
> > > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > > > Hi Oldřich,
> > > >
> > > > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > > >
> > > > > > After trace rfkill-input stuff, I thought this is rfkill-input's
> > > > > > normal behavior but not a bug.
> > > > > >
> > > > > > Unfortunately, I didn't find any workaround way when a driver
> > > > > > need to call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > > > >
> > > > > > The rfkill-input will sync the rfkill state to all killswitchs
> > > > > > that have the same type. For example, acer-wmi set the initial
> > > > > > software switch to _BLOCK_ when driver initial, then
> > > > > > rfkill-input will also set any new bluetooth killswitch state to
> > > > > > _BLOCK_ .
> > > > >
> > > > > The rfkill_sync_work syncs with rfkill_global_states, which is set
> > > > > during intitialization or by rfkill_switch_all, if I read it
> > > > > correctly. This should be independent to acer-bluetooth state. The
> > > > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I
> > > > > need to verify it.
> > > >
> > > > Yes!
> > > > Ideally, killswitch state should be independent to different driver,
> > > > even the killswitch type is the same.
> > > >
> > > > But,
> > > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will
> > > > replicate state for each killswitch that have the same type:
> > > >
> > > > vi net/rfkill/core.c
> > > >
> > > > int __must_check rfkill_register(struct rfkill *rfkill)
> > > > {
> > > > ...
> > > >
> > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > >
> > > > schedule_work(&rfkill->sync_work);
> > > >
> > > > } else { /* if rfkill->persistent then set the state
to all
> > >
> > > the
> > >
> > > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT =
> > > > Y */
> > > >
> > > > bool soft_blocked = !!(rfkill->state &
> > > > RFKILL_BLOCK_SW);
> > > >
> > > > if (!atomic_read(&rfkill_input_disabled))
> > > >
> > > > __rfkill_switch_all(rfkill->type,
> > > > soft_blocked); /*
> > > >
> > > > here call switch all to sync state */ #endif
> > > >
> > > > }
> > > >
> > > > When any driver call rfkill_init_sw_state for set the initial state
> > > > to killswitch, this rfkill->persistent will set to true:
> > > >
> > > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /*
> > > > acer-
> > >
> > > wmi
> > >
> > > > driver used it to set inital killswitch state */ {
> > > > ....
> > > >
> > > > spin_lock_irqsave(&rfkill->lock, flags);
> > > > __rfkill_set_sw_state(rfkill, blocked);
> > > > rfkill->persistent = true /* persistent set to
true */
> > > >
> > > > That's why acer-wmi bluetooth killswitch's state was been replicate
> > > > to hci_core's killswitch state.
> > > >
> > > > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > > > rfkill_init_sw_state before register rfkill, then rfkill_register
> > > > will try to sync state to the same killswitch type like the above.
> > > >
> > > > It's make sense,
> > > > because rfkill-input only can block/unblock the same killswitch type
> > > > at the same time, before rfkill-input active, it want all the same
> > > > type's state is full the same.
> > > >
> > > > And,
> > > > rfkill-input also suppose user only can use keycode (maybe Fn key) to
> > > > control killswitch state, so, direct use rkill tool or echo state to
> > > > killswitch for change the state will cause killswitchs' state lost
> > > > link. It like we do.
> > > >
> > > > > There is some magic in rfkill/input.c that plays with global
> > > > > states, but I don't know if or how that one is used in my case.
> > > >
> > > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> > > > code. You will see the new bluetooth killswitch will be unblock when
> > > > it created.
> > > >
> > > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > > > index 0198191..0dec078 100644
> > > > --- a/net/rfkill/core.c
> > > > +++ b/net/rfkill/core.c
> > > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> > > > *rfkill)
> > > >
> > > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > >
> > > > schedule_work(&rfkill->sync_work);
> > > >
> > > > - } else {
> > > > -#ifdef CONFIG_RFKILL_INPUT
> > > > - bool soft_blocked = !!(rfkill->state &
> > > > RFKILL_BLOCK_SW); -
> > > > - if (!atomic_read(&rfkill_input_disabled))
> > > > - __rfkill_switch_all(rfkill->type,
> > > > soft_blocked); -#endif
> > > > - }
> > > > + } //else {
> > > > +//#ifdef CONFIG_RFKILL_INPUT
> > > > +// bool soft_blocked = !!(rfkill->state &
> > > > RFKILL_BLOCK_SW); +//
> > > > +// if (!atomic_read(&rfkill_input_disabled))
> > > > +// __rfkill_switch_all(rfkill->type,
> > > > soft_blocked); +//#endif
> > > > +// }
> > > >
> > > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > >
> > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've
> > > tried to enable CONFIG_RFKILL_INPUT, but remove the mentioned block of
> > > code. The result is working bluetooth HW switch.
> >
> > Yes, that because the following patch introduce
> > driver with persistent state will affect the global state only if
> > rfkill-input is enabled:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> > ;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> >
> > It maybe workaround another rfkill-input issue, but causes it replicate
> > acer-wmi's bluetooth killswitch initial state (or any driver that used
> > rfkill_init_sw_state) to any new bluetooth killswitch.
> >
> > It's not make sense.
> >
> > > > > > Acer's BIOS default setup bluetooth's state is disable when
> > > > > > system cold boot, and BIOS also can save the connection devices'
> > > > > > state when system reboot. Currently, acer-wmi driver have right
> > > > > > behavior to sync the state with BIOS.
> > > > > >
> > > > > > Face to your situation, my suggestion is:
> > > > > >
> > > > > > - Use userland application to correct killswitch state.
> > > > > >
> > > > > > highly suggest You can try urfkill daemon:
> > > > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > > > >
> > > > > > write a startup script to enable bluetooth when system boot.
> > > > > >
> > > > > > - Disable rfkill-input module if you didn't real use it.
> > > > > >
> > > > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN,
> > > > > > but doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't
> > > > > > help you enable bluetooth killswitch.
> > > > >
> > > > > I didn't have time to look at the problem more deeply to identify
> > > > > who is setting the global state to "blocked" or what really
> > > > > happens. Anyway, I did some testing with pressing the HW bluetooth
> > > > > switch and I saw the following immediately _after_ pressing the HW
> > > > > switch to enable bluetooth:
> > > > >
> > > > > oldium ~ # rfkill list
> > > > > 0: acer-wireless: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 1: acer-bluetooth: Bluetooth
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 2: acer-threeg: Wireless WAN
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > > >
> > > > > 3: phy0: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > I had this output 3 times immediately after each other. I'm using
> > > > > keyboard "up" and "enter" to repeat the last shell command, so this
> > > > > is a relatively slow operation. So the state when the
> > > > > acer-bluetooth was unbloc> > > >
> > > > > oldium ~ # rfkill list
> > > > > 0: acer-wireless: Wireless LAN
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 1: acer-bluetooth: Bluetooth
> > > > >
> > > > > Soft blocked: no
> > > > > Hard blocked: no
> > > > >
> > > > > 2: acer-threeg: Wireless WAN
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked> > >
> > > > >
> > > > > 5: hci0: Bluetooth
> > > > >
> > > > > Soft blocked: yes
> > > > > Hard blocked: no
> > > >
> > > > My Acer machine have no HW bluetooth key but only have one HW WLAN
> > > > key that emit KEY_WLAN.
> > > > Please use lshal to monitor your HW bluetooth key and make sure it
> > > > emit KEY_BLUETOOTH.
> > >
> > > `lshal -m` outputs this:
> > >
> > > <bluetooth key pressed>
> > > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > > ButtonPressed = bluetooth
> > > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > property killswitch.state = 1 (0x1)
> > > 20:45:54.678: usb_device_a5c_2101_noserial added
> > > ...
> > > <bluetooth key pressed again>
> > > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > > ButtonPressed = brightness-up
> > > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth
> > > property killswitch.state = 0 (0x0)
> > > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> > > ...
> > >
> > > Strange is "brightness-up" key, somebody is wrong here.
> >
> > Yes, brightness-up key is another story, maybe you can enable acpi debug
> > to look at montior which acpi method or _Q event method used:
> >
> > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
> > echo 0xF >/sys/module/acpi/parameters/debug_level
> >
> > But, this is not related to our current killswitch issue, let us skip
> > it.
> >
> > > > > So it looks like the hci0 went blocked even when the acer-bluetooth
> > > > > switch was unblocked. So it looks like the hci0 state is
> > > > > independent on the initial acer- bluetooth state.
> > > > >
> > > > > Hopefully I have some time this evening (CET timezone) to add some
> > > > > stack traces and logs to see what really happens on my system.
> > > > >
> > > > > Cheers,
> > > > > Oldřich.
> > > >
> > > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill
> > > > tool to set acer-wmi bluetooth killswitch for test, must have
> > > > different result.
> > >
> > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at
> > > Kconfig in net/rfkill and there is a line "default y if !EXPERT" which
> > > means (I think) that it would be enabled by default for anybody not
> > > enabling expert options. So other non-expert users would have the same
> > > troubles as I have.
> >
> > I agreed your point, and I don't think rfkill-input need enable for all
> > non-Expert user because it sometimes have conflict with EC or userland
> > behavior.
> >
> > I still suggest you can disable rfkill-input then please try Gary Lin's
> > urfkill daemon, it can do what does rfkill-input do and more
> > flexibility.
> >
> > > I've tried `rfkill unblock <acer-bluetooth number>` with my second test
> > > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
> > >
> > > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some
> > > degree, because enabling the config switch changes bluetooth HW/SW
> > > switch from working to not-fully-working.
> > >
> > > Cheers,
> > > Oldřich.
> >
> > The root cause is what I said in the above, it's hard to fix in kernel
> > module because user only can choice enable/disable rfkill-input in
> > Kconfig and even cann't choice it when system boot.
> >
> > I thought we need:
> > - set rfkill-input to EXPERT, remove !EXPERT
> > - add a kernel option to rfkill for user can choice enable it or not
> >
> > when system boot.
> >
> > - Add comment in Documentation/rfkill.txt for remind user can use
> >
> > urfkill daemon (or any other userland daemon) to replace rfkill-input.
> >
> > Of course need rfkill experts' more professional comments for this
> > topic.
> > I will try to gener> Thank's a lot!
> > Joey Lee
>
> Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited
> flag to workaround issue, please kindly help to test the following
> acer-wmi patch, it works fine to me on my acer travelmate 8572 machine.
>
> Maybe it will be our backup solution after you tested:
The patch works more than well - the bluetooth starts-up automatically during
boot. I don't know who does it, because it looks like the last action done
before any service gets started.
...
[ 4.434293] acer-wmi: Acer Laptop ACPI-WMI Extras
...
[ 4.559937] acer-wmi: Brightness must be controlled by generic video driver
...
[ 6.024186] usb 8-2: new full speed USB device using uhci_hcd and address 2
[ 6.183561] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101
...
[ 9.763265] udev[1947]: starting version 164
It looks like the sync work synchronizes the state to "unblocked". I don't
have more time to investigate the difference today, so maybe in following days
- if it is important.
Regards,
Oldřich.
> >From dd3d9208aa63d9670d24409b4aaaeb619f3137d6 Mon Sep 17 00:00:00 2001
>
> From: Lee, Chun-Yi <jlee@novell.com>
> Date: Tue, 22 Mar 2011 01:43:11 +0800
> Subject: [PATCH] acer-wmi: remove rfkill_init_sw_state to workaround
> rfkill-input issue
>
> acer-wmi: remove rfkill_init_sw_state to workaround issue for bko#31002
>
> Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
> ---
> drivers/platform/x86/acer-wmi.c | 19 ++++++++++++++-----
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/platform/x86/acer-wmi.c
> b/drivers/platform/x86/acer-wmi.c index 38b34a7..3d3cb46 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -222,6 +222,7 @@ struct acer_debug {
> static struct rfkill *wireless_rfkill;
> static struct rfkill *bluetooth_rfkill;
> static struct rfkill *threeg_rfkill;
> +static int rfkill_inited;
>
> /* Each low-level interface must define at least some of the following */
> struct wmi_interface {
> @@ -1161,9 +1162,13 @@ static int acer_rfkill_set(void *data, bool blocked)
> {
> acpi_status status;
> u32 cap = (unsigned long)data;
> - status = set_u32(!blocked, cap);
> - if (ACPI_FAILURE(status))
> - return -ENODEV;
> +
> + if (rfkill_inited) {
> + status = set_u32(!blocked, cap);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> + }
> +
> return 0;
> }
>
> @@ -1187,14 +1192,16 @@ static struct rfkill *acer_rfkill_register(struct
> device *dev, return ERR_PTR(-ENOMEM);
>
> status = get_device_status(&state, cap);
> - if (ACPI_SUCCESS(status))
> - rfkill_init_sw_state(rfkill_dev, !state);
>
> err = rfkill_register(rfkill_dev);
> if (err) {
> rfkill_destroy(rfkill_dev);
> return ERR_PTR(err);
> }
> +
> + if (ACPI_SUCCESS(status))
> + rfkill_set_sw_state(rfkill_dev, !state);
> +
> return rfkill_dev;
> }
>
> @@ -1229,6 +1236,8 @@ static int acer_rfkill_init(struct device *dev)
> }
> }
>
> + rfkill_inited = 1;
> +
> schedule_delayed_work(&acer_rfkill_work, round_jiffies_relative(HZ));
>
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
@ 2011-03-21 17:52 ` Joey Lee
0 siblings, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-21 17:52 UTC (permalink / raw)
To: oldium.pro
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi Oldřich,
於 一，2011-03-21 於 05:26 -0600，Joey Lee 提到：
> Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and
> Gary Lin
>
> Hi Oldřich,
>
> 於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> > Hi Joey Lee,
> >
> > Finally I've got little time to expriment.
> >
>
> Thank's for you also reserve time to trace it. And, I also add comment
> on bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=31002
>
> > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > > Hi Oldřich,
> > >
> > > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > >
> > > > > After trace rfkill-input stuff, I thought this is rfkill-input's normal
> > > > > behavior but not a bug.
> > > > >
> > > > > Unfortunately, I didn't find any workaround way when a driver need to
> > > > > call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > > >
> > > > > The rfkill-input will sync the rfkill state to all killswitchs that
> > > > > have the same type. For example, acer-wmi set the initial software
> > > > > switch to _BLOCK_ when driver initial, then rfkill-input will also set
> > > > > any new bluetooth killswitch state to _BLOCK_ .
> > > >
> > > > The rfkill_sync_work syncs with rfkill_global_states, which is set during
> > > > intitialization or by rfkill_switch_all, if I read it correctly. This
> > > > should be independent to acer-bluetooth state. The
> > > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I need to
> > > > verify it.
> > >
> > > Yes!
> > > Ideally, killswitch state should be independent to different driver,
> > > even the killswitch type is the same.
> > >
> > > But,
> > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will replicate
> > > state for each killswitch that have the same type:
> > >
> > > vi net/rfkill/core.c
> > >
> > > int __must_check rfkill_register(struct rfkill *rfkill)
> > > {
> > > ...
> > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > schedule_work(&rfkill->sync_work);
> > > } else { /* if rfkill->persistent then set the state to all
> > the
> > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = Y */
> > > bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > >
> > > if (!atomic_read(&rfkill_input_disabled))
> > > __rfkill_switch_all(rfkill->type, soft_blocked); /*
> > > here call switch all to sync state */ #endif
> > > }
> > >
> > > When any driver call rfkill_init_sw_state for set the initial state to
> > > killswitch, this rfkill->persistent will set to true:
> > >
> > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* acer-
> > wmi
> > > driver used it to set inital killswitch state */ {
> > > ....
> > > spin_lock_irqsave(&rfkill->lock, flags);
> > > __rfkill_set_sw_state(rfkill, blocked);
> > > rfkill->persistent = true /* persistent set to true */
> > >
> > >
> > > That's why acer-wmi bluetooth killswitch's state was been replicate to
> > > hci_core's killswitch state.
> > >
> > > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > > rfkill_init_sw_state before register rfkill, then rfkill_register will
> > > try to sync state to the same killswitch type like the above.
> > >
> > > It's make sense,
> > > because rfkill-input only can block/unblock the same killswitch type at
> > > the same time, before rfkill-input active, it want all the same type's
> > > state is full the same.
> > >
> > > And,
> > > rfkill-input also suppose user only can use keycode (maybe Fn key) to
> > > control killswitch state, so, direct use rkill tool or echo state to
> > > killswitch for change the state will cause killswitchs' state lost link.
> > > It like we do.
> > >
> > > > There is some magic in rfkill/input.c that plays with global states, but
> > > > I don't know if or how that one is used in my case.
> > >
> > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> > > code. You will see the new bluetooth killswitch will be unblock when it
> > > created.
> > >
> > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > > index 0198191..0dec078 100644
> > > --- a/net/rfkill/core.c
> > > +++ b/net/rfkill/core.c
> > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> > > *rfkill)
> > >
> > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > schedule_work(&rfkill->sync_work);
> > > - } else {
> > > -#ifdef CONFIG_RFKILL_INPUT
> > > - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > -
> > > - if (!atomic_read(&rfkill_input_disabled))
> > > - __rfkill_switch_all(rfkill->type, soft_blocked);
> > > -#endif
> > > - }
> > > + } //else {
> > > +//#ifdef CONFIG_RFKILL_INPUT
> > > +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > +//
> > > +// if (!atomic_read(&rfkill_input_disabled))
> > > +// __rfkill_switch_all(rfkill->type, soft_blocked);
> > > +//#endif
> > > +// }
> > >
> > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> >
> > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
> > enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
> > is working bluetooth HW switch.
> >
>
> Yes, that because the following patch introduce
> driver with persistent state will affect the global state only if rfkill-input
> is enabled:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
>
> It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> to any new bluetooth killswitch.
>
> It's not make sense.
>
> > > > > Acer's BIOS default setup bluetooth's state is disable when system cold
> > > > > boot, and BIOS also can save the connection devices' state when system
> > > > > reboot. Currently, acer-wmi driver have right behavior to sync the
> > > > > state with BIOS.
> > > > >
> > > > > Face to your situation, my suggestion is:
> > > > >
> > > > > - Use userland application to correct killswitch state.
> > > > >
> > > > > highly suggest You can try urfkill daemon:
> > > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > > >
> > > > > write a startup script to enable bluetooth when system boot.
> > > > >
> > > > > - Disable rfkill-input module if you didn't real use it.
> > > > >
> > > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> > > > > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> > > > > enable bluetooth killswitch.
> > > >
> > > > I didn't have time to look at the problem more deeply to identify who is
> > > > setting the global state to "blocked" or what really happens. Anyway, I
> > > > did some testing with pressing the HW bluetooth switch and I saw the
> > > > following immediately _after_ pressing the HW switch to enable
> > > > bluetooth:
> > > >
> > > > oldium ~ # rfkill list
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > 3: phy0: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > I had this output 3 times immediately after each other. I'm using
> > > > keyboard "up" and "enter" to repeat the last shell command, so this is a
> > > > relatively slow operation. So the state when the acer-bluetooth was
> > > > unbloc> > > >
> > > > oldium ~ # rfkill list
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked> > >
> > > > 5: hci0: Bluetooth
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > >
> > > My Acer machine have no HW bluetooth key but only have one HW WLAN key
> > > that emit KEY_WLAN.
> > > Please use lshal to monitor your HW bluetooth key and make sure it emit
> > > KEY_BLUETOOTH.
> >
> > `lshal -m` outputs this:
> >
> > <bluetooth key pressed>
> > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > ButtonPressed = bluetooth
> > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> > killswitch.state = 1 (0x1)
> > 20:45:54.678: usb_device_a5c_2101_noserial added
> > ...
> > <bluetooth key pressed again>
> > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > ButtonPressed = brightness-up
> > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> > killswitch.state = 0 (0x0)
> > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> > ...
> >
> > Strange is "brightness-up" key, somebody is wrong here.
> >
>
> Yes, brightness-up key is another story, maybe you can enable acpi debug
> to look at montior which acpi method or _Q event method used:
>
> echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
> echo 0xF >/sys/module/acpi/parameters/debug_level
>
> But, this is not related to our current killswitch issue, let us skip
> it.
>
> > > > So it looks like the hci0 went blocked even when the acer-bluetooth
> > > > switch was unblocked. So it looks like the hci0 state is independent on
> > > > the initial acer- bluetooth state.
> > > >
> > > > Hopefully I have some time this evening (CET timezone) to add some stack
> > > > traces and logs to see what really happens on my system.
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill tool
> > > to set acer-wmi bluetooth killswitch for test, must have different
> > > result.
> >
> > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
> > net/rfkill and there is a line "default y if !EXPERT" which means (I think)
> > that it would be enabled by default for anybody not enabling expert options.
> > So other non-expert users would have the same troubles as I have.
> >
>
> I agreed your point, and I don't think rfkill-input need enable for all
> non-Expert user because it sometimes have conflict with EC or userland
> behavior.
>
> I still suggest you can disable rfkill-input then please try Gary Lin's
> urfkill daemon, it can do what does rfkill-input do and more
> flexibility.
>
> > I've tried `rfkill unblock <acer-bluetooth number>` with my second test
> > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
> >
> > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some degree,
> > because enabling the config switch changes bluetooth HW/SW switch from working
> > to not-fully-working.
> >
> > Cheers,
> > Oldřich.
> >
>
> The root cause is what I said in the above, it's hard to fix in kernel
> module because user only can choice enable/disable rfkill-input in
> Kconfig and even cann't choice it when system boot.
>
> I thought we need:
> - set rfkill-input to EXPERT, remove !EXPERT
> - add a kernel option to rfkill for user can choice enable it or not
> when system boot.
> - Add comment in Documentation/rfkill.txt for remind user can use
> urfkill daemon (or any other userland daemon) to replace rfkill-input.
>
> Of course need rfkill experts' more professional comments for this
> topic.
> I will try to gener> Thank's a lot!
> Joey Lee
Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited
flag to workaround issue, please kindly help to test the following
acer-wmi patch, it works fine to me on my acer travelmate 8572 machine.
Maybe it will be our backup solution after you tested:
>From dd3d9208aa63d9670d24409b4aaaeb619f3137d6 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee@novell.com>
Date: Tue, 22 Mar 2011 01:43:11 +0800
Subject: [PATCH] acer-wmi: remove rfkill_init_sw_state to workaround rfkill-input issue
acer-wmi: remove rfkill_init_sw_state to workaround issue for bko#31002
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
drivers/platform/x86/acer-wmi.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 38b34a7..3d3cb46 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -222,6 +222,7 @@ struct acer_debug {
static struct rfkill *wireless_rfkill;
static struct rfkill *bluetooth_rfkill;
static struct rfkill *threeg_rfkill;
+static int rfkill_inited;
/* Each low-level interface must define at least some of the following */
struct wmi_interface {
@@ -1161,9 +1162,13 @@ static int acer_rfkill_set(void *data, bool blocked)
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!blocked, cap);
- if (ACPI_FAILURE(status))
- return -ENODEV;
+
+ if (rfkill_inited) {
+ status = set_u32(!blocked, cap);
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+ }
+
return 0;
}
@@ -1187,14 +1192,16 @@ static struct rfkill *acer_rfkill_register(struct device *dev,
return ERR_PTR(-ENOMEM);
status = get_device_status(&state, cap);
- if (ACPI_SUCCESS(status))
- rfkill_init_sw_state(rfkill_dev, !state);
err = rfkill_register(rfkill_dev);
if (err) {
rfkill_destroy(rfkill_dev);
return ERR_PTR(err);
}
+
+ if (ACPI_SUCCESS(status))
+ rfkill_set_sw_state(rfkill_dev, !state);
+
return rfkill_dev;
}
@@ -1229,6 +1236,8 @@ static int acer_rfkill_init(struct device *dev)
}
}
+ rfkill_inited = 1;
+
schedule_delayed_work(&acer_rfkill_work, round_jiffies_relative(HZ));
return 0;
--
1.6.0.2
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
@ 2011-03-21 17:52 ` Joey Lee
0 siblings, 0 replies; 48+ messages in thread
From: Joey Lee @ 2011-03-21 17:52 UTC (permalink / raw)
To: oldium.pro
Cc: davem, marcel, Al Cho, Gary Lin, johannes, mjg59, linux-acpi,
linux-bluetooth, platform-driver-x86
Hi Oldřich,
於 一，2011-03-21 於 05:26 -0600，Joey Lee 提到：
> Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and
> Gary Lin
>
> Hi Oldřich,
>
> 於 日，2011-03-20 於 21:09 +0100，Oldřich Jedlička 提到：
> > Hi Joey Lee,
> >
> > Finally I've got little time to expriment.
> >
>
> Thank's for you also reserve time to trace it. And, I also add comment
> on bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=31002
>
> > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote:
> > > Hi Oldřich,
> > >
> > > 於 三，2011-03-16 於 07:32 +0100，Oldřich Jedlička 提到：
> > >
> > > > > After trace rfkill-input stuff, I thought this is rfkill-input's normal
> > > > > behavior but not a bug.
> > > > >
> > > > > Unfortunately, I didn't find any workaround way when a driver need to
> > > > > call rfkill_init_sw_state, e.g. acer-wmi driver.
> > > > >
> > > > > The rfkill-input will sync the rfkill state to all killswitchs that
> > > > > have the same type. For example, acer-wmi set the initial software
> > > > > switch to _BLOCK_ when driver initial, then rfkill-input will also set
> > > > > any new bluetooth killswitch state to _BLOCK_ .
> > > >
> > > > The rfkill_sync_work syncs with rfkill_global_states, which is set during
> > > > intitialization or by rfkill_switch_all, if I read it correctly. This
> > > > should be independent to acer-bluetooth state. The
> > > > rfkill_global_states[BLUETOOTH] should be unblocked initially, I need to
> > > > verify it.
> > >
> > > Yes!
> > > Ideally, killswitch state should be independent to different driver,
> > > even the killswitch type is the same.
> > >
> > > But,
> > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will replicate
> > > state for each killswitch that have the same type:
> > >
> > > vi net/rfkill/core.c
> > >
> > > int __must_check rfkill_register(struct rfkill *rfkill)
> > > {
> > > ...
> > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > schedule_work(&rfkill->sync_work);
> > > } else { /* if rfkill->persistent then set the state to all
> > the
> > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = Y */
> > > bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > >
> > > if (!atomic_read(&rfkill_input_disabled))
> > > __rfkill_switch_all(rfkill->type, soft_blocked); /*
> > > here call switch all to sync state */ #endif
> > > }
> > >
> > > When any driver call rfkill_init_sw_state for set the initial state to
> > > killswitch, this rfkill->persistent will set to true:
> > >
> > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* acer-
> > wmi
> > > driver used it to set inital killswitch state */ {
> > > ....
> > > spin_lock_irqsave(&rfkill->lock, flags);
> > > __rfkill_set_sw_state(rfkill, blocked);
> > > rfkill->persistent = true /* persistent set to true */
> > >
> > >
> > > That's why acer-wmi bluetooth killswitch's state was been replicate to
> > > hci_core's killswitch state.
> > >
> > > When CONFIG_RFKILL_INPUT set to Y, and any driver call
> > > rfkill_init_sw_state before register rfkill, then rfkill_register will
> > > try to sync state to the same killswitch type like the above.
> > >
> > > It's make sense,
> > > because rfkill-input only can block/unblock the same killswitch type at
> > > the same time, before rfkill-input active, it want all the same type's
> > > state is full the same.
> > >
> > > And,
> > > rfkill-input also suppose user only can use keycode (maybe Fn key) to
> > > control killswitch state, so, direct use rkill tool or echo state to
> > > killswitch for change the state will cause killswitchs' state lost link.
> > > It like we do.
> > >
> > > > There is some magic in rfkill/input.c that plays with global states, but
> > > > I don't know if or how that one is used in my case.
> > >
> > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following
> > > code. You will see the new bluetooth killswitch will be unblock when it
> > > created.
> > >
> > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> > > index 0198191..0dec078 100644
> > > --- a/net/rfkill/core.c
> > > +++ b/net/rfkill/core.c
> > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill
> > > *rfkill)
> > >
> > > if (!rfkill->persistent || rfkill_epo_lock_active) {
> > > schedule_work(&rfkill->sync_work);
> > > - } else {
> > > -#ifdef CONFIG_RFKILL_INPUT
> > > - bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > -
> > > - if (!atomic_read(&rfkill_input_disabled))
> > > - __rfkill_switch_all(rfkill->type, soft_blocked);
> > > -#endif
> > > - }
> > > + } //else {
> > > +//#ifdef CONFIG_RFKILL_INPUT
> > > +// bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > +//
> > > +// if (!atomic_read(&rfkill_input_disabled))
> > > +// __rfkill_switch_all(rfkill->type, soft_blocked);
> > > +//#endif
> > > +// }
> > >
> > > rfkill_send_events(rfkill, RFKILL_OP_ADD);
> >
> > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to
> > enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result
> > is working bluetooth HW switch.
> >
>
> Yes, that because the following patch introduce
> driver with persistent state will affect the global state only if rfkill-input
> is enabled:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
>
> It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's
> bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state)
> to any new bluetooth killswitch.
>
> It's not make sense.
>
> > > > > Acer's BIOS default setup bluetooth's state is disable when system cold
> > > > > boot, and BIOS also can save the connection devices' state when system
> > > > > reboot. Currently, acer-wmi driver have right behavior to sync the
> > > > > state with BIOS.
> > > > >
> > > > > Face to your situation, my suggestion is:
> > > > >
> > > > > - Use userland application to correct killswitch state.
> > > > >
> > > > > highly suggest You can try urfkill daemon:
> > > > > http://www.freedesktop.org/wiki/Software/urfkill or
> > > > >
> > > > > write a startup script to enable bluetooth when system boot.
> > > > >
> > > > > - Disable rfkill-input module if you didn't real use it.
> > > > >
> > > > > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
> > > > > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
> > > > > enable bluetooth killswitch.
> > > >
> > > > I didn't have time to look at the problem more deeply to identify who is
> > > > setting the global state to "blocked" or what really happens. Anyway, I
> > > > did some testing with pressing the HW bluetooth switch and I saw the
> > > > following immediately _after_ pressing the HW switch to enable
> > > > bluetooth:
> > > >
> > > > oldium ~ # rfkill list
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > > >
> > > > 3: phy0: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > I had this output 3 times immediately after each other. I'm using
> > > > keyboard "up" and "enter" to repeat the last shell command, so this is a
> > > > relatively slow operation. So the state when the acer-bluetooth was
> > > > unbloc> > > >
> > > > oldium ~ # rfkill list
> > > > 0: acer-wireless: Wireless LAN
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 1: acer-bluetooth: Bluetooth
> > > >
> > > > Soft blocked: no
> > > > Hard blocked: no
> > > >
> > > > 2: acer-threeg: Wireless WAN
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked> > >
> > > > 5: hci0: Bluetooth
> > > >
> > > > Soft blocked: yes
> > > > Hard blocked: no
> > >
> > > My Acer machine have no HW bluetooth key but only have one HW WLAN key
> > > that emit KEY_WLAN.
> > > Please use lshal to monitor your HW bluetooth key and make sure it emit
> > > KEY_BLUETOOTH.
> >
> > `lshal -m` outputs this:
> >
> > <bluetooth key pressed>
> > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > ButtonPressed = bluetooth
> > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> > killswitch.state = 1 (0x1)
> > 20:45:54.678: usb_device_a5c_2101_noserial added
> > ...
> > <bluetooth key pressed again>
> > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition
> > ButtonPressed = brightness-up
> > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth property
> > killswitch.state = 0 (0x0)
> > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed
> > ...
> >
> > Strange is "brightness-up" key, somebody is wrong here.
> >
>
> Yes, brightness-up key is another story, maybe you can enable acpi debug
> to look at montior which acpi method or _Q event method used:
>
> echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer
> echo 0xF >/sys/module/acpi/parameters/debug_level
>
> But, this is not related to our current killswitch issue, let us skip
> it.
>
> > > > So it looks like the hci0 went blocked even when the acer-bluetooth
> > > > switch was unblocked. So it looks like the hci0 state is independent on
> > > > the initial acer- bluetooth state.
> > > >
> > > > Hopefully I have some time this evening (CET timezone) to add some stack
> > > > traces and logs to see what really happens on my system.
> > > >
> > > > Cheers,
> > > > Oldřich.
> > >
> > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill tool
> > > to set acer-wmi bluetooth killswitch for test, must have different
> > > result.
> >
> > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in
> > net/rfkill and there is a line "default y if !EXPERT" which means (I think)
> > that it would be enabled by default for anybody not enabling expert options.
> > So other non-expert users would have the same troubles as I have.
> >
>
> I agreed your point, and I don't think rfkill-input need enable for all
> non-Expert user because it sometimes have conflict with EC or userland
> behavior.
>
> I still suggest you can disable rfkill-input then please try Gary Lin's
> urfkill daemon, it can do what does rfkill-input do and more
> flexibility.
>
> > I've tried `rfkill unblock <acer-bluetooth number>` with my second test
> > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly.
> >
> > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some degree,
> > because enabling the config switch changes bluetooth HW/SW switch from working
> > to not-fully-working.
> >
> > Cheers,
> > Oldřich.
> >
>
> The root cause is what I said in the above, it's hard to fix in kernel
> module because user only can choice enable/disable rfkill-input in
> Kconfig and even cann't choice it when system boot.
>
> I thought we need:
> - set rfkill-input to EXPERT, remove !EXPERT
> - add a kernel option to rfkill for user can choice enable it or not
> when system boot.
> - Add comment in Documentation/rfkill.txt for remind user can use
> urfkill daemon (or any other userland daemon) to replace rfkill-input.
>
> Of course need rfkill experts' more professional comments for this
> topic.
> I will try to gener> Thank's a lot!
> Joey Lee
Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited
flag to workaround issue, please kindly help to test the following
acer-wmi patch, it works fine to me on my acer travelmate 8572 machine.
Maybe it will be our backup solution after you tested:
From dd3d9208aa63d9670d24409b4aaaeb619f3137d6 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee@novell.com>
Date: Tue, 22 Mar 2011 01:43:11 +0800
Subject: [PATCH] acer-wmi: remove rfkill_init_sw_state to workaround rfkill-input issue
acer-wmi: remove rfkill_init_sw_state to workaround issue for bko#31002
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
drivers/platform/x86/acer-wmi.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 38b34a7..3d3cb46 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -222,6 +222,7 @@ struct acer_debug {
static struct rfkill *wireless_rfkill;
static struct rfkill *bluetooth_rfkill;
static struct rfkill *threeg_rfkill;
+static int rfkill_inited;
/* Each low-level interface must define at least some of the following */
struct wmi_interface {
@@ -1161,9 +1162,13 @@ static int acer_rfkill_set(void *data, bool blocked)
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!blocked, cap);
- if (ACPI_FAILURE(status))
- return -ENODEV;
+
+ if (rfkill_inited) {
+ status = set_u32(!blocked, cap);
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+ }
+
return 0;
}
@@ -1187,14 +1192,16 @@ static struct rfkill *acer_rfkill_register(struct device *dev,
return ERR_PTR(-ENOMEM);
status = get_device_status(&state, cap);
- if (ACPI_SUCCESS(status))
- rfkill_init_sw_state(rfkill_dev, !state);
err = rfkill_register(rfkill_dev);
if (err) {
rfkill_destroy(rfkill_dev);
return ERR_PTR(err);
}
+
+ if (ACPI_SUCCESS(status))
+ rfkill_set_sw_state(rfkill_dev, !state);
+
return rfkill_dev;
}
@@ -1229,6 +1236,8 @@ static int acer_rfkill_init(struct device *dev)
}
}
+ rfkill_inited = 1;
+
schedule_delayed_work(&acer_rfkill_work, round_jiffies_relative(HZ));
return 0;
--
1.6.0.2
^ permalink raw reply related [flat|nested] 48+ messages in thread
* acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
@ 2011-03-10 18:37 Oldřich Jedlička
0 siblings, 0 replies; 48+ messages in thread
From: Oldřich Jedlička @ 2011-03-10 18:37 UTC (permalink / raw)
To: linux acpi
Hi all,
This is about Acer WMI driver and bluetooth support. I hope I'm at the right
place with my question :-)
I tried to use bluetooth again on my Acer TravelMate 5730G and discovered a
usability problem. I've checked 2.6.38-rc7:
0. On startup, the bluetooth LED is off, acer-bluetooth SW rfkill is blocked.
1. I have to enable the HW bluetooth switch to get the bluetooth LED running
(USB device appears in lsusb). The acer-bluetooth SW rfkill is unblocked, the
SW rfkill of hci0 is blocked.
2. Next I have to unblock SW rfkill on hci0 by a call to `rfkill unblock
<number of hci0>`.
3. Last I have to enable the HCI by the call to `hciconfig hci0 up`.
How is this supposed to work? I tried to use "rfkill.default_state=1" on
kernel command line, but without any success.
When I boot into 2.6.37, the bluetooth LED goes ON automatically and hciconfig
shows the hci0 as UP.
Thanks.
Best regards,
Oldřich.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2011-03-31 20:27 UTC | newest]
Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-10 22:02 acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37 Joey Lee
2011-03-11 20:21 ` Oldřich Jedlička
2011-03-11 20:34 ` Joey Lee
2011-03-11 20:54 ` Oldřich Jedlička
2011-03-11 21:25 ` Joey Lee
2011-03-11 21:34 ` Oldřich Jedlička
2011-03-11 21:45 ` Joey Lee
[not found] ` <4D7B32B10200002300029B5E-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
2011-03-15 11:11 ` Joey Lee
[not found] ` <4D7FE4260200002300029D70-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
2011-03-16 6:32 ` Oldřich Jedlička
2011-03-16 8:59 ` Joey Lee
2011-03-20 20:09 ` Oldřich Jedlička
2011-03-21 11:26 ` Joey Lee
2011-03-21 11:43 ` Johannes Berg
2011-03-21 13:57 ` Joey Lee
2011-03-21 14:35 ` Johannes Berg
2011-03-21 16:25 ` Joey Lee
[not found] ` <4D881693020000230002A2FC-jb/6P8Q/KsjOKUPnnb0SpZ/xhEQF/MHJojBamW5iJbs@public.gmane.org>
2011-03-23 12:17 ` Johannes Berg
[not found] ` <1300882647.3790.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-03-24 7:01 ` Joey Lee
2011-03-24 8:35 ` Johannes Berg
2011-03-24 12:55 ` Joey Lee
2011-03-24 12:58 ` Johannes Berg
2011-03-24 13:36 ` Joey Lee
2011-03-21 19:27 ` Oldřich Jedlička
[not found] ` <201103212027.01952.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
2011-03-23 11:58 ` Johannes Berg
2011-03-23 21:38 ` Oldřich Jedlička
2011-03-24 8:36 ` Johannes Berg
[not found] ` <1300955793.3807.6.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-03-24 13:13 ` Joey Lee
2011-03-24 13:13 ` Joey Lee
[not found] ` <201103242234.03598.oldium.pro@seznam.cz>
2011-03-25 6:29 ` Oldřich Jedlička
[not found] ` <201103242234.03598.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
2011-03-25 8:13 ` Joey Lee
2011-03-25 19:22 ` Oldřich Jedlička
2011-03-25 22:35 ` Joey Lee
2011-03-27 17:09 ` Dmitry Torokhov
2011-03-28 8:51 ` Joey Lee
2011-03-31 5:23 ` Oldřich Jedlička
[not found] ` <AANLkTi=QREK2r6zbvo6RyTNMG4=NCf+kCUWi52ZwjOhS@mail.gmail.com>
2011-03-31 7:51 ` Joey Lee
2011-03-31 8:09 ` Joey Lee
2011-03-31 9:10 ` Joey Lee
2011-03-31 20:27 ` Oldřich Jedlička
[not found] ` <201103252022.26766.oldium.pro-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org>
2011-03-28 9:04 ` Joey Lee
2011-03-30 18:49 ` Oldřich Jedlička
2011-03-11 22:00 ` Oldřich Jedlička
-- strict thread matches above, loose matches on Subject: below --
2011-03-21 17:52 Joey Lee
2011-03-21 17:52 ` Joey Lee
2011-03-21 20:44 ` Oldřich Jedlička
2011-03-22 2:32 ` Joey Lee
2011-03-24 21:56 ` Oldřich Jedlička
2011-03-10 18:37 Oldřich Jedlička
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.