Wireless Security Lock driver.
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
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
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
@@ -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
@@ -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
@@ -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
@@ -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
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.
*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.
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
I'll try it again ... - it looks ok now - sorry for the noise!
drivers/usb/Makefile +1 -0
@@ -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
@@ -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
@@ -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
@@ -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?
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
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
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
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
Hi Pavel,
I (and others) have tried using combinations of libusb/userland stuff - but have failed miserably.
/brian
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
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
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]>
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/micenot also be affected?
Yes, /dev/input/mice == /dev/psaux.
Quoted 5 lines
Until X can hotplug input devices
/dev/input/micerather 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
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/micenot also be affected?Yes,
/dev/input/mice==/dev/psaux.Quoted 5 lines
Until X can hotplug input devices
/dev/input/micerather 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
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.
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
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Pavel" == Pavel Machek <[email protected]> writes:
Would
/dev/input/micenot 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