Skip to contentSkip to conversation

Writing a bluetooth mouse driver...

Bluez-devel Keith Pemberton 5 participants 7 messages Mar 15, 2004 Bluetooth drivers

lore
Share & tools
lore

Keith Pemberton

author
#0 lore raw

I'm going to write a bluetooth mouse driver for my MS bluetooth mouse just to see if I can do it. (yes, I do know that there is one out there already, but I don't like the way that that driver is doing things). My hang up in understanding is in the communication between the mouse and the wireless transceiver. I am guessing that the functions providing communication to the transceiver are defined in hci.c (or hci.h). Does anyone have a good document that describes how the Bluez stack communicates with different hardware? Any other documents that you can suggest would be much appreciated! Thanks in advance.

Keith

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

maintainer
#1 lore raw

Hi Keith,

Quoted 9 lines

I'm going to write a bluetooth mouse driver for my MS bluetooth mouse just to see if I can do it. (yes, I do know that there is one out there already, but I don't like the way that that driver is doing things). My hang up in understanding is in the communication between the mouse and the wireless transceiver. I am guessing that the functions providing communication to the transceiver are defined in hci.c (or hci.h). Does anyone have a good document that describes how the Bluez stack communicates with different hardware? Any other documents that you can suggest would be much appreciated! Thanks in advance.

actually you must understand how the Bluetooth stack is designed and how the HID profile makes use of it. You will notice that HID uses two L2CAP connections, one for control message and the other one for interrupt messages. The transport protocol is HIDP and than you need of course a HID parser, which is the biggest part.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#2 lore raw
Quoted 2 lines · Marcel Holtmann

messages. The transport protocol is HIDP and than you need of course a HID parser, which is the biggest part.

I spoke with Vojtech last year about moving the HID parser from the USB code into the input subsystem, so that it could be shared with Bluetooth. He seemed happy with that in principle, and I don't think it would be very difficult to implement, but I haven't had time to actually write a patch yet.

p.

maintainer
#3 lore raw

Hi Philip,

Quoted 5 lines

I spoke with Vojtech last year about moving the HID parser from the USB code into the input subsystem, so that it could be shared with Bluetooth. He seemed happy with that in principle, and I don't think it would be very difficult to implement, but I haven't had time to actually write a patch yet.

the problematic part is hid-core.c, because it contains the USB specific transport layer. I ripped it off and included the rest into my HIDP code and it works flawless. The Bluetooth transport code is almost ready. I only need to include some workarounds for the stupid L2CAP disconnect problems with some HID implementations, but this has nothing to do with the HID parser.

Actually the HID parser is independent from the input and USB subsystem, because you can use a Bluetooth transport and the hiddev interface for reading and writing reports. What I have in mind is cleaning up the current code and putting it under drivers/hid/ with this API:

	struct hid_device {
		...

		void *driver_data;
		int (*send)(struct hid_device *device, unsigned char *data, int size);
	}

	struct hid_device *hid_alloc_device(unsigned char *data, int size);
	void hid_free_device(struct hid_device *device);
	int hid_register_device(struct hid_device *device);
	void hid_unregister_device(struct hid_device *device);
	int hid_recv_report(struct hid_device *hid, int type, unsigned char *data, int size);

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#4 lore raw
Quoted 20 lines · Marcel Holtmann

Hi Philip,

Quoted 5 lines

I spoke with Vojtech last year about moving the HID parser from the USB code into the input subsystem, so that it could be shared with Bluetooth. He seemed happy with that in principle, and I don't think it would be very difficult to implement, but I haven't had time to actually write a patch yet.

the problematic part is hid-core.c, because it contains the USB specific transport layer. I ripped it off and included the rest into my HIDP code and it works flawless. The Bluetooth transport code is almost ready. I only need to include some workarounds for the stupid L2CAP disconnect problems with some HID implementations, but this has nothing to do with the HID parser.

Actually the HID parser is independent from the input and USB subsystem, because you can use a Bluetooth transport and the hiddev interface for reading and writing reports. What I have in mind is cleaning up the current code and putting it under drivers/hid/ with this API:

Quoted 12 lines
	struct hid_device {
		...

		void *driver_data;
		int (*send)(struct hid_device *device, unsigned char *data, int size);
	}

	struct hid_device *hid_alloc_device(unsigned char *data, int size);
	void hid_free_device(struct hid_device *device);
	int hid_register_device(struct hid_device *device);
	void hid_unregister_device(struct hid_device *device);
	int hid_recv_report(struct hid_device *hid, int type, unsigned char *data, int size);

This is a very nice idea. I'm all for it.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
maintainer
#5 lore raw

Hi Vojtech,

Quoted 19 lines
Quoted 19 lines

the problematic part is hid-core.c, because it contains the USB specific transport layer. I ripped it off and included the rest into my HIDP code and it works flawless. The Bluetooth transport code is almost ready. I only need to include some workarounds for the stupid L2CAP disconnect problems with some HID implementations, but this has nothing to do with the HID parser.

Actually the HID parser is independent from the input and USB subsystem, because you can use a Bluetooth transport and the hiddev interface for reading and writing reports. What I have in mind is cleaning up the current code and putting it under drivers/hid/ with this API:

	struct hid_device {
		...

		void *driver_data;
		int (*send)(struct hid_device *device, unsigned char *data, int size);
	}
Quoted 7 lines
Quoted 5 lines
	struct hid_device *hid_alloc_device(unsigned char *data, int size);
	void hid_free_device(struct hid_device *device);
	int hid_register_device(struct hid_device *device);
	void hid_unregister_device(struct hid_device *device);
	int hid_recv_report(struct hid_device *hid, int type, unsigned char *data, int size);

This is a very nice idea. I'm all for it.

the problem that I see is that someone has to code it and I am not a real HID parser expert. I want to add kernel side Bluetooth HID support into 2.6.5 and at the moment I only see to choices:

1. I include my ripped hid-core.c and hid-input.c code along with my HIDP code in net/bluetooth/hidp/

2. I build up a basic drivers/hid/ with limited functionality (only input and no hiddev support) and the proposed API. The name of the kernel module should be something like hid-ng.ko until we have a full replacement for hid.ko.

Comments?

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#6 lore raw

[Bluez-devel] Implementing Bluez into microchip MSP430...

In reply to Keith Pemberton

Hi
I have a problem because I have to program microchip to work with a device and let me to communicate with that device over BT. I would be appreciate if someone sent me some helpfull stuff - some steps what to start from. It has to emulate RS232 from my PC to be able to connect BT to any device with RS232 and use hmmm... rfcomm to let me to control that device using old simple programs which work with RS232
Wright now I can communicate between two computers: one with USB dongle and one with dongle connected via RS232.
It's emergency because it has to be done till friday :))

Regards

Maciej Zubilewicz

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel