Hey,
in Marcels version of bthid it seem we go around the while in the
worker method until __io_canceled. At this point we then close the sockets
with a sleep in between them to avoid the ACL connection problem. I added
in some sleeps into Peters code and this made no difference. After looking
into this further (by putting debug at every close statement), a close is
not called after
} else if (!nbytes) {
syslog (LOG_NOTICE, "EOF on Interrupt channel");
shut_down (EXIT_SUCCESS);
}
and my mouse thinks this ACL connection is still open. I have 2 questions:
1)When __io_canceled is true, is this the same as (or at least a case of)
when the above code is called (IE when the mouse goes to sleep)?
2)Why is it in Marcels bthid code that the control and interrupt channels
are shut down in different a order depending on if __io_canceled is true
or not?
Cheers,
Gareth
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Gareth,
> OK then, I will take a look at the HID profile and the USB HID docs over
> the weekend. Any links/tutorials you would advise reading?
you can also look at my Bluetooth slides
http://www.holtmann.org/papers/bluetooth/wtc2003_slides.pdf
http://www.holtmann.org/papers/bluetooth/btk2003_slides.pdf
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi,
> have fun with the Bluetooth spec. ;) The new 1.2 core spec. has 1200
> pages and covers only HCI, L2CAP and SDP on the host side. However
> reading the spec. is not so important, but you must understand how
> Bluetooth works and how the layers interact. For the HID part you have
> to read the HID profile and the USB HID documents. If we decide to
> implement our own HID parser I need someone who will do this, because I
> have no time for working on a HID parser. I can do everything which
> depends on L2CAP and HIDP, but the HID part must be done by someone
> else.
OK then, I will take a look at the HID profile and the USB HID docs over
the weekend. Any links/tutorials you would advise reading?
Regards,
Gareth
HI Gareth,
> > I am thinking of having only one bthid running and using an event loop
> > to multiplex all the file descriptors. We can also try to use uinput and
> > have our own HID parser in userspace. What do you think?
>
> Sounds good to me. I will happily put some time in. I am going to read the
> Bluetooth spec over the weekend. Any other reading materials you suggest
> that I should read before we attempt this?
have fun with the Bluetooth spec. ;) The new 1.2 core spec. has 1200
pages and covers only HCI, L2CAP and SDP on the host side. However
reading the spec. is not so important, but you must understand how
Bluetooth works and how the layers interact. For the HID part you have
to read the HID profile and the USB HID documents. If we decide to
implement our own HID parser I need someone who will do this, because I
have no time for working on a HID parser. I can do everything which
depends on L2CAP and HIDP, but the HID part must be done by someone
else.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hey Marcel,
> I am thinking of having only one bthid running and using an event loop
> to multiplex all the file descriptors. We can also try to use uinput and
> have our own HID parser in userspace. What do you think?
Sounds good to me. I will happily put some time in. I am going to read the
Bluetooth spec over the weekend. Any other reading materials you suggest
that I should read before we attempt this?
Cheers,
Gareth
Hi Gareth,
> Does anyone have any idea what to try next (I will start work on the USB
> HID kernel modification when I have some time soon but would love to get
> them working first)?
I am thinking of having only one bthid running and using an event loop
to multiplex all the file descriptors. We can also try to use uinput and
have our own HID parser in userspace. What do you think?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hey,
grrrrrr. This did not work. I think my problem is different so I
suggest that someone who has the M$ stuff try Marcels idea. To try this I
think you can put the code in the shutdown method. Mine now looks like
this
static
void
shut_down (int status) {
kb_reset ();
mouse_reset ();
close(intr_sock);
sleep(1);
close(ctl_sock);
if (status == EXIT_SUCCESS &&
will_initiate_reconnections)
status = EXIT_FAILURE;
exit (status);
}
Note that this may not end up being the correct place for the code,
especially if the control and interupt have to be shut down in different
orders, depending on who is terminating, but it should do to test if this
will solve the problem.
This may well solve the keyboard reconnect problem. I would be interested
to hear anyones results. I would also like to know peoples experience when
they go ./bthid -l. The moment I touch the mouse or keyboard 100% of the
CPU is used until I kill bthid. Does this happen with other people? Note
that I have no other bthids running.
Does anyone have any idea what to try next (I will start work on the USB
HID kernel modification when I have some time soon but would love to get
them working first)?
Cheers,
Gareth
On Fri, 28 Nov 2003, Gareth Reakes wrote:
>
> > If you exit the program without closing the L2CAP sockets, the OS will
> > close it for you and this is the same as you close the sockets without
> > sleeping between it. Closing the ACL link is the job of the kernel.
>
> OK, this may be the problem then :) Thanks for that. I will try it when I
> get home tonight and report back.
>
> I appreciate all your time on this Marcel,
>
> Gareth
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
> If you exit the program without closing the L2CAP sockets, the OS will
> close it for you and this is the same as you close the sockets without
> sleeping between it. Closing the ACL link is the job of the kernel.
OK, this may be the problem then :) Thanks for that. I will try it when I
get home tonight and report back.
I appreciate all your time on this Marcel,
Gareth
Hi Gareth,
> Thanks for the clarification. I have 1 more question. Is the ACL link
> supposed to be terminated with the close of the control/interupt channels?
> I'm sorry if this is obvious, but I do not yet understand exactly what
> this ACL link is in relation to the sockets we have open. If this is the
> case (and I am reading Peter's code correctly) then would you think that
> my problem may be that when the HID terminiates the connection, we do not
> close the sockets and therefore the ACL link?
this is Bluetooth specific, so you should read the specification. The
underlaying data link is always ACL and there is also only one ACL link
between two devices. The L2CAP or RFCOMM connections share always the
same ACL link.
If you exit the program without closing the L2CAP sockets, the OS will
close it for you and this is the same as you close the sockets without
sleeping between it. Closing the ACL link is the job of the kernel.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marcel,
> let me clear this a little bit up. When __io_canceled is true, we are
> terminating the connection to the HID device. In general this is done by
> sending SIGTERM to the process. When __io_canceld is false then the HID
> device cuts the connection. For the Microsoft devices this is after 12
> minutes.
Thanks for the clarification. I have 1 more question. Is the ACL link
supposed to be terminated with the close of the control/interupt channels?
I'm sorry if this is obvious, but I do not yet understand exactly what
this ACL link is in relation to the sockets we have open. If this is the
case (and I am reading Peter's code correctly) then would you think that
my problem may be that when the HID terminiates the connection, we do not
close the sockets and therefore the ACL link?
Cheers,
Gaerth
Hi Gareth,
> 1)When __io_canceled is true, is this the same as (or at least a case of)
> when the above code is called (IE when the mouse goes to sleep)?
>
> 2)Why is it in Marcels bthid code that the control and interrupt channels
> are shut down in different a order depending on if __io_canceled is true
> or not?
let me clear this a little bit up. When __io_canceled is true, we are
terminating the connection to the HID device. In general this is done by
sending SIGTERM to the process. When __io_canceld is false then the HID
device cuts the connection. For the Microsoft devices this is after 12
minutes.
While I was playing with the Microsoft devices I found that the order of
closing the connections differ on who terminates the connection. I think
that the problem is on the Linux side, but I couldn't found it. If it is
really the fault of BlueZ it must be something very odd that we have
overlooked all the time.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users