[Bluez-users] bthid updated

[Bluez-users] bthid updated

[Peter Klausler]

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
pmk@cray.com, peter@klausler.com, 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Gareth Reakes]

> 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Michal Semler (volny.cz)]

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

Re: [Bluez-users] bthid updated

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Olivier Bornet]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

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/
Olivier.Bornet@smartdata.ch         SMARTDATA SA
GPG key ID: C53D9218                CH Martigny/Lausanne

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-users] bthid updated

[Edd Dumbill]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Edd Dumbill]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

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




[-- Attachment #2: bthid-uinput.diff --]
[-- Type: text/x-patch, Size: 6689 bytes --]

Only in bthid: bthid
Only in bthid.orig: fake.c
diff -ur bthid.orig/hid.c bthid/hid.c
--- bthid.orig/hid.c	2003-09-08 16:01:35.000000000 +0100
+++ bthid/hid.c	2003-11-15 21:51:31.000000000 +0000
@@ -565,6 +565,7 @@
 		case 0xb5:	butt = KEY_NEXTSONG;	break;
 		case 0xb6:	butt = KEY_PREVIOUSSONG;	break;
 		case 0xb7:	butt = KEY_STOPCD;	break;
+        case 0xb8:  butt = KEY_EJECTCD; break; /* Apple kbd */
 		case 0xcd:	butt = KEY_PLAYPAUSE;	break;
 		case 0xe2:	butt = KEY_MUTE;	break;
 		case 0xe9:	butt = KEY_VOLUMEUP;	break;
diff -ur bthid.orig/main.c bthid/main.c
--- bthid.orig/main.c	2003-11-06 01:20:03.000000000 +0000
+++ bthid/main.c	2003-11-15 21:14:37.000000000 +0000
@@ -781,9 +781,6 @@
 	int	scan_mode = 0;
 	int	listen_mode = 0;
 
-
-	out_path = "/dev/input/bluetooth-in";
-
 	for (argi = 1; argi < argc; argi++)
 		if (argv [argi][0] != '-')
 			break;
@@ -791,8 +788,6 @@
 			daemonize = 0;
 		else if (!strcmp (argv [argi], "-v"))
 			verbosity++;
-		else if (!strcmp (argv [argi], "-o") && argi < argc-1)
-			out_path = argv [++argi];
 		else if (!strcmp (argv [argi], "-l"))
 			listen_mode = 1;
 		else if (!strcmp (argv [argi], "-s"))
@@ -822,7 +817,6 @@
 				 "  -n  don't become daemon\n"
 				 "  -l  listen for incoming connections\n"
 				 "  -s  scan for devices\n"
-				 "  -o  output device (%s)\n"
 				 "  -b  reverse mouse buttons 2 and 5\n"
 				 "  -B ms  keyboard debounce time (millisecs)\n"
 				 "  -a  authentication link mode\n"
@@ -833,8 +827,7 @@
 				 "  -d  Dvorak keyboard and system\n"
 				 "  -D  Dvorak keyboard on QWERTY system\n"
 				 "  -r  attempt automatic reconnection\n"
-				 "  -v  verbose mode (-v -v is extra)\n",
-				 out_path);
+				 "  -v  verbose mode (-v -v is extra)\n");
 			return EXIT_FAILURE;
 		}
 
Only in bthid.orig: make.fake
diff -ur bthid.orig/Makefile bthid/Makefile
--- bthid.orig/Makefile	2003-06-17 17:32:07.000000000 +0100
+++ bthid/Makefile	2003-11-15 21:22:25.000000000 +0000
@@ -1,41 +1,34 @@
 BTHID_C =	global.c sock.c kb.c main.c out.c sdp.c hid.c
 BTHID_HDRS =	global.h hid.h sock.h kb.h out.h sdp.h hid.h
-EXTRA	=	README Makefile make.fake fake.c \
-		bluetooth-hid bthid-modules msblue.def
+EXTRA	=	README Makefile \
+		bluetooth-hid msblue.def
 SHIP	=	$(BTHID_C) $(BTHID_HDRS) $(EXTRA)
 BTHID_RELS =	$(BTHID_C:.c=.o)
 CFLAGS	=	-O -Wall -Wno-parentheses
-MODINSTDIR =	/lib/modules/`uname -r`/kernel/drivers/input
 
-world: bthid fake.o
+world: bthid 
 
 bthid: $(BTHID_RELS)
 	cc -o $@ $(BTHID_RELS) -lbluetooth
 
 $(BTHID_RELS): $(BTHID_HDRS)
 
-fake.o: fake.c
-	make -f make.fake $@
-
-install: bthid fake.o
+install: bthid
 	[ -c /dev/input/mice ] || \
 		mknod -m 644 /dev/input/mice c 13 63
-	[ -c /dev/input/bluetooth-in ] || \
-		mknod -m 644 /dev/input/bluetooth-in c 250 0
+	[ -c /dev/input/uinput ] || \
+		mknod -m 644 /dev/input/bluetooth-in c 10 223
 	install -m u=rwxs,go=rxs -o pmk -g os bthid /usr/local/bin
-	install -m u=rw,go=r -o root -g root fake.o $(MODINSTDIR)
 	install -m u=rwx,go=rx -o root -g root bluetooth-hid /etc/init.d
-	install -m u=rw,go=r -o root -g root bthid-modules /etc/modutils
 	install -m u=rw,go=r -o root -g root msblue.def /usr/share/hotkeys
 	(cd /etc/rc2.d; \
 	 rm -f S90bluetooth-hid; \
 	 ln -s ../init.d/bluetooth-hid S90bluetooth-hid)
-	update-modules
 
 clean:
 	rm -f $(BTHID_RELS)
 clobber: clean
-	rm -f fake.o bthid
+	rm -f bthid
 
 bthid.tar.gz: $(SHIP)
 	rm -f bthid.tar bthid.tar.gz
diff -ur bthid.orig/out.c bthid/out.c
--- bthid.orig/out.c	2003-01-19 00:58:05.000000000 +0000
+++ bthid/out.c	2003-11-15 21:16:01.000000000 +0000
@@ -3,58 +3,84 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <string.h>
+#include <stdio.h>
 #include <errno.h>
 
+
+#include <asm/types.h>
+#include <linux/input.h>
+#include <linux/uinput.h>
+
 /*
  *	Output to the pseudo-input device
  */
 
-#define	MAX_BUFF 1024
+char *out_path;
 
-char	*out_path;
-
-static	int	out_fd = -1;
-static	int	out_ct;
-static	char	out_buff [MAX_BUFF];
+static int out_fd=-1;
 
 void
-out_open (void) {
-	if (out_fd < 0 && out_path) {
-		out_fd = open (out_path, O_WRONLY | O_NDELAY);
-		if (out_fd < 0) {
-			syslog (LOG_ERR, "can't open %s: %s",
-				out_path, strerror (errno));
-			out_path = 0;
-		}
-	}
+out_open(void)
+{
+    struct uinput_user_dev  device;
+    int aux;
+
+    if (out_fd >=0)
+        return;
+
+    out_fd = open ("/dev/input/uinput", O_RDWR);
+    if (out_fd < 0) {
+        syslog (LOG_ERR, "can't open %s: %s",
+            out_path, strerror (errno));
+        out_path = 0;
+    }
+
+    strcpy(device.name, "Bluetooth device");
+    device.id.bustype = BUS_USB;
+    device.id.vendor = 2;
+    device.id.product = 3;
+    device.id.version = 4;
+    ioctl(out_fd, UI_SET_EVBIT, EV_KEY);
+    ioctl(out_fd, UI_SET_EVBIT, EV_REL);
+
+    /* set key events we can generate (in this case, all) */
+    for (aux = 0; aux < KEY_MAX; aux++)
+        ioctl(out_fd, UI_SET_KEYBIT, aux);
+
+    for (aux = REL_X; aux <= REL_MISC; aux++)
+        ioctl(out_fd, UI_SET_RELBIT, aux);
+
+    /* write down information for creating a new device */
+    if (write(out_fd, &device, sizeof(struct uinput_user_dev)) < 0) {
+        syslog (LOG_ERR, "can't write device description: %s",
+            strerror (errno));
+        close(out_fd);
+        out_fd=0;
+        return;
+    }
+
+    /* actually creates the device */
+    ioctl(out_fd, UI_DEV_CREATE);
 }
 
+static struct input_event event;
+
 void
 out_event (int evt, int which, int amount) {
-	out_buff [out_ct++] = evt;
-	out_buff [out_ct++] = which;
-	out_buff [out_ct++] = which >> 8;
-	out_buff [out_ct++] = amount;
-	if (out_ct == MAX_BUFF)
-		out_ct = 0;
-}
+    if (out_fd < 0)
+        return;
 
+    memset(&event, 0, sizeof(struct input_event));
 
-void
-out_flush (void) {
+    event.code = which;
+    event.type = evt;
+    event.value = amount;
 
-	int	n;
+    write(out_fd, &event, sizeof(struct input_event));
+}
 
-	if (!out_ct)
-		return;
-	if (out_fd >= 0) {
-		n = write (out_fd, out_buff, out_ct);
-		if (n != out_ct) {
-			syslog (LOG_ERR, "error writing to %s: %s",
-				out_path, strerror (errno));
-			close (out_fd);
-			out_fd = -1;
-		}
-	}
-	out_ct = 0;
+void out_flush (void) {
+    memset(&event, 0, sizeof(struct input_event));
+    event.type = EV_SYN;
+    write(out_fd, &event, sizeof(struct input_event));
 }
diff -ur bthid.orig/out.h bthid/out.h
--- bthid.orig/out.h	2003-01-19 00:56:33.000000000 +0000
+++ bthid/out.h	2003-11-15 21:14:44.000000000 +0000
@@ -5,8 +5,6 @@
  *	Output to the pseudo-input device
  */
 
-extern	char	*out_path;
-
 void	out_open (void);
 void	out_event (int /*event*/, int /*which*/, int /*amount*/);
 void	out_flush (void);

Re: [Bluez-users] bthid updated

[Edd Dumbill]

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

Re: [Bluez-users] bthid updated

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] bthid updated

[Florian Echtler]

-----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-----

Re: [Bluez-users] bthid updated

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users