Heya,
(As promised to Claudio)
2(3) HID devices I own have the same problem with BlueZ when using the
input service. Both use HID initiated connections, rather than the Host
initiated connection use case you would see when addind a Bluetooth
mouse to a laptop for example.
* First device: Logitech MX5000 mouse/keyboard combo
When not switched into HCI mode, the device works as a normal USB HID.
On boot, hid2hci is run, and the 2 devices (mouse and keyboard) try to
connect to bluetooth dongle (ex-USB wireless dongle).
There's no bluetooth-applet, or other services, and the requests are
dropped to the floor, and I end up with a Bluetooth HCI device, and no
keyboard or mouse (unplug/replug "fixes" the problem though).
Could we integrate hid2hci into the input service, so that it would only
be started when a session is available? I'm not sure how to handle the
pairing without a keyboard or mouse though...
* Second device: Sixaxis PS3 Bluetooth joypad
Again, 2 connections modes. Firstly, there's no pairing, the joypad
knows about the computer when one runs sixpair when the pad is connected
via USB, as per:
http://www.pabr.org/sixlinux/sixlinux.en.html
(Marcel talked about integrating this with udev, which should be pretty
straight forward)
Once disconnected from USB, and turned on, the device will try to
connect to the computer. bluetooth-applet will request auth, and ask us
whether we want to allow the connection. But as the device was never
discovered/setup using CreateDevice, the get_store_device_info in
input/server.c will fail.
You can't use CreateDevice with the device, as it's either connecting to
our computer, or off, and connection requests will fail.
Any idea on how to handle those type of devices using the Input Service
and giving good user experience?
Cheers
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2007-06-18 at 22:16 +0200, Pascal wrote:
> Bastien Nocera wrote:
>
> > It's trying to "HIDP: Set report: Feature report" and gets disconnected
> > afterwards.
>
> OK, this comes from bluez-utils/input/server.c, right
> before ioctl(HIDPCONNADD).
>
> You could strace the bluetoothd-service-input process
> to check whether this ioctl returns an error code.
I'm getting an EINVAL. Which probably means that my version of sixpair
pushes garbage in the input store.
If anyone fancies checking the stupid things I'm doing in there...
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Bastien Nocera wrote:
> It's trying to "HIDP: Set report: Feature report" and gets disconnected
> afterwards.
OK, this comes from bluez-utils/input/server.c, right
before ioctl(HIDPCONNADD).
You could strace the bluetoothd-service-input process
to check whether this ioctl returns an error code.
If that doesn't help, you will have to add printk()s in
linux/net/bluetooth/hidp/core.c:hidp_add_connection()
to understand what is happening.
Pascal
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2007-06-18 at 19:30 +0200, Pascal wrote:
> Bastien Nocera wrote:
> > Jun 18 16:27:12 snoogens input[4052]: New input device 00:19:C1:7D:2E:FA ()
> >
> > But no device is actually created.
>
> Do you mean nothing shows up in /dev/input/ ?
> Maybe you need to "modprobe joydev" or "modprobe evdev" manually.
evdev is builtin, joydev is loaded (and is getting loaded).
> > Could it be that I'm not setting the device flags to
> > HIDP_BOOT_PROTOCOL_MODE? (Incidentally, is there any way to check
> > whether a device is in this mode, or in full HID mode?)
>
> You want it to be in "report protocol" mode, not "boot protocol".
> The PS3 controller only supports "report protocol" anyway.
> "hcidump -V -x" will show whether hidp.ko is trying to send a
> "HIDP: Set protocol" command.
It's trying to "HIDP: Set report: Feature report" and gets disconnected
afterwards.
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Bastien Nocera wrote:
> Jun 18 16:27:12 snoogens input[4052]: New input device 00:19:C1:7D:2E:FA ()
>
> But no device is actually created.
Do you mean nothing shows up in /dev/input/ ?
Maybe you need to "modprobe joydev" or "modprobe evdev" manually.
> Could it be that I'm not setting the device flags to
> HIDP_BOOT_PROTOCOL_MODE? (Incidentally, is there any way to check
> whether a device is in this mode, or in full HID mode?)
You want it to be in "report protocol" mode, not "boot protocol".
The PS3 controller only supports "report protocol" anyway.
"hcidump -V -x" will show whether hidp.ko is trying to send a
"HIDP: Set protocol" command.
Pascal
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, 2007-06-16 at 21:24 +0200, Marcel Holtmann wrote:
<snip>
> something like that and I have no idea how to do that for Logitech
> devices. I have strange code for pure CSR dongles, but it is so ugly
> that I am not going to share it. It is mostly CSR vendor stuff.
Shame. Is there any reason to run hid2hci by default then? As in,
shouldn't be opt-in, rather than opt-out?
> > > Getting the HID report descriptor over USB makes always the assumption
> > > that it is exactly the same as on Bluetooth. This should be checked.
> >
> > How can I verify that?
>
> I don't have code for that. Need to write a tool that does this.
My version of sixpair gets the report descriptor over usb, and stuff it
in a hci_connadd_req, but the point is moot for HCI proxy dongles, and I
don't know how to get the Bluetooth one for the sixaxis.
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2007-06-18 at 15:36 +0100, Bastien Nocera wrote:
> On Mon, 2007-06-18 at 16:00 +0200, Pascal wrote:
> > Bastien Nocera wrote:
> > > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x84) pressed.
> > > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) pressed.
> > > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) released.
> >
> > This typically occurs when the kernel thinks the device
> > is reporting in "boot protocol" mode, for example when
> > net/bluetooth/hidp/core.c:hidp_add_connection() fails to
> > parse the report descriptor and consequently initializes
> > session->input instead of session->hid.
> >
> > Another possible cause is that your kernel does not have
> > HIDP support at all (2.6.20 or earlier).
>
> Absolutely ancient FC6 kernel (2.6.19-1.2895.fc6 because of the crappy
> driver, for my crappy wireless card).
>
> Will test on my rawhide laptop. Thanks for the pointer!
On the laptop, after getting the authorisation dialogue, I get this
message from the input service:
Jun 18 16:27:12 snoogens input[4052]: New input device 00:19:C1:7D:2E:FA ()
But no device is actually created.
The class show up in the bluez files as 0x000508, which seems to be
correct for a gamepad.
The kernel has HIDP support built in to a module, and seems to be
getting automatically loaded.
Could it be that I'm not setting the device flags to
HIDP_BOOT_PROTOCOL_MODE? (Incidentally, is there any way to check
whether a device is in this mode, or in full HID mode?)
Any idea on how to debug this?
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2007-06-18 at 16:00 +0200, Pascal wrote:
> Bastien Nocera wrote:
> > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x84) pressed.
> > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) pressed.
> > Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) released.
>
> This typically occurs when the kernel thinks the device
> is reporting in "boot protocol" mode, for example when
> net/bluetooth/hidp/core.c:hidp_add_connection() fails to
> parse the report descriptor and consequently initializes
> session->input instead of session->hid.
>
> Another possible cause is that your kernel does not have
> HIDP support at all (2.6.20 or earlier).
Absolutely ancient FC6 kernel (2.6.19-1.2895.fc6 because of the crappy
driver, for my crappy wireless card).
Will test on my rawhide laptop. Thanks for the pointer!
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Bastien Nocera wrote:
> Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x84) pressed.
> Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) pressed.
> Jun 18 13:56:40 cookie kernel: hidp_input_report: Unknown key (scancode 0x82) released.
This typically occurs when the kernel thinks the device
is reporting in "boot protocol" mode, for example when
net/bluetooth/hidp/core.c:hidp_add_connection() fails to
parse the report descriptor and consequently initializes
session->input instead of session->hid.
Another possible cause is that your kernel does not have
HIDP support at all (2.6.20 or earlier).
Pascal
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > * Second device: Sixaxis PS3 Bluetooth joypad
> > >
> > > Again, 2 connections modes. Firstly, there's no pairing, the joypad
> > > knows about the computer when one runs sixpair when the pad is connected
> > > via USB, as per:
> > > http://www.pabr.org/sixlinux/sixlinux.en.html
> > > (Marcel talked about integrating this with udev, which should be pretty
> > > straight forward)
> > >
> > > Once disconnected from USB, and turned on, the device will try to
> > > connect to the computer. bluetooth-applet will request auth, and ask us
> > > whether we want to allow the connection. But as the device was never
> > > discovered/setup using CreateDevice, the get_store_device_info in
> > > input/server.c will fail.
> > >
> > > You can't use CreateDevice with the device, as it's either connecting to
> > > our computer, or off, and connection requests will fail.
> >
> > The sixpair.c tool needs to do some nasty tricks. It hast to get its own
> > Bluetooth address from the controller and then get its HID report
> > descriptor over USB. Then store them in /var/lib/bluetooth and also set
> > itself to trusted.
> >
> > We might wanna integrate that into the input service, but to be honest I
> > currently don't know how. It also might make more sense to let a HAL
> > addon handle this kind of authentication instead of at udev level.
>
> What we could do is:
> 1) have a HAL addon that will set the device's bdaddr in a property of
> the device when plugged into USB
I think a HAL addon that export the BD_ADDR of the controller as a
property is a good idea. We might also wanna add the current configured
host controller for that device and add a method to change that address.
> 2) have bluetooth-applet (or any other front-end) ask the user whether
> to set the device as trusted when it's plugged in (can be switched off
> with a config item)
Personally I think this should happen without any user-interaction once
you plugin the controller. However haven't thought about it that much.
> 3) Add a method to the input service (AddUSBDevice(string address,
> string usbdev) that will get the USB HID report descriptor, and set the
> device as trusted along with the rest of the info
No. I don't wanna have hardware specific methods in that API.
> I could work on that (it should be pretty straight-forward), except I
> don't have any code to get the bdaddr from the device and I don't know
> how to get the HID report descriptor from the device either. If you have
> some code that does that, feel free to pass it on, I can do the
> integration.
Check http://www.holtmann.org/papers/bluetooth/csw2007_slides.pdf and
you will see the report ids that will give you that information. I do
have code for that, but can't find it right now. Maybe it is on one of
my machines that I switched off.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > 2(3) HID devices I own have the same problem with BlueZ when using the
> > > input service. Both use HID initiated connections, rather than the
> > > Host
> > > initiated connection use case you would see when addind a Bluetooth
> > > mouse to a laptop for example.
> > >
> > > * First device: Logitech MX5000 mouse/keyboard combo
> > >
> > > When not switched into HCI mode, the device works as a normal USB HID.
> > > On boot, hid2hci is run, and the 2 devices (mouse and keyboard) try to
> > > connect to bluetooth dongle (ex-USB wireless dongle).
> > > There's no bluetooth-applet, or other services, and the requests are
> > > dropped to the floor, and I end up with a Bluetooth HCI device, and no
> > > keyboard or mouse (unplug/replug "fixes" the problem though).
> > >
> > > Could we integrate hid2hci into the input service, so that it would only
> > > be started when a session is available? I'm not sure how to handle the
> > > pairing without a keyboard or mouse though...
> >
> > after catching up with the IRC, I realized another problem with this HID
> > proxy dongles. We can fix that for the original firmwares from CSR that
> > are used by Apple, but for the Logitech's (they are slightly modified) I
> > am not sure.
> >
> > So when you switch a HID proxy dongle from HID mode into HCI, you have
> > to read its information about stored devices and their link keys. These
> > information have then to be put into /var/lib/bluetooth. This leaves out
> > the HID report descriptor that we also need. So that needs to be gotten
> > while it is still in USB mode.
>
> So it would be:
> 1) Get info from dongle about its own bdaddr, and the bdaddr of the
> attached devices (do you have code to do that for Logitech devices?)
> 2) Add attached devices' bdaddr as trusted for the device, and get the
> HID report descriptor, save it
> 3) switch the dongle to HCI mode
>
> Would that work? We could even do this in a HAL addon, or udev callback
> so that we're sure that newly plugged dongles are handled automatically.
something like that and I have no idea how to do that for Logitech
devices. I have strange code for pure CSR dongles, but it is so ugly
that I am not going to share it. It is mostly CSR vendor stuff.
> > Getting the HID report descriptor over USB makes always the assumption
> > that it is exactly the same as on Bluetooth. This should be checked.
>
> How can I verify that?
I don't have code for that. Need to write a tool that does this.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hey Marcel,
On Sat, 2007-06-16 at 09:25 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > 2(3) HID devices I own have the same problem with BlueZ when using the
> > input service. Both use HID initiated connections, rather than the
> > Host
> > initiated connection use case you would see when addind a Bluetooth
> > mouse to a laptop for example.
> >
> > * First device: Logitech MX5000 mouse/keyboard combo
> >
> > When not switched into HCI mode, the device works as a normal USB HID.
> > On boot, hid2hci is run, and the 2 devices (mouse and keyboard) try to
> > connect to bluetooth dongle (ex-USB wireless dongle).
> > There's no bluetooth-applet, or other services, and the requests are
> > dropped to the floor, and I end up with a Bluetooth HCI device, and no
> > keyboard or mouse (unplug/replug "fixes" the problem though).
> >
> > Could we integrate hid2hci into the input service, so that it would only
> > be started when a session is available? I'm not sure how to handle the
> > pairing without a keyboard or mouse though...
>
> after catching up with the IRC, I realized another problem with this HID
> proxy dongles. We can fix that for the original firmwares from CSR that
> are used by Apple, but for the Logitech's (they are slightly modified) I
> am not sure.
>
> So when you switch a HID proxy dongle from HID mode into HCI, you have
> to read its information about stored devices and their link keys. These
> information have then to be put into /var/lib/bluetooth. This leaves out
> the HID report descriptor that we also need. So that needs to be gotten
> while it is still in USB mode.
So it would be:
1) Get info from dongle about its own bdaddr, and the bdaddr of the
attached devices (do you have code to do that for Logitech devices?)
2) Add attached devices' bdaddr as trusted for the device, and get the
HID report descriptor, save it
3) switch the dongle to HCI mode
Would that work? We could even do this in a HAL addon, or udev callback
so that we're sure that newly plugged dongles are handled automatically.
> Getting the HID report descriptor over USB makes always the assumption
> that it is exactly the same as on Bluetooth. This should be checked.
How can I verify that?
Cheers
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hey Marcel,
On Sat, 2007-06-16 at 09:05 +0200, Marcel Holtmann wrote:
<snip>
> > * Second device: Sixaxis PS3 Bluetooth joypad
> >
> > Again, 2 connections modes. Firstly, there's no pairing, the joypad
> > knows about the computer when one runs sixpair when the pad is connected
> > via USB, as per:
> > http://www.pabr.org/sixlinux/sixlinux.en.html
> > (Marcel talked about integrating this with udev, which should be pretty
> > straight forward)
> >
> > Once disconnected from USB, and turned on, the device will try to
> > connect to the computer. bluetooth-applet will request auth, and ask us
> > whether we want to allow the connection. But as the device was never
> > discovered/setup using CreateDevice, the get_store_device_info in
> > input/server.c will fail.
> >
> > You can't use CreateDevice with the device, as it's either connecting to
> > our computer, or off, and connection requests will fail.
>
> The sixpair.c tool needs to do some nasty tricks. It hast to get its own
> Bluetooth address from the controller and then get its HID report
> descriptor over USB. Then store them in /var/lib/bluetooth and also set
> itself to trusted.
>
> We might wanna integrate that into the input service, but to be honest I
> currently don't know how. It also might make more sense to let a HAL
> addon handle this kind of authentication instead of at udev level.
What we could do is:
1) have a HAL addon that will set the device's bdaddr in a property of
the device when plugged into USB
2) have bluetooth-applet (or any other front-end) ask the user whether
to set the device as trusted when it's plugged in (can be switched off
with a config item)
3) Add a method to the input service (AddUSBDevice(string address,
string usbdev) that will get the USB HID report descriptor, and set the
device as trusted along with the rest of the info
I could work on that (it should be pretty straight-forward), except I
don't have any code to get the bdaddr from the device and I don't know
how to get the HID report descriptor from the device either. If you have
some code that does that, feel free to pass it on, I can do the
integration.
Cheers
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> 2(3) HID devices I own have the same problem with BlueZ when using the
> input service. Both use HID initiated connections, rather than the
> Host
> initiated connection use case you would see when addind a Bluetooth
> mouse to a laptop for example.
>
> * First device: Logitech MX5000 mouse/keyboard combo
>
> When not switched into HCI mode, the device works as a normal USB HID.
> On boot, hid2hci is run, and the 2 devices (mouse and keyboard) try to
> connect to bluetooth dongle (ex-USB wireless dongle).
> There's no bluetooth-applet, or other services, and the requests are
> dropped to the floor, and I end up with a Bluetooth HCI device, and no
> keyboard or mouse (unplug/replug "fixes" the problem though).
>
> Could we integrate hid2hci into the input service, so that it would only
> be started when a session is available? I'm not sure how to handle the
> pairing without a keyboard or mouse though...
after catching up with the IRC, I realized another problem with this HID
proxy dongles. We can fix that for the original firmwares from CSR that
are used by Apple, but for the Logitech's (they are slightly modified) I
am not sure.
So when you switch a HID proxy dongle from HID mode into HCI, you have
to read its information about stored devices and their link keys. These
information have then to be put into /var/lib/bluetooth. This leaves out
the HID report descriptor that we also need. So that needs to be gotten
while it is still in USB mode.
Getting the HID report descriptor over USB makes always the assumption
that it is exactly the same as on Bluetooth. This should be checked.
We can't use 2 L2CAP connections and SDP at the same time, because some
devices are limited of the maximum L2CAP connection. If the HID report
descriptors are different then this is all becomes a little bit more
trickier. In general it is possible since you first have to disconnect
the interrupt channel of HID and then do SDP and re-connect it. If I
remember the specification correctly, this should work.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> 2(3) HID devices I own have the same problem with BlueZ when using the
> input service. Both use HID initiated connections, rather than the Host
> initiated connection use case you would see when addind a Bluetooth
> mouse to a laptop for example.
>
> * First device: Logitech MX5000 mouse/keyboard combo
>
> When not switched into HCI mode, the device works as a normal USB HID.
> On boot, hid2hci is run, and the 2 devices (mouse and keyboard) try to
> connect to bluetooth dongle (ex-USB wireless dongle).
> There's no bluetooth-applet, or other services, and the requests are
> dropped to the floor, and I end up with a Bluetooth HCI device, and no
> keyboard or mouse (unplug/replug "fixes" the problem though).
you can do a adapter.SetTrusted(address) call once and no authorization
agent is called.
> Could we integrate hid2hci into the input service, so that it would only
> be started when a session is available? I'm not sure how to handle the
> pairing without a keyboard or mouse though...
I wanna integrate hid2hci somehow, but currently I don't know how.
> * Second device: Sixaxis PS3 Bluetooth joypad
>
> Again, 2 connections modes. Firstly, there's no pairing, the joypad
> knows about the computer when one runs sixpair when the pad is connected
> via USB, as per:
> http://www.pabr.org/sixlinux/sixlinux.en.html
> (Marcel talked about integrating this with udev, which should be pretty
> straight forward)
>
> Once disconnected from USB, and turned on, the device will try to
> connect to the computer. bluetooth-applet will request auth, and ask us
> whether we want to allow the connection. But as the device was never
> discovered/setup using CreateDevice, the get_store_device_info in
> input/server.c will fail.
>
> You can't use CreateDevice with the device, as it's either connecting to
> our computer, or off, and connection requests will fail.
The sixpair.c tool needs to do some nasty tricks. It hast to get its own
Bluetooth address from the controller and then get its HID report
descriptor over USB. Then store them in /var/lib/bluetooth and also set
itself to trusted.
We might wanna integrate that into the input service, but to be honest I
currently don't know how. It also might make more sense to let a HAL
addon handle this kind of authentication instead of at udev level.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel