Hi,
anyone working on toshiba_acpi or omnibook module ?
toshiba_acpi:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=commit;h=c41a40c58b623f97dd2e23aa3baab2cedb47d99f
The rfkill-switch does not work. The device is disabled when switched of,
but it gets not reenabled. But the bluetooth dongle is enabled after booting.
AFAIK this only works for Toshiba manufactured devices (toshiba_acpi), not
for Compal manufactured.
Omnibook:
Omnibook module functionality for Compal manufactured lptops should still
be included in the kernel. The Compal supporting module omnibook
additionaly works on many laptops from HP, ... The omnibook-module seems to
be abandoned, the last commit is nearly two years ago.
Omnibook-module: http://sourceforge.net/projects/omnibook
cu romal
http://www.romal.de
blog.romal.de
On Mon, 15 Dec 2008 21:29:05 +0100, "Robert M. Albrecht" <[email protected]>
wrote:
> Hi,
>
> anyone working on toshiba_acpi or omnibook module ?
>
> toshiba_acpi:
>
>
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=commit;h=c41a40c58b623f97dd2e23aa3baab2cedb47d99f
>
> The rfkill-switch does not work. The device is disabled when switched of,
> but it gets not reenabled. But the bluetooth dongle is enabled after
> booting.
>
> AFAIK this only works for Toshiba manufactured devices (toshiba_acpi),
not
> for Compal manufactured.
The officially stated maintainer for toshiba_acpi seems to be out of
contact,
but I'm responsible for the rfkill patch. I can only say that the patch is
designed
to re-enable bluetooth when the hardware kill switch is de-asserted and
that I tested
this to work before the change was merged. If it doesn't work now, it's
either:
a) a regression introduced by one of the fixes for laptops with no
bluetooth device. I
consider this unlikely.
b) different behaviour in your model of toshiba vs. mine
c) a difference in how you've got the kill switch configured in sysfs. Not
sure if that's
even possible.
As you might conclude, I suspect B.
--phil
Hi Phil,
anything I can do ? Providing some logs or granting ssh access to the
machine to have a look ?
cu romal
http://www.romal.de
blog.romal.de
Am 15.12.2008 23:35 Uhr, schrieb Philip Langdale:
> On Mon, 15 Dec 2008 21:29:05 +0100, "Robert M. Albrecht"<[email protected]>
> wrote:
>> Hi,
>>
>> anyone working on toshiba_acpi or omnibook module ?
>>
>> toshiba_acpi:
>>
>>
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=commit;h=c41a40c58b623f97dd2e23aa3baab2cedb47d99f
>> The rfkill-switch does not work. The device is disabled when switched of,
>
>> but it gets not reenabled. But the bluetooth dongle is enabled after
>> booting.
>>
>> AFAIK this only works for Toshiba manufactured devices (toshiba_acpi),
> not
>> for Compal manufactured.
>
> The officially stated maintainer for toshiba_acpi seems to be out of
> contact,
> but I'm responsible for the rfkill patch. I can only say that the patch is
> designed
> to re-enable bluetooth when the hardware kill switch is de-asserted and
> that I tested
> this to work before the change was merged. If it doesn't work now, it's
> either:
>
> a) a regression introduced by one of the fixes for laptops with no
> bluetooth device. I
> consider this unlikely.
>
> b) different behaviour in your model of toshiba vs. mine
>
> c) a difference in how you've got the kill switch configured in sysfs. Not
> sure if that's
> even possible.
>
> As you might conclude, I suspect B.
>
> --phil
>
On Mon, 15 Dec 2008 23:34:52 +0100, "Robert M. Albrecht" <[email protected]>
wrote:
> Hi Phil,
>
> anything I can do ? Providing some logs or granting ssh access to the
> machine to have a look ?
If necessary, that would be useful. However, the first question to ask is
actually
related to my possibility C) - which I'm now re-evaluating as much more
likely.
If you don't load the 'rfkill-input' module, then there is no policy
applied to
killswitch handling. The core driver puts the device in the SOFT_BLOCKED
state
when the de-assert the hardware switch. rfkill-input contains the policy
that
decides to go one step further and re-enable the device. This module has no
hardware dependencies so it is not automatically loaded - you must do it
explicitly yourself.
If that's not your problem, then we'll have to dig deeper.
--phil
Hi,
the module is loaded:
[root@tycho ~]# lsmod | grep kill
rfkill 11288 2 toshiba_acpi
[root@tycho ~]#
The wlan-devices works ok, it get's disabled and enabled via rfkill. But
the bluetooth-device does not get reeanbled after switching it off.
cu romal
Am 15.12.2008 23:47 Uhr, schrieb Philip Langdale:
> On Mon, 15 Dec 2008 23:34:52 +0100, "Robert M. Albrecht"<[email protected]>
> wrote:
>> Hi Phil,
>>
>> anything I can do ? Providing some logs or granting ssh access to the
>> machine to have a look ?
>
> If necessary, that would be useful. However, the first question to ask is
> actually
> related to my possibility C) - which I'm now re-evaluating as much more
> likely.
>
> If you don't load the 'rfkill-input' module, then there is no policy
> applied to
> killswitch handling. The core driver puts the device in the SOFT_BLOCKED
> state
> when the de-assert the hardware switch. rfkill-input contains the policy
> that
> decides to go one step further and re-enable the device. This module has no
> hardware dependencies so it is not automatically loaded - you must do it
> explicitly yourself.
>
> If that's not your problem, then we'll have to dig deeper.
>
> --phil
>
>
Robert M. Albrecht wrote:
> Hi,
>
> the module is loaded:
>
> [root@tycho ~]# lsmod | grep kill
> rfkill 11288 2 toshiba_acpi
> [root@tycho ~]#
>
> The wlan-devices works ok, it get's disabled and enabled via rfkill. But
> the bluetooth-device does not get reeanbled after switching it off.
Umm. I'll quote you quoting me.
>
> Am 15.12.2008 23:47 Uhr, schrieb Philip Langdale:
>>
>> If you don't load the 'rfkill-input' module, then there is no policy
>> applied to killswitch handling.
--phil