Hello again,
I've got my Logitech diNovo mouse & keyboard working with BlueZ by
finding them manually with hidd (with '--search' or '--connect <addr>').
But for some reason 'hidd --server' doesn't want to recognize both of
the devices at the same time: When it starts up it will detect whichever
device I use first, and not the other.
In other words, if I start typing on my keyboard after starting hidd, it
will work, but the mouse won't. If I start by clicking the mouse, that
will work, but the keyboard won't. This happens consistently, and the
non-working device will only start working if I first press its little
'connect' button and then manually connect it with 'hidd --connect
<addr>'.
Has anyone experienced anything like this? I can't imagine this is
intended or required behavior; if it can recognize one, why not the
other?
Jon
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Jon,
> > I think the problem here is your Bluetooth card. The Nokia card is
> > working fine, but it seems that it has problems when you try to get
> > another device into that piconet in which it is already master. I only
> > own the DTL-1 and so I can't test this, but with a newer card or USB
> > dongle everything should work, because I tested already this case with
> > seven HID devices and it was working perfect.
>
> Ok, thank you very much for your help. I was actually happy when I
> received a Socket card of revision F instead of G, because then I
> wouldn't have to worry about the G card not working with the 2.6 kernel.
> But I guess there's a reason they never supported HID in their windows
> drivers for the previous revisions.
your thought is wrong here. The problem is not that the card don't
supports HID, because you can work with one of your devices. The problem
is that this card is "very old" and in the beginning of Bluetooth not
all chip manufacturers did a good job in implementing all features. Many
of them think to short and in a special case the phone companies. They
made sure that their card works with their phone and from their view
that was mostly an one-to-one communication. The keywords are scatternet
and multi-connection support. Another example is that in most phones you
can't synchronize your phonebook while you are makeing a phone call with
your Bluetooth headset.
Btw I also saw a very new Bluetooth 1.2 chip that don't really like a
piconet full of HID devices :(
> I've just ordered their special upgrade offer, so hopefully in a week or
> two I'll have both the F and the G revision to play with. Maybe I can
> even somehow make the newer card work with 2.6, so I can have both a new
> kernel and working HID. Wish me luck :)
If you find the real problem between hci_uart, serial_cs and 2.6 we will
all thank you.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 2004-06-18 at 01:01, Marcel Holtmann wrote:
<snip>
>
> I think the problem here is your Bluetooth card. The Nokia card is
> working fine, but it seems that it has problems when you try to get
> another device into that piconet in which it is already master. I only
> own the DTL-1 and so I can't test this, but with a newer card or USB
> dongle everything should work, because I tested already this case with
> seven HID devices and it was working perfect.
>
Ok, thank you very much for your help. I was actually happy when I
received a Socket card of revision F instead of G, because then I
wouldn't have to worry about the G card not working with the 2.6 kernel.
But I guess there's a reason they never supported HID in their windows
drivers for the previous revisions.
I've just ordered their special upgrade offer, so hopefully in a week or
two I'll have both the F and the G revision to play with. Maybe I can
even somehow make the newer card work with 2.6, so I can have both a new
kernel and working HID. Wish me luck :)
Jon
Hi Jon,
> Can anyone? This may be a silly question, but what exactly is the link
> manager? Is there anything I can do to track the problem down, or should
> I just give up?
you must buy a protocol analyzer for this ;)
> Just to make sure I've understood this right: The problem is that once
> the first connection is set up, the link manager won't accept (or
> detect?) another incoming connection. The reason it works when I do it
> manually is that the connect button on the keyboard makes the keyboard
> listen for a connection, and the subsequent 'hidd --connect <addr>'
> makes the CF card connect to the keyboard. Is that right?
I think the problem here is your Bluetooth card. The Nokia card is
working fine, but it seems that it has problems when you try to get
another device into that piconet in which it is already master. I only
own the DTL-1 and so I can't test this, but with a newer card or USB
dongle everything should work, because I tested already this case with
seven HID devices and it was working perfect.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 2004-06-18 at 00:38, Marcel Holtmann wrote:
> Hi Jon,
>
> > > show us the output of "hciconfig -a".
> >
> > # hciconfig -a
> > hci0: Type: PCCARD
> > BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> > UP RUNNING PSCAN ISCAN
> > RX bytes:1374134 acl:63939 sco:0 events:4549 errors:0
> > TX bytes:741932 acl:3358 sco:0 commands:158 errors:0
> > Features: 0xbf 0x00 0x20 0x00 0x00 0x00 0x00 0x00
> > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1
> > Link policy: RSWITCH HOLD SNIFF PARK
> > Link mode: ACCEPT MASTER
> > Name: 'BlueZ (0)'
> > Class: 0x000100
> > Service Classes: Unspecified
> > Device Class: Computer, Uncategorized
> > HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver:
> > 0x21a
> > Manufacturer: Nokia Mobile Phones (1)
>
> this looks like a card problem. Do "hciconfig hci0 features" show the
> role switch support? May you try the link mode accept and slave, because
> the hidd will force the role switch by itself.
Yep:
# hciconfig hci0 features
hci0: Type: PCCARD
BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
Features: 0xbf 0x00 0x20 0x00 0x00 0x00 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot
offset>
<timing accuracy> <role switch> <sniff mode>
And I tried with accept and slave; no change.
> > > Check with "hcidump -x" what happens when you press a button of your
> > > second device.
> >
> > Nothing at all, I'm afraid.
>
> In this case it is on the link manager level and I can't debug it.
Can anyone? This may be a silly question, but what exactly is the link
manager? Is there anything I can do to track the problem down, or should
I just give up?
Just to make sure I've understood this right: The problem is that once
the first connection is set up, the link manager won't accept (or
detect?) another incoming connection. The reason it works when I do it
manually is that the connect button on the keyboard makes the keyboard
listen for a connection, and the subsequent 'hidd --connect <addr>'
makes the CF card connect to the keyboard. Is that right?
Jon
Hi Jon,
> > show us the output of "hciconfig -a".
>
> # hciconfig -a
> hci0: Type: PCCARD
> BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> UP RUNNING PSCAN ISCAN
> RX bytes:1374134 acl:63939 sco:0 events:4549 errors:0
> TX bytes:741932 acl:3358 sco:0 commands:158 errors:0
> Features: 0xbf 0x00 0x20 0x00 0x00 0x00 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: ACCEPT MASTER
> Name: 'BlueZ (0)'
> Class: 0x000100
> Service Classes: Unspecified
> Device Class: Computer, Uncategorized
> HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver:
> 0x21a
> Manufacturer: Nokia Mobile Phones (1)
this looks like a card problem. Do "hciconfig hci0 features" show the
role switch support? May you try the link mode accept and slave, because
the hidd will force the role switch by itself.
> > Check with "hcidump -x" what happens when you press a button of your
> > second device.
>
> Nothing at all, I'm afraid.
In this case it is on the link manager level and I can't debug it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 2004-06-18 at 00:19, Marcel Holtmann wrote:
> Hi Jon,
>
> > > do you've activated the role switch support on your host device?
> >
> > I believe so:
> >
> > # hciconfig hci0 lm
> > hci0: Type: PCCARD
> > BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> > Link mode: ACCEPT MASTER
> > # hciconfig hci0 lp
> > hci0: Type: PCCARD
> > BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> > Link policy: RSWITCH HOLD SNIFF PARK
>
> show us the output of "hciconfig -a".
# hciconfig -a
hci0: Type: PCCARD
BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:1374134 acl:63939 sco:0 events:4549 errors:0
TX bytes:741932 acl:3358 sco:0 commands:158 errors:0
Features: 0xbf 0x00 0x20 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: ACCEPT MASTER
Name: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver:
0x21a
Manufacturer: Nokia Mobile Phones (1)
>
> > # hidd --server --nodaemon
> > hidd[6666]: Bluetooth HID daemon
> > hidd[6666]: New HID device 00:07:61:1A:78:E2 (Logitech Bluetooth Mouse)
> >
> > ... and then nothing when I try to use the keyboard. Is there something
> > I've overlooked regarding the role-switch stuff?
> >
> > I've done some simple debugging in hidd's main.c, which so far only
> > reveals that the poll() call in run_server() fails to produce any new
> > events once the first create_device() call has been made. The problem
> > doesn't appear to be caused inside hidd itself though, because killing
> > and restarting it after it's established the connection to the first
> > device doesn't help it discover the second one.
> >
> > Any pointers to where else I might look for the bug? I'm afraid I don't
> > really know my way around BlueZ internals.
>
> Check with "hcidump -x" what happens when you press a button of your
> second device.
Nothing at all, I'm afraid.
Jon
Hi Jon,
> > do you've activated the role switch support on your host device?
>
> I believe so:
>
> # hciconfig hci0 lm
> hci0: Type: PCCARD
> BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> Link mode: ACCEPT MASTER
> # hciconfig hci0 lp
> hci0: Type: PCCARD
> BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
> Link policy: RSWITCH HOLD SNIFF PARK
show us the output of "hciconfig -a".
> # hidd --server --nodaemon
> hidd[6666]: Bluetooth HID daemon
> hidd[6666]: New HID device 00:07:61:1A:78:E2 (Logitech Bluetooth Mouse)
>
> ... and then nothing when I try to use the keyboard. Is there something
> I've overlooked regarding the role-switch stuff?
>
> I've done some simple debugging in hidd's main.c, which so far only
> reveals that the poll() call in run_server() fails to produce any new
> events once the first create_device() call has been made. The problem
> doesn't appear to be caused inside hidd itself though, because killing
> and restarting it after it's established the connection to the first
> device doesn't help it discover the second one.
>
> Any pointers to where else I might look for the bug? I'm afraid I don't
> really know my way around BlueZ internals.
Check with "hcidump -x" what happens when you press a button of your
second device.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thu, 2004-06-17 at 22:29, Marcel Holtmann wrote:
> Hi Jon,
>
> > I've got my Logitech diNovo mouse & keyboard working with BlueZ by
> > finding them manually with hidd (with '--search' or '--connect <addr>').
> > But for some reason 'hidd --server' doesn't want to recognize both of
> > the devices at the same time: When it starts up it will detect whichever
> > device I use first, and not the other.
> >
> > In other words, if I start typing on my keyboard after starting hidd, it
> > will work, but the mouse won't. If I start by clicking the mouse, that
> > will work, but the keyboard won't. This happens consistently, and the
> > non-working device will only start working if I first press its little
> > 'connect' button and then manually connect it with 'hidd --connect
> > <addr>'.
> >
> > Has anyone experienced anything like this? I can't imagine this is
> > intended or required behavior; if it can recognize one, why not the
> > other?
>
> do you've activated the role switch support on your host device?
>
I believe so:
# hciconfig hci0 lm
hci0: Type: PCCARD
BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
Link mode: ACCEPT MASTER
# hciconfig hci0 lp
hci0: Type: PCCARD
BD Address: 00:E0:03:25:3E:29 ACL MTU: 340:4 SCO MTU: 64:0
Link policy: RSWITCH HOLD SNIFF PARK
# hidd --server --nodaemon
hidd[6666]: Bluetooth HID daemon
hidd[6666]: New HID device 00:07:61:1A:78:E2 (Logitech Bluetooth Mouse)
... and then nothing when I try to use the keyboard. Is there something
I've overlooked regarding the role-switch stuff?
I've done some simple debugging in hidd's main.c, which so far only
reveals that the poll() call in run_server() fails to produce any new
events once the first create_device() call has been made. The problem
doesn't appear to be caused inside hidd itself though, because killing
and restarting it after it's established the connection to the first
device doesn't help it discover the second one.
Any pointers to where else I might look for the bug? I'm afraid I don't
really know my way around BlueZ internals.
Jon
Hi Jon,
> I've got my Logitech diNovo mouse & keyboard working with BlueZ by
> finding them manually with hidd (with '--search' or '--connect <addr>').
> But for some reason 'hidd --server' doesn't want to recognize both of
> the devices at the same time: When it starts up it will detect whichever
> device I use first, and not the other.
>
> In other words, if I start typing on my keyboard after starting hidd, it
> will work, but the mouse won't. If I start by clicking the mouse, that
> will work, but the keyboard won't. This happens consistently, and the
> non-working device will only start working if I first press its little
> 'connect' button and then manually connect it with 'hidd --connect
> <addr>'.
>
> Has anyone experienced anything like this? I can't imagine this is
> intended or required behavior; if it can recognize one, why not the
> other?
do you've activated the role switch support on your host device?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users