With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes.
Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver.
Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two.
I took a second look at your comments with the help of Benjamin Tissoires, who is by the way working with us for a few weeks here at Logitech.
We finally agreed to remove BUS_DJ, as you suggested, and we are now using BUS_VIRTUAL. We can not use BUS_USB because that would assign the hid-logitech-dj created "virtual" devices back to the hid-logitech-dj module while they should be treated by hid-core.
Concerning the conditional compilation on_id hid_have_special_driver[], we also agreed to remove them. This implies that if the driver is not included by a certain distribution, then the receiver and all of the paired devices will not work at all. Note that today, even if there is no driver installed this devices work in a basic mode. For this reason we added a 'default m' in the Kconfig
Overall, the totality of your suggestions have been addressed.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 306b15f..e0f1360 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -245,6 +245,15 @@ config HID_LOGITECH ---help--- Support for Logitech devices that are not fully compliant with HID standard.
+config HID_LOGITECH_DJ + tristate "Logitech Unifying receivers full support" + depends on HID_LOGITECH + default m + ---help--- + Say Y if you want support for Logitech Unifying receivers and devices. + Unifying receivers are capable of pairing up to 6 Logitech compliant + devices to the same receiver. + config LOGITECH_FF bool "Logitech force feedback support" depends on HID_LOGITECH diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 0a0a38e..ff36e489 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_HID_KEYTOUCH) += hid-keytouch.o obj-$(CONFIG_HID_KYE) += hid-kye.o obj-$(CONFIG_HID_LCPOWER) += hid-lcpower.o obj-$(CONFIG_HID_LOGITECH) += hid-logitech.o +obj-$(CONFIG_HID_LOGITECH_DJ) += hid-logitech-dj.o obj-$(CONFIG_HID_MAGICMOUSE) += hid-magicmouse.o obj-$(CONFIG_HID_MICROSOFT) += hid-microsoft.o obj-$(CONFIG_HID_MONTEREY) += hid-monterey.o diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 1a5cf0c..ab4ae12 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1419,6 +1419,8 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFP_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G25_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G27_WHEEL) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WII_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACETRAVELLER) }, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index db63ccf..2081d1a 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -443,6 +443,8 @@ #define USB_DEVICE_ID_S510_RECEIVER_2 0xc517 #define USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500 0xc512 #define USB_DEVICE_ID_MX3000_RECEIVER 0xc513 +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER 0xc52b +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2 0xc532 #define USB_DEVICE_ID_SPACETRAVELLER 0xc623 #define USB_DEVICE_ID_SPACENAVIGATOR 0xc626 #define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704 @@ -450,6 +452,7 @@ #define USB_DEVICE_ID_DINOVO_MINI 0xc71f #define USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2 0xca03
+ #define USB_VENDOR_ID_LUMIO 0x202e #define USB_DEVICE_ID_CRYSTALTOUCH 0x0006 #define USB_DEVICE_ID_CRYSTALTOUCH_DUAL 0x0007 diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c new file mode 100644 index 0000000..82091ca --- /dev/null +++ b/drivers/hid/hid-logitech-dj.c @@ -0,0 +1,945 @@ +/* + * HID driver for Logitech Unifying receivers + * + * Copyright (c) 2011 Logitech (c) + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Should you need to contact me, the author, you can do so by e-mail send + * your message to Nestor Lopez Casado <xnlopez at gmail com> + * + */ + + +#include <linux/device.h> +#include <linux/hid.h> +#include <linux/module.h> +#include <linux/usb.h> +#include "usbhid/usbhid.h" +#include "hid-ids.h" +#include "hid-logitech-dj.h" + +/* Keyboard descriptor (1) */ +static const char kbd_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (generic Desktop) */ + 0x09, 0x06, /* USAGE (Keyboard) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x01, /* REPORT_ID (1) */ + 0x95, 0x08, /* REPORT_COUNT (8) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0xE0, /* USAGE_MINIMUM (Left Control) */ + 0x29, 0xE7, /* USAGE_MAXIMUM (Right GUI) */ + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ + 0x95, 0x05, /* REPORT COUNT (5) */ + 0x05, 0x08, /* USAGE PAGE (LED page) */ + 0x19, 0x01, /* USAGE MINIMUM (1) */ + 0x29, 0x05, /* USAGE MAXIMUM (5) */ + 0x91, 0x02, /* OUTPUT (Data, Variable, Absolute) */ + 0x95, 0x01, /* REPORT COUNT (1) */ + 0x75, 0x03, /* REPORT SIZE (3) */ + 0x91, 0x01, /* OUTPUT (Constant) */ + 0x95, 0x06, /* REPORT_COUNT (6) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x26, 0xFF, 0x00, /* LOGICAL_MAXIMUM (255) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0x00, /* USAGE_MINIMUM (no event) */ + 0x2A, 0xFF, 0x00, /* USAGE_MAXIMUM (reserved) */ + 0x81, 0x00, /* INPUT (Data,Ary,Abs) */ + 0xC0 +}; + +/* Mouse descriptor (2) */ +static const char mse_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ + 0x09, 0x02, /* USAGE (Mouse) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x02, /* REPORT_ID = 2 */ + 0x09, 0x01, /* USAGE (pointer) */ + 0xA1, 0x00, /* COLLECTION (physical) */ + 0x05, 0x09, /* USAGE_PAGE (buttons) */ + 0x19, 0x01, /* USAGE_MIN (1) */ + 0x29, 0x10, /* USAGE_MAX (16) */ + 0x15, 0x00, /* LOGICAL_MIN (0) */ + 0x25, 0x01, /* LOGICAL_MAX (1) */ + 0x95, 0x10, /* REPORT_COUNT (16) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x81, 0x02, /* INPUT (data var abs) */ + 0x05, 0x01, /* USAGE_PAGE (generic desktop) */ + 0x16, 0x01, 0xF8, /* LOGICAL_MIN (-2047) */ + 0x26, 0xFF, 0x07, /* LOGICAL_MAX (2047) */ + 0x75, 0x0C, /* REPORT_SIZE (12) */ + 0x95, 0x02, /* REPORT_COUNT (2) */ + 0x09, 0x30, /* USAGE (X) */ + 0x09, 0x31, /* USAGE (Y) */ + 0x81, 0x06, /* INPUT */ + 0x15, 0x81, /* LOGICAL_MIN (-127) */ + 0x25, 0x7F, /* LOGICAL_MAX (127) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x09, 0x38, /* USAGE (wheel) */ + 0x81, 0x06, /* INPUT */ + 0x05, 0x0C, /* USAGE_PAGE(consumer) */ + 0x0A, 0x38, 0x02, /* USAGE(AC Pan) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x81, 0x06, /* INPUT */ + 0xC0, /* END_COLLECTION */ + 0xC0, /* END_COLLECTION */ +}; + +/* Consumer Control descriptor (3) */ +static const char consumer_descriptor[] = { + 0x05, 0x0C, /* USAGE_PAGE (Consumer Devices) */ + 0x09,
...
On Thu, Aug 11, 2011 at 05:22:17PM +0200, Nestor Lopez Casado wrote: > With this driver, all the devices paired to a single Unifying > receiver are exposed to user processes in separated /input/dev > nodes.
> Keyboards with different layouts can be treated differently, > Multiplayer games on single PC (like home theater PC) can > differentiate input coming from different kbds paired to the > same receiver.
> Up to now, when Logitech Unifying receivers are connected to a > Linux based system, a single keyboard and a single mouse are > presented to the HID Layer, even if the Unifying receiver can > pair up to six compatible devices. The Unifying receiver by default > multiplexes all incoming events (from multiple keyboards/mice) > into these two.
> I took a second look at your comments with the help of Benjamin > Tissoires, who is by the way working with us for a few weeks here > at Logitech.
> We finally agreed to remove BUS_DJ, as you suggested, and we are now > using BUS_VIRTUAL. We can not use BUS_USB because that would assign > the hid-logitech-dj created "virtual" devices back to the hid-logitech-dj > module while they should be treated by hid-core.
You do not need BUS_VIRTUAL; you can have logi_dj_probe() detect devices that you created (looking at the parent for example) and refuse them with -ENODEV. Then next driver will have chance to bind I believe.
> Concerning the conditional compilation on_id hid_have_special_driver[], > we also agreed to remove them. This implies that if the driver is not included > by a certain distribution, then the receiver and all of the paired devices > will not work at all. Note that today, even if there is no driver installed > this devices work in a basic mode. For this reason we added a 'default m' in > the Kconfig
> Overall, the totality of your suggestions have been addressed.
> +#define NUMBER_OF_HID_REPORTS 32 > +static const u8 hid_reportid_size_map[NUMBER_OF_HID_REPORTS] = { > + 0, /* Not used */ > + 8, /* Standard keyboard */ > + 8, /* Standard mouse */ > + 5, /* Consumer control */ > + 2, /* System control */ > + 0, /* Not used */ > + 0, /* Not used */ > + 0, /* Not used */ > + 2, /* Media Center */
Hmm, instead of notif_fifo_pop() returning variety of return codes why don't you ahve a separate function that tells you if your buffer is empty or not. Or, again, use kfifo.
On Sat, 13 Aug 2011, Benjamin Tissoires wrote: > First of all, thank you for this detailed review. Nestor and I agree > yesterday on the fact that I'll submit the next version of this patch. > He'll be busy for 2 weeks, and I need to work with this driver for other > devices we have at Logitech. I'll make the straight forward changes, and > when it will require more expertise on the receiver, I'll ask to Nestor.
If you could send first the patch with Dmitry's feedback (thanks Dmitry!) incorporated, and support for other devices as a separate patch on top of that, that'd be great.
On Tue, Aug 16, 2011 at 11:46, Jiri Kosina <jkos...@suse.cz> wrote: > On Sat, 13 Aug 2011, Benjamin Tissoires wrote:
>> First of all, thank you for this detailed review. Nestor and I agree >> yesterday on the fact that I'll submit the next version of this patch. >> He'll be busy for 2 weeks, and I need to work with this driver for other >> devices we have at Logitech. I'll make the straight forward changes, and >> when it will require more expertise on the receiver, I'll ask to Nestor.
> If you could send first the patch with Dmitry's feedback (thanks Dmitry!) > incorporated, and support for other devices as a separate patch on top of > that, that'd be great.
That's exactly what we want to do. The corrected patch will come first, and we'll add features later: I'm currently writing them now ;-)
Cheers, Benjamin
PS: sorry for the people in the list, my previous reply has not been accepted by the LKML with my Logitech address.
> Thanks,
> -- > Jiri Kosina > SUSE Labs > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes.
Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver.
Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two.
Signed-off-by: Nestor Lopez Casado <nlopezca...@logitech.com> Signed-off-by: Benjamin Tissoires <btissoi...@logitech.com> ---
Hi guys,
this is the third version of the unifying receiver. I made the changes requested by Dmitry: - switch to kfifo - introduce __func__ in all debugs/errors messages - in logi_dj_ll_input_event, do not use the report of the device, but a copy (is it the right way to do it to avoid the DMA problem?) - switch to BUS_USB for the created devices - small other cosmetic changes
One side note: We really thing using BUS_USB is not the right way to do it when we will have more drivers: by keeping it, we will have no choice but to provide the VIP/PID of the receiver to the created devices. We then will have to handle a manual parsing of the wireless id to know which driver to use. This will result in having all the Logitech's drivers loaded when someone plug an unifying receiver. if we switch to a new BUS_DJ, we could then rely on the automatic user-space loading of the drivers to load only the right drivers.
BTW, as long as Logitech does not provide those drivers (I hope they will come out soon), there is no point using BUS_DJ. So it's fine not using it right now.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 36ca465..0eb7f04 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -231,6 +231,15 @@ config HID_LOGITECH ---help--- Support for Logitech devices that are not fully compliant with HID standard.
+config HID_LOGITECH_DJ + tristate "Logitech Unifying receivers full support" + depends on HID_LOGITECH + default m + ---help--- + Say Y if you want support for Logitech Unifying receivers and devices. + Unifying receivers are capable of pairing up to 6 Logitech compliant + devices to the same receiver. + config LOGITECH_FF bool "Logitech force feedback support" depends on HID_LOGITECH diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index a24cee4..3aba5e7 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_HID_KEYTOUCH) += hid-keytouch.o obj-$(CONFIG_HID_KYE) += hid-kye.o obj-$(CONFIG_HID_LCPOWER) += hid-lcpower.o obj-$(CONFIG_HID_LOGITECH) += hid-logitech.o +obj-$(CONFIG_HID_LOGITECH_DJ) += hid-logitech-dj.o obj-$(CONFIG_HID_MAGICMOUSE) += hid-magicmouse.o obj-$(CONFIG_HID_MICROSOFT) += hid-microsoft.o obj-$(CONFIG_HID_MONTEREY) += hid-monterey.o diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index b0e618b..ebe4fdd 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1423,6 +1423,8 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFP_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G25_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G27_WHEEL) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WII_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACETRAVELLER) }, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index a756ee6..c42764b 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -440,6 +440,8 @@ #define USB_DEVICE_ID_S510_RECEIVER_2 0xc517 #define USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500 0xc512 #define USB_DEVICE_ID_MX3000_RECEIVER 0xc513 +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER 0xc52b +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2 0xc532 #define USB_DEVICE_ID_SPACETRAVELLER 0xc623 #define USB_DEVICE_ID_SPACENAVIGATOR 0xc626 #define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704 diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c new file mode 100644 index 0000000..896328d --- /dev/null +++ b/drivers/hid/hid-logitech-dj.c @@ -0,0 +1,893 @@ +/* + * HID driver for Logitech Unifying receivers + * + * Copyright (c) 2011 Logitech (c) + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Should you need to contact me, the author, you can do so by e-mail send + * your message to Nestor Lopez Casado <xnlopez at gmail com> + * + */ + + +#include <linux/device.h> +#include <linux/hid.h> +#include <linux/module.h> +#include <linux/usb.h> +#include "usbhid/usbhid.h" +#include "hid-ids.h" +#include "hid-logitech-dj.h" + +/* Keyboard descriptor (1) */ +static const char kbd_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (generic Desktop) */ + 0x09, 0x06, /* USAGE (Keyboard) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x01, /* REPORT_ID (1) */ + 0x95, 0x08, /* REPORT_COUNT (8) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0xE0, /* USAGE_MINIMUM (Left Control) */ + 0x29, 0xE7, /* USAGE_MAXIMUM (Right GUI) */ + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ + 0x95, 0x05, /* REPORT COUNT (5) */ + 0x05, 0x08, /* USAGE PAGE (LED page) */ + 0x19, 0x01, /* USAGE MINIMUM (1) */ + 0x29, 0x05, /* USAGE MAXIMUM (5) */ + 0x91, 0x02, /* OUTPUT (Data, Variable, Absolute) */ + 0x95, 0x01, /* REPORT COUNT (1) */ + 0x75, 0x03, /* REPORT SIZE (3) */ + 0x91, 0x01, /* OUTPUT (Constant) */ + 0x95, 0x06, /* REPORT_COUNT (6) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x26, 0xFF, 0x00, /* LOGICAL_MAXIMUM (255) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0x00, /* USAGE_MINIMUM (no event) */ + 0x2A, 0xFF, 0x00, /* USAGE_MAXIMUM (reserved) */ + 0x81, 0x00, /* INPUT (Data,Ary,Abs) */ + 0xC0 +}; + +/* Mouse descriptor (2) */ +static const char mse_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ + 0x09, 0x02, /* USAGE (Mouse) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x02, /* REPORT_ID = 2 */ + 0x09, 0x01, /* USAGE (pointer) */ + 0xA1, 0x00, /* COLLECTION (physical) */ + 0x05, 0x09, /* USAGE_PAGE (buttons) */ + 0x19, 0x01, /* USAGE_MIN (1) */ + 0x29, 0x10, /* USAGE_MAX (16) */ + 0x15, 0x00, /* LOGICAL_MIN (0) */ + 0x25, 0x01, /* LOGICAL_MAX (1) */ + 0x95, 0x10, /* REPORT_COUNT (16) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x81, 0x02, /* INPUT (data var abs) */ + 0x05, 0x01, /* USAGE_PAGE (generic desktop) */ + 0x16, 0x01, 0xF8, /* LOGICAL_MIN (-2047) */ + 0x26, 0xFF, 0x07, /* LOGICAL_MAX (2047) */ + 0x75, 0x0C, /* REPORT_SIZE (12) */ + 0x95, 0x02, /* REPORT_COUNT (2) */ + 0x09, 0x30, /* USAGE (X) */ + 0x09, 0x31, /* USAGE (Y) */ + 0x81, 0x06, /* INPUT */ + 0x15, 0x81, /* LOGICAL_MIN (-127) */ + 0x25, 0x7F, /* LOGICAL_MAX (127) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x09, 0x38, /* USAGE (wheel) */ + 0x81, 0x06, /* INPUT */ + 0x05, 0x0C, /* USAGE_PAGE(consumer) */ + 0x0A, 0x38, 0x02, /* USAGE(AC Pan) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x81, 0x06, /* INPUT */ + 0xC0, /* END_COLLECTION */ + 0xC0, /* END_COLLECTION */ +}; + +/* Consumer Control descriptor (3) */ +static const char
...
> With this driver, all the devices paired to a single Unifying > receiver are exposed to user processes in separated /input/dev > nodes.
> Keyboards with different layouts can be treated differently, > Multiplayer games on single PC (like home theater PC) can > differentiate input coming from different kbds paired to the > same receiver.
> Up to now, when Logitech Unifying receivers are connected to a > Linux based system, a single keyboard and a single mouse are > presented to the HID Layer, even if the Unifying receiver can > pair up to six compatible devices. The Unifying receiver by default > multiplexes all incoming events (from multiple keyboards/mice) > into these two.
> this is the third version of the unifying receiver. I made the changes requested > by Dmitry: > - switch to kfifo > - introduce __func__ in all debugs/errors messages > - in logi_dj_ll_input_event, do not use the report of the device, but a copy > (is it the right way to do it to avoid the DMA problem?) > - switch to BUS_USB for the created devices > - small other cosmetic changes
> One side note: > We really thing using BUS_USB is not the right way to do it when we will have > more drivers: > by keeping it, we will have no choice but to provide the VIP/PID of the > receiver to the created devices. We then will have to handle a manual parsing > of the wireless id to know which driver to use. This will result in having > all the Logitech's drivers loaded when someone plug an unifying receiver. > if we switch to a new BUS_DJ, we could then rely on the automatic user-space > loading of the drivers to load only the right drivers.
> BTW, as long as Logitech does not provide those drivers (I hope they will come > out soon), there is no point using BUS_DJ. So it's fine not using it right now.
On Thu, Sep 01, 2011 at 02:43:32PM +0200, Benjamin Tissoires wrote: > > + > > + usbhid_submit_report(dj_rcv_hiddev, &report, USB_DIR_OUT);
> This is not working when the receiver is paired to a keyboard. When > the session launches, Gnome try to send leds commands to the keyboard > and this results in an oops.
> Using a pointer to the struct hid_report solves the crash.
> However, Dmitry, you told us about a DMA stack problem. Can you give > us a better way to handle that?
Actually it is OK, usbhid_submit_report internally allocates DMA_safe memory for raw report and copies the data for you.
On Fri, Sep 9, 2011 at 20:28, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Thu, Sep 01, 2011 at 02:43:32PM +0200, Benjamin Tissoires wrote: >> > + >> > + usbhid_submit_report(dj_rcv_hiddev, &report, USB_DIR_OUT);
>> This is not working when the receiver is paired to a keyboard. When >> the session launches, Gnome try to send leds commands to the keyboard >> and this results in an oops.
>> Using a pointer to the struct hid_report solves the crash.
>> However, Dmitry, you told us about a DMA stack problem. Can you give >> us a better way to handle that?
> Actually it is OK, usbhid_submit_report internally allocates DMA_safe > memory for raw report and copies the data for you.
With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes.
Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver.
Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two.
Signed-off-by: Nestor Lopez Casado <nlopezca...@logitech.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@gmail.com> ---
Hi guys,
this is the v4 of the bus enumerator patch. Since the v3: - it corrects a kernel oops when starting gnome-panel (due to a hid_report not given as a pointer in logi_dj_ll_input_event). - I also added the function logi_dj_reset_resume to re-enable dj mode after coming from suspend to disk in case usb has been shut off.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 36ca465..0eb7f04 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -231,6 +231,15 @@ config HID_LOGITECH ---help--- Support for Logitech devices that are not fully compliant with HID standard.
+config HID_LOGITECH_DJ + tristate "Logitech Unifying receivers full support" + depends on HID_LOGITECH + default m + ---help--- + Say Y if you want support for Logitech Unifying receivers and devices. + Unifying receivers are capable of pairing up to 6 Logitech compliant + devices to the same receiver. + config LOGITECH_FF bool "Logitech force feedback support" depends on HID_LOGITECH diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index a24cee4..3aba5e7 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_HID_KEYTOUCH) += hid-keytouch.o obj-$(CONFIG_HID_KYE) += hid-kye.o obj-$(CONFIG_HID_LCPOWER) += hid-lcpower.o obj-$(CONFIG_HID_LOGITECH) += hid-logitech.o +obj-$(CONFIG_HID_LOGITECH_DJ) += hid-logitech-dj.o obj-$(CONFIG_HID_MAGICMOUSE) += hid-magicmouse.o obj-$(CONFIG_HID_MICROSOFT) += hid-microsoft.o obj-$(CONFIG_HID_MONTEREY) += hid-monterey.o diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index b0e618b..ebe4fdd 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1423,6 +1423,8 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFP_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G25_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G27_WHEEL) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WII_WHEEL) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD2) }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACETRAVELLER) }, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index a756ee6..c42764b 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -440,6 +440,8 @@ #define USB_DEVICE_ID_S510_RECEIVER_2 0xc517 #define USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500 0xc512 #define USB_DEVICE_ID_MX3000_RECEIVER 0xc513 +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER 0xc52b +#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2 0xc532 #define USB_DEVICE_ID_SPACETRAVELLER 0xc623 #define USB_DEVICE_ID_SPACENAVIGATOR 0xc626 #define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704 diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c new file mode 100644 index 0000000..3963a99 --- /dev/null +++ b/drivers/hid/hid-logitech-dj.c @@ -0,0 +1,913 @@ +/* + * HID driver for Logitech Unifying receivers + * + * Copyright (c) 2011 Logitech (c) + */ + +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Should you need to contact me, the author, you can do so by e-mail send + * your message to Nestor Lopez Casado <xnlopez at gmail com> + * + */ + + +#include <linux/device.h> +#include <linux/hid.h> +#include <linux/module.h> +#include <linux/usb.h> +#include "usbhid/usbhid.h" +#include "hid-ids.h" +#include "hid-logitech-dj.h" + +/* Keyboard descriptor (1) */ +static const char kbd_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (generic Desktop) */ + 0x09, 0x06, /* USAGE (Keyboard) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x01, /* REPORT_ID (1) */ + 0x95, 0x08, /* REPORT_COUNT (8) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0xE0, /* USAGE_MINIMUM (Left Control) */ + 0x29, 0xE7, /* USAGE_MAXIMUM (Right GUI) */ + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ + 0x95, 0x05, /* REPORT COUNT (5) */ + 0x05, 0x08, /* USAGE PAGE (LED page) */ + 0x19, 0x01, /* USAGE MINIMUM (1) */ + 0x29, 0x05, /* USAGE MAXIMUM (5) */ + 0x91, 0x02, /* OUTPUT (Data, Variable, Absolute) */ + 0x95, 0x01, /* REPORT COUNT (1) */ + 0x75, 0x03, /* REPORT SIZE (3) */ + 0x91, 0x01, /* OUTPUT (Constant) */ + 0x95, 0x06, /* REPORT_COUNT (6) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x26, 0xFF, 0x00, /* LOGICAL_MAXIMUM (255) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0x00, /* USAGE_MINIMUM (no event) */ + 0x2A, 0xFF, 0x00, /* USAGE_MAXIMUM (reserved) */ + 0x81, 0x00, /* INPUT (Data,Ary,Abs) */ + 0xC0 +}; + +/* Mouse descriptor (2) */ +static const char mse_descriptor[] = { + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ + 0x09, 0x02, /* USAGE (Mouse) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x02, /* REPORT_ID = 2 */ + 0x09, 0x01, /* USAGE (pointer) */ + 0xA1, 0x00, /* COLLECTION (physical) */ + 0x05, 0x09, /* USAGE_PAGE (buttons) */ + 0x19, 0x01, /* USAGE_MIN (1) */ + 0x29, 0x10, /* USAGE_MAX (16) */ + 0x15, 0x00, /* LOGICAL_MIN (0) */ + 0x25, 0x01, /* LOGICAL_MAX (1) */ + 0x95, 0x10, /* REPORT_COUNT (16) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x81, 0x02, /* INPUT (data var abs) */ + 0x05, 0x01, /* USAGE_PAGE (generic desktop) */ + 0x16, 0x01, 0xF8, /* LOGICAL_MIN (-2047) */ + 0x26, 0xFF, 0x07, /* LOGICAL_MAX (2047) */ + 0x75, 0x0C, /* REPORT_SIZE (12) */ + 0x95, 0x02, /* REPORT_COUNT (2) */ + 0x09, 0x30, /* USAGE (X) */ + 0x09, 0x31, /* USAGE (Y) */ + 0x81, 0x06, /* INPUT */ + 0x15, 0x81, /* LOGICAL_MIN (-127) */ + 0x25, 0x7F, /* LOGICAL_MAX (127) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x09, 0x38, /* USAGE (wheel) */ + 0x81, 0x06, /* INPUT */ + 0x05, 0x0C, /* USAGE_PAGE(consumer) */ + 0x0A, 0x38, 0x02, /* USAGE(AC Pan) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x81, 0x06, /* INPUT */ + 0xC0, /* END_COLLECTION */ + 0xC0, /* END_COLLECTION */ +}; + +/* Consumer Control descriptor (3) */ +static const char consumer_descriptor[] = { + 0x05, 0x0C, /* USAGE_PAGE (Consumer Devices) */ + 0x09, 0x01, /* USAGE (Consumer Control) */ + 0xA1, 0x01, /* COLLECTION (Application) */ + 0x85, 0x03, /* REPORT_ID = 3 */ + 0x75, 0x10, /* REPORT_SIZE (16) */ + 0x95, 0x02, /* REPORT_COUNT (2) */ + 0x15, 0x01, /* LOGICAL_MIN (1) */ + 0x26, 0x8C, 0x02, /* LOGICAL_MAX (652) */ + 0x19, 0x01, /* USAGE_MIN (1) */ + 0x2A, 0x8C, 0x02, /* USAGE_MAX (652) */ + 0x81, 0x00, /* INPUT (Data Ary Abs) */ + 0xC0, /* END_COLLECTION */ +};
...
> With this driver, all the devices paired to a single Unifying
> receiver are exposed to user processes in separated /input/dev
> nodes.
> Keyboards with different layouts can be treated differently,
> Multiplayer games on single PC (like home theater PC) can
> differentiate input coming from different kbds paired to the
> same receiver.
Nice. Does this mean I will be able to use the thumb-button of my M705
mouse in the near future?
>> With this driver, all the devices paired to a single Unifying >> receiver are exposed to user processes in separated /input/dev >> nodes.
>> Keyboards with different layouts can be treated differently, >> Multiplayer games on single PC (like home theater PC) can >> differentiate input coming from different kbds paired to the >> same receiver.
> Nice. Does this mean I will be able to use the thumb-button of my M705 > mouse in the near future?
This is quite weird. I was going to say that it will work, but with the M705 I've got at home,this thumb button doesn't work at all (anything is emitted from the usb, even with this driver). But I'm pretty sure I made it work with the one I got at work.
I'll give a try on Monday unless people at Logitech gave us the solution.
> With this driver, all the devices paired to a single Unifying
> receiver are exposed to user processes in separated /input/dev
> nodes.
> Keyboards with different layouts can be treated differently,
> Multiplayer games on single PC (like home theater PC) can
> differentiate input coming from different kbds paired to the
> same receiver.
> Up to now, when Logitech Unifying receivers are connected to a
> Linux based system, a single keyboard and a single mouse are
> presented to the HID Layer, even if the Unifying receiver can
> pair up to six compatible devices. The Unifying receiver by default
> multiplexes all incoming events (from multiple keyboards/mice)
> into these two.
> this is the v4 of the bus enumerator patch.
> Since the v3:
> - it corrects a kernel oops when starting gnome-panel (due to
> a hid_report not given as a pointer in logi_dj_ll_input_event).
> - I also added the function logi_dj_reset_resume to re-enable dj mode after
> coming from suspend to disk in case usb has been shut off.
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * Should you need to contact me, the author, you can do so by e-mail send
> + * your message to Nestor Lopez Casado <xnlopez at gmail com>
As the file is not copyrighted by a single person, but a company instead, perhaps this paragraph should rather be removed?
On Sun, 11 Sep 2011 10:48:12 +0200, Jiri Kosina said:
> On Sat, 10 Sep 2011, Benjamin Tissoires wrote: > > + * Should you need to contact me, the author, you can do so by e-mail send > > + * your message to Nestor Lopez Casado <xnlopez at gmail com>
> As the file is not copyrighted by a single person, but a company instead, > perhaps this paragraph should rather be removed?
More correctly, these 2 lines should be a patch to MAINTAINERS.
With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes.
Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver.
Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two.
Signed-off-by: Nestor Lopez Casado <nlopezca...@logitech.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@gmail.com> --- Hi guys,
This is patch v5 of the dj bus driver. I addressed the comments from Jiri concerning the double (c) and the paragraph with author information on the file header.
Also changed the tmpstr[20] to tmpstr[3] with an additional check for the validity of the device_index returned by the receiver.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 306b15f..e0f1360 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -245,6 +245,15 @@ config HID_LOGITECH ---help--- Support for Logitech devices that are not fully compliant with HID standard.
I got some information for you. Apparently, it won't be possible to
enable this thumb button right now.
To enable it, the Windows driver put the mouse in a kind of debug mode
that need to be handled properly, which is not the case as of today.
I was able to make it work at home because there were different series
of M705, the latest sending the thumb button by default.
<benjamin.tissoi...@gmail.com> wrote:
> Hi Markus,
> On Sat, Sep 10, 2011 at 09:28, Markus Trippelsdorf
> <mar...@trippelsdorf.de> wrote:
>> On 2011.09.10 at 09:11 +0200, Benjamin Tissoires wrote:
>>> From: Nestor Lopez Casado <nlopezca...@logitech.com>
>>> With this driver, all the devices paired to a single Unifying
>>> receiver are exposed to user processes in separated /input/dev
>>> nodes.
>>> Keyboards with different layouts can be treated differently,
>>> Multiplayer games on single PC (like home theater PC) can
>>> differentiate input coming from different kbds paired to the
>>> same receiver.
>> Nice. Does this mean I will be able to use the thumb-button of my M705
>> mouse in the near future?
> This is quite weird. I was going to say that it will work, but with
> the M705 I've got at home,this thumb button doesn't work at all
> (anything is emitted from the usb, even with this driver).
> But I'm pretty sure I made it work with the one I got at work.
> I'll give a try on Monday unless people at Logitech gave us the solution.
On 2011.09.14 at 18:45 +0200, Benjamin Tissoires wrote:
> I got some information for you. Apparently, it won't be possible to
> enable this thumb button right now.
> To enable it, the Windows driver put the mouse in a kind of debug mode
> that need to be handled properly, which is not the case as of today.
Understood. But all we need to know is the magic bytes to send to the
controller to enable the thumb-button. And because it works without
problems under Windows, it shouldn't be impossible to implement in
Linux. Maybe the Logitech guys could cook something up?
here, you'll find a small C program that allows you to do a pairing of
a new device to a receiver.
compile it with with gcc -o pairing_tool pairing_tool.c
--------------------------------- file pairing_tool.c
---------------------------------
/*
* Copyright 2011 Benjamin Tissoires <benjamin.tissoi...@gmail.com>
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
/* Open the Device with non-blocking reads. */
fd = open(argv[1], O_RDWR|O_NONBLOCK);
if (fd < 0) {
perror("Unable to open device");
return 1;
}
/* Get Raw Info */
res = ioctl(fd, HIDIOCGRAWINFO, &info);
if (res < 0) {
perror("error while getting info from device");
} else {
if (info.bustype != BUS_USB ||
info.vendor != USB_VENDOR_ID_LOGITECH ||
(info.product != USB_DEVICE_ID_UNIFYING_RECEIVER &&
info.product != USB_DEVICE_ID_UNIFYING_RECEIVER_2)) {
errno = EPERM;
perror("The given device is not a Logitech "
"Unifying Receiver");
return 1;
}
}
/* Send the magic sequence to the Device */
res = write(fd, magic_sequence, sizeof(magic_sequence));
if (res < 0) {
printf("Error: %d\n", errno);
perror("write");
} else if (res == sizeof(magic_sequence)) {
printf("The receiver is ready to pair a new device.\n"
"Switch your device on to pair it.\n");
} else {
errno = ENOMEM;
printf("write: %d were written instead of %ld.\n", res,
sizeof(magic_sequence));
perror("write");
}
close(fd);
return 0;
}
----------------------------- end of file pairing_tool.c
----------------------------
>> With this driver, all the devices paired to a single Unifying
>> receiver are exposed to user processes in separated /input/dev
>> nodes.
> But there's still no way to pair devices with an Unifying receiver under
> Linux, right? It would be nice to have a simple userspace tool for that,
> too.
> here, you'll find a small C program that allows you to do a pairing of > a new device to a receiver.
Thanks.
Could you also add the possibility to remove a pairing? It would be nice if the program would print the product name of device detected during the pairing process, too.
I think the tool should be distributed somewhere officially. There are probably a lot of people, who would use the Unifying feature under Linux, but don't read the mailing lists.
On Thu, Sep 22, 2011 at 23:17, Richard Sch tz <r.sc...@t-online.de> wrote: > Am 22.09.2011 22:48, schrieb Benjamin Tissoires:
>> Hi Richard,
>> here, you'll find a small C program that allows you to do a pairing of >> a new device to a receiver.
> Thanks.
> Could you also add the possibility to remove a pairing? It would be nice if > the program would print the product name of device detected during the > pairing process, too.
mmm... this would be more complicated: - the first problem is a NDA and political one. As I worked in Logitech, I had access to some internal (confidential) documentation. I was able to release this piece of code as it can be easily retrieved by adding a spy on the usb stack when doing the pairing on windows. Discovering the command that removes devices is not so easy (to my mind), thus, I can not give it right now. Please note that I asked them if I could release this magic sequence, and it went quite high in the hierarchy (but this piece of code has nothing to do with Logitech, just to be clear). - the second problem is more a technical one. The removal of the device would require you two know which device you want to remove. So it would require the ability to know all the different devices and their pairing number. This information shows up somewhere in the log but there is no way to ask the receiver for this information with the current status of the driver (without knowing internal commands). Getting it from the list of devices would be quite complicated depending on the number of receivers you have plugged, etc... - Obtaining the name of the device can not be retrieved at the moment without knowing the different commands to send to the device. As it's confidential Logitech, I can not give them to you unless someone else does the retro-engineering.
So, to sum up, I agree this would be better, but today, this has to be done by someone else, either officially at Logitech, or by someone not related to Logitech that does the retro-engineering.
> I think the tool should be distributed somewhere officially. There are > probably a lot of people, who would use the Unifying feature under Linux, > but don't read the mailing lists.
I really don't have the time to do it. If somebody else want to pack it and publish it, I'm fine with it. I just gave this piece of code on this channel in order to target skilled persons that are able to compile a C file, and to run it from a shell. Then, if someone wants to do a gui or anything else (the important part in the code is the magic sequence), it's ok for me.
> On Thu, Sep 22, 2011 at 23:17, Richard Schütz<r.sc...@t-online.de> wrote:
>> Am 22.09.2011 22:48, schrieb Benjamin Tissoires:
>>> Hi Richard,
>>> here, you'll find a small C program that allows you to do a pairing of
>>> a new device to a receiver.
>> Thanks.
>> Could you also add the possibility to remove a pairing? It would be nice if
>> the program would print the product name of device detected during the
>> pairing process, too.
> mmm... this would be more complicated:
> - the first problem is a NDA and political one. As I worked in
> Logitech, I had access to some internal (confidential) documentation.
> I was able to release this piece of code as it can be easily retrieved
> by adding a spy on the usb stack when doing the pairing on windows.
> Discovering the command that removes devices is not so easy (to my
> mind), thus, I can not give it right now. Please note that I asked
> them if I could release this magic sequence, and it went quite high in
> the hierarchy (but this piece of code has nothing to do with Logitech,
> just to be clear).
> - the second problem is more a technical one. The removal of the
> device would require you two know which device you want to remove. So
> it would require the ability to know all the different devices and
> their pairing number. This information shows up somewhere in the log
> but there is no way to ask the receiver for this information with the
> current status of the driver (without knowing internal commands).
> Getting it from the list of devices would be quite complicated
> depending on the number of receivers you have plugged, etc...
> - Obtaining the name of the device can not be retrieved at the moment
> without knowing the different commands to send to the device. As it's
> confidential Logitech, I can not give them to you unless someone else
> does the retro-engineering.
> So, to sum up, I agree this would be better, but today, this has to be
> done by someone else, either officially at Logitech, or by someone not
> related to Logitech that does the retro-engineering.
So what do the Logitech guys think about this? Without userspace tools for creating/removing pairings a Unifying receiver is quite useless for Linux users.
On Thu, 22 Sep 2011, Benjamin Tissoires wrote:
> Hi Richard,
> here, you'll find a small C program that allows you to do a pairing of
> a new device to a receiver.
> compile it with with gcc -o pairing_tool pairing_tool.c
Could this perhaps be provided into Documentation/ or samples/ somewhere? I don't think that Logitech themselves do ship pairing application for Linux, or do they?
If they don't, it'd be nice to have this at least documented somewhere, so that someone could write a pairing GUI.
> --------------------------------- file pairing_tool.c
> ---------------------------------
> /*
> * Copyright 2011 Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> *
> * This program is free software: you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation, either version 3 of the License, or
> * (at your option) any later version.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>> here, you'll find a small C program that allows you to do a pairing of
>> a new device to a receiver.
>> compile it with with gcc -o pairing_tool pairing_tool.c
> Could this perhaps be provided into Documentation/ or samples/ somewhere?
> I don't think that Logitech themselves do ship pairing application for
> Linux, or do they?
> If they don't, it'd be nice to have this at least documented somewhere, so
> that someone could write a pairing GUI.
> Thanks.
Hi all,
Just as an FYI there is the Logitech Wireless WiiWheel which also uses the
nRF24L01 in it's dongle.
This wheel is handled in Linux with 'hid-lg' and 'hid-lg4ff' drivers, but
we all know engineers are lazy and a certain amount of the control
protocol is likely to be similar.
Maybe they are of some use from the Unifying dongles.
Cheers,
Simon
--
Configuration
The Wheel/Dongle are configured by writing to the feature port of the USB
dongle. This allows the control of the 'on-air' features, such as
initiating the wireless link, controlling the RF channel/hooping sequence
and RF addressing (sub-channel coding).
When first plugged in the wireless link between the dongle and the wheel
is not active, the link can be 'brought up' with writing the '0xAF
Command' followed by the '0xB2 Command'.
The commands take some time to action, this can be confirmed by reading
back the feature port, when the command completes the MSB of the first
byte will be cleared. For most commands the same data that was sent is
returned, some commands return different data.
Configure RX/TX Address?
Byte 1 - 0xA9
Byte 2 - 2nd and 4th Address/Sub-Channel Bytes
Byte 3 = 3rd and 5th Address/Sub-Channel Bytes
Note 1st Sub-Channel byte is always 0xAE
RF Test Mode
Byte 1 = 0xAC
Byte 2 = Test Mode
0 - Normal Mode (LED flashes on/off as normal)
1 - Constant TX (LED on), RF channel in 'P3' (can kill WiFi ;-)
2 - Pulsed TX (LED flashes long-on/short-off)
3 - Receive Only? (LED off), RF channel in 'P3'. Continually polls
nRF24L01 status and clears
Change RX/TX Address
Byte 1 - 0xB2
Byte 2 - 2nd and 4th Address/Sub-Channel Bytes
Byte 3 = 3rd and 5th Address/Sub-Channel Bytes
Note 1st Sub-Channel byte is always 0xAE
The following commands do not cause SPI activity to the nRF24L01
Check Status?
Byte 1 - 0xA8
Returns RX/TX Address bytes in Byte 5 and Byte 6
Returns whether the 'button' pressed in Byte 7 bit 5
Returns something in Byte 7 bits 4..0 related to 'LED mode' (not a
direct map)
Returns something in Byte 8 which depends on Byte 2 sent
LED Mode
Byte 1 - 0xAA
Byte 2 - changes the way the LED flashes, unknown what is actually
happening
Unknown
Byte 1 - 0xAE
Doesn't clear Byte 1 bit 7, like the other commands. Perhaps it is
waiting for something...
Returns 0x14 in Byte 5 and 0x00 in Byte 6
Active Address?
Byte 1 - 0xB3
Only clears Byte 1 bit 7 if Command '0xAF' is issued first
Returns values in Byte 5 and Byte 6 which are the values from Command
'0xB2' Bytes 2 & 3
--
On 17/04/2012, Jiri Kosina <jkos...@suse.cz> wrote:
> On Thu, 22 Sep 2011, Benjamin Tissoires wrote:
>> Hi Richard,
>> here, you'll find a small C program that allows you to do a pairing of
>> a new device to a receiver.
>> compile it with with gcc -o pairing_tool pairing_tool.c
> Could this perhaps be provided into Documentation/ or samples/ somewhere?
> I don't think that Logitech themselves do ship pairing application for
> Linux, or do they?
Hi Jiri,
well, I don't have any information about an official pairing tool.
However, I don't think the kernel is the good place for this stuff.
Other people started projects based on this code:
https://bitbucket.org/clach04/logitech-unifying-receiver-tools/ for instance.
> If they don't, it'd be nice to have this at least documented somewhere, so
> that someone could write a pairing GUI.
> Thanks.
>> --------------------------------- file pairing_tool.c
>> ---------------------------------
>> /*
>> * Copyright 2011 Benjamin Tissoires <benjamin.tissoi...@gmail.com>
>> *
>> * This program is free software: you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License as published by
>> * the Free Software Foundation, either version 3 of the License, or
>> * (at your option) any later version.
>> *
>> * This program is distributed in the hope that it will be useful,
>> * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> * GNU General Public License for more details.
>> *
>> * You should have received a copy of the GNU General Public License
>> * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> */
