Skip to contentSkip to conversation

Wireless Security Lock driver.

PATCH In review Brian Schau 6 participants 19 messages Jul 30, 2005 – Jul 31, 2005 USB

lore
Share & tools
lore

Brian Schau

author
#0 lore raw

PATCH 1/1 Wireless Security Lock driver.

Hello,

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
A Wireless Security Lock (WSL or weasel :-) is made up of two parts. One part is a receiver which you plug into any available USB port. The other part is a transmitter which at fixed intervals sends "ping packets".
A "ping packet" usually consists of an ID and a flag telling if the transmitter has just been turned on.
Both devices lights up in a nice way when a "ping packet" is send/ received.
The whole idea of this is that when the transmitter is brought out of range one could have a process (such as xscreensaver) lock the display.
The WSL is a toy gadget.

For more information see:

http://www.schau.com/l/wsl/index.html

The WSL driver touches these files:

	drivers/usb/Makefile			(1 line)
	drivers/usb/input/Kconfig		(10 lines)
	drivers/usb/input/Makefile		(1 line)
	drivers/usb/input/hid-core.c		(2 lines)
	drivers/usb/input/wsl.c			(224 lines)

This is my first driver for Linux - feel free to harass me if I am not following procedures or you think the driver is lame. Better still, educate me :-)

/brian

#1 lore raw
Quoted 10 lines · Brian Schau

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
The WSL driver touches these files:

drivers/usb/Makefile (1 line)
drivers/usb/input/Kconfig (10 lines)
drivers/usb/input/Makefile (1 line)
drivers/usb/input/hid-core.c (2 lines)
drivers/usb/input/wsl.c (224 lines)

Quoted 3 lines

This is my first driver for Linux - feel free to harass me if I am not following procedures or you think the driver is lame. Better still, educate me :-)

Please don't take this as harassment, but this mailing list [LKML] is archieved all over the internet... In order for people to see your patch, you should re-send your patch to the list as INLINE text, or as a text attachment. My mailer sends my text attachments as inline text, but I don't think every mailer does the same...

Most people on this list will be happy to look at your patch and harass you / applaud you about it, but only if they don't have to jump through hoops in order to see it ;-)

keep patching...

Signature · 1 line
Michael Krufky
author
#2 lore raw

Hi Michael (and others),

Thanks for the info. Well, the reason why I didn't inline the patch
was due to the size of it - in terms of lines. However, here it is:

drivers/usb/Makefile +1 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/Makefile linux-2.6.13-rc4/drivers/usb/Makefile
@@ -34,6 +34,7 @@
 obj-$(CONFIG_USB_WACOM)		+= input/
 obj-$(CONFIG_USB_ACECAD)	+= input/
 obj-$(CONFIG_USB_XPAD)		+= input/
+obj-$(CONFIG_USB_WSL)		+= input/
 
 obj-$(CONFIG_USB_DABUSB)	+= media/
 obj-$(CONFIG_USB_DSBR)		+= media/
drivers/usb/input/Kconfig +10 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/Kconfig linux-2.6.13-rc4/drivers/usb/input/Kconfig
@@ -272,3 +272,13 @@
 
 	  To compile this driver as a module, choose M here: the module will
 	  be called keyspan_remote.
+
+config USB_WSL
+	tristate "Wireless Security lock"
+	depends on USB && INPUT
+	---help---
+	  Say Y here if you want support for Wireless Security Locks (WSLs)
+	  based on the Cypress Ultra Mouse controller.
+
+	  See <http://www.schau.com/l/wsl/> for more information and
+ 	  "how to use it".
drivers/usb/input/Makefile +1 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/Makefile linux-2.6.13-rc4/drivers/usb/input/Makefile
@@ -40,3 +40,4 @@
 obj-$(CONFIG_USB_WACOM)		+= wacom.o
 obj-$(CONFIG_USB_ACECAD)	+= acecad.o
 obj-$(CONFIG_USB_XPAD)		+= xpad.o
+obj-$(CONFIG_USB_WSL)		+= wsl.o
drivers/usb/input/hid-core.c +1 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/hid-core.c linux-2.6.13-rc4/drivers/usb/input/hid-core.c
@@ -1375,6 +1375,7 @@
 #define USB_VENDOR_ID_CYPRESS		0x04b4
 #define USB_DEVICE_ID_CYPRESS_MOUSE	0x0001
 #define USB_DEVICE_ID_CYPRESS_HIDCOM	0x5500
+#define USB_DEVICE_ID_CYPRES_ULTRAMOUSE	0x7417
 
 #define USB_VENDOR_ID_BERKSHIRE		0x0c98
 #define USB_DEVICE_ID_BERKSHIRE_PCWD	0x1140

