Bug 384111 - [PATCH] bluetooth subsystem not working in Fedora 8 on T60
[PATCH] bluetooth subsystem not working in Fedora 8 on T60
Status: CLOSED DUPLICATE of bug 399601
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 371061 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-15 01:31 EST by Edmond Hui
Modified: 2013-01-13 08:51 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-01 03:34:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Edmond Hui 2007-11-15 01:31:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8

Description of problem:
After upgrade from Fedora 7, bluetooth subsystem failed to turn on when Fn-F5 is hit.

The following log is observed:
Nov 15 01:19:39 localhost acpid: notifying client 2561[68:68]
Nov 15 01:19:39 localhost acpid: notifying client 2792[0:0]
Nov 15 01:19:39 localhost acpid: completed event "ibm/hotkey HKEY 00000080 00001005"

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
install Fedora 8
login GNOME
hit Fn-F5 to turn on the on-board bluetooth device

Actual Results:


Expected Results:


Additional info:
Comment 1 Edmond Hui 2007-11-15 01:32:15 EST
The system is a Thinkpad T60
Comment 2 Bastien Nocera 2007-11-15 05:53:57 EST
This is a kernel bug, not related to bluez-gnome.
Comment 3 Christian Wilhelm 2007-11-15 17:58:50 EST
I've the problem too (on a T42p). During you start Fedora, you can turn on the 
bluetooth device, but you have to be speedy. If someone kernel module loaded, 
then isn't possible to switch the bluetooth adapter on/off.
Comment 4 Neil Viglieno 2007-11-17 09:35:11 EST
I got the Fn-F5 combo to work on my T60 using acpid events.

Create /etc/acpi/events/bluetooth.conf containing:
event=ibm/hotkey HKEY 00000080 00001005
action=/etc/acpi/actions/bluetooth.sh


Create /etc/acpi/actions/bluetooth.sh, with 755 permissions, containing:
#!/bin/bash
# toggle bluetooth
grep status /proc/acpi/ibm/bluetooth|grep -q enabled
if [ $? == 0 ]; then
  echo disabled > /proc/acpi/ibm/bluetooth
else
  echo enabled > /proc/acpi/ibm/bluetooth
fi

Restart acpid

Fn-F5 will now toggle your bluetooth on and off :)
Comment 5 Edmond Hui 2007-11-17 11:25:18 EST
Hi Neil,

I confirmed this worked! wonderful.

Thanks!
Comment 6 Christopher Brown 2008-02-13 17:19:25 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

It looks like the workaround had resolved the issue for you but do you know if
this has been fixed in any recent updates so you no longer have to manually add
the fix? I'm re-assigning this to the acpid maintainer for their comment if they
wish to add any.

If the problem no longer exists then please close this bug or I'll do so in a
few weeks if there is no additional information lodged.
Comment 7 Zdenek Prikryl 2008-02-14 06:08:33 EST
Hello,
the script above is ok and works fine with acpid. Unfortunately, in comments
above isn't written what software Edmond uses in F7 for catching acpi events, so
I cannot make any other conclusions. But I thing, that Fn-F5 isn't pure hardware
stuff. It has to be caught by some acpi event catcher. So, a solution with the
script is the correct solution.

Zdenek
Comment 8 Edmond Hui 2008-02-14 11:55:45 EST
What happen is before the upgrade, things just work out of the box, but now I
need to use a script to get it to work. I think what I will test is to roll back
the change as suggested by Neil, and thing should still work. Does this make sense?
Comment 9 Zdenek Prikryl 2008-02-15 09:17:22 EST
In my opinion, if you remove the scipt, it will not work. Because there will be 
no daemon, which would catch and interpret acpi events. Did/Do you use some 
bluetooth-applet or gnome-obex-server or something like these applets?
Comment 10 Edmond Hui 2008-02-15 12:17:25 EST
yes. I am using the bluetooth-applet. In the previous version I do not need this
script to get bluetooth to work....
Comment 11 Edmond Hui 2008-02-15 20:20:46 EST
I confirmed with out the hack fro Neil, the bluetooth function is not working...
so I guess someone has to add this fix for F9.
Comment 12 Christopher Brown 2008-02-15 20:31:16 EST
Changing subject to reflect patch available and changing component to acpid for
patch review and comment.
Comment 13 Zdenek Prikryl 2008-02-19 07:59:31 EST
I cannot accept this script into acpid package because it doesn't work for other
laptops. This is only workaround. I'll go through a changelog of
bluetooth-applet and try to find where is a problem. Acpid never contains this
kind of scripts, so an error has to be somewhere else.
Comment 14 Bastien Nocera 2008-02-19 09:21:57 EST
(In reply to comment #13)
> I cannot accept this script into acpid package because it doesn't work for other
> laptops. This is only workaround. I'll go through a changelog of
> bluetooth-applet and try to find where is a problem. Acpid never contains this
> kind of scripts, so an error has to be somewhere else.

You don't need to go through bluetooth-applet's changelog, it has nothing to do
with the problem. The kernel used to enable the bluetooth adapter in the
machines on startup and don't do it anymore. This is a kernel bug (or at least a
kernel change in behaviour), which is why I reassigned this bug to the kernel 3
months ago.
Comment 15 Zdenek Prikryl 2008-02-20 08:21:57 EST
(In reply to comment #14)
> You don't need to go through bluetooth-applet's changelog, it has nothing to do
> with the problem. The kernel used to enable the bluetooth adapter in the
> machines on startup and don't do it anymore. This is a kernel bug (or at least a
> kernel change in behaviour), which is why I reassigned this bug to the kernel 3
> months ago.
> 

