login
Search
The following patch series adds 17 new drivers for assorted infrared and/or RF remote control receivers and/or transmitters. These drivers have long lived out-of-tree at http://www.lirc.org/, packaged as 3rd-party modules by many distributions, and more recently, patched into the kernels of at least Fedora and Ubuntu. The primary maintainer of lirc, Christoph Bartelmus simply hasn't had the time to send these bits upstream, and a few months back, gave me the go-ahead to take on the task. Most drivers are fairly widely tested, certainly within the MythTV community, which relies upon this code quite a bit. However, note that in preparation for this submission, a fair number of code changes have been made only recently that may or may not have yet made it back into lirc cvs, and thus might not be as widely tested. Any bugs found were probably introduced by either myself or Janne Grunau, the primary folks working on the latest round of whacking checkpatch.pl complaints to prepare for this submission. Speaking of checkpatch... When I first added the lirc driver patch to the Fedora kernels (oy, way back in August of 2007), there were tens of thousands of lines of checkpatch warnings and errors. Through the efforts of myself, Janne, Eric Sandeen, and misc contributions from others, I'm now quite tickled to see the following: -- $ scripts/checkpatch.pl /data/patches/lirc-for-upstream-combined.patch total: 0 errors, 0 warnings, 17877 lines checked /data/patches/lirc-for-upstream-combined.patch has no obvious style problems and is ready for submission. -- Earlier rounds of checkpatch cleanups have already been fed back into lirc cvs, and Christoph has given me commit access there, so as to filter the latest changes back in as well. For the time being, lirc cvs will continue to be the canonical upstream for the lirc drivers, and all the earlier kernel compat bits get stripped out via an export script[1], though the script is still under a bit of development... I'll be ...
-Add Kconfig and Makefile bits -Add device driver interface and headers The initial Kconfig and Makefile bits were done by Mario Limonciello for the Ubuntu kernel, but have been tweaked a bit since then. Any errors are probably my doing. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> CC: Mario Limonciello <superm1@ubuntu.com> --- MAINTAINERS | 9 + drivers/input/Kconfig | 2 + drivers/input/Makefile | 2 + drivers/input/lirc/Kconfig | 21 + drivers/input/lirc/Makefile | 8 + drivers/input/lirc/lirc.h | 103 ++++++ drivers/input/lirc/lirc_dev.c | 809 +++++++++++++++++++++++++++++++++++++++++ drivers/input/lirc/lirc_dev.h | 262 +++++++++++++ 8 files changed, 1216 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/Kconfig create mode 100644 drivers/input/lirc/Makefile create mode 100644 drivers/input/lirc/lirc.h create mode 100644 drivers/input/lirc/lirc_dev.c create mode 100644 drivers/input/lirc/lirc_dev.h diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 5f9d860..2ba0904 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -170,6 +170,8 @@ source "drivers/input/tablet/Kconfig" source "drivers/input/touchscreen/Kconfig" +source "drivers/input/lirc/Kconfig" + source "drivers/input/misc/Kconfig" endif diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 98c4f9a..4dcb852 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -25,3 +25,5 @@ obj-$(CONFIG_INPUT_MISC) += misc/ obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o obj-$(CONFIG_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o + +obj-$(CONFIG_INPUT_LIRC) += lirc/ diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig new file mode 100644 index 0000000..2a04d9b --- /dev/null +++ b/drivers/input/lirc/Kconfig @@ -0,0 +1,21 @@ +# +# LIRC driver(s) ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_serial.c | 1312 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 1320 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_serial.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 2a04d9b..73403b9 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -18,4 +18,11 @@ config LIRC_DEV help LIRC device loadable module support, required for most LIRC drivers +config LIRC_SERIAL + tristate "Homebrew Serial Port Receiver" + default n + depends on LIRC_DEV + help + Driver for Homebrew Serial Port Receivers + endif diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index cdb4c45..7d76128 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -6,3 +6,4 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o +obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o diff --git a/drivers/input/lirc/lirc_serial.c b/drivers/input/lirc/lirc_serial.c new file mode 100644 index 0000000..465edd9 --- /dev/null +++ b/drivers/input/lirc/lirc_serial.c @@ -0,0 +1,1312 @@ +/**************************************************************************** + ** lirc_serial.c *********************************************************** + **************************************************************************** + * + * lirc_serial - Device driver that records pulse- and pause-lengths + * (space-lengths) between DDCD event on a serial port. + * + * Copyright (C) 1996,97 Ralph Metzler <rjkm@thp.uni-koeln.de> + * Copyright (C) 1998 Trent Piepho <xyzzy@u.washington.edu> + * Copyright (C) 1998 Ben Pfaff <blp@gnu.org> + * Copyright (C) 1999 Christoph Bartelmus ...
Works a treat with the lirc_mceusb receiver hooked to my own mythtv frontend, feeding it signals from a Logitech Harmony 880 remote. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Jarod Wilson <jarod@redhat.com> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_mceusb.c | 890 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 898 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_mceusb.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 73403b9..7dbf1a5 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -18,6 +18,13 @@ config LIRC_DEV help LIRC device loadable module support, required for most LIRC drivers +config LIRC_MCEUSB + tristate "Microsoft Media Center Ed. Receiver, v1" + default n + depends on LIRC_DEV + help + Driver for the Microsoft Media Center Ed. Receiver, v1 + config LIRC_SERIAL tristate "Homebrew Serial Port Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 7d76128..fafdd25 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -6,4 +6,5 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o +obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o diff --git a/drivers/input/lirc/lirc_mceusb.c b/drivers/input/lirc/lirc_mceusb.c new file mode 100644 index 0000000..f1874f3 --- /dev/null +++ b/drivers/input/lirc/lirc_mceusb.c @@ -0,0 +1,890 @@ +/* + * USB Microsoft IR Transceiver driver - 0.2 + * + * Copyright (c) 2003-2004 Dan Conti (dconti@acm.wwu.edu) + * + * This driver is based on the USB skeleton driver packaged with the + * kernel, and the notice from that package has been retained below. + * + * The Microsoft IR ...
Successfully tested with the mce v2 receiver and remote that shipped with my Hauppauge HVR-1500 expresscard tuner. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Jarod Wilson <jarod@redhat.com> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_mceusb2.c | 1119 +++++++++++++++++++++++++++++++++++++ 3 files changed, 1127 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_mceusb2.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 7dbf1a5..0a0b059 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -25,6 +25,13 @@ config LIRC_MCEUSB help Driver for the Microsoft Media Center Ed. Receiver, v1 +config LIRC_MCEUSB2 + tristate "Microsoft Media Center Ed. Receiver, v2" + default n + depends on LIRC_DEV + help + Driver for the Microsoft Media Center Ed. Receiver, v2 + config LIRC_SERIAL tristate "Homebrew Serial Port Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index fafdd25..f6accb9 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -7,4 +7,5 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o +obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o diff --git a/drivers/input/lirc/lirc_mceusb2.c b/drivers/input/lirc/lirc_mceusb2.c new file mode 100644 index 0000000..1e683d3 --- /dev/null +++ b/drivers/input/lirc/lirc_mceusb2.c @@ -0,0 +1,1119 @@ +/* + * LIRC driver for Philips eHome USB Infrared Transceiver + * and the Microsoft MCE 2005 Remote Control + * + * (C) by Martin A. Blatter <martin_a_blatter@yahoo.com> + * + * Transmitter support and reception code cleanup. + * (C) by Daniel Melander ...
Successfully tested with the IR interface on a Hauppauge PVR-250 and the flimsly little grey remote that shipped with it. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannua.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Jarod Wilson <jarod@redhat.com> --- drivers/input/lirc/Kconfig | 8 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_i2c.c | 639 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 648 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_i2c.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 0a0b059..ba30d2e 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -18,6 +18,14 @@ config LIRC_DEV help LIRC device loadable module support, required for most LIRC drivers +config LIRC_I2C + tristate "I2C Based IR Receivers" + default n + depends on LIRC_DEV + help + Driver for I2C-based IR receivers, such as those commonly + found onboard Hauppauge PVR-150/250/350 video capture cards + config LIRC_MCEUSB tristate "Microsoft Media Center Ed. Receiver, v1" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index f6accb9..99765d9 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -6,6 +6,7 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o +obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o diff --git a/drivers/input/lirc/lirc_i2c.c b/drivers/input/lirc/lirc_i2c.c new file mode 100644 index 0000000..4714641 --- /dev/null +++ b/drivers/input/lirc/lirc_i2c.c @@ -0,0 +1,639 @@ +/* + * i2c IR lirc plugin for Hauppauge and Pixelview cards - new 2.3.x i2c stack + * + * Copyright (c) 2000 Gerd Knorr <kraxel@goldbach.in-berlin.de> + * modified for ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_atiusb.c | 1321 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 1329 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_atiusb.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index ba30d2e..e17b39a 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -18,6 +18,13 @@ config LIRC_DEV help LIRC device loadable module support, required for most LIRC drivers +config LIRC_ATIUSB + tristate "ATI RF USB Receiver support" + default n + depends on LIRC_DEV + help + Driver for the ATI USB RF remote receiver + config LIRC_I2C tristate "I2C Based IR Receivers" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 99765d9..ba8d445 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -6,6 +6,7 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o +obj-$(CONFIG_LIRC_ATIUSB) += lirc_atiusb.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o diff --git a/drivers/input/lirc/lirc_atiusb.c b/drivers/input/lirc/lirc_atiusb.c new file mode 100644 index 0000000..0e07204 --- /dev/null +++ b/drivers/input/lirc/lirc_atiusb.c @@ -0,0 +1,1321 @@ +/* lirc_atiusb - USB remote support for LIRC + * (currently only supports X10 USB remotes) + * (supports ATI Remote Wonder and ATI Remote Wonder II, too) + * + * Copyright (C) 2003-2004 Paul Miller <pmiller9@users.sourceforge.net> + * + * This driver was derived from: + * Vladimir Dergachev <volodya@minspring.com>'s 2002 + * "USB ATI Remote support" (input device) + * Adrian Dewhurst ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/commandir.c | 982 +++++++++++++++++++++++++++++++++++++++ drivers/input/lirc/commandir.h | 68 +++ drivers/input/lirc/lirc_cmdir.c | 596 ++++++++++++++++++++++++ drivers/input/lirc/lirc_cmdir.h | 25 + 6 files changed, 1679 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/commandir.c create mode 100644 drivers/input/lirc/commandir.h create mode 100644 drivers/input/lirc/lirc_cmdir.c create mode 100644 drivers/input/lirc/lirc_cmdir.h diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index e17b39a..67802fe 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -25,6 +25,13 @@ config LIRC_ATIUSB help Driver for the ATI USB RF remote receiver +config LIRC_CMDIR + tristate "CommandIR USB Transceiver" + default n + depends on LIRC_DEV + help + Driver for the CommandIR USB Transceiver + config LIRC_I2C tristate "I2C Based IR Receivers" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index ba8d445..86df97d 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -7,6 +7,7 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o obj-$(CONFIG_LIRC_ATIUSB) += lirc_atiusb.o +obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o diff --git a/drivers/input/lirc/commandir.c b/drivers/input/lirc/commandir.c new file mode 100644 index 0000000..a05b0d6 --- /dev/null +++ b/drivers/input/lirc/commandir.c @@ -0,0 +1,982 @@ + +/* + * + * Hardware Driver for COMMANDIR USB Transceiver + * 2005-2007 InnovationOne - Matt Bodkin, ...
Successfully tested earlier tonight, see: https://bugzilla.redhat.com/show_bug.cgi?id=459523 Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Tom Horsley <tom.horsley@att.net> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_imon.c | 1280 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1288 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_imon.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 67802fe..7e37b2d 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -40,6 +40,13 @@ config LIRC_I2C Driver for I2C-based IR receivers, such as those commonly found onboard Hauppauge PVR-150/250/350 video capture cards +config LIRC_IMON + tristate "Soundgraph IMON Receiver" + default n + depends on LIRC_DEV + help + Driver for the Soundgraph IMON IR Receiver + config LIRC_MCEUSB tristate "Microsoft Media Center Ed. Receiver, v1" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 86df97d..f39fa06 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_LIRC_DEV) += lirc_dev.o obj-$(CONFIG_LIRC_ATIUSB) += lirc_atiusb.o obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o +obj-$(CONFIG_LIRC_IMON) += lirc_imon.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o diff --git a/drivers/input/lirc/lirc_imon.c b/drivers/input/lirc/lirc_imon.c new file mode 100644 index 0000000..bdfd953 --- /dev/null +++ b/drivers/input/lirc/lirc_imon.c @@ -0,0 +1,1280 @@ +/* + * lirc_imon.c: LIRC plugin/VFD driver for Ahanix/Soundgraph IMON IR/VFD + * + * Version 0.3 + * Supports newer iMON models that send decoded IR signals. + ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_streamzap.c | 795 +++++++++++++++++++++++++++++++++++ 3 files changed, 803 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_streamzap.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 7e37b2d..c105ac6 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -68,4 +68,11 @@ config LIRC_SERIAL help Driver for Homebrew Serial Port Receivers +config LIRC_STREAMZAP + tristate "Streamzap PC Receiver" + default n + depends on LIRC_DEV + help + Driver for the Streamzap PC Receiver + endif diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index f39fa06..b348110 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_LIRC_IMON) += lirc_imon.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o +obj-$(CONFIG_LIRC_STREAMZAP) += lirc_streamzap.o diff --git a/drivers/input/lirc/lirc_streamzap.c b/drivers/input/lirc/lirc_streamzap.c new file mode 100644 index 0000000..69865cb --- /dev/null +++ b/drivers/input/lirc/lirc_streamzap.c @@ -0,0 +1,795 @@ +/* + * Streamzap Remote Control driver + * + * Copyright (c) 2005 Christoph Bartelmus <lirc@bartelmus.de> + * + * This driver was based on the work of Greg Wickham and Adrian + * Dewhurst. It was substantially rewritten to support correct signal + * gaps and now maintains a delay buffer, which is used to present + * consistent timing behaviour to user space applications. Without the + * delay buffer an ugly hack would be required in lircd, which can + * cause sluggish signal decoding in certain situations. + * + * This driver is based on the ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_igorplugusb.c | 619 +++++++++++++++++++++++++++++++++ 3 files changed, 627 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_igorplugusb.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index c105ac6..8579f96 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -40,6 +40,13 @@ config LIRC_I2C Driver for I2C-based IR receivers, such as those commonly found onboard Hauppauge PVR-150/250/350 video capture cards +config LIRC_IGORPLUGUSB + tristate "Igor Cesko's USB IR Receiver" + default n + depends on LIRC_DEV + help + Driver for Igor Cesko's USB IR Receiver + config LIRC_IMON tristate "Soundgraph IMON Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index b348110..68f8da2 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_LIRC_DEV) += lirc_dev.o obj-$(CONFIG_LIRC_ATIUSB) += lirc_atiusb.o obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o +obj-$(CONFIG_LIRC_IGORPLUGUSB) += lirc_igorplugusb.o obj-$(CONFIG_LIRC_IMON) += lirc_imon.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o diff --git a/drivers/input/lirc/lirc_igorplugusb.c b/drivers/input/lirc/lirc_igorplugusb.c new file mode 100644 index 0000000..ab9bdd6 --- /dev/null +++ b/drivers/input/lirc/lirc_igorplugusb.c @@ -0,0 +1,619 @@ +/* lirc_igorplugusb - USB remote support for LIRC + * + * Supports the standard homebrew IgorPlugUSB receiver with Igor's firmware. + * See http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm + * + * The device can only record bursts of up to 36 ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 6 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_ttusbir.c | 400 +++++++++++++++++++++++++++++++++++++ 3 files changed, 407 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_ttusbir.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 8579f96..7e924fe 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -82,4 +82,10 @@ config LIRC_STREAMZAP help Driver for the Streamzap PC Receiver +config LIRC_TTUSBIR + tristate "Technotrend USB IR Receiver" + default n + depends on LIRC_DEV + help + Driver for the Technotrend USB IR Receiver endif diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 68f8da2..2ee00d1 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -15,3 +15,4 @@ obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o obj-$(CONFIG_LIRC_STREAMZAP) += lirc_streamzap.o +obj-$(CONFIG_LIRC_TTUSBIR) += lirc_ttusbir.o diff --git a/drivers/input/lirc/lirc_ttusbir.c b/drivers/input/lirc/lirc_ttusbir.c new file mode 100644 index 0000000..9ed9c7b --- /dev/null +++ b/drivers/input/lirc/lirc_ttusbir.c @@ -0,0 +1,400 @@ +/**************************************************************************** + ** lirc_ttusbir.c *********************************************************** + **************************************************************************** + * + * lirc_ttusbir - LIRC device driver for the TechnoTrend USB IR Receiver + * + * Copyright (C) 2007 Stefan Macher <st_maker-lirc@yahoo.de> + * + * 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 ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_sasem.c | 969 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 977 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_sasem.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 7e924fe..2731c40 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -68,6 +68,13 @@ config LIRC_MCEUSB2 help Driver for the Microsoft Media Center Ed. Receiver, v2 +config LIRC_SASEM + tristate "Sasem USB IR Remote" + default n + depends on LIRC_DEV + help + Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module + config LIRC_SERIAL tristate "Homebrew Serial Port Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 2ee00d1..1b2793d 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_LIRC_IGORPLUGUSB) += lirc_igorplugusb.o obj-$(CONFIG_LIRC_IMON) += lirc_imon.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o +obj-$(CONFIG_LIRC_SASEM) += lirc_sasem.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o obj-$(CONFIG_LIRC_STREAMZAP) += lirc_streamzap.o obj-$(CONFIG_LIRC_TTUSBIR) += lirc_ttusbir.o diff --git a/drivers/input/lirc/lirc_sasem.c b/drivers/input/lirc/lirc_sasem.c new file mode 100644 index 0000000..003f492 --- /dev/null +++ b/drivers/input/lirc/lirc_sasem.c @@ -0,0 +1,969 @@ +/* lirc_sasem.c - USB remote support for LIRC + * Version 0.5 + * + * Copyright (C) 2004-2005 Oliver Stabel <oliver.stabel@gmx.de> + * Tim Davies <tim@opensystems.net.au> + * + * This driver was derived from: + * Venky Raju <dev@venky.ws> + * "lirc_imon - "LIRC plugin/VFD driver for Ahanix/Soundgraph IMON ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_ite8709.c | 545 +++++++++++++++++++++++++++++++++++++ 3 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_ite8709.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 2731c40..9783639 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -54,6 +54,13 @@ config LIRC_IMON help Driver for the Soundgraph IMON IR Receiver +config LIRC_ITE8709 + tristate "ITE8709 CIR Port Receiver" + default n + depends on LIRC_DEV && PNP + help + Driver for the ITE8709 IR Receiver + config LIRC_MCEUSB tristate "Microsoft Media Center Ed. Receiver, v1" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 1b2793d..1da7c5b 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_IGORPLUGUSB) += lirc_igorplugusb.o obj-$(CONFIG_LIRC_IMON) += lirc_imon.o +obj-$(CONFIG_LIRC_ITE8709) += lirc_ite8709.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SASEM) += lirc_sasem.o diff --git a/drivers/input/lirc/lirc_ite8709.c b/drivers/input/lirc/lirc_ite8709.c new file mode 100644 index 0000000..d03ecf7 --- /dev/null +++ b/drivers/input/lirc/lirc_ite8709.c @@ -0,0 +1,545 @@ +/* + * LIRC driver for ITE8709 CIR port + * + * Copyright (C) 2008 Gr
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_it87.c | 999 ++++++++++++++++++++++++++++++++++++++++ drivers/input/lirc/lirc_it87.h | 116 +++++ 4 files changed, 1123 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_it87.c create mode 100644 drivers/input/lirc/lirc_it87.h diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 9783639..42e9bc3 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -54,6 +54,13 @@ config LIRC_IMON help Driver for the Soundgraph IMON IR Receiver +config LIRC_IT87 + tristate "ITE IT87XX CIR Port Receiver" + default n + depends on LIRC_DEV + help + Driver for the ITE IT87xx IR Receiver + config LIRC_ITE8709 tristate "ITE8709 CIR Port Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 1da7c5b..4ee32f3 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_IGORPLUGUSB) += lirc_igorplugusb.o obj-$(CONFIG_LIRC_IMON) += lirc_imon.o +obj-$(CONFIG_LIRC_IT87) += lirc_it87.o obj-$(CONFIG_LIRC_ITE8709) += lirc_ite8709.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o diff --git a/drivers/input/lirc/lirc_it87.c b/drivers/input/lirc/lirc_it87.c new file mode 100644 index 0000000..0a64847 --- /dev/null +++ b/drivers/input/lirc/lirc_it87.c @@ -0,0 +1,999 @@ +/* + * LIRC driver for ITE IT8712/IT8705 CIR port + * + * Copyright (C) 2001 Hans-Gunter Lutke Uphues <hg_lu@web.de> + * + * 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 ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_sir.c | 1302 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1310 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_sir.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 42e9bc3..b2bdbfb 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -96,6 +96,13 @@ config LIRC_SERIAL help Driver for Homebrew Serial Port Receivers +config LIRC_SIR + tristate "Built-in SIR IrDA port" + default n + depends on LIRC_DEV + help + Driver for the SIR IrDA port + config LIRC_STREAMZAP tristate "Streamzap PC Receiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 4ee32f3..761cb47 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -17,5 +17,6 @@ obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o obj-$(CONFIG_LIRC_SASEM) += lirc_sasem.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o +obj-$(CONFIG_LIRC_SIR) += lirc_sir.o obj-$(CONFIG_LIRC_STREAMZAP) += lirc_streamzap.o obj-$(CONFIG_LIRC_TTUSBIR) += lirc_ttusbir.o diff --git a/drivers/input/lirc/lirc_sir.c b/drivers/input/lirc/lirc_sir.c new file mode 100644 index 0000000..ea192b2 --- /dev/null +++ b/drivers/input/lirc/lirc_sir.c @@ -0,0 +1,1302 @@ +/* + * LIRC SIR driver, (C) 2000 Milan Pikula <www@fornax.sk> + * + * lirc_sir - Device driver for use with SIR (serial infra red) + * mode of IrDA on many notebooks. + * + * 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 2 of the License, or + * (at your option) any later version. + * + * ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_bt829.c | 388 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 396 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_bt829.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index b2bdbfb..2af6278 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -25,6 +25,13 @@ config LIRC_ATIUSB help Driver for the ATI USB RF remote receiver +config LIRC_BT829 + tristate "BT829 based hardware" + default n + depends on LIRC_DEV + help + Driver for the IR interface on BT829-based hardware + config LIRC_CMDIR tristate "CommandIR USB Transceiver" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 761cb47..c5f71fa 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -7,6 +7,7 @@ EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src) obj-$(CONFIG_LIRC_DEV) += lirc_dev.o obj-$(CONFIG_LIRC_ATIUSB) += lirc_atiusb.o +obj-$(CONFIG_LIRC_BT829) += lirc_bt829.o obj-$(CONFIG_LIRC_CMDIR) += lirc_cmdir.o obj-$(CONFIG_LIRC_I2C) += lirc_i2c.o obj-$(CONFIG_LIRC_IGORPLUGUSB) += lirc_igorplugusb.o diff --git a/drivers/input/lirc/lirc_bt829.c b/drivers/input/lirc/lirc_bt829.c new file mode 100644 index 0000000..01cbdfe --- /dev/null +++ b/drivers/input/lirc/lirc_bt829.c @@ -0,0 +1,388 @@ +/* + * Remote control driver for the TV-card based on bt829 + * + * by Leonid Froenchenko <lfroen@galileo.co.il> + * + * 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 2 of the License, or + * (at your option) any later version. + * + * ...
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_parallel.c | 728 ++++++++++++++++++++++++++++++++++++ drivers/input/lirc/lirc_parallel.h | 26 ++ 4 files changed, 762 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_parallel.c create mode 100644 drivers/input/lirc/lirc_parallel.h diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 2af6278..fb8ba38 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -89,6 +89,13 @@ config LIRC_MCEUSB2 help Driver for the Microsoft Media Center Ed. Receiver, v2 +config LIRC_PARALLEL + tristate "Homebrew Parallel Port Receiver" + default n + depends on LIRC_DEV && !SMP + help + Driver for Homebrew Parallel Port Receivers + config LIRC_SASEM tristate "Sasem USB IR Remote" default n diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index c5f71fa..3a1469c 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_LIRC_IT87) += lirc_it87.o obj-$(CONFIG_LIRC_ITE8709) += lirc_ite8709.o obj-$(CONFIG_LIRC_MCEUSB) += lirc_mceusb.o obj-$(CONFIG_LIRC_MCEUSB2) += lirc_mceusb2.o +obj-$(CONFIG_LIRC_PARALLEL) += lirc_parallel.o obj-$(CONFIG_LIRC_SASEM) += lirc_sasem.o obj-$(CONFIG_LIRC_SERIAL) += lirc_serial.o obj-$(CONFIG_LIRC_SIR) += lirc_sir.o diff --git a/drivers/input/lirc/lirc_parallel.c b/drivers/input/lirc/lirc_parallel.c new file mode 100644 index 0000000..912cad2 --- /dev/null +++ b/drivers/input/lirc/lirc_parallel.c @@ -0,0 +1,728 @@ +/**************************************************************************** + ** lirc_parallel.c ********************************************************* + ...
Hopefully, I get this summary more or less correct... A number of Hauppauge devices contain both an IR receiver and an IR transmitter. The RX side is rather similar to those handled by the lirc_i2c driver, but the TX side is quite different. Devices with both have to be handled a bit carefully... The TX side is serviced by a zilog processor, running some zilog firmware, but is interfaced with via a software db/table apparently written by a Hauppauge sub-contractor. This is provided via a binary blob, loaded via a request_firmware() call, and the binary blob was generated via i2c sniffing, so general consensus between myself, Janne, Steve and Mike was that there shouldn't be any reason it can't be redistributed, but Mark (the original author) and Christoph had concerns about redistribution, so this originally lived outside of lirc cvs as lirc_pvr150.c. Either way, the "firmware" lives out of tree at the moment anyhow... See http://www.blushingpenguin.com/mark/blog/?p=24 for more details. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> CC: Mike Krufky <mkrufky@linuxtv.org> CC: Steven Toth <stoth@hauppauge.com> CC: Mark Weaver <mark@npsl.co.uk> --- drivers/input/lirc/Kconfig | 9 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_zilog.c | 1395 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 1405 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_zilog.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index fb8ba38..47183ee 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -130,4 +130,13 @@ config LIRC_TTUSBIR depends on LIRC_DEV help Driver for the Technotrend USB IR Receiver + +config LIRC_ZILOG + tristate "Zilog/Hauppauge IR Transmitter" + default n + depends on LIRC_DEV + help + Driver for the Zilog/Hauppauge IR Transmitter, found on + PVR-150/500, ...
--- diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 5f9d860..2ba0904 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -170,6 +170,8 @@ source "drivers/input/tablet/Kconfig" source "drivers/input/touchscreen/Kconfig" +source "drivers/input/lirc/Kconfig" + source "drivers/input/misc/Kconfig" endif diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 98c4f9a..4dcb852 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -25,3 +25,5 @@ obj-$(CONFIG_INPUT_MISC) += misc/ obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o obj-$(CONFIG_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o + +obj-$(CONFIG_INPUT_LIRC) += lirc/ diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig new file mode 100644 index 0000000..47183ee --- /dev/null +++ b/drivers/input/lirc/Kconfig @@ -0,0 +1,142 @@ +# +# LIRC driver(s) configuration +# +menuconfig INPUT_LIRC + bool "Linux Infrared Remote Control IR receiver/transmitter drivers" + default n + help + Say Y here, and all supported Linux Infrared Remote Control IR and + RF receiver and transmitter drivers will be displayed. When paired + with a remote control and the lirc daemon, the receiver drivers + allow control of your Linux system via remote control. + +if INPUT_LIRC + +config LIRC_DEV + tristate "LIRC device loadable module support" + default m + help + LIRC device loadable module support, required for most LIRC drivers + +config LIRC_ATIUSB + tristate "ATI RF USB Receiver support" + default m + depends on LIRC_DEV + help + Driver for the ATI USB RF remote receiver + +config LIRC_BT829 + tristate "BT829 based hardware" + default m + depends on LIRC_DEV + help + Driver for the IR interface on BT829-based hardware + +config LIRC_CMDIR + tristate "CommandIR USB Transceiver" + default m + depends on LIRC_DEV + help + Driver for the CommandIR USB Transceiver + +config LIRC_I2C + tristate "I2C Based IR Receivers" + default ...
[Yes, you said I shouldn't do more reviews of the posted code, but the following was already pretty much written. I really only found one thing in this driver, and I suspect it may not have been addressed yet. This was set to be the last anyway, I'm pretty much out of time for now.] jon The timer acquires the lock too, so this looks a bit like a deadlock to me. Probably del_timer_sync() should be called without the lock? --
The driver can only do one or the other? You can't have both in the system? And somehow the user is supposed to configure it at load time to I *guess* that's one value per file, but it's still not quite the sysfs norm. How about one-word status codes which can be made more verbose by I wonder if the single-open semantics are really doing what the author This discards "retval", which could hold an error status - the function What if this races with another thread waiting for the completion? It seems like it should be completed with complete_all(), but that wasn't the case. --
All three already resolved. I think it would wise to stop the review of this patch set until we repost or review based on Jarod's git repository (http://git.wilsonet.com/linux-2.6-lirc.git/). Thanks for the reviews so far. Janne --
Yeah, I'd say for any driver that hasn't yet been reviewed, if anyone wants to continue reviewing, it might be best to poke the version in that git tree, as a number of issues common across multiple drivers have already (hopefully) been whacked. We'll definitely put together an updated patch set in the near future, but at the moment, we're still working through all the bits that have Indeed, very much appreciated! -- Jarod Wilson jarod@redhat.com --
Should be autodetected by default now, based on usb device ID, but can still be overridden by a module para 'display_type'. Not sure exactly what would happen if the user had more than one, but I don't know why they would in the Original author probably thought it was necessary. Certainly doesn't look like Yuk. There really is no user space. But chances of someone stumbling upon these directions in sysfs are pretty slim. Reducing to single-word, and logging a url pointer to the lirc.org page on setting these up. Sound sane I think we're good to go with disconnect_sem being converted to an actual Agreed. At this point, we're disconnecting, no point in waiting on anyone else. I've attempted to remedy everything, compile-tested and briefly run-time tested the changes, and have pushed 'em all into my git tree. My shiny new iMon Knob receiver and remote are reasonably happy still (less some lockdep spew that I have to figure out what to do with still), but I have no vfd or lcd to test with, unfortunately. -- Jarod Wilson jarod@redhat.com --
No. The lock here is worthless, as is the check for context->ir_isopen, as this function *only* gets called with the driver_lock held in lirc_dev, and lirc_dev won't call this if the device is already open. I've simply dropped the context lock, as its not needed at all (and in fact, triggered lockdep spew). -- Jarod Wilson jarod@redhat.com --
This driver has real locking problems. Parts of it depend on the BKL, but I would have a hard time arguing for the addition of new BKL users in this century. The assumption that ->open() is called under the BKL no longer holds. It's really time to put a proper lock here. As with a previous driver, a more descriptive name than "usb_skel" would be nice. As far as I can tell, the kref here is just extra overhead. Why not just [...] This kind of stuff looks like a recipe for confusion. Why not just deal For devfs?? Again, this messing around with the minor number looks like So it ignores the count the user asked for and stuffs the full length down So we have a command parser built into this driver. It looks like somebody wanted to avoid ioctl() at all costs. But ioctl() exists for a reason, and this looks like a good use for it to me. Of course, now this is a user-space API which will be hard to change, but I think consideration This code never checks minor for validity, it just assumes that the device exists - and that the current process has the right to mess with it. I will confess that I have no clue what this function is really trying to do. I also note, though, that the only call to it is commented out. So it This looks like mdelay() in disguise? Perhaps something that sleeps would Ah, this is why those functions are exported? Is there any reason not to Hmm... num_data_bytes can be 60, so num_data values can be 20, so i*4+3 Hmm...I think there ought to be a better way. Even before considering That's a global buffer - what's protecting it from concurrent access? I assume that compatibility is not needed now? In that case, this code (and safe_udelay()) can go away. jon --
Hi, there is a user-space driver that is going to replace the kernel driver for the CommandIR driver. I don't think there is a reason anymore to get this driver into the kernel. Added, Matthew. Christoph --
The kernel-space drivers for CommandIR devices are being dropped entirely, in favor of the new userspace driver for it, which is included in the lirc 0.8.4pre1 userspace. -- Jarod Wilson jarod@redhat.com --
We already have proper input drivers for these devices (ati_remote and ati_remote2). -- Ville Syrjälä syrjala@sci.fi http://www.sci.fi/~syrjala/ --
True, though I think some users still prefer using them with the lirc drivers
for assorted reasons. Configuring something like mythtv to work with the
ati_remote{,2} driver appears to be a bit more complex (or at least non-
standard vs. several other popular remotes) and not as functional vs.
configuring mythtv w/lirc_atiusb.
http://evuraan.blogspot.com/2008/01/how-to-use-ati-remote-wonder-ii-
remote.html
--
Jarod Wilson
jarod@redhat.com
--
Bad idea to have two drivers for the same piece of hardware. And this gets straight back into the why should lirc be different from the input layer point raised earlies. I think we really shouldn't keep lirc as a separate subsystem, but make sure all the drivers are written to the input layer. To make the migration easier for exiting users we could add a /dev/lirc driver ontop of the input layer, similar to how the ps2 mouse and joystick drivers sit ontop of the input core. --
There have been concerns on the lirc list that integrating with the input core would mean that the kernel has to translate from the lirc timing data to key strokes. Keyboards do their translation in user space, lirc can do the same, right? User space app receives lirc event and then calls a translation library function. A second issue is that some IR drivers are completely in user space. Is there a mechanism for these user space drivers to send events down into the input layer? These events would then get queued with the other kernel generated events and be delivered to consuming apps in -- Jon Smirl jonsmirl@gmail.com --
Uinput driver (/dev/uinput, drivers/input/misc/uinput.c) can be used to inject events into kernel for subsequent distribution through normal interfaces (console, evdev, etc). -- Dmitry --
Some drivers don't report events but deliver the signal to the lirc daemon. The daemon decodes the signal. Decoding of several IR protocols and mapping of each possible remote to events are things much easier done in userspace. Aslo LIRC is not only about IR input but also output. See following mail from Christoph Bertelmus for more details. This shouldn't be necessary since the lirc daemon can already read from input devices. Janne --
Okay, so what I'm hearing and thinking is that we should at drop lirc_atiusb
from consideration for inclusion, and instead extend ati_remote{,2} as/if
necessary to be able to let the lirc daemon use it via the provided input
device, so people can get the best of both worlds (it behaves like a keyboard
if so configured, talks to lircd if so configured).
--
Jarod Wilson
jarod@redhat.com
--
Mixing these two in the same interface seems like a really bad idea. The input layer is the right interface for devices that directly produce events. If you want to decode them in userspace you need a different interface for the daemon. Not sure why you really want to do this in The input layer also does some outputs, like the pc speaker :) --
The X11 limitations are unfortunate but they can be worked around with keymap support in the kernel driver. ati_remote2 keymap patch is somewhere on it's way upstream as we speak. Not sure about ati_remote though. Furthermore if lirc can already handle input from event devices then the lirc_atiusb drivers are simply not needed. -- Ville Syrjälä syrjala@sci.fi http://www.sci.fi/~syrjala/ --
X's evdev support is also maturing and hopefully hotplug support will be -- Dmitry --
Knew I had to screw up at least one thing. That should be j@jannau.net, not jannua.net. -- Jarod Wilson jarod@redhat.com --
This driver offers relatively few things to gripe about. But I'm not one It looks like this driver is semaphore-free? Actually, it looks kind of lock-free in general. That's probably my biggest concern; what is This ignores the return value from the first i2c_smbus_read_byte() and i2c_smbus_write_byte() calls. Beyond that, i2c_smbus_read_byte() can return -EANYTHING, so I think the check should be "rc < 0", no? Tests Why are all these modules being loaded here? That would seem like a job for udev. jon --
On Tue, 9 Sep 2008 00:05:49 -0400 As I understand it, proper assertions of copyright need the word My guess is that this will not be a major impediment to mainline inclusion; What is the locking regime for this function? As far as I can tell, it's called with no locking at all, even though it's manipulating the irctl This kind of formatting suggests that, just maybe, the control structures Looking at lirc_unregister_plugin(), I don't see any cause of failure that could be expected to go away one second later. But this code has the look of something somebody actually needed once upon a time. Am I missing One function sets ir->flags.connected under lock, the other does not. Is that what was intended? Also, set_use_inc() is returning a normal zero-or-negative-error status to an outside caller. It shouldn't return a locally-defined symbol like That looks like roughly 1400 bytes on the stack - on a 32-bit system. Why do you need to delay here? And wouldn't something like msleep() be a better way to do it? My first reaction here was that .ioctl=lirc_ioctl is missing. But, of course, it's the plugin ioctl() function instead. I still think that needs Usually this kind of error recovery is handled at the end of the function with a series of cascading goto labels. To find it wedged into the middle of this (very long) function as a switch is a bit disorienting. Normal execution will just route around the whole thing via the (missing) default branch. I think it would be better to put it at the end and use the normal At this point, the plugin is already registered, but you're still You're calling functions from lirc_dev.c, so modprobe will not load this module until lirc_dev is already there. There's no point in trying to load "return 0;" please. jon --
As far as I understand it your statement is only true if you are in
the USA and travel back in time by at least 20 years, and otherwise
no proper assertion is required at all.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
General convention is that this sort of changelog information belongs in the SCM, not in the code. That's doubly true for the USB skeleton driver Perhaps renaming this structure to something more directly descriptive res is set many times in this function, but it is never checked. It seems to me like the addition of some error handling would be a good idea. Hmm...how was that information obtained? If this driver was reverse-engineered, it would be good to know just what process was As others have noted, I think, getting new sleep_on() calls into the kernel So...this driver has a mutex called "sem" and a semaphore called "minor_table_mutex". I suspect that minor_table_mutex should, in fact, be a mutex. This will leak the memory allocated for dev. It also leaves the entry in minor_table pointing to a nonfunctional device. jon --
I don't really care and I agree that the SCM is the preferred place for the information. The only problem is that the info is in a different SCM (lirc cvs repository). I've removed the changelogs from all files as long as no names wre sigh, It would be a good idea, not sure if I'm motivated enough to add That's probably a question for the original author, Dan. CC added. I'm yes, the declaration looks like this: static DECLARE_MUTEX(...); which gives us a single holder semaphore. the static in front of DECLARE_MUTEX() fools checkpatch. changed to to DEFINE_MUTEX, also in fixed. Thanks for the review. Janne --
I'll take a look, I've at least got the hardware to test with. -- Jarod Wilson jarod@redhat.com --
Argh, I replied too quickly. kfree(dev) and minor_table cleanup are in mceusb_delete() Janne --
So where do all these LIRC_SERIAL_* macros come from? I can't really tell It would be really nice to use the .field=value structure initialization This is a little scary. Maybe hrtimers would be a better way of handling This all looks like a reimplementation of ioport_map() and the associated This looks like a hard busy wait, without even an occasional, polite, cpu_relax() call. There's got to be a better way? The i2c code has the result of a lot of bit-banging work, I wonder if That won't help you if an interrupt is handled by another processor. This needs proper locking, methinks. Nothing in this function does anything to assure itself that the port actually exists and is the right kind of hardware. Maybe that can't really OK, so set_use_inc() really is just an open() function. It still seems like a strange duplication. Again, local_irq_save() seems insufficient here. You need a lock to serialize access to the hardware. jon --
Hi [...] This might actually be the most common setup, as it is very easy to build[1] with minimal soldering skills and has also been used by various vendors (older models of the TechniSat SkyStar2 DVB-S budget card, to name just one example; it is only slowly being replaced by alternative means, as serial ports are becoming rare on newer systems. Regards Stefan Lippers-Hollmann [1] http://www.lirc.org/receivers.html --
One frequently-used source of pre-built serial receivers (and transmitters) here in the US is http://irblaster.info/. Hey, that actually just reminded me... I think I *do* have a serial IR receiver laying about somewhere that came w/one of my TechniSat SkyStar HD-5000 cards... Thank you, Stefan! ;) -- Jarod Wilson jarod@redhat.com --
Bleah. I believe these get passed in when building lirc userspace and drivers together, when manually selected the specific type of serial receiver you have in lirc's menu-driven configuration tool thingy... In other words, they do us absolutely no good here. We just build for the default type (LIRC_HOMEBREW), and users can override the type as necessary via Sounds plausible, will look into it. Of course, this partially hinges on the Hrm... So at some point in the past, there was an "#if defined(rdtscl)" in the lirc_serial.c code that triggered USE_RDTSC being defined. At the moment, there's nothing defining it (I probably overzealously nuked it during clean- up), so we're not even touching the above code. However, this is supposed to be the "better" code path wrt producing a reliable waveform, at least on platforms with rdtscl... Will have to do some investigating... This actually affects whether or not we bother with hrtimers as suggested above too, as We should probably try to make sure the port actually exists, but I don't think there's a whole lot (if anything) we can do as far as verifying the Going to let the duplication be for the moment, since I don't know the history behind why there's duplication, and there are enough other mountains to climb Will do. -- Jarod Wilson jarod@redhat.com --
Do you rely on this specific major? Since your daemon opens /dev/lirc0 you don't need a fixed major do you? LIRC_SERIAL_TRANSMITTER is used in patch 2 and just to enable a module options. Since it is always the case, please remove it. if you need this than you use the BKL back. As far as I remember the ioctl() handler in kernel core no longer takes the BKL and I don't For all comments above functions: - Please use the default comment style. - don't comment obvious things - please use kernel doc if this inline can go in my opinion. The others here as well. It is not You don't need that one. subsys_initcall() does the right thing for you Please don't enforce formating that way. Regards, Sebastian --
Added CONFIG_LIRC_SERIAL_TRANSMITTER to Kconfig and removed this from A relict. Lirc used many single holder semaphore and I forgot to remove the include after converting them to mutexes. I'll check the other Probably not, but it doesn't make a difference for the current kernel. The only other hit for this symbol is arch/xtensa/kernel/syscall.c 38:#undef __KERNEL_SYSCALLS__ There is only one other inline. I doubt it makes a difference there but I won't change it without test. It does for the object size since the function is only called from one place. yes, and while this is ugly I see no obvious CodingStyle violation. is following better? bytes_in_key = p->code_length/8; if (p->code_length%8) Afaik yes, all drivers using this symbol are in this patchset and under GPL. If it is desireable to to use EXPORT_SYMBOL_GPL() has someone else Removed, from all other files as well. Thanks for the review. We will address the misssing comments later Janne --
bytes_in_key = p->code_length / 8; if (p->code_length % 8) bytes_in_key++; I meant the missing spaces around / and %. Looking now at it, it seems Sebastian --
There is also BITS_TO_LONGS(x) which does the intended. I found it only since it uses DIV_ROUND_UP. Will use that. Thanks. Janne --
Hi Janne, Please keep EXPORT_SYMBOL(). Christoph --
Needs to change anyway 60 is already assigned for local and experimental use. Alan --
Really? .open() has been changed to be called without the BKL held, but
.ioctl() is still called with BKL protection. Currently, many .ioctl()
implementations are replaced by .unlocked_ioctl() which take the BKL
themselves if necessary or if it is not yet clear whether they would
work without BKL protection.
This should be audited for the following aspects:
- Could there be a race condition between irctl_open() and
lirc_dev_init()? If yes, try to rework them to eliminate the race,
or as a last resort take the BKL in irctl_open().
- Does irctl_ioctl() require BKL protection, i.e. does it have to be
serialized against itself and against irctl_open()? If not, replace
it by .unlocked_ioctl. If yes, preferably convert it to
.unlocked_ioctl too and add a local mutex for the necessary
serialization.
(Added Cc: Jonathan Corbet to correct me if I'm wrong.)
--
Stefan Richter
-=====-==--- =--= -=--=
http://arcgraph.de/sr/
--
Janne took care of these. Heck, he's already replied, I'll just leave out the Historical. I think it is supposed to signify that this was originally licensed and written by Artur, but simply removing "(L) " is fine (here and in Yeah, but now that you point that out, I'm not sure how... :) Me too. Gone. -- Jarod Wilson jarod@redhat.com --
Hi, LIRC does not rely on a specific major. But to be honest, the last time I looked into this issue, was when devfs was bleeding-edge... So, we need some advice here how to proceed. Should we try to register an official major number for LIRC? Should we try to have a minor number mapping, e.g. /dev/lirc/serial/0 LIRC device on 1st UART serial port ... /dev/lirc/serial/n LIRC device on n-th UART serial port /dev/lirc/parallel/0 LIRC device on 1st parallel port ... /dev/lirc/parallel/n LIRC device on n-th parallel port /dev/lirc/usb/0 1st LIRC USB device ... Christoph --
Janne took a crack at dynamic device allocation earlier today, committed into my git tree: http://git.wilsonet.com/linux-2.6- lirc.git/?a=commitdiff;h=ea74897bf7b03e2ed2401df3815637caa0702eab Haven't yet tested it out, that's on tap for tonight... -- Jarod Wilson jarod@redhat.com --
Hi Jarod, The problem is this: http://www.lirc.org/html/configure.html#multiple Quoting the very last paragraph: "The only situation where the described procedure will not work is when you have two devices that both use a kernel driver that can only handle one device at once like e.g. lirc_serial, lirc_sir or lirc_parallel. You can still make it work with a trick by compiling the affected driver multiple times using different names and different major numbers. You will find detailed instructions how to achieve this by searching the mailing list. Lifting this limitation is one of the todo items for future releases." The limitation that lirc_serial can only handle one device at a time still exists and I think we should have a concept how to solve it before the drivers are merged into the kernel. Christoph --
Jarod Wilson <jwilson@redhat.com> writes: This means you always wake up every half a second? That will not make the powertop users happy. When there's nothing to do it should just sleep. The checks in plugin_register seem a bit extreme. Always use the #ifdef MODULE path, it does DTRT when compiled in too. Remove the init_module wrapper, replace with module_init() ... not read further ... -Andi -- ak@linux.intel.com --
LIRC_SERIAL_TRANSMITTER is already gone, not sure that should happen to done thanks for the review. My changes are until Jarod pulls them in following tree git://git.jannau.net/linux-2.6-lirc.git Janne --
> pr_printk is not found in include/ nor by google. please explain pr_debug() sorry. -Andi --
pr_debug() does something else. that dprintk macro prints depending on a module parameter Janne --
pr_debug() is what you want, 2.6.28 will turn it into a dynamic option to turn on and off at a per-module level. Actually you should be using dev_dbg() instead, that's much better and will also work the same way on a per-module level. thanks, greg k-h --
n is the default, no needed add a "default n" line for it. Anyone configuring the kernel should know he's on Linux, so strike the Obviously this can be built in, so it should be named better. Also I don't think LIRC means anything to a user, so use Infrared Remote Control support or something similar instead. I don't quite understand why this needs a different option from Please don't mark funtion inline unless there's a very good reason for What's the init doing in a cleanup routine? Oh, you initialize it again becaus of the static array. I think the right approach is to I guess success is a #define for 0? Just user 0 directly. Also the kthread_stop here looks odd. The normal way to use kthreads is to start them when bringing up an interface of some sorts, and call kthread_stop when the interface is brought down. Doing it in a routine No sleep on, please. But this one should be trivial to fix anyway, by just changing this to a set_current_state(TASK_INTERRUPTIBLE); schedule(); Please add a kerneldoc comments for exported functions like this, No need for this, a null pointer derference should be a clear enough in which case this 'plugin' should just install it's own fops. Thanks Yikes. All these should never really be null. But once you have a Please move these out of line. And please document all the functions. Please don't do you own spinlock wrappers. --
No driver uses the get_queue callback. So I'm inclined to just remove it. Christoph, any objections? Janne --
Oh, just realized that there are two Christophs in TO an CC, I meant Christoph Bartelmus, the LIRC maintainer, sorry. Janne --
Hi Janne, lirc_gpio is using it. I guess there will be no need to use lirc_gpio in future, but I'd like to keep this in CVS for people who still use it. Christoph --
We don't have lirc_gpio in the kernel tree? And I guess there is no need to integrate into the kernel. I've removed it already. --
I'm pretty sure LIRC will be recognized by its current users, it is I don't know, It doesn't really help though since the struct lirc_plugin removed Thanks for the review. Janne --
But we don't care just for your current users :) Kernel features / I don't think you'll need a wait queue - you can just call Well, the lifetime rules for these structures seems a litte odd. I would except this to work like: struct lirc_plugin statically allocated by the driver, then passed into lirc_register_plugin, which dynamically allocates an irdev. The irdev would point to the plugin, not copy it. And btw, any chance for an s/plugin/driver/g - that's the terminology we use everywhere else in the kernel. --
I'll work on that, as well as some less terse help texts. Done. (will push after doing a quick sanity build-test to make sure I didn't miss anything) -- Jarod Wilson jarod@redhat.com --
I think it's most cool that this code is finally making its way toward kthread_stop() will wake up the process, so there is no need to do it separately here. In fact, it almost looks like the separate wake_up_process() call could create an (unlikely) race where the thread would miss the fact that it's supposed to stop and sleep again. Fixing the sleep_on() call there to use something like wait_event() would help in that So the plugin open() function is called outside of any lock. Note that open() no longer has BKL protection as of 2.6.27. This might all be OK, but I hope you're convinced of it. If "no owner" is a fatal condition, it seems better to check it when the plugin is registered. (Also, BTW, your variant of dprintk() is confusing to read - I was wondering where all the %'s were. I still wonder, Should this be interruptible? You probably want the close call to get its job done. Maybe mutex_lock_killable() - and still do the cleanup on a Why two ioctl() handlers? It seems better to just have one way for plugins to handle this call. Hmm, I note with interest that unlocked_ioctl() remaps -ENOIOCTLCMD to -EINVAL, while regular, locked ioctl() (which this is) does not. Not sure How can ir->attached go to zero? You checked it earlier and have been Do you want to fail completely if class_create() fails? What if somebody All of these inlines probably shouldn't be. jon --
since not all plugins set p.fops? some of those functions in the drivers after a cursory look this is used if the plugin doesn't reimplement or want to overwrite the commands handled in irctl. I'll look if this can plugins fops will be used directly now, no need for this comment and order reversed and using alloc_chrdev_region so there is no device which could be opened. Also returning correct error values now. Thanks for the review. Janne --
Hi Jarod, Couple of questions - what is missing in the current input core to properly support IR devices? How can we enhance it to not need new subsystem to handle such devices? We already have in-kernel support for some of the devices you are adding (ATI remotes, xbox, etc) so the situation is not ideal. Could we try to work it in ininput core and maybe provide LIRC device access through an input handler implementation so that applications do not have to implement 2 types of interfaces? -- Dmitry --
One issue is *sending* IR codes. Another one is access to the raw IR signal (more on this below). Not needed. Applications don't talk to the lirc device directly, they talk to the lircd daemon. The lircd daemon can handle linux input layer devices just fine. So moving drivers from lirc to the input layer can be done transparently to the applications. Quite some time ago, back the days when I maintained video4linux, I've switched the tv card IR drivers from lirc to the input layer. Main reason for that was that having a in-kernel driver using an out-of-tree subsystem was a PITA. I think these days most (all?) TV card drivers use the input layer for the IR remotes frequently shipped with those cards. Some more background, using the Hauppauge cards as example, which usually use rc5 coding with the remotes. The older, bt878 based ones do decoding in hardware (i2c chip). You'll get the decoded rc5 keycode. The newer, cx88 based ones just sample the raw IR signal and give you that. The decoding has to be done in software. The driver can program the sample rate and has to do the biphase decoding in software to get the rc5 keycodes. The driver gets that done just fine, and the remote shipped with the TV card works without problems. The part which doesn't work is supporting *any* remote. The (newer) hardware gives you the raw IR signal, so it is possible to decode any IR signal in software. The missing bit is some way to send the raw IR samples to userspace (i.e. the lircd daemon) for decoding. lirc drivers do just that. HTH, Gerd --
Hi, Just my .02 cents, I personally don't like the lircd daemon (*), I would like to have all input keycodes in input layer. What do you, lirc developers think about making lircd a daemon that injects input events via uinput? (*) the reason I don't like lircd is that not all applications support it. Best regards, --
Hi Maxim, on 12 Sep 08 at 00:28, Maxim Levitsky wrote: I have already agreed to implement this in lircd. The reason why I didn't until now is that there never was any reguest for such a feature from real users of LIRC. This is often suggested by people from an architectural viewpoint, because it's nice to have a unified interface through the input layer. But if you start using LIRC you usually realise quite fast that simple key events are not enough to build a remote controlled home entertainment system for example. But if enough people want this feature, it will be in the next release. Christoph --
Hi Gerd, I see. I guess what I would like to see it first to have "smart" devices that do decoding in hardware to be converted to input subsystem since lirc can use it and other programs can do that too. We should probably start using KEY_NUMERIC_* there to help userspace distinguishing RC keys from normal numeric/keypad keys. For protocols that require decoding in userspace the best solution IMHO is to route them back via uinput so that applications would not need to keep implementing 2 interfaces, one for standard input devices and another for lirc. I am not sure if input devices are the best for transmittign raw IR signal. It is pretty easy to add EV_MSC/IR_RAW event type to the input core... It would give you a timestamp and a 32 bit value... I guess I need to start looking at extending number of event devices in the system. -- Dmitry --
Why does most of this have to be in the kernel? Can a lot of this not be done from userspace? --
Woo-hoo! One Vista-compatible (oh how it's called) remote control was
waiting for this!
All version.h and autoconf.h inclusions aren't needed.
#ifdef MODULE is gross and very old. Don't need that. Just use
static int __init x_init(void)
{
...
}
static void __exit x_exit(void)
{
...
}
module_init(x_init);
module_exit(x_exit);
MODULE_LICENSE
...
It will work correctly in modular and built-in case.
Static number of devices is simple but how about adding them dynamically.
--
Any reason this is a separate subsystem instead of just a bunch new Can you first only send the actually tested drivers? That way review an cleanup can focus on the core and those few and we might get them ready for 2.6.28. Other drivers can than be added when testing and review is done. --
IR device handling is often a bit, shall we say, "special", for a number of devices... Some receivers decode the waveform and give us something sensible the input layer could use (and some IR receivers do work that way), while other receivers pass along raw IR codes, which we require the use of the lirc daemon to decode and convert into something sensible. To complicate the matter further, a number of devices are either output-only devices, or both input and output devices. There's been talk about converting lirc drivers over to using evdev in the long run, but evdev would need a decent amount of extending to be able to I meant to include that the ordering of the patches was more or less from most-used/most-tested to least-used/least-tested, and a few of the patches do include Tested-by: lines in them. Basically, the first four or five drivers probably cover the majority of users, so getting them in first would provide the most bang-for-your-buck. But I can certainly re-send with only the tested drivers after we get through the first round of comments, if that's preferred over my approach of putting the higher-prio ones to the front of the ordering. -- Jarod Wilson jarod@redhat.com --
The soundgraph imon driver is number 8, but it works great for me, and lots of cases include that one (at least silverstone cases). I think more than the first 4 or 5 are in very active use. -- Len Sorensen --
Yeah, I realized imon was much lower in the sort order after my reply there, which was a bad initial move by me, since its actually one of the ones that has definite positive testing feedback already. I believe quite a number of vendors of HTPC cases use imon lcd (or vfd) and ir combo devices. -- Jarod Wilson jarod@redhat.com --
I've been asking this one too. Can someone familiar with the guts of input give an assessment of integrating LIRC in with the rest of input? Don't we want these events handled via evdev so that ordering between IR, mouse, keyboard will be maintained? -- Jon Smirl jonsmirl@gmail.com --