@@ -1465,6 +1466,7 @@
 	{ USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW48,

HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW28,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRES_ULTRAMOUSE, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_ESSENTIAL_REALITY,
USB_DEVICE_ID_ESSENTIAL_REALITY_P5, HID_QUIRK_IGNORE },

drivers/usb/input/wsl.c +224 -0

224 lines not on this page · raw message

#3 lore raw

drivers/usb/input/wsl.c line 70

Quoted 12 lines · Brian Schau

Hi Michael (and others),

Thanks for the info. Well, the reason why I didn't inline the patch
was due to the size of it - in terms of lines. However, here it is:

drivers/usb/input/wsl.c +6 -0
+static void wsl_irq_in(struct urb *urb, struct pt_regs *regs)
+{
+	struct usb_wsl *wsl=urb->context;
+	int id=0, retval;
+	+	switch (urb->status) { <==========
+	case -ECONNRESET:

There is something wrong with your patch or mailer.

author
#4 lore raw

*Grrr* - it's the mailer (I'm using Mozilla Thunderbird). I don't
know why it has chosen to fold those two lines.

The section looks like:

+ struct usb_wsl *wsl=urb->context;
+ int id=0, retval;
+
+ switch (urb->status) {
+ case -ECONNRESET:

/brian

Quoted 21 lines · Zwane Mwaikambo

drivers/usb/input/wsl.c line 70

Quoted 13 lines · Brian Schau

Hi Michael (and others),

Thanks for the info. Well, the reason why I didn't inline the patch
was due to the size of it - in terms of lines. However, here it is:

drivers/usb/input/wsl.c +6 -0
+static void wsl_irq_in(struct urb *urb, struct pt_regs *regs)
+{
+	struct usb_wsl *wsl=urb->context;
+	int id=0, retval;
+	+	switch (urb->status) { <==========
+	case -ECONNRESET:

There is something wrong with your patch or mailer.

#5 lore raw
Quoted 2 lines · Brian Schau

*Grrr* - it's the mailer (I'm using Mozilla Thunderbird). I don't
know why it has chosen to fold those two lines.

I use thunderbird too... It does a good job with text file attachments, it inserts them inline correctly... Maybe try again that way?

Signature · 1 line
Michael Krufky
author
#6 lore raw

I'll try it again ... - it looks ok now - sorry for the noise!

drivers/usb/Makefile +1 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/Makefile linux-2.6.13-rc4/drivers/usb/Makefile
@@ -34,6 +34,7 @@
 obj-$(CONFIG_USB_WACOM)		+= input/
 obj-$(CONFIG_USB_ACECAD)	+= input/
 obj-$(CONFIG_USB_XPAD)		+= input/
+obj-$(CONFIG_USB_WSL)		+= input/
 
 obj-$(CONFIG_USB_DABUSB)	+= media/
 obj-$(CONFIG_USB_DSBR)		+= media/
drivers/usb/input/Kconfig +10 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/Kconfig linux-2.6.13-rc4/drivers/usb/input/Kconfig
@@ -272,3 +272,13 @@
 
 	  To compile this driver as a module, choose M here: the module will
 	  be called keyspan_remote.
+
+config USB_WSL
+	tristate "Wireless Security lock"
+	depends on USB && INPUT
+	---help---
+	  Say Y here if you want support for Wireless Security Locks (WSLs)
+	  based on the Cypress Ultra Mouse controller.
+
+	  See <http://www.schau.com/l/wsl/> for more information and
+ 	  "how to use it".
drivers/usb/input/Makefile +1 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/Makefile linux-2.6.13-rc4/drivers/usb/input/Makefile
@@ -40,3 +40,4 @@
 obj-$(CONFIG_USB_WACOM)		+= wacom.o
 obj-$(CONFIG_USB_ACECAD)	+= acecad.o
 obj-$(CONFIG_USB_XPAD)		+= xpad.o
+obj-$(CONFIG_USB_WSL)		+= wsl.o
drivers/usb/input/hid-core.c +2 -0
diff -urN linux-2.6.13-rc4.orig/drivers/usb/input/hid-core.c linux-2.6.13-rc4/drivers/usb/input/hid-core.c
@@ -1375,6 +1375,7 @@
 #define USB_VENDOR_ID_CYPRESS		0x04b4
 #define USB_DEVICE_ID_CYPRESS_MOUSE	0x0001
 #define USB_DEVICE_ID_CYPRESS_HIDCOM	0x5500
+#define USB_DEVICE_ID_CYPRES_ULTRAMOUSE	0x7417
 
 #define USB_VENDOR_ID_BERKSHIRE		0x0c98
 #define USB_DEVICE_ID_BERKSHIRE_PCWD	0x1140

@@ -1465,6 +1466,7 @@
 	{ USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW48, HID_QUIRK_IGNORE },
 	{ USB_VENDOR_ID_CODEMERCS, USB_DEVICE_ID_CODEMERCS_IOW28, HID_QUIRK_IGNORE },
 	{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM, HID_QUIRK_IGNORE },
+	{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRES_ULTRAMOUSE, HID_QUIRK_IGNORE },
 	{ USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE, HID_QUIRK_IGNORE },
 	{ USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20, HID_QUIRK_IGNORE },
 	{ USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5, HID_QUIRK_IGNORE },
drivers/usb/input/wsl.c +224 -0

224 lines not on this page · raw message

Quoted 8 lines · Michael Krufky
Quoted 2 lines · Brian Schau

*Grrr* - it's the mailer (I'm using Mozilla Thunderbird). I don't
know why it has chosen to fold those two lines.

I use thunderbird too... It does a good job with text file attachments, it inserts them inline correctly... Maybe try again that way?

#7 lore raw
In reply to Brian Schau

Hi!

Quoted 8 lines

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
A Wireless Security Lock (WSL or weasel :-) is made up of two parts. One part is a receiver which you plug into any available USB port. The other part is a transmitter which at fixed intervals sends "ping packets".
A "ping packet" usually consists of an ID and a flag telling if the transmitter has just been turned on.

Idea is good... but why don't you simply use bluetooth (built into many notebooks) and bluetooth-enabled phone?

Probably could be done in userspace, too :-).
Pavel

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address
author
#8 lore raw

Hi Pavel,

Hehe - the WSLs are already reality. Sitecom is a producer of these and you can get another brand from ThinkGeek.

Sitecom device:
http://www.sitecom.com/products_info.php?product_id=293&grp_id=1

ThinkGeek:
http://www.thinkgeek.com/gadgets/security/698d/

Why in kernel? Well, the device is based on the Cypress Ultra
Mouse. So with a non WSL aware kernel the events from the WSL will be merged into the standard mouse input queue which will make your mouse pointer move uncontrollable - it'll jump across the screen in a couple of steps every 3 seconds or so. Quite amusing but not very handy!
The problem is described here:

http://www.qbik.ch/usb/devices/showdev.php?id=3095

The WSL kernel driver will translate the device packets to a separate event queue.

And you're right. The WSL driver is not a standalone thingy - you'll some userland tools as well. These can be gotten from:

http://www.schau.com/l/wsl/index.html

The tools contains a patch for xscreensaver (patch submitted to maintainer) and a small WSL monitor program which will monitor in-range/out-of-range signals and disable/enable xscreensaver as needed.

/brian

Quoted 19 lines · Pavel Machek

Hi!

Quoted 8 lines

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
A Wireless Security Lock (WSL or weasel :-) is made up of two parts. One part is a receiver which you plug into any available USB port. The other part is a transmitter which at fixed intervals sends "ping packets".
A "ping packet" usually consists of an ID and a flag telling if the transmitter has just been turned on.

Idea is good... but why don't you simply use bluetooth (built into many notebooks) and bluetooth-enabled phone?

Probably could be done in userspace, too :-).
Pavel