In f7 is default acpi event catcher hal-addon-acpi, co maybe is a bug there. It
doesn't seems like kernel problem, because bluetooth can be enabled/disabled via
thinkpad_acpi module. If in older kernels is default to enable bluetooth on
startup and newer kernels don't do that, than in my opinion it is change in
behavior. in f8 is default acpi event catcher acpid, but hal-addon-acpi's
listening on acpid's socket, so it is practical same situation.

So, it could be a bug in hal and/or a his quirks!?
Comment 16 Christopher Brown 2008-02-24 10:58:40 EST
(In reply to comment #14)
> (In reply to comment #13)
> > I cannot accept this script into acpid package because it doesn't work for other
> > laptops. This is only workaround. I'll go through a changelog of
> > bluetooth-applet and try to find where is a problem. Acpid never contains this
> > kind of scripts, so an error has to be somewhere else.
> 
> You don't need to go through bluetooth-applet's changelog, it has nothing to do
> with the problem. The kernel used to enable the bluetooth adapter in the
> machines on startup and don't do it anymore. This is a kernel bug (or at least a
> kernel change in behaviour), which is why I reassigned this bug to the kernel 3
> months ago.
> 

I'll copy Dave and Chuck back into this for their comments.
Comment 17 Bastien Nocera 2008-02-24 13:13:29 EST
(In reply to comment #15)
<snip>
> In f7 is default acpi event catcher hal-addon-acpi, co maybe is a bug there. It
> doesn't seems like kernel problem, because bluetooth can be enabled/disabled via
> thinkpad_acpi module. If in older kernels is default to enable bluetooth on
> startup and newer kernels don't do that, than in my opinion it is change in
> behavior.

Yes, the kernel used to enable the Bluetooth adapter on boot, and doesn't anymore.

> in f8 is default acpi event catcher acpid, but hal-addon-acpi's
> listening on acpid's socket, so it is practical same situation.
>
> So, it could be a bug in hal and/or a his quirks!?

Why would it be a bug in hal? You can still run acpid and enable the script.
Make the kernel enable Bluetooth again by default until we have a UI for kill
switches is the way to solve this problem.
Comment 18 Zdenek Prikryl 2008-02-26 05:26:39 EST
(In reply to comment #17)
> 
> Yes, the kernel used to enable the Bluetooth adapter on boot, and doesn't 
> anymore.

I tested few things and found, that if you once enable bluetooth ($ echo
"enable" > /proc/acpi/ibm/bluetooth) then it will stay enabled even if you
reboot or power off/on a laptop.

> Why would it be a bug in hal? 

In hal-0.5.10 is a bug, witch disables keymaps for thinkpads (fdi files). In
hal's repository is a patch for it.
(http://lists.freedesktop.org/archives/hal-commit/2008-February/004155.html).
But it's true, that this doesn't solve this problem.

> You can still run acpid and enable the script.

As I wrote, I cannot accept this script into acpid, because it is only for one
type of laptops. And acpid never contained this kind of scripts. It contains
only common scripts which are independent on a hardware.

> Make the kernel enable Bluetooth again by default until we have a UI for kill
> switches is the way to solve this problem.

Yes, I agree, that if kernel enables bluetooth by default, it will be a way to
solve this problem. But it doesn't solve fn5 key problem.
Comment 19 Zdenek Prikryl 2008-03-06 05:05:03 EST
About fn5 key... There is a discussion on HAL list
(http://lists.freedesktop.org/archives/hal/2007-December/010429.html) which
tried to figure out who is responsible for enable/disable a bluetooth when this
key is pressed. For now there is no daemon or applet which takes care about this
key out-of-the-box. 

So I'm reassigning this to the kernel again. They should enable bluetooth by
default (I suppose, that changes will be in a thinkpad_acpi module).
Comment 20 Bastien Nocera 2008-05-20 20:00:09 EDT
*** Bug 371061 has been marked as a duplicate of this bug. ***
Comment 21 Bug Zapper 2008-11-26 03:26:50 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Edmond Hui 2008-12-01 03:34:20 EST
This seem to be duplicate with this:

https://bugzilla.redhat.com/show_bug.cgi?id=399601

So, I think this F8 bug report can be closed

*** This bug has been marked as a duplicate of bug 399601 ***

Note You need to log in before you can comment on or make changes to this bug.