I've updated my bthid daemon with some tweaks that
may or may not have been necessary to get the new
Apple Bluetooth keyboard to work, and a new "-p"
option that enables regular pinging after inactivity,
which appears to be the key to keeping the Microsoft
keyboard from going to sleep so hard that it needs
to be power-cycled. Michal Semler suggested the
technique, and I wish that I had thought of it before
I broke the keyboard's battery compartment cover from
overuse.
The code is linked to http://klausler.com/msbtkb-linux.html,
a web page that badly needs revamping, I know.
I'm *very* happy with the new Apple keyboard, by the way.
It's affordable, solidly built, has an ON/OFF switch (!), and
is much more amenable to the Dvorak layout. But I still prefer
the 5-button Microsoft mouse with its scroll wheel to Apple's
one-button Bluetooth mouse.
The Microsoft and Apple offerings remain the only Bluetooth
keyboards of commercial availability known to me. Has anyone
seen another?
--
Peter Klausler, Sr. Principal Engineer, Cray Inc. ',.PY FGCRL
[email protected], [email protected], http://klausler.com AOEUI DHTNS
O/S kernel, compilers, simulation, and ISA design ;QJKX BMWVZ
-------------------------------------------------------
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 Florian,
> > I also put my bthid utility into the utils2 CVS repository. It was
> ..at SourceForge? Either I'm too dumb to find it, or it's not there.
it looks like that the anonymous CVS is not updated yet :(
> > their HID parser. But this USB HID modification is only a bad hack at
> > the moment.
> Hmm, as long as it works, it's not a bad hack :-)
In this case it is a very bad and ugly hack ;)
Regards
Marcel
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I also put my bthid utility into the utils2 CVS repository. It was
..at SourceForge? Either I'm too dumb to find it, or it's not there.
> their HID parser. But this USB HID modification is only a bad hack at
> the moment.
Hmm, as long as it works, it's not a bad hack :-)
Yours, Florian
- --
Zeit fuer eine neue .sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)
iD8DBQE/t3hE7CzyshGvatgRAhIYAJ0Suse6ESXP0eb38pa5Wy7P27JDhACfYcIi
B+TpZU/qnbnzm5wErFqvNYU=
=RyW9
-----END PGP SIGNATURE-----
Hi Edd,
> Thanks for the pointer. Attached is a patch to make Peter's software
> work with the uinput driver, suitable for bthid-0.8. Tested under
> 2.6.0-test9.
>
> With a bit of trouble I have this working with an Apple keyboard and an
> MS mouse. I have found it troublesome to connect the devices:
>
> * power cycling the mouse is required after a connection is
> lost, and even this doesn't always work
>
> * the Apple keyboard is very difficult to connect. Often after
> reading the HID descriptor it receives no key events.
>
> Also, the mouse events get lagged and the cursor sways drunkenly around
> the desktop: looks like we need to do something to batch up mouse events
> so the cursor keeps up with the mouse.
maybe it is a good idea to read my notes about HID
http://www.holtmann.org/linux/bluetooth/hid.html
I also put my bthid utility into the utils2 CVS repository. It was
working fine for me and I solved the problem when the HID device
disconnects the L2CAP channels. However it depends on a modified USB HID
kernel module which allows us to input the HID reports directly into
their HID parser. But this USB HID modification is only a bad hack at
the moment.
I like to reuse the kernel HID parser from the USB subsystem, but this
is not as easy as I thought in the first place, because it is hardwired
with the USB subsystem. A HID parser is not a USB only thing, not
anymore. Maybe we should have the HID parser also in user space like
Peter's code does and use the uinput driver. At the moment I think this
is bad, because both parsers must be maintained and writing a good HID
parser is not a easy job. The kernel parser is doing quite a very good
job, but the people from the input subsystem are not very helpful in
building a general HID interface. Any thoughts about how to proceed?
As a side note, be careful with libs2 and utils2 ;)
Regards
Marcel
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Sat, 2003-11-15 at 21:59, Edd Dumbill wrote:
> Also, the mouse events get lagged and the cursor sways drunkenly around
> the desktop: looks like we need to do something to batch up mouse events
> so the cursor keeps up with the mouse.
OK, I just read Marcel's note about the MS mouse and older CSR chipsets,
like mine. That explains the lag then.
-- Edd
On Sat, 2003-11-15 at 19:39, Marcel Holtmann wrote:
> the "User level driver support for input subsystem" should replace the
> fake.o driver. For the 2.4 series I have posted a backport to the LKML,
> but Marcelo don't picked it up by now.
Thanks for the pointer. Attached is a patch to make Peter's software
work with the uinput driver, suitable for bthid-0.8. Tested under
2.6.0-test9.
With a bit of trouble I have this working with an Apple keyboard and an
MS mouse. I have found it troublesome to connect the devices:
* power cycling the mouse is required after a connection is
lost, and even this doesn't always work
* the Apple keyboard is very difficult to connect. Often after
reading the HID descriptor it receives no key events.
Also, the mouse events get lagged and the cursor sways drunkenly around
the desktop: looks like we need to do something to batch up mouse events
so the cursor keeps up with the mouse.
Anyway, I guess this is progress. Thanks Peter and Marcel!
My patch also adds support for the CD eject key on the apple keyboard.
-- Edd
Hi Edd,
> > I've updated my bthid daemon with some tweaks that
> > may or may not have been necessary to get the new
> > Apple Bluetooth keyboard to work
>
> Is there any chance you might update your module to work against the 2.6
> kernel too?
the "User level driver support for input subsystem" should replace the
fake.o driver. For the 2.4 series I have posted a backport to the LKML,
but Marcelo don't picked it up by now.
Regards
Marcel
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thu, 2003-11-06 at 01:45, Peter Klausler wrote:
> I've updated my bthid daemon with some tweaks that
> may or may not have been necessary to get the new
> Apple Bluetooth keyboard to work
Hi Peter,
Is there any chance you might update your module to work against the 2.6
kernel too?
Thanks
-- Edd
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hello,
> I've updated my bthid daemon with some tweaks that
I have just look at it very shortly. I'm not really happy: my patches
against the 0.6 release for the Logitech diNovo desktop is not inclued.
I have send it two time: one times directly to you, one time to the
mailing BlueZ mailing list. I have received no feedback from you at all.
The patches was for:
- support correctly the LT mouse buttons (it has 8 buttons).
- support for more keymaps (using the table from the USB
driver).
Is there some reason to have not answered me ?
> The Microsoft and Apple offerings remain the only Bluetooth
> keyboards of commercial availability known to me. Has anyone
> seen another?
Logitech at at least two keyboards and one mouse with Bluetooth. Don't
have see them in shops, but they will be available really soon. I have
one pre-release.
See: http://logitech.com/bluetooth/ for Logitech bluetooth products.
A review on CNET:
http://reviews.cnet.com/Logitech_DiNovo_Media_Desktop/4505-3134_7-30586106.html
Some online shops already take orders, and even say they have some in
stock.
Good day.
Olivier
--
Olivier Bornet http://www.smartdata.ch/
[email protected] SMARTDATA SA
GPG key ID: C53D9218 CH Martigny/Lausanne
Hi Michal,
> > Let's talk a little bit about the freezing of the Microsoft devices,
> > because I already solved this for my own HID implementation, but I
> > forgot to share my knowledge. The mouse and the keyboard drop both L2CAP
> > connections after 12 minutes of idle time and try to disconnect the ACL
> > link after that, but on the Linux side we don't handle this correctly.
>
> Maybe M$ handle it incorrectly on theit side :)
I don't think that this is a Microsoft problem, because it works fine
with the XP Bluetooth stack and the keyboard and mouse are running the
HID implementation from CSR.
> > Keeping the HID device alive with some kind of pinging is not a good
> > idea, because it consumes to much power ;)
>
> For now I prefer working solution if non other and better is known...
Try to include my approach into the code from Peter and see if it works
for you.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Dne =E8t 6. listopadu 2003 10:10 Marcel Holtmann napsal(a):
> Hi Peter,
>
> > I've updated my bthid daemon with some tweaks that
> > may or may not have been necessary to get the new
> > Apple Bluetooth keyboard to work, and a new "-p"
> > option that enables regular pinging after inactivity,
> > which appears to be the key to keeping the Microsoft
> > keyboard from going to sleep so hard that it needs
> > to be power-cycled. Michal Semler suggested the
> > technique, and I wish that I had thought of it before
> > I broke the keyboard's battery compartment cover from
> > overuse.
>
> if you have some extra time, please send me the information from
> "hcitool inq" and "hcitool info" of the Apple devices. And the output
> from the libs2 CVS "sdptest records" could be very helpful, too.
>
> Let's talk a little bit about the freezing of the Microsoft devices,
> because I already solved this for my own HID implementation, but I
> forgot to share my knowledge. The mouse and the keyboard drop both L2CAP
> connections after 12 minutes of idle time and try to disconnect the ACL
> link after that, but on the Linux side we don't handle this correctly.
Maybe M$ handle it incorrectly on theit side :)
> It seems that closing the two L2CAP connections at the same time causes
> problems. The problem must be inside the kernel HCI or L2CAP layer, but
> on my latest review I found nothing wrong. So I used this pseudo code
>
> if (we_close_connection) {
> close(control_psm);
> sleep(1);
> close(interrupt_psm);
> } else { /* HID device after 12 minutes idle */
> close(interrupt_psm);
> sleep(1);
> close(control_psm);
> }
>
> If you don't do it this way the ACL connection between the host and the
> HID device will not be terminated. In general this is not a problem, but
> it gets unusable and so you have to power-cycle.
>
> Keeping the HID device alive with some kind of pinging is not a good
> idea, because it consumes to much power ;)
=46or now I prefer working solution if non other and better is known...
>
> > The Microsoft and Apple offerings remain the only Bluetooth
> > keyboards of commercial availability known to me. Has anyone
> > seen another?
>
> Logitech seems to have some devices on the market. Last time I tried the
> old Logitech Presenter I found that your SDP implementation can't get
> the HID descriptor out of this device. I don't have this device handy,
> so I can't reproduce the error.
>
> Have you ever looked at the "User level driver support for input"? It
> maybe can replace your fake driver and I also backported it to 2.4, but
> Marcelo didn't picked it up.
>
> Regards
>
> Marcel
Michal
Hi Peter,
> I've updated my bthid daemon with some tweaks that
> may or may not have been necessary to get the new
> Apple Bluetooth keyboard to work, and a new "-p"
> option that enables regular pinging after inactivity,
> which appears to be the key to keeping the Microsoft
> keyboard from going to sleep so hard that it needs
> to be power-cycled. Michal Semler suggested the
> technique, and I wish that I had thought of it before
> I broke the keyboard's battery compartment cover from
> overuse.
if you have some extra time, please send me the information from
"hcitool inq" and "hcitool info" of the Apple devices. And the output
from the libs2 CVS "sdptest records" could be very helpful, too.
Let's talk a little bit about the freezing of the Microsoft devices,
because I already solved this for my own HID implementation, but I
forgot to share my knowledge. The mouse and the keyboard drop both L2CAP
connections after 12 minutes of idle time and try to disconnect the ACL
link after that, but on the Linux side we don't handle this correctly.
It seems that closing the two L2CAP connections at the same time causes
problems. The problem must be inside the kernel HCI or L2CAP layer, but
on my latest review I found nothing wrong. So I used this pseudo code
if (we_close_connection) {
close(control_psm);
sleep(1);
close(interrupt_psm);
} else { /* HID device after 12 minutes idle */
close(interrupt_psm);
sleep(1);
close(control_psm);
}
If you don't do it this way the ACL connection between the host and the
HID device will not be terminated. In general this is not a problem, but
it gets unusable and so you have to power-cycle.
Keeping the HID device alive with some kind of pinging is not a good
idea, because it consumes to much power ;)
> The Microsoft and Apple offerings remain the only Bluetooth
> keyboards of commercial availability known to me. Has anyone
> seen another?
Logitech seems to have some devices on the market. Last time I tried the
old Logitech Presenter I found that your SDP implementation can't get
the HID descriptor out of this device. I don't have this device handy,
so I can't reproduce the error.
Have you ever looked at the "User level driver support for input"? It
maybe can replace your fake driver and I also backported it to 2.4, but
Marcelo didn't picked it up.
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
> technique, and I wish that I had thought of it before
> I broke the keyboard's battery compartment cover from
> overuse.
I have been using this technique. I think there is another timeout
somewhere as both the mouse and keyboard drop connection within 5 mins
of each other after about a day. Could just be my broken kit though :(
Thanks for all your work Peter. Did the UK keyboard patch make it into
this release?
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