#9 lore raw

Hi!

Quoted 2 lines

Hehe - the WSLs are already reality. Sitecom is a producer of these and you can get another brand from ThinkGeek.

Aha, ok.

Quoted 6 lines

Sitecom device:
http://www.sitecom.com/products_info.php?product_id=293&grp_id=1

ThinkGeek:
http://www.thinkgeek.com/gadgets/security/698d/

Quoted 6 lines

Why in kernel? Well, the device is based on the Cypress Ultra
Mouse. So with a non WSL aware kernel the events from the WSL will be merged into the standard mouse input queue which will make your mouse pointer move uncontrollable - it'll jump across the screen in a couple of steps every 3 seconds or so. Quite amusing but not very handy!

Well, that is if you use /dev/psaux, right? Using event devices you should be able to access it from userland. Or you could drive it using libusb driver.
Pavel

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address
author
#10 lore raw

Hi Pavel,

I (and others) have tried using combinations of libusb/userland stuff - but have failed miserably.

/brian

#11 lore raw

Hi!

Quoted 2 lines

I (and others) have tried using combinations of libusb/userland stuff - but have failed miserably.

You may need to patch input to keep hands off that device, but the rest should be doable using libusb, right? Or talk to vojtech, using input devices should devices without libusb should be possible too.

Pavel

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address
author
#12 lore raw

Part of what I do is to tell input to keep hands of the device (in hid-core.c).

I have tried to contact vojtech - I sent him the patches earlier this week but I got no response. He's probably on vacation or so :-)

Ah well ...

Quoted 12 lines · Pavel Machek

Hi!

Quoted 2 lines

