Bug 384111

The system is a Thinkpad T60

This is a kernel bug, not related to bluez-gnome.

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.

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 :)

Hi Neil,

I confirmed this worked! wonderful.

Thanks!

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.

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

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?

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?

yes. I am using the bluetooth-applet. In the previous version I do not need this
script to get bluetooth to work....

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.

Changing subject to reflect patch available and changing component to acpid for
patch review and comment.

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.

(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.

(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!?

(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.

(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.

(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.

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).

*** Bug 371061 has been marked as a duplicate of this bug. ***

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

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 ***