Kernel Bug Tracker – Bug 10173
Toshiba Bluetooth adapter is disabled - Toshiba Satellite A100-847 (request for omnibook driver)
Last modified: 2013-04-09 06:23:26 UTC
Latest working kernel version: none
Earliest failing kernel version: none
Distribution: Fedora 8
Hardware Environment: Toshiba Satellite A100-847
Software Environment: Fedora 8
Toshiba Bluetooth adapter is in disabled state by default. It works perfectly well if enabled, which can be accomplished by means of either omnibook module . Merely loading it makes the adapter show up. It can be enabled/disabled as well. Unfortunately, omnibook developers do not have time to merge the driver upstream , but maybe it would be possible just to merge some parts of it?
Steps to reproduce:
1. Get a Toshiba Satellite A100 laptop (or a similar one)
2. Fire it up
On Wed, 5 Mar 2008 08:58:42 -0800 (PST) firstname.lastname@example.org wrote:
> Summary: Toshiba Bluetooth adapter is disabled
> Product: Drivers
> Version: 2.5
> KernelVersion: 188.8.131.52-137.fc8
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Bluetooth
> AssignedTo: email@example.com
> ReportedBy: firstname.lastname@example.org
> Latest working kernel version: none
> Earliest failing kernel version: none
> Distribution: Fedora 8
> Hardware Environment: Toshiba Satellite A100-847
> Software Environment: Fedora 8
> Problem Description:
> Toshiba Bluetooth adapter is in disabled state by default. It works perfectly
> well if enabled, which can be accomplished by means of either omnibook module
> . Merely loading it makes the adapter show up. It can be enabled/disabled as
> well. Unfortunately, omnibook developers do not have time to merge the driver
> upstream , but maybe it would be possible just to merge some parts of it?
>  http://omnibook.sourceforge.net/doku.php
> Steps to reproduce:
> 1. Get a Toshiba Satellite A100 laptop (or a similar one)
> 2. Fire it up
The same problem applies to all Toshiba notebooks.
There are two families of Toshiba notebooks, the ones made by Compal (Phoenix BIOS), and the original Toshiba manufactured.
The Compal-OEMs are supported by Omnibook (along with some others laptops by HP, ...).
The Toshiba modells need toshiba_acpi. toshiba_acpi is included in the kernel is outdated and does not work on newer modells. The newer one: http://memebeam.org/toys/ExperimentalToshibaAcpiDriver
Both drivers are maintained outside the kernel. Could this change ?
I think this is more an acpi-problem as a bluetooth-bug, the product should be changed from bluetooth to acpi.
For reference, this bug is still present in 184.108.40.206-55.fc9.
can you submit the toshiba-acpi patch to acpi maillist, so it can be merged?
yes, it seems that we need somebody who owns one (at least one) toshiba laptop to volunteer to submit the new toshiba-acpi driver patch and maintain it, better from the omnibook developers.
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.
Is this supposed to fix Compal-manufactured Toshibas as well (aka the ones using omnibook module)?
AFAIK this only works for Toshiba manufactured devices (toshiba_acpi), not for Compal manufactured.
Omnibook module (Compal manufactured) should still be upstreamed. The Compal supporting module omnibook additionaly works on many laptops from HP, ...
Well, I opened this bug for my compal-made Satellite A100, so I believe it's not resolved yet. I could open another bug if you wish, though.
When it comes to upstreaming omnibook, it can be a problem. It has not seen a single commit for a really good while, and the code is not good enough to go into the kernel (that's what maintainers said). So, I think the only hope lies in the linux driver project.
Hmm, so it looks like resolving the original intent of this bug report
requires getting the omnibook driver upstream.
The driver will need a maintainer, and will need to be submitted for
inclusion upstream, via the staging tree, or otherwise.
When the driver actually exists upstream, then it will make sense
to file bugs against it, but not before. (closing this one)