I (and others) have tried using combinations of libusb/userland stuff - but have failed miserably.

You may need to patch input to keep hands off that device, but the rest should be doable using libusb, right? Or talk to vojtech, using input devices should devices without libusb should be possible too.

Pavel

#13 lore raw
In reply to Pavel Machek
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Pavel" == Pavel Machek <[email protected]> writes:

Pavel> Well, that is if you use /dev/psaux, right? Using event devices Pavel> you should be able to access it from userland.

Would /dev/input/mice not also be affected?

Until X can hotplug input devices /dev/input/mice rather than evdev will remain necessary in many cases for a reasonable user experience.

So at least a quirk/whatever to keep that device from being included in mice (and psaux) should be added.

-JimC

Signature · 1 line
James H. Cloos, Jr. <[email protected]>
#14 lore raw

Hi!

Quoted 4 lines

Pavel> Well, that is if you use /dev/psaux, right? Using event devices Pavel> you should be able to access it from userland.

Would /dev/input/mice not also be affected?

Yes, /dev/input/mice == /dev/psaux.

Quoted 5 lines

Until X can hotplug input devices /dev/input/mice rather than evdev will remain necessary in many cases for a reasonable user experience.

So at least a quirk/whatever to keep that device from being included in mice (and psaux) should be added.

Yes... why not. But that should be close to one liner, right?
Pavel

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address
author
#15 lore raw

Yes, the quirk is in the patch :-)

Quoted 21 lines · Pavel Machek

Hi!

Quoted 4 lines

Pavel> Well, that is if you use /dev/psaux, right? Using event devices Pavel> you should be able to access it from userland.

Would /dev/input/mice not also be affected?

Yes, /dev/input/mice == /dev/psaux.

Quoted 5 lines

Until X can hotplug input devices /dev/input/mice rather than evdev will remain necessary in many cases for a reasonable user experience.

So at least a quirk/whatever to keep that device from being included in mice (and psaux) should be added.

Yes... why not. But that should be close to one liner, right?
Pavel

#16 lore raw
In reply to Pavel Machek
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Pavel" == Pavel Machek <[email protected]> writes:

Would /dev/input/mice not also be affected?

Pavel> Yes, /dev/input/mice == /dev/psaux.

What I get for looking in /dev (c 10 1 vs c 13 63) rather than /usr/src/linux. :-/

-JimC

#17 lore raw
In reply to Pavel Machek
Quoted 11 lines · Pavel Machek

Hi!

Quoted 8 lines

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
A Wireless Security Lock (WSL or weasel :-) is made up of two parts. One part is a receiver which you plug into any available USB port. The other part is a transmitter which at fixed intervals sends "ping packets".
A "ping packet" usually consists of an ID and a flag telling if the transmitter has just been turned on.

Quoted 4 lines

Idea is good... but why don't you simply use bluetooth (built into many notebooks) and bluetooth-enabled phone?

Probably could be done in userspace, too :-).

There's a script to this on the gentoo wiki via BlueZ.

http://gentoo-wiki.com/TIP_Bluetooth_Proximity_Monitor

I personally think the problem with this approach is that most phones have bluetooth enabled explicitly as an option, it doesn't run all the time, or default on. Primarily this is because bluetooth can drain your phone's battery (though, I don't know by how much, if you're not actually transferring data over it).

A CR2032 cell, in a specific piece of kit, is going to last for a lot longer than a phone battery.

Signature · 6 lines
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
#18 lore raw

Hi!

Quoted 16 lines
Quoted 9 lines
Quoted 8 lines

I've attached a gzipped version of my Wireless Security Lock patch for v2.6.13-rc4.
A Wireless Security Lock (WSL or weasel :-) is made up of two parts. One part is a receiver which you plug into any available USB port. The other part is a transmitter which at fixed intervals sends "ping packets".
A "ping packet" usually consists of an ID and a flag telling if the transmitter has just been turned on.

Quoted 4 lines

Idea is good... but why don't you simply use bluetooth (built into many notebooks) and bluetooth-enabled phone?

Probably could be done in userspace, too :-).

There's a script to this on the gentoo wiki via BlueZ.

Quoted 7 lines

http://gentoo-wiki.com/TIP_Bluetooth_Proximity_Monitor

I personally think the problem with this approach is that most phones have bluetooth enabled explicitly as an option, it doesn't run all the time, or default on. Primarily this is because bluetooth can drain your phone's battery (though, I don't know by how much, if you're not actually transferring data over it).

I have bluetooth turned on all the time, anyway, and it does not drain battery that badly (standby time goes down 30%?).

Quoted 2 lines

A CR2032 cell, in a specific piece of kit, is going to last for a lot longer than a phone battery.

Well, you know... phones have *rechargable* batteries :-).

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address