My ThinkPad X61 laptop has a special wireless networking hotkey, Fn+F5.
Traditionally this has been used to enable/disable bluetooth. That's
how it worked with previous ThinkPads I've owned, but on this X61, when
I press Fn+F5, nothing happens.
The HAL daemon running on correctly detects the key press and broadcasts
this on the system D-BUS:
signal sender=:1.5 -> dest=(null destination)
path=/org/freedesktop/Hal/devices/computer;
interface=org.freedesktop.Hal.Device;
member=Condition
string "ButtonPressed"
string "wifi-power"
If I want Fn+F5 to toggle bluetooth, how should I hook that up? I
already know how to write a small Python script that reacts to HAL
ButtonPressed signals. But this script would need to run as root, since
normal uses cannot write to /proc/acpi/ibm/bluetooth. (One
enables/disables bluetooth by echoing "enable" or "disable" into
/proc/acpi/ibm/bluetooth.)
I'm loath to create new scripts running as root. Is that really the
right approach here? Or is there some other system component that
already ought to be listening for this signal but is either buggy or not
running?
I asked about this on the HAL mailing list, and Rui Tiago Matos replied:
> Shouldn't bluez-utils' hcid daemon handle this? Actually, I think
> these kind of daemons should be autostarted by D-Bus when HAL
> broadcasts their signal and exit gracefully when the user turns the
> killswitch off.
Do the bluez-utils developers agree? Is this something hcid should
already be listening for and handling? Should I file a bluez-utils bug
report requesting that it do this? Or do you consider this to be
outside of hcid's domain of responsibility?
Please note that my concern here is not actually the radio kill switch
that Rui Tiago Matos mentions. That seems to work fine. (The daemons
keep running and do not "exit gracefully", but at least the desktop
reacts appropriately when the radio kill switch takes bluetooth away.)
So the question here is the Fn+F5 wifi button, not the radio kill switch.
Thanks!
-- Ben
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi to all,
I use suse linux 10.1 and i connected bluetooth usb dongle and enabled
bluetooth server and i removed mouse from my system and i own sony erricsion
(K750i) mobile and it contains remote control application in it and using
that i am able to access desktop in windows vista and is this possible to
do in linux.please send your valuable comments
Regards
Umesh
On Jan 5, 2008 2:12 AM, Ben Liblit <[email protected]> wrote:
> Marcel Holtmann wrote:
> > The reason for this is that the Bluetooth on/off switches are all
> > different and HAL and rfkill is the way to abstract it into a common
> > interface. It is not the job of hcid to abstract this.
>
> OK, I see your point. HAL is supposed to keep other daemons from having
> to worry about such things. I've conveyed your reply back to the HAL
> mailing list.
>
> That said, it's unfortunate that the end result is an Fn+F5 key which
> does *nothing* useful out of the box. Even if different users would
> want it to do slightly different things, right now it does *nothing* by
> default. I'm savvy enough to write my own script that runs as root,
> hooks into HAL D-BUS signals, and responds accordingly. Most users
> won't do that, so for them, this key is useless.
>
> Oh well. Between HAL and Bluez, things are much better now than they
> ever were before. We're not done yet, but at least we're making progress.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
Marcel Holtmann wrote:
> The reason for this is that the Bluetooth on/off switches are all
> different and HAL and rfkill is the way to abstract it into a common
> interface. It is not the job of hcid to abstract this.
OK, I see your point. HAL is supposed to keep other daemons from having
to worry about such things. I've conveyed your reply back to the HAL
mailing list.
That said, it's unfortunate that the end result is an Fn+F5 key which
does *nothing* useful out of the box. Even if different users would
want it to do slightly different things, right now it does *nothing* by
default. I'm savvy enough to write my own script that runs as root,
hooks into HAL D-BUS signals, and responds accordingly. Most users
won't do that, so for them, this key is useless.
Oh well. Between HAL and Bluez, things are much better now than they
ever were before. We're not done yet, but at least we're making progress.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Ben,
> My ThinkPad X61 laptop has a special wireless networking hotkey, Fn+F5.
> Traditionally this has been used to enable/disable bluetooth. That's
> how it worked with previous ThinkPads I've owned, but on this X61, when
> I press Fn+F5, nothing happens.
>
> The HAL daemon running on correctly detects the key press and broadcasts
> this on the system D-BUS:
>
> signal sender=:1.5 -> dest=(null destination)
> path=/org/freedesktop/Hal/devices/computer;
> interface=org.freedesktop.Hal.Device;
> member=Condition
> string "ButtonPressed"
> string "wifi-power"
>
> If I want Fn+F5 to toggle bluetooth, how should I hook that up? I
> already know how to write a small Python script that reacts to HAL
> ButtonPressed signals. But this script would need to run as root, since
> normal uses cannot write to /proc/acpi/ibm/bluetooth. (One
> enables/disables bluetooth by echoing "enable" or "disable" into
> /proc/acpi/ibm/bluetooth.)
>
> I'm loath to create new scripts running as root. Is that really the
> right approach here? Or is there some other system component that
> already ought to be listening for this signal but is either buggy or not
> running?
>
> I asked about this on the HAL mailing list, and Rui Tiago Matos replied:
> > Shouldn't bluez-utils' hcid daemon handle this? Actually, I think
> > these kind of daemons should be autostarted by D-Bus when HAL
> > broadcasts their signal and exit gracefully when the user turns the
> > killswitch off.
>
> Do the bluez-utils developers agree? Is this something hcid should
> already be listening for and handling? Should I file a bluez-utils bug
> report requesting that it do this? Or do you consider this to be
> outside of hcid's domain of responsibility?
>
> Please note that my concern here is not actually the radio kill switch
> that Rui Tiago Matos mentions. That seems to work fine. (The daemons
> keep running and do not "exit gracefully", but at least the desktop
> reacts appropriately when the radio kill switch takes bluetooth away.)
> So the question here is the Fn+F5 wifi button, not the radio kill switch.
we discussed this some time ago at one of the BlueZ developer meetings.
The overall agreement was that this should be handled via rfkill and/or
HAL.
The reason for this is that the Bluetooth on/off switches are all
different and HAL and rfkill is the way to abstract it into a common
interface. It is not the job of hcid to abstract this.
Also when it comes to handle these events from HAL/rfkill, then we can
discuss handling this inside bluez-gnome. Putting that code into hcid
would be wrong.
The discussion about starting hcid from within HAL has been discussed
and yes, eventually it will happen.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users