Re: [PATCH 2/3] ir-core: add imon pad and mce keymaps
On Fri, Apr 16, 2010 at 05:28:35PM -0400, Jarod Wilson wrote:
This adds the keymaps for the hardware decode scancodes imon
devices create for their native imon pad (and mini) remotes,
and the hardware scancodes generated by the imon devices when
used with an rc6 windows media center ed. remote.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/keymaps/Makefile |2 +
drivers/media/IR/keymaps/rc-imon-mce.c | 142 +
drivers/media/IR/keymaps/rc-imon-pad.c | 155
include/media/rc-map.h |2 +
4 files changed, 301 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index c4d891d..ec25258 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-genius-tvgo-a11mce.o \
rc-gotview7135.o \
rc-hauppauge-new.o \
+ rc-imon-mce.o \
+ rc-imon-pad.o \
rc-iodata-bctv7e.o \
rc-kaiomy.o \
rc-kworld-315u.o \
diff --git a/drivers/media/IR/keymaps/rc-imon-mce.c
b/drivers/media/IR/keymaps/rc-imon-mce.c
new file mode 100644
index 000..9c6dda3
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-imon-mce.c
@@ -0,0 +1,142 @@
+/* rc5-imon-mce.c - Keytable for Windows Media Center RC-6 remotes for use
+ * with the SoundGraph iMON/Antec Veris hardware IR decoder
+ *
+ * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+/* mce-mode imon mce remote key table */
+static struct ir_scancode imon_mce[] = {
+ /* keys sorted mostly by frequency of use to optimize lookups */
Won't help at all, entries are inserted in scancode order in the actual
in-kernel keytable to allow for binary scancode searches.
+ { 0x800ff415, KEY_REWIND },
+ { 0x800ff414, KEY_FASTFORWARD },
+ { 0x800ff41b, KEY_PREVIOUS },
+ { 0x800ff41a, KEY_NEXT },
...
diff --git a/drivers/media/IR/keymaps/rc-imon-pad.c
b/drivers/media/IR/keymaps/rc-imon-pad.c
new file mode 100644
index 000..331ba90
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-imon-pad.c
@@ -0,0 +1,155 @@
+/* rc5-imon-pad.c - Keytable for SoundGraph iMON PAD and Antec Veris
+ * RM-200 Remote Control
+ *
+ * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+/*
+ * standard imon remote key table, which isn't really entirely
+ * standard, as different receivers decode the same key on the
+ * same remote to different hex codes, and the silkscreened names
+ * vary a bit between the SoundGraph and Antec remotes... ugh.
+ */
+static struct ir_scancode imon_pad[] = {
+ /* keys sorted mostly by frequency of use to optimize lookups */
Ditto
--
David Härdeman
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] V4L/DVB: input: Add support for EVIO[CS]GKEYCODEBIG
On Thu, Apr 01, 2010 at 02:56:31PM -0300, Mauro Carvalho Chehab wrote:
Several devices use a high number of bits for scancodes. One important
group is the Remote Controllers. Some new protocols like RC-6 define a
scancode space of 64 bits.
The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode
translation tables, but it is limited to up to 32 bits for scancode.
Also, if userspace wants to clean the existing table, replacing it by
a new one, it needs to run a loop calling the old ioctls, over the
entire sparsed scancode userspace.
To solve those problems, this patch introduces two new ioctls:
EVIOCGKEYCODEBIG - reads a scancode from the translation table;
EVIOSGKEYCODEBIG - writes a scancode into the translation table.
...
diff --git a/include/linux/input.h b/include/linux/input.h
index 663208a..6445fc9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -34,7 +34,7 @@ struct input_event {
* Protocol version.
*/
-#define EV_VERSION 0x01
+#define EV_VERSION 0x010001
/*
* IOCTLs (0x00 - 0x7f)
@@ -56,12 +56,22 @@ struct input_absinfo {
__s32 resolution;
};
+struct keycode_table_entry {
+ __u32 keycode; /* e.g. KEY_A */
+ __u32 index;/* Index for the given scan/key table, on
EVIOCGKEYCODEBIG */
+ __u32 len; /* Length of the scancode */
+ __u32 reserved[2]; /* Reserved for future usage */
+ char *scancode; /* scancode, in machine-endian */
+};
Wouldn't changing the scancode member from a pointer to a flexible array
member (C99 feature, which I assume is ok since other C99 features are
already in use in the kernel code) remove the need for any compat32
code?
struct keycode_table_entry {
__u32 keycode;
__u32 index;
__u32 len;
__u32 reserved[2];
char scancode[];
};
--
David Härdeman
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman da...@hardeman.nu wrote: On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: Not that my commit rate has been 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That problem is handled differently in the graphics code. You only have one /dev device for graphics. IOCTLs on it are divided into ranges - core and driver. The IOCTL call initially lands in the core code, but if it is in the driver range it simply gets forwarded to the specific driver and handled there. Doing it that was avoids needing two /dev devices nodes for the same device. Two device nodes has problems. How do you keep them from being open by two different users and different privilege levels, or one is open and one closed, etc... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. Don't forget about binary sysfs attributes. I have scars from implementing sysfs attributes as text that other people thought should have been binary. There has long been talk of implementing sysfs transactions. I think the closest thing that got implemented was to not make the attributes take effect until an action occurs. For example, you would set all of the RX parameters using sysfs. They would be written into shadow variables. Then you write to a 'commit' attribute. The write triggers the copy from the shadow variables to the real ones. Why are the TX variables being set via sysfs? I think the attributes were read only in the code I wrote. Instead I set them via commands in the input stream. Setting via the stream make it easy to change them on each transmit. The input layer already supports transactions wrapping in output. The same transactions could be used to wrap input parameter setting. Start an input transaction, set the TX variables, send the pulse data, end the input transaction. I don't remember if I got around to implementing that. That same chardev could also be used to implement TX, once a suitable interface has been fleshed out. The end result might not look exactly like lirc... -- David Härdeman -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with cx25840 and Terratec Grabster AV400
Hello together!
I'm the owner of a Terratec Grabster AV400, which is supported by the
pvrusb2 (currently standalone version only). Video works well, but I
have a problem with audio, when I use an unmodified v4l-dvb: the audio
is too slow, as if the bitrate is set to low.
The device contains a cx25837-3 (according to dmesg) and audio routing
has to be set to CX25840_AUDIO_SERIAL.
The problem now is, that this audio route setting is never applied,
because there are (at least) two locations in cx25840-core.c where a
check with is_cx2583x is done.
Locally I've simply disabled that checks (see attached patch) and the
AV400 works as expected now. Of course this can't be the correct
solution for the official v4l. Also I have to apply that patch after
every kernel update (which happens rather often with ArchLinux ^^).
Thus I ask how this situation might be solved so that I can use the
AV400 without patching around in the source of v4l.
Attached:
* dmesg output with unpatched cx25840 module
* my quick dirty patch for cx25840-core.c
Regards,
Sven
usb 1-5: new high speed USB device using ehci_hcd and address 9
pvrusb2: Hardware description: Terratec Grabster AV400
cx25840 4-0044: cx25837-3 found @ 0x88 (pvrusb2_a)
pvrusb2: Attached sub-driver cx25840
pvrusb2: Supported video standard(s) reported available in hardware:
PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/
pvrusb2: Mapping standards mask=0xff
(PAL-B/B1/D/D1/G/H/I/K/M/N/Nc/60;NTSC-M/Mj/443/Mk;SECAM-B/D/G/H/K/K1/L/LC)
pvrusb2: Setting up 28 unique standard(s)
pvrusb2: Set up standard idx=0 name=PAL-B/G
pvrusb2: Set up standard idx=1 name=PAL-D/K
pvrusb2: Set up standard idx=2 name=SECAM-B/G
pvrusb2: Set up standard idx=3 name=SECAM-D/K
pvrusb2: Set up standard idx=4 name=NTSC-M
pvrusb2: Set up standard idx=5 name=NTSC-Mj
pvrusb2: Set up standard idx=6 name=NTSC-443
pvrusb2: Set up standard idx=7 name=NTSC-Mk
pvrusb2: Set up standard idx=8 name=PAL-B
pvrusb2: Set up standard idx=9 name=PAL-B1
pvrusb2: Set up standard idx=10 name=PAL-G
pvrusb2: Set up standard idx=11 name=PAL-H
pvrusb2: Set up standard idx=12 name=PAL-I
pvrusb2: Set up standard idx=13 name=PAL-D
pvrusb2: Set up standard idx=14 name=PAL-D1
pvrusb2: Set up standard idx=15 name=PAL-K
pvrusb2: Set up standard idx=16 name=PAL-M
pvrusb2: Set up standard idx=17 name=PAL-N
pvrusb2: Set up standard idx=18 name=PAL-Nc
pvrusb2: Set up standard idx=19 name=PAL-60
pvrusb2: Set up standard idx=20 name=SECAM-B
pvrusb2: Set up standard idx=21 name=SECAM-D
pvrusb2: Set up standard idx=22 name=SECAM-G
pvrusb2: Set up standard idx=23 name=SECAM-H
pvrusb2: Set up standard idx=24 name=SECAM-K
pvrusb2: Set up standard idx=25 name=SECAM-K1
pvrusb2: Set up standard idx=26 name=SECAM-L
pvrusb2: Set up standard idx=27 name=SECAM-LC
pvrusb2: Initial video standard auto-selected to PAL-B/G
pvrusb2: Device initialization completed successfully.
usb 1-5: firmware: requesting v4l-cx2341x-enc.fw
pvrusb2: registered device video0 [mpeg]
cx25840 4-0044: 0x is not a valid video input!
--- v4l-src/linux/drivers/media/video/cx25840/cx25840-core.c2010-04-24
10:48:56.392367351 +0200
+++ v4l-build/linux/drivers/media/video/cx25840/cx25840-core.c 2010-04-24
14:54:08.797561848 +0200
@@ -849,10 +849,10 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
+// if (!is_cx2583x(state)) {
cx25840_audio_set_path(client);
input_change(client);
- }
+// }
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
@@ -1504,8 +1504,8 @@
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (is_cx2583x(state))
- return -EINVAL;
+/* if (is_cx2583x(state))
+ return -EINVAL;*/
return set_input(client, state-vid_input, input);
}
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman da...@hardeman.nu wrote: On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: Not that my commit rate has been 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That problem is handled differently in the graphics code. You only have one /dev device for graphics. IOCTLs on it are divided into ranges - core and driver. The IOCTL call initially lands in the core code, but if it is in the driver range it simply gets forwarded to the specific driver and handled there. Doing it that was avoids needing two /dev devices nodes for the same device. Two device nodes has problems. How do you keep them from being open by two different users and different privilege levels, or one is open and one closed, etc... I'm not sure which two devices you're talking about. ir-core currently creates no device at all (unless you count the input device). And further down the road I think each rc (ir) device should support multiple keytables, each keytable having an associated input device. Input device(s) would be used by the majority of applications that only want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns would apply to that division... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. The input maintainers have already NAK'ed adding any ir-specific ioctls to the input layer, and I tend to agree with them. Don't forget about binary sysfs attributes. I have scars from implementing sysfs attributes as text that other people thought should have been binary. There has long been talk of implementing sysfs transactions. I think the closest thing that got implemented was to not make the attributes take effect until an action occurs. For example, you would set all of the RX parameters using sysfs. They would be written into shadow variables. Then you write to a 'commit' attribute. The write triggers the copy from the shadow variables to the real ones. I still fail to understand why sysfs is preferrable over ioctls. Why are the TX variables being set via sysfs? There's not a single line of TX code yet. I think the attributes were read only in the code I wrote. Instead I set them via commands in the input stream. Setting via the stream make it easy to change them on each transmit. The input layer already supports transactions wrapping in output. The same transactions could be used to wrap input parameter setting. Start an input transaction, set the TX variables, send the pulse data, end the input transaction. I don't remember if I got around to implementing that. Again, the input maintainers have NAK'ed the kind of changes that would be necessary to support TX through the input layer. We're going to have to go with something ir-core specific. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~endriss/ngene
On Wednesday 21 April 2010 04:14:11 Oliver Endriss wrote: On Sunday 21 March 2010 21:15:01 Oliver Endriss wrote: Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene for the following changeset: 01/01: ngene: Workaround for stuck DiSEqC pin http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 stv090x.c |4 1 file changed, 4 insertions(+) Thanks, Oliver Added two more changesets: Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene for the following 3 changesets: 01/03: ngene: Workaround for stuck DiSEqC pin http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 02/03: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe' http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=aa7f03d11744 03/03: ngene: Do not call demuxer with interrupts disabled http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=a5ff8f64d1f7 frontends/stv090x.c |4 ngene/ngene-core.c | 35 +-- 2 files changed, 29 insertions(+), 10 deletions(-) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~endriss/ngene
On Sat, Apr 24, 2010 at 10:29 AM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 04:14:11 Oliver Endriss wrote: On Sunday 21 March 2010 21:15:01 Oliver Endriss wrote: Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene for the following changeset: 01/01: ngene: Workaround for stuck DiSEqC pin http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 stv090x.c | 4 1 file changed, 4 insertions(+) Thanks, Oliver Added two more changesets: Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene for the following 3 changesets: 01/03: ngene: Workaround for stuck DiSEqC pin http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 02/03: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe' http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=aa7f03d11744 03/03: ngene: Do not call demuxer with interrupts disabled http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=a5ff8f64d1f7 frontends/stv090x.c | 4 ngene/ngene-core.c | 35 +-- 2 files changed, 29 insertions(+), 10 deletions(-) CU Oliver Mauro, Where are we at with pulling my other ngene changeset? The whole reason I submitted it so early was to avoid merge conflicts with patches such as this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~endriss/ngene
On Saturday 24 April 2010 16:33:09 Devin Heitmueller wrote: On Sat, Apr 24, 2010 at 10:29 AM, Oliver Endriss o.endr...@gmx.de wrote: On Wednesday 21 April 2010 04:14:11 Oliver Endriss wrote: On Sunday 21 March 2010 21:15:01 Oliver Endriss wrote: Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene for the following changeset: 01/01: ngene: Workaround for stuck DiSEqC pin http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 stv090x.c | 4 1 file changed, 4 insertions(+) Thanks, Oliver Added two more changesets: Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene for the following 3 changesets: 01/03: ngene: Workaround for stuck DiSEqC pin http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 02/03: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe' http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=aa7f03d11744 03/03: ngene: Do not call demuxer with interrupts disabled http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=a5ff8f64d1f7 frontends/stv090x.c | 4 ngene/ngene-core.c | 35 +-- 2 files changed, 29 insertions(+), 10 deletions(-) CU Oliver Mauro, Where are we at with pulling my other ngene changeset? The whole reason I submitted it so early was to avoid merge conflicts with patches such as this. Ok, drop the last two patches. I will resubmit them after Devin's patch set has been applied. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~endriss/ngene
On Sat, Apr 24, 2010 at 10:56 AM, Oliver Endriss o.endr...@gmx.de wrote: Ok, drop the last two patches. I will resubmit them after Devin's patch set has been applied. Oliver Thanks Oliver. I've got over a hundred patches queued up behind this series, so I am obviously pretty concerned about merge conflicts. In fact, Steven may have already taken care of the issue with certain operations occurring during the IRQ handler (I would have to double check to be sure though, he reworked large amounts of that logic). Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 10:15 AM, David Härdeman da...@hardeman.nu wrote: On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman da...@hardeman.nu wrote: On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: Not that my commit rate has been 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That problem is handled differently in the graphics code. You only have one /dev device for graphics. IOCTLs on it are divided into ranges - core and driver. The IOCTL call initially lands in the core code, but if it is in the driver range it simply gets forwarded to the specific driver and handled there. Doing it that was avoids needing two /dev devices nodes for the same device. Two device nodes has problems. How do you keep them from being open by two different users and different privilege levels, or one is open and one closed, etc... I'm not sure which two devices you're talking about. ir-core currently creates no device at all (unless you count the input device). And further down the road I think each rc (ir) device should support multiple keytables, each keytable having an associated input device. Input device(s) would be used by the majority of applications that only want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns would apply to that division... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. The input maintainers have already NAK'ed adding any ir-specific ioctls to the input layer, and I tend to agree with them. Based on my experience with DRM adding a split to the IOCTL range is a good solution. The split does not add IR specific IOCTLs to the input core. The input core just looks at the IOCTL number and if it is out of range it forwards it down the chain - to IR core, which can process it or forward to the specific driver. This model is already in use and it works without problem. want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns These would be implemented by IOCTL forwarding. Don't forget about binary sysfs attributes. I have scars from implementing sysfs attributes as text that other people thought should have been binary. There has long been talk of implementing sysfs transactions. I think the closest thing that got implemented was to not make the attributes take effect until an action occurs. For example, you would set all of the RX parameters using sysfs. They would be written into shadow variables. Then you write to a 'commit' attribute. The write triggers the copy from the shadow variables to the real ones. I still fail to understand why sysfs is preferrable over ioctls. I don't care one way or the other. IOCTLs have portability issues with word size and endianness. sysfs gets rid of those problems. But sysfs doesn't have an explicit transaction mechanism. So both strategies have issues. Why are the TX variables being set via sysfs? There's not a single line of TX code yet. I think the attributes were read only in the code I wrote. Instead I set them via commands in the input stream. Setting via the stream make it easy to change them on each transmit. The input layer already supports transactions wrapping in output. The same transactions could be used to wrap input parameter setting. Start an input transaction, set the TX variables, send the pulse data, end the input transaction. I don't remember if I got around to implementing that. Again, the input maintainers have NAK'ed the kind of changes that would be necessary to support TX through the input layer. We're going to have to go with something ir-core specific. We already have two way devices in the input layer (keyboards with displays). Why create a new mechanism? The same concept of chained extensions can be used to keep the
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Apr 24 19:00:31 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14592:b438301e588f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1f96716187774be265c59a713fb570810e3a15c7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
On 24.04.2010 19:13, Mike Isely wrote: Actually the support in the pvrusb2 driver was never really completed. But since I don't have a sample of the hardware here I went on ahead and merged what was there so that it could get exposure and the remaining problems sorted out. -Mike Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). I wrote the last mail, because I want to sort out why the cx25837 chip in my device is behaving differently than expected by the corresponding driver and to remove the need to patch the v4l sources manually. Once I don't need to fear that the next system update breaks the device again (because cx25840.ko is overwritten), I'm more then willed to help you to complete the support for my device in your driver (feature testing, etc). Regards, Sven PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
On Sat, 24 Apr 2010, Sven Barth wrote: On 24.04.2010 19:13, Mike Isely wrote: Actually the support in the pvrusb2 driver was never really completed. But since I don't have a sample of the hardware here I went on ahead and merged what was there so that it could get exposure and the remaining problems sorted out. -Mike Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. I wrote the last mail, because I want to sort out why the cx25837 chip in my device is behaving differently than expected by the corresponding driver and to remove the need to patch the v4l sources manually. Once I don't need to fear that the next system update breaks the device again (because cx25840.ko is overwritten), I'm more then willed to help you to complete the support for my device in your driver (feature testing, etc). We definitely need to do this. Regards, Sven PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ir-core: add imon pad and mce keymaps
On Sat, Apr 24, 2010 at 4:53 AM, David Härdeman da...@hardeman.nu wrote:
On Fri, Apr 16, 2010 at 05:28:35PM -0400, Jarod Wilson wrote:
This adds the keymaps for the hardware decode scancodes imon
devices create for their native imon pad (and mini) remotes,
and the hardware scancodes generated by the imon devices when
used with an rc6 windows media center ed. remote.
...
+/* mce-mode imon mce remote key table */
+static struct ir_scancode imon_mce[] = {
+ /* keys sorted mostly by frequency of use to optimize lookups */
Won't help at all, entries are inserted in scancode order in the actual
in-kernel keytable to allow for binary scancode searches.
Ah, yeah, that'd be some legacy cruft from when the driver was using
its own internal key table and lookups, making mental note to remove
those comments...
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
Hi! On 24.04.2010 22:24, Mike Isely wrote: On Sat, 24 Apr 2010, Sven Barth wrote: Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I don't want to have this hacking as much as you do. But currently it's the only way that works for me (I'm really glad that it has come that far ^^)... I'll try to help here as good as I can (and time permits) to solve this issue. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. No offense intended, but do you really think that people will read that? Normal users (using Ubuntu, etc) don't really care whether their device is marked as experimental or not... they just want it to work and thus can go to great lengths to disturb the developers working on their driver... PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( I know that problem pretty well. ^^ I was only curious. The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike It would be interesting to know why the v4l devs disabled the audio routing for cx2583x chips and whether it was intended that a cx25837 chip gets the same treatment as a e.g. cx25836. And those implications you're talking about is the reason why I wrote here: I want to check whether there is a better or more correct way than to disable those checks (it works here, because I have only that one device that contains a cx2583x chip...). Just a thought: can it be that my chip's audio routing isn't set to the correct value after initialization and thus it needs to be set at least once, while all other chips default to a working routing after initialization? Could be a design mistake done by Terratec... Regards, Sven -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
On Sat, 24 Apr 2010, Sven Barth wrote: Hi! On 24.04.2010 22:24, Mike Isely wrote: On Sat, 24 Apr 2010, Sven Barth wrote: Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I don't want to have this hacking as much as you do. But currently it's the only way that works for me (I'm really glad that it has come that far ^^)... I'll try to help here as good as I can (and time permits) to solve this issue. I understand. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. No offense intended, but do you really think that people will read that? Normal users (using Ubuntu, etc) don't really care whether their device is marked as experimental or not... they just want it to work and thus can go to great lengths to disturb the developers working on their driver... No offense taken. Not a problem. But I felt it was at least important enough for the driver to document this fact. For those who use the device who are capable of attempting some hacking - those people WILL see the message and hopefully that will encourage such folks to contact the author (me) for assistance in further stabilizing the device. The intent wasn't for the flag to be any excuse not to work on it - I just want to leave a marker indicating that the driver is not expected to be fully working (or supported) at this time. PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( I know that problem pretty well. ^^ I was only curious. Spending a lot of time today catching up on stuff like this. Just smoked out two kernel oopses in the driver today as well. The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike It would be interesting to know why the v4l devs disabled the audio routing for cx2583x chips and whether it was intended that a cx25837 chip gets the same treatment as a e.g. cx25836. I wish I could provide specific information about that :-( And those implications you're talking about is the reason why I wrote here: I want to check whether there is a better or more correct way than to disable those checks (it works here, because I have only that one device that contains a cx2583x chip...). Just a thought: can it be that my chip's audio routing isn't set to the correct value after initialization and thus it needs to be set at least once, while all other chips default to a working routing after initialization? Could be a design mistake done by Terratec... There is no one correct audio routing. And by audio routing I mean the wiring between the chip and the various audio inputs that feed it. The choice for how to route all this is up to the vendor of the device. In many cases there is a common reference design that the vendor starts from, in which case such routing will be more common across devices. But that's just luck really. The cx25840 driver provides an API to things like the pvrusb2 driver to select the proper routing based on that bridge driver's knowledge of the surrounding hardware. This is one of the areas that have to be worked on when porting to a new device. The PVR2_ROUTING_SCHEME_ enumeration in the pvrusb2 driver is part of this. With that all said I haven't looked closely enough at your patch to the cx25840 module so I'm only assuming that we're talking about the same thing here. I have a funny feeling that you're hitting on something else however. I need to look at this more
cx88-input questions
I've been looking at converting drivers/media/video/cx88/cx88-input.c to use the ir-core subsystem, and I have a few questions. As far as I understand the code, the sampling case will sample at a 4Khz interval and generate one bit for each sample to represent a pulse or space (i.e. a 250us resolution). This is done by writing a magic value in __cx88_ir_start: cx_write(MO_DDS_IO, 0xa80a80); 250us is a quite low resolution, is it possible to get the hardware to generate samples at a higher rate (say, 20Khz for a 50us resolution)? Also, how does the polling mode work in the hardware? Is a complete scancode (or as complete as the hardware can handle at least) returned from the gpio read after a keypress? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ir-core sysfs protocol selection simplification
The following series changes the sysfs implementation in ir-core to make the protocol selection work in the same manner for hardware decoders and software decoders (the distinction between the two should be hidden from the user as much as possible IMHO). This also allows for a nice reduction of duplicated code between the raw ir protocol decoders. The first patch is merely preparatory and should hopefully not be controversial. The second and third patch should be considered RFC's on the implementation of the sysfs interface. The last patch is orthogonal to the rest of the patchset and should hopefully not be controversial (though it would be nice if someone with the actual hardware could test it). --- David Härdeman (4): ir-core: remove IR_TYPE_PD ir-core: centralize sysfs raw decoder enabling/disabling ir-core: move decoding state to ir_raw_event_ctrl ir-core: remove ir-functions usage from cx231xx drivers/media/IR/ir-core-priv.h | 40 drivers/media/IR/ir-jvc-decoder.c | 152 +--- drivers/media/IR/ir-nec-decoder.c | 151 +--- drivers/media/IR/ir-raw-event.c | 136 ++ drivers/media/IR/ir-rc5-decoder.c | 165 ++--- drivers/media/IR/ir-rc6-decoder.c | 154 +--- drivers/media/IR/ir-sony-decoder.c | 155 +--- drivers/media/IR/ir-sysfs.c | 262 +++ drivers/media/video/cx231xx/cx231xx-input.c | 47 + drivers/media/video/cx231xx/cx231xx.h |2 drivers/media/video/cx88/cx88-input.c |8 - include/media/ir-kbd-i2c.h |2 include/media/rc-map.h |9 - 13 files changed, 322 insertions(+), 961 deletions(-) -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ir-core: remove IR_TYPE_PD
Pulse-distance is not a protocol, it is a line coding (used by some protocols,
like NEC). Looking at the uses of IR_TYPE_PD, the real protocol seems to be
NEC in all cases (drivers/media/video/cx88/cx88-input.c is the only user).
So, remove IR_TYPE_PD while it is still easy to do so.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/ir-sysfs.c |6 --
drivers/media/video/cx88/cx88-input.c |8
include/media/ir-kbd-i2c.h|2 +-
include/media/rc-map.h|9 -
4 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 501dc2f..facca11 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -56,8 +56,6 @@ static ssize_t show_protocol(struct device *d,
s = Unknown;
else if (ir_type == IR_TYPE_RC5)
s = rc-5;
- else if (ir_type == IR_TYPE_PD)
- s = pulse-distance;
else if (ir_type == IR_TYPE_NEC)
s = nec;
else if (ir_type == IR_TYPE_RC6)
@@ -99,8 +97,6 @@ static ssize_t store_protocol(struct device *d,
while ((buf = strsep((char **) data, \n)) != NULL) {
if (!strcasecmp(buf, rc-5) || !strcasecmp(buf, rc5))
ir_type |= IR_TYPE_RC5;
- if (!strcasecmp(buf, pd) || !strcasecmp(buf,
pulse-distance))
- ir_type |= IR_TYPE_PD;
if (!strcasecmp(buf, nec))
ir_type |= IR_TYPE_NEC;
if (!strcasecmp(buf, jvc))
@@ -145,8 +141,6 @@ static ssize_t show_supported_protocols(struct device *d,
buf += sprintf(buf, unknown );
if (ir_dev-props-allowed_protos IR_TYPE_RC5)
buf += sprintf(buf, rc-5 );
- if (ir_dev-props-allowed_protos IR_TYPE_PD)
- buf += sprintf(buf, pulse-distance );
if (ir_dev-props-allowed_protos IR_TYPE_NEC)
buf += sprintf(buf, nec );
if (buf == orgbuf)
diff --git a/drivers/media/video/cx88/cx88-input.c
b/drivers/media/video/cx88/cx88-input.c
index 5e60b48..0de9bdf 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -271,7 +271,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev
*pci)
break;
case CX88_BOARD_TERRATEC_CINERGY_1400_DVB_T1:
ir_codes = RC_MAP_CINERGY_1400;
- ir_type = IR_TYPE_PD;
+ ir_type = IR_TYPE_NEC;
ir-sampling = 0xeb04; /* address */
break;
case CX88_BOARD_HAUPPAUGE:
@@ -374,18 +374,18 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev
*pci)
case CX88_BOARD_PROF_7301:
case CX88_BOARD_PROF_6200:
ir_codes = RC_MAP_TBS_NEC;
- ir_type = IR_TYPE_PD;
+ ir_type = IR_TYPE_NEC;
ir-sampling = 0xff00; /* address */
break;
case CX88_BOARD_TEVII_S460:
case CX88_BOARD_TEVII_S420:
ir_codes = RC_MAP_TEVII_NEC;
- ir_type = IR_TYPE_PD;
+ ir_type = IR_TYPE_NEC;
ir-sampling = 0xff00; /* address */
break;
case CX88_BOARD_DNTV_LIVE_DVB_T_PRO:
ir_codes = RC_MAP_DNTV_LIVE_DVBT_PRO;
- ir_type = IR_TYPE_PD;
+ ir_type = IR_TYPE_NEC;
ir-sampling = 0xff00; /* address */
break;
case CX88_BOARD_NORWOOD_MICRO:
diff --git a/include/media/ir-kbd-i2c.h b/include/media/ir-kbd-i2c.h
index 057ff64..0506e45 100644
--- a/include/media/ir-kbd-i2c.h
+++ b/include/media/ir-kbd-i2c.h
@@ -36,7 +36,7 @@ enum ir_kbd_get_key_fn {
struct IR_i2c_init_data {
char*ir_codes;
const char *name;
- u64 type; /* IR_TYPE_RC5, IR_TYPE_PD, etc */
+ u64 type; /* IR_TYPE_RC5, etc */
/*
* Specify either a function pointer or a value indicating one of
* ir_kbd_i2c's internal get_key functions
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 67af24e..ba53fe2 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -13,11 +13,10 @@
#define IR_TYPE_UNKNOWN0
#define IR_TYPE_RC5(1 0) /* Philips RC5 protocol */
-#define IR_TYPE_PD (1 1) /* Pulse distance encoded IR */
-#define IR_TYPE_NEC(1 2)
-#define IR_TYPE_RC6(1 3) /* Philips RC6 protocol */
-#define IR_TYPE_JVC(1 4) /* JVC protocol */
-#define IR_TYPE_SONY (1 5) /* Sony12/15/20 protocol */
+#define IR_TYPE_NEC(1 1)
+#define IR_TYPE_RC6(1 2) /* Philips RC6 protocol */
+#define IR_TYPE_JVC(1 3) /* JVC protocol */
+#define IR_TYPE_SONY (1 4) /* Sony12/15/20 protocol */
#define IR_TYPE_OTHER (1u 31)
[PATCH 2/4] ir-core: centralize sysfs raw decoder enabling/disabling
With the current logic, each raw decoder needs to add a copy of the exact
same sysfs code. This is both unnecessary and also means that (re)loading
an IR driver after raw decoder modules have been loaded won't work as
expected.
This patch moves that logic into ir-raw-event and adds a single sysfs
file per device.
Reading that file returns something like:
rc5 [rc6] nec jvc [sony]
(with enabled protocols in [] brackets)
Writing either +protocol or -protocol to that file will
enable or disable the according protocol decoder.
An additional benefit is that the disabling of a decoder will be
remembered across module removal/insertion so a previously
disabled decoder won't suddenly be activated again. The default
setting is to enable all decoders.
This is also necessary for the next patch which moves even more decoder
state into the central raw decoding structs.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/ir-core-priv.h|3
drivers/media/IR/ir-jvc-decoder.c | 64 -
drivers/media/IR/ir-nec-decoder.c | 64 -
drivers/media/IR/ir-raw-event.c| 112 +---
drivers/media/IR/ir-rc5-decoder.c | 64 -
drivers/media/IR/ir-rc6-decoder.c | 64 -
drivers/media/IR/ir-sony-decoder.c | 64 -
drivers/media/IR/ir-sysfs.c| 252 +---
8 files changed, 231 insertions(+), 456 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 04962a6..821d012 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -21,6 +21,7 @@
struct ir_raw_handler {
struct list_head list;
+ u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
int (*raw_register)(struct input_dev *input_dev);
int (*raw_unregister)(struct input_dev *input_dev);
@@ -32,6 +33,7 @@ struct ir_raw_event_ctrl {
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
+ u64 enabled_protocols; /* enabled raw
protocol decoders */
};
/* macros for IR decoders */
@@ -76,6 +78,7 @@ void ir_unregister_class(struct input_dev *input_dev);
/*
* Routines from ir-raw-event.c to be used internally and by decoders
*/
+u64 ir_raw_get_allowed_protocols(void);
int ir_raw_event_register(struct input_dev *input_dev);
void ir_raw_event_unregister(struct input_dev *input_dev);
int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 0b80494..1055de4 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -41,7 +41,6 @@ enum jvc_state {
struct decoder_data {
struct list_headlist;
struct ir_input_dev *ir_dev;
- int enabled:1;
/* State machine control */
enum jvc_state state;
@@ -72,53 +71,6 @@ static struct decoder_data *get_decoder_data(struct
ir_input_dev *ir_dev)
return data;
}
-static ssize_t store_enabled(struct device *d,
-struct device_attribute *mattr,
-const char *buf,
-size_t len)
-{
- unsigned long value;
- struct ir_input_dev *ir_dev = dev_get_drvdata(d);
- struct decoder_data *data = get_decoder_data(ir_dev);
-
- if (!data)
- return -EINVAL;
-
- if (strict_strtoul(buf, 10, value) || value 1)
- return -EINVAL;
-
- data-enabled = value;
-
- return len;
-}
-
-static ssize_t show_enabled(struct device *d,
-struct device_attribute *mattr, char *buf)
-{
- struct ir_input_dev *ir_dev = dev_get_drvdata(d);
- struct decoder_data *data = get_decoder_data(ir_dev);
-
- if (!data)
- return -EINVAL;
-
- if (data-enabled)
- return sprintf(buf, 1\n);
- else
- return sprintf(buf, 0\n);
-}
-
-static DEVICE_ATTR(enabled, S_IRUGO | S_IWUSR, show_enabled, store_enabled);
-
-static struct attribute *decoder_attributes[] = {
- dev_attr_enabled.attr,
- NULL
-};
-
-static struct attribute_group decoder_attribute_group = {
- .name = jvc_decoder,
- .attrs = decoder_attributes,
-};
-
/**
* ir_jvc_decode() - Decode one JVC pulse or space
* @input_dev: the struct input_dev descriptor of the device
@@ -135,7 +87,7 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
if (!data)
return -EINVAL;
- if (!data-enabled)
+ if (!(ir_dev-raw-enabled_protocols IR_TYPE_JVC))
[PATCH 3/4] ir-core: move decoding state to ir_raw_event_ctrl
This patch moves the state from each raw decoder into the
ir_raw_event_ctrl struct.
This allows the removal of code like this:
spin_lock(decoder_lock);
list_for_each_entry(data, decoder_list, list) {
if (data-ir_dev == ir_dev)
break;
}
spin_unlock(decoder_lock);
return data;
which is currently run for each decoder on each event in order
to get the client-specific decoding state data.
In addition, ir decoding modules and ir driver module load
order is now independent. Centralizing the data also allows
for a nice code reduction of about 30% per raw decoder as
client lists and client registration callbacks are no longer
necessary.
Out-of-tree modules can still use a similar trick to what
the raw decoders did before this patch until they are merged.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/ir-core-priv.h| 37 -
drivers/media/IR/ir-jvc-decoder.c | 90 ++-
drivers/media/IR/ir-nec-decoder.c | 89 +++
drivers/media/IR/ir-raw-event.c| 48 +++--
drivers/media/IR/ir-rc5-decoder.c | 103 +---
drivers/media/IR/ir-rc6-decoder.c | 92 ++--
drivers/media/IR/ir-sony-decoder.c | 93 +++--
7 files changed, 87 insertions(+), 465 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 821d012..1e9464a 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -23,8 +23,6 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
- int (*raw_register)(struct input_dev *input_dev);
- int (*raw_unregister)(struct input_dev *input_dev);
};
struct ir_raw_event_ctrl {
@@ -34,6 +32,41 @@ struct ir_raw_event_ctrl {
enum raw_event_type last_type; /* last event type */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
+
+ /* raw decoder state follows */
+ struct ir_raw_event prev_ev;
+ struct nec_dec {
+ int state;
+ unsigned count;
+ u32 bits;
+ } nec;
+ struct rc5_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc5;
+ struct rc6_dec {
+ int state;
+ u8 header;
+ u32 body;
+ bool toggle;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc6;
+ struct sony_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ } sony;
+ struct jvc_dec {
+ int state;
+ u16 bits;
+ u16 old_bits;
+ unsigned count;
+ bool first;
+ bool toggle;
+ } jvc;
};
/* macros for IR decoders */
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 1055de4..8894d8b 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -25,10 +25,6 @@
#define JVC_TRAILER_PULSE (1 * JVC_UNIT)
#defineJVC_TRAILER_SPACE (35 * JVC_UNIT)
-/* Used to register jvc_decoder clients */
-static LIST_HEAD(decoder_list);
-DEFINE_SPINLOCK(decoder_lock);
-
enum jvc_state {
STATE_INACTIVE,
STATE_HEADER_SPACE,
@@ -38,39 +34,6 @@ enum jvc_state {
STATE_TRAILER_SPACE,
};
-struct decoder_data {
- struct list_headlist;
- struct ir_input_dev *ir_dev;
-
- /* State machine control */
- enum jvc_state state;
- u16 jvc_bits;
- u16 jvc_old_bits;
- unsignedcount;
- boolfirst;
- booltoggle;
-};
-
-
-/**
- * get_decoder_data() - gets decoder data
- * @input_dev: input device
- *
- * Returns the struct decoder_data that corresponds to a device
- */
-static struct decoder_data *get_decoder_data(struct ir_input_dev *ir_dev)
-{
- struct decoder_data *data = NULL;
-
- spin_lock(decoder_lock);
- list_for_each_entry(data, decoder_list, list) {
- if (data-ir_dev == ir_dev)
- break;
- }
- spin_unlock(decoder_lock);
- return data;
-}
-
/**
* ir_jvc_decode() - Decode one JVC pulse or space
* @input_dev: the struct input_dev descriptor of the device
@@ -80,12 +43,8 @@ static struct decoder_data *get_decoder_data(struct
ir_input_dev *ir_dev)
*/
static int ir_jvc_decode(struct input_dev *input_dev,
[PATCH 4/4] ir-core: remove ir-functions usage from cx231xx
Convert drivers/media/video/cx231xx/cx231xx-input.c to not
rely on ir-functions.c.
(I do not have the hardware so I can only compile test this)
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/video/cx231xx/cx231xx-input.c | 47 +--
drivers/media/video/cx231xx/cx231xx.h |2 +
2 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c
b/drivers/media/video/cx231xx/cx231xx-input.c
index dbd6218..a3d6593 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -60,7 +60,6 @@ struct cx231xx_ir_poll_result {
struct cx231xx_IR {
struct cx231xx *dev;
struct input_dev *input;
- struct ir_input_state ir;
char name[32];
char phys[32];
@@ -68,9 +67,7 @@ struct cx231xx_IR {
int polling;
struct work_struct work;
struct timer_list timer;
- unsigned int last_toggle:1;
unsigned int last_readcount;
- unsigned int repeat_interval;
int (*get_key) (struct cx231xx_IR *, struct cx231xx_ir_poll_result *);
};
@@ -82,7 +79,6 @@ struct cx231xx_IR {
static void cx231xx_ir_handle_key(struct cx231xx_IR *ir)
{
int result;
- int do_sendkey = 0;
struct cx231xx_ir_poll_result poll_result;
/* read the registers containing the IR status */
@@ -96,44 +92,23 @@ static void cx231xx_ir_handle_key(struct cx231xx_IR *ir)
poll_result.toggle_bit, poll_result.read_count,
ir-last_readcount, poll_result.rc_data[0]);
- if (ir-dev-chip_id == CHIP_ID_EM2874) {
+ if (poll_result.read_count 0
+ poll_result.read_count != ir-last_readcount)
+ ir_keydown(ir-input,
+ poll_result.rc_data[0],
+ poll_result.toggle_bit);
+
+ if (ir-dev-chip_id == CHIP_ID_EM2874)
/* The em2874 clears the readcount field every time the
register is read. The em2860/2880 datasheet says that it
is supposed to clear the readcount, but it doesn't. So with
the em2874, we are looking for a non-zero read count as
opposed to a readcount that is incrementing */
ir-last_readcount = 0;
- }
-
- if (poll_result.read_count == 0) {
- /* The button has not been pressed since the last read */
- } else if (ir-last_toggle != poll_result.toggle_bit) {
- /* A button has been pressed */
- dprintk(button has been pressed\n);
- ir-last_toggle = poll_result.toggle_bit;
- ir-repeat_interval = 0;
- do_sendkey = 1;
- } else if (poll_result.toggle_bit == ir-last_toggle
- poll_result.read_count 0
- poll_result.read_count != ir-last_readcount) {
- /* The button is still being held down */
- dprintk(button being held down\n);
-
- /* Debouncer for first keypress */
- if (ir-repeat_interval++ 9) {
- /* Start repeating after 1 second */
- do_sendkey = 1;
- }
- }
+ else
+ ir-last_readcount = poll_result.read_count;
- if (do_sendkey) {
- dprintk(sending keypress\n);
- ir_input_keydown(ir-input, ir-ir, poll_result.rc_data[0]);
- ir_input_nokey(ir-input, ir-ir);
}
-
- ir-last_readcount = poll_result.read_count;
- return;
}
static void ir_timer(unsigned long data)
@@ -199,10 +174,6 @@ int cx231xx_ir_init(struct cx231xx *dev)
usb_make_path(dev-udev, ir-phys, sizeof(ir-phys));
strlcat(ir-phys, /input0, sizeof(ir-phys));
- err = ir_input_init(input_dev, ir-ir, IR_TYPE_OTHER);
- if (err 0)
- goto err_out_free;
-
input_dev-name = ir-name;
input_dev-phys = ir-phys;
input_dev-id.bustype = BUS_USB;
diff --git a/drivers/media/video/cx231xx/cx231xx.h
b/drivers/media/video/cx231xx/cx231xx.h
index 17d4d1a..38d4171 100644
--- a/drivers/media/video/cx231xx/cx231xx.h
+++ b/drivers/media/video/cx231xx/cx231xx.h
@@ -32,7 +32,7 @@
#include media/videobuf-vmalloc.h
#include media/v4l2-device.h
-#include media/ir-kbd-i2c.h
+#include media/ir-core.h
#if defined(CONFIG_VIDEO_CX231XX_DVB) || \
defined(CONFIG_VIDEO_CX231XX_DVB_MODULE)
#include media/videobuf-dvb.h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 11:07:07AM -0400, Jon Smirl wrote: On Sat, Apr 24, 2010 at 10:15 AM, David Härdeman da...@hardeman.nu wrote: On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman da...@hardeman.nu wrote: I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That problem is handled differently in the graphics code. You only have one /dev device for graphics. IOCTLs on it are divided into ranges - core and driver. The IOCTL call initially lands in the core code, but if it is in the driver range it simply gets forwarded to the specific driver and handled there. Doing it that was avoids needing two /dev devices nodes for the same device. Two device nodes has problems. How do you keep them from being open by two different users and different privilege levels, or one is open and one closed, etc... I'm not sure which two devices you're talking about. ir-core currently creates no device at all (unless you count the input device). And further down the road I think each rc (ir) device should support multiple keytables, each keytable having an associated input device. Input device(s) would be used by the majority of applications that only want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns would apply to that division... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. The input maintainers have already NAK'ed adding any ir-specific ioctls to the input layer, and I tend to agree with them. Based on my experience with DRM adding a split to the IOCTL range is a good solution. The split does not add IR specific IOCTLs to the input core. The input core just looks at the IOCTL number and if it is out of range it forwards it down the chain - to IR core, which can process it or forward to the specific driver. This model is already in use and it works without problem. I don't care either way. Get the input maintainers to agree and I'll happily write patches that follow that approach (writing TX data to the input dev will also have to be supported). The only real problem I see is if we implement 1 input device per rc/ir device (which I think we should do - each logical remote should have a separate keytable and input device). -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 5:23 PM, David Härdeman da...@hardeman.nu wrote: I don't care either way. Get the input maintainers to agree and I'll happily write patches that follow that approach (writing TX data to the input dev will also have to be supported). The only real problem I see is if we implement 1 input device per rc/ir device (which I think we should do - each logical remote should have a separate keytable and input device). I forgot about the many to 1 aspect of the receiver. You should have started off with this point and I would have shut up, DRM does not have many to 1 mappings. My radio receivers show up as network devices. So I have multiple devices too. I don't think we want a 'rc' device. The IR transceiver should be an 'ir' device. My radios are already 'net' devices. So my complaint really is, I don't want an three devices - input, rc and net. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with cx25840 and Terratec Grabster AV400
On Sat, 2010-04-24 at 22:54 +0200, Sven Barth wrote:
It would be interesting to know why the v4l devs disabled the audio
routing for cx2583x chips and whether it was intended that a cx25837
chip gets the same treatment as a e.g. cx25836.
And those implications you're talking about is the reason why I wrote
here: I want to check whether there is a better or more correct way than
to disable those checks (it works here, because I have only that one
device that contains a cx2583x chip...).
The CX25836 and CX25837 do not have any audio functions. They are video
only chips.
The only difference between the chips is that the CX25837 comes in two
different packages and has a version that is pin compatible with the
CX2584[0123] chips.
The public data sheet is here:
http://www.conexant.com/products/entry.jsp?id=77
Note that the CX2583x chip do have an AUX_PLL which can be output from
the chip as an audio clock.
Just a thought: can it be that my chip's audio routing isn't set to the
correct value after initialization and thus it needs to be set at least
once, while all other chips default to a working routing after
initialization? Could be a design mistake done by Terratec...
No chip defaults are what they are, most people don't design a board to
match up with them.
I does look like Terratec saved themselves an external oscillator by
using the AUX_PLL in the CX2583x as an audio clock.
As for your changes. They are wrong, but in a benign way I think.
There is no real penalty for writing to the Merlin audio core
registers that don't exist in this chip (0x800-0x9ff), as long as the
chip is decoding all the address bits properly and not wrapping them
back down to the Thresher video core registers at 0x000-0x1ff.
As for your first change:
@@ -849,10 +849,10 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
+// if (!is_cx2583x(state)) {
cx25840_audio_set_path(client);
input_change(client);
- }
+// }
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
This is incomplete. Along with removing the check, you need to push
down the is_cx2583x() check into input_change() and
cx25840_audio_set_path(). What you likely also need to do for a CX2583x
is:
a. Modify input_change() to add is_cx2583x() checks to avoid the
operations on registers in the 0x800-0x9ff range, but still let the
operations to registers in the 0x400-0x4ff range be performed. These
are Chroma processing settings that may have some effect on your video.
b. Modify cx25840_audio_set_path() to add is_cx2583x() checks to avoid
the operations on registers in the 0x800-0x9ff range, but still let the
call to set_audclk_freq() go through. From there
cx25836_set_audclk_freq() and cx25840_set_audclk_freq() will set up the
PLLs while avoiding writes to registers in the 0x800-0x9ff range for the
CX2583x chips.
Let's look at your second change:
@@ -1504,8 +1504,8 @@
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (is_cx2583x(state))
- return -EINVAL;
+/* if (is_cx2583x(state))
+ return -EINVAL;*/
return set_input(client, state-vid_input, input);
}
If you made the proper changes to
set_input()
cx25840_audio_set_path()
set_audclk_freq()
cx25836_set_audclk_freq()
cx25840_set_audclk_freq()
input_change()
then you have already pushed this check down to several places and
allowed AUX_PLL reconfiguration to take place. Thus it is then correct
to remove the check from here.
Well, that's my guess anyway. Did it all make sense?
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
