Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
If all three of you agree on this approch, I'll write a patch to convert
ir-core to use it instead.
--
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
[GIT PULL for 2.6.35] vivi cleanup and bug fixes
The following changes since commit 8b680a770f6bdcd52f6816d7a5fe7aee9a9f7c78: Mauro Carvalho Chehab (1): V4L/DVB: ir Kconfig: better describe the options are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git vivi Hans Verkuil (1): vivi: clean up and a major overhaul drivers/media/video/Kconfig |1 + drivers/media/video/font.h | 407 -- drivers/media/video/vivi.c | 809 +-- 3 files changed, 325 insertions(+), 892 deletions(-) delete mode 100644 drivers/media/video/font.h -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Sat, 2010-04-10 at 08:48 +0200, David Härdeman wrote:
On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
If all three of you agree on this approch, I'll write a patch to convert
ir-core to use it instead.
I'm OK with it.
I haven't been paying close attention,so I must ask: What will the units
of duration be?
a. If we use nanoseconds the max duration is 2.147 seconds.
If passing pulse measurments out to LIRC, there are cases where irrecord
and lircd want the duration of the long silence between the
transmissions from the remote. Do any remotes have silence periods
longer than 2.1 seconds?
b. If we use microseconds, the max duration is 214.7 seconds or 3.6
minutes. That's too high to be useful.
c. Something in between, like 1/8 (or 1/2, 1/4, or 1/10) of a
microsecond? 1/8 gives a max duration of 26.8 seconds and a little
extra precision.
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
Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
Andy Walls wrote:
On Sat, 2010-04-10 at 08:48 +0200, David Härdeman wrote:
On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
If all three of you agree on this approch, I'll write a patch to convert
ir-core to use it instead.
I'm OK with it.
I haven't been paying close attention,so I must ask: What will the units
of duration be?
a. If we use nanoseconds the max duration is 2.147 seconds.
If passing pulse measurments out to LIRC, there are cases where irrecord
and lircd want the duration of the long silence between the
transmissions from the remote. Do any remotes have silence periods
longer than 2.1 seconds?
b. If we use microseconds, the max duration is 214.7 seconds or 3.6
minutes. That's too high to be useful.
c. Something in between, like 1/8 (or 1/2, 1/4, or 1/10) of a
microsecond? 1/8 gives a max duration of 26.8 seconds and a little
extra precision.
(c) is really ugly.
(b) max limit is too high. Currently, the core assumes that everything longer
than one second is enough to re-start the state machine. So, I think (a)
is the better option.
Another way to see it: it is not reasonable for someone to press a key and wait
for 2.1 seconds to see one bit of the key to be recognized.
So, IMHO, let's just use nanoseconds with 31 bits. the sampling event function
should check for ktime value: if bigger than 2^32-1, then assume it is a
long event, resetting the state machine.
Cheers,
Mauro
--
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: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Sat, Apr 10, 2010 at 2:48 AM, David Härdeman da...@hardeman.nu wrote:
On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it is
clearly indicated what's mark and what's duration.
If all three of you agree on this approach, I'll write a patch to convert
ir-core to use it instead.
Fine with me.
--
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
Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations
On Sat, 2010-04-10 at 09:10 -0300, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Sat, 2010-04-10 at 08:48 +0200, David Härdeman wrote:
On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
struct {
unsigned mark : 1;
unsigned duration :31;
}
There's no memory spend at all: it will use just one unsigned int and it
is
clearly indicated what's mark and what's duration.
If all three of you agree on this approch, I'll write a patch to convert
ir-core to use it instead.
I'm OK with it.
I haven't been paying close attention,so I must ask: What will the units
of duration be?
a. If we use nanoseconds the max duration is 2.147 seconds.
If passing pulse measurments out to LIRC, there are cases where irrecord
and lircd want the duration of the long silence between the
transmissions from the remote. Do any remotes have silence periods
longer than 2.1 seconds?
b. If we use microseconds, the max duration is 214.7 seconds or 3.6
minutes. That's too high to be useful.
c. Something in between, like 1/8 (or 1/2, 1/4, or 1/10) of a
microsecond? 1/8 gives a max duration of 26.8 seconds and a little
extra precision.
(c) is really ugly.
(b) max limit is too high. Currently, the core assumes that everything longer
than one second is enough to re-start the state machine. So, I think (a)
is the better option.
Another way to see it: it is not reasonable for someone to press a key and
wait
for 2.1 seconds to see one bit of the key to be recognized.
True enough.
So, IMHO, let's just use nanoseconds with 31 bits. the sampling event function
should check for ktime value: if bigger than 2^32-1, then assume it is a
long event, resetting the state machine.
Sounds OK to me. Thanks for the reply.
Regards,
Andy
Cheers,
Mauro
--
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] DVB-T initial scan file for Israel (dvb-utils)
On Sat, Apr 10, 2010 at 3:02 AM, hermann pitton hermann-pit...@arcor.de wrote: Hi Shaul, Am Samstag, den 10.04.2010, 02:16 +0300 schrieb Shaul Kremer: Hi, Here is an initial scan file for IBA's DVB-T transmitters. Generated from info at http://www.iba.org.il/reception/ (Hebrew) # HG changeset patch # User Shaul Kremer shau...@gmail.com # Date 1270854557 -10800 # Node ID ac84f6db6f031db82509c247ac1775ca48b0e2f3 # Parent 7de0663facd92bbb9049aeeda3dcba9601228f30 Added DVB-T initial tuning tables for Israel. diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN1 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN1 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-1 transmitter (northern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN2 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN2 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-2 transmitter (central Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN3 --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-SFN3 Sat Apr 10 02:09:17 2010 +0300 @@ -0,0 +1,4 @@ +# Israel, Israel Broadcasting Authority's SFN-3 transmitter (southern Israel) +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE why you don't put them into one scan file for now? scan for sure does not know about any difference between northern and southern Israel from the above and to scan the central transponder too in one run might cost in worst case a few seconds. Cheers, Hermann Sounds good. Here: # HG changeset patch # User Shaul Kremer shau...@gmail.com # Date 1270911802 -10800 # Node ID 9c2dabea9d1b63a75593b920d41159e7ba607747 # Parent 7de0663facd92bbb9049aeeda3dcba9601228f30 Added DVB-T initial tuning tables for Israel. diff -r 7de0663facd9 -r 9c2dabea9d1b util/scan/dvb-t/il-All --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/il-AllSat Apr 10 18:03:22 2010 +0300 @@ -0,0 +1,5 @@ +# Israel, Israel Broadcasting Authority's transmitters +# Generated from list in http://www.iba.org.il/reception/ +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE -- 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 08/26] V4L/DVB: Break Remote Controller keymaps into modules
Andy Walls wrote: On Tue, 2010-04-06 at 15:18 -0300, Mauro Carvalho Chehab wrote: The original Remote Controller approach were very messy: a big file, that were part of ir-common kernel module, containing 64 different RC keymap tables, used by the V4L/DVB drivers. Better to break each RC keymap table into a separate module, registering them into rc core on a process similar to the fs/nls tables. As an userspace program is now in charge of loading those tables, adds an option to allow the complete removal of those tables from kernelspace. Yet, on embedded devices like Set Top Boxes and TV sets, maybe the only available input device is the IR. So, we should keep allowing the usage of in-kernel tables, but a latter patch should change the default to 'n', after giving some time for distros to add the v4l-utils with the ir-keytable program, to allow the table load via userspace. I know I'm probably late on commenting on this. Although this is interesting, it seems like overkill. 1. How will this help move us to the just works case, if now userspace has to help the kernel. Every distro is likely just going to bundle a script which loads them all into the kernel and forgets about them. No. They will either use userspace or kernelspace keymaps. For in-kernel keymaps, there's nothing needed on userspace. 2. How is a driver, which knows the bundled remote, supposed to convey to userspace load this map by default for my IR receiver? Is that covered in another portion of the patch? It is on a separate patch. Basically, by the name. The table name is stored on each IR map entry on kernel. If the table is in kernel, the table will be dynamically loaded, when needed. Userspace can always replace it by another one. For example, this is my current test setup: $ ./ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event8) with: Driver saa7134, raw software decoder, table rc-avermedia-m135a-rm-jx Supported protocols: NEC RC-5 RC-6 Found /sys/class/rc/rc1/ (/dev/input/event9) with: Driver cx88xx, hardware decoder, table rc-pixelview-mk12 Supported protocols: other Current protocols: NEC Found /sys/class/rc/rc2/ (/dev/input/event10) with: Driver em28xx, hardware decoder, table rc-rc5-hauppauge-new Supported protocols: NEC RC-5 Current protocols: RC-5 When ready, ir-keytable udev option will get driver and table info and seek on some files for the proper keymap, if the user wants to replace it by a customized one, or if the kernel keymap is disabled. 3. If you're going to be so remote specific, why not add protocol information in these regarding the remotes? You can tell the core everything to expect from this remote: raw vs. hardware decoder and the RC-5/NEC/RC-6/JVC/whatever raw protocol decoder to use. That gets us closer to just works and avoids false input events from two of the raw deoders both thinking they got a valid code. The table contains the info. 4. /sbin/lsmod is now going to give a very long listing with lots of noise. When these things are registered with the core, is the module's use count incremented when the core knows a driver is using one of them? No. It will just show the used modules, as they're dynamically loaded. For example, with my 3 test device driver loaded, it shows: rc_rc5_hauppauge_new 1100 0 rc_pixelview_mk12953 0 rc_avermedia_m135a_rm_jx 1016 0 5. Each module is going to consume a page of vmalloc address space and ram, and an addtional page of vmalloc address as a gap behind it. These maps are rather small in comparison. Is it really worth all the page table entries to load all these as individual modules? Memory is cheap, and small allocations can fill in fragmentation gaps in the vmalloc address space, but page table entries are spent on better things. My plan is to merge several keymaps. I'm currently trying to obtain some RC's to write the correct keymaps and try to merge them. I guess I'm not aware of what the return is here for the costs. -- Cheers, Mauro -- 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] device_attributes: add sysfs_attr_init() for dynamic attributes
Acked-By: Mike Isely is...@pobox.com
(in the context of the pvrusb2 driver related changes)
-Mike
On Mon, 22 Mar 2010, Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(name-A.attr);
(
+ sysfs_attr_init(name-A.attr);
if (device_create_file(E, name-A))
S
|
+ sysfs_attr_init(name-A.attr);
err = device_create_file(E, name-A);
)
While reviewing, I put the initialization to apropriate places.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Greg KH gre...@suse.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sujith Thomas sujith.tho...@intel.com
Cc: Matthew Garrett m...@redhat.com
---
The thermal-sys.c-part should fix bugs #15548 and #15584.
drivers/macintosh/windfarm_core.c |1 +
drivers/media/video/pvrusb2/pvrusb2-sysfs.c |8
drivers/platform/x86/intel_menlow.c |1 +
drivers/thermal/thermal_sys.c |1 +
drivers/video/fsl-diu-fb.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/windfarm_core.c
b/drivers/macintosh/windfarm_core.c
index 419795f..f447642 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -209,6 +209,7 @@ int wf_register_control(struct wf_control *new_ct)
kref_init(new_ct-ref);
list_add(new_ct-link, wf_controls);
+ sysfs_attr_init(new_ct-attr.attr);
new_ct-attr.attr.name = new_ct-name;
new_ct-attr.attr.mode = 0644;
new_ct-attr.show = wf_show_control;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 6c23456..71f5056 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -423,10 +423,12 @@ static void pvr2_sysfs_add_debugifc(struct pvr2_sysfs
*sfp)
dip = kzalloc(sizeof(*dip),GFP_KERNEL);
if (!dip) return;
+ sysfs_attr_init(dip-attr_debugcmd.attr);
dip-attr_debugcmd.attr.name = debugcmd;
dip-attr_debugcmd.attr.mode = S_IRUGO|S_IWUSR|S_IWGRP;
dip-attr_debugcmd.show = debugcmd_show;
dip-attr_debugcmd.store = debugcmd_store;
+ sysfs_attr_init(dip-attr_debuginfo.attr);
dip-attr_debuginfo.attr.name = debuginfo;
dip-attr_debuginfo.attr.mode = S_IRUGO;
dip-attr_debuginfo.show = debuginfo_show;
@@ -644,6 +646,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
return;
}
+ sysfs_attr_init(sfp-attr_v4l_minor_number.attr);
sfp-attr_v4l_minor_number.attr.name = v4l_minor_number;
sfp-attr_v4l_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_minor_number.show = v4l_minor_number_show;
@@ -658,6 +661,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_v4l_radio_minor_number.attr);
sfp-attr_v4l_radio_minor_number.attr.name = v4l_radio_minor_number;
sfp-attr_v4l_radio_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_radio_minor_number.show = v4l_radio_minor_number_show;
@@ -672,6 +676,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_radio_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_unit_number.attr);
sfp-attr_unit_number.attr.name = unit_number;
sfp-attr_unit_number.attr.mode = S_IRUGO;
sfp-attr_unit_number.show = unit_number_show;
@@ -685,6 +690,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-unit_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_bus_info.attr);
sfp-attr_bus_info.attr.name = bus_info_str;
sfp-attr_bus_info.attr.mode = S_IRUGO;
sfp-attr_bus_info.show = bus_info_show;
@@ -699,6 +705,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-bus_info_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_name.attr);
sfp-attr_hdw_name.attr.name = device_hardware_type;
sfp-attr_hdw_name.attr.mode = S_IRUGO;
sfp-attr_hdw_name.show = hdw_name_show;
@@ -713,6 +720,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-hdw_name_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_desc.attr);
sfp-attr_hdw_desc.attr.name = device_hardware_description;
sfp-attr_hdw_desc.attr.mode = S_IRUGO;
sfp-attr_hdw_desc.show = hdw_desc_show;
Re: [PATCH 09/11] pvrusb2-v4l2: Rename dev_info to pdi
Acked-By: Mike Isely is...@pobox.com
-Mike
On Mon, 5 Apr 2010, Joe Perches wrote:
There is a macro called dev_info that prints struct device specific
information. Having variables with the same name can be confusing and
prevents conversion of the macro to a function.
Rename the existing dev_info variables to something else in preparation
to converting the dev_info macro to a function.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index cc8ddb2..ba32c91 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -48,7 +48,7 @@ struct pvr2_v4l2_dev {
struct pvr2_v4l2_fh {
struct pvr2_channel channel;
- struct pvr2_v4l2_dev *dev_info;
+ struct pvr2_v4l2_dev *pdi;
enum v4l2_priority prio;
struct pvr2_ioread *rhp;
struct file *file;
@@ -161,7 +161,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_v4l2 *vp = fh-vhead;
- struct pvr2_v4l2_dev *dev_info = fh-dev_info;
+ struct pvr2_v4l2_dev *pdi = fh-pdi;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
long ret = -EINVAL;
@@ -563,14 +563,14 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_STREAMON:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
ret = -EPERM;
break;
}
- ret = pvr2_hdw_set_stream_type(hdw,dev_info-config);
+ ret = pvr2_hdw_set_stream_type(hdw,pdi-config);
if (ret 0) return ret;
ret = pvr2_hdw_set_streaming(hdw,!0);
break;
@@ -578,7 +578,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_STREAMOFF:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
@@ -1031,7 +1031,7 @@ static int pvr2_v4l2_open(struct file *file)
}
init_waitqueue_head(fhp-wait_data);
- fhp-dev_info = dip;
+ fhp-pdi = dip;
pvr2_trace(PVR2_TRACE_STRUCT,Creating pvr_v4l2_fh id=%p,fhp);
pvr2_channel_init(fhp-channel,vp-channel.mc_head);
@@ -1112,7 +1112,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
struct pvr2_hdw *hdw;
if (fh-rhp) return 0;
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means that we're
not currently allowed to stream from this node. */
return -EPERM;
@@ -1121,21 +1121,21 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
/* First read() attempt. Try to claim the stream and start
it... */
if ((ret = pvr2_channel_claim_stream(fh-channel,
- fh-dev_info-stream)) != 0) {
+ fh-pdi-stream)) != 0) {
/* Someone else must already have it */
return ret;
}
- fh-rhp = pvr2_channel_create_mpeg_stream(fh-dev_info-stream);
+ fh-rhp = pvr2_channel_create_mpeg_stream(fh-pdi-stream);
if (!fh-rhp) {
pvr2_channel_claim_stream(fh-channel,NULL);
return -ENOMEM;
}
hdw = fh-channel.mc_head-hdw;
- sp = fh-dev_info-stream-stream;
+ sp = fh-pdi-stream-stream;
pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
- pvr2_hdw_set_stream_type(hdw,fh-dev_info-config);
+ pvr2_hdw_set_stream_type(hdw,fh-pdi-config);
if ((ret = pvr2_hdw_set_streaming(hdw,!0)) 0) return ret;
return pvr2_ioread_set_enabled(fh-rhp,!0);
}
--
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] device_attributes: add sysfs_attr_init() for dynamic attributes
Mike Isely wrote:
Acked-By: Mike Isely is...@pobox.com
(in the context of the pvrusb2 driver related changes)
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
-Mike
On Mon, 22 Mar 2010, Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(name-A.attr);
(
+ sysfs_attr_init(name-A.attr);
if (device_create_file(E, name-A))
S
|
+ sysfs_attr_init(name-A.attr);
err = device_create_file(E, name-A);
)
While reviewing, I put the initialization to apropriate places.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Greg KH gre...@suse.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sujith Thomas sujith.tho...@intel.com
Cc: Matthew Garrett m...@redhat.com
---
The thermal-sys.c-part should fix bugs #15548 and #15584.
drivers/macintosh/windfarm_core.c |1 +
drivers/media/video/pvrusb2/pvrusb2-sysfs.c |8
drivers/platform/x86/intel_menlow.c |1 +
drivers/thermal/thermal_sys.c |1 +
drivers/video/fsl-diu-fb.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/windfarm_core.c
b/drivers/macintosh/windfarm_core.c
index 419795f..f447642 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -209,6 +209,7 @@ int wf_register_control(struct wf_control *new_ct)
kref_init(new_ct-ref);
list_add(new_ct-link, wf_controls);
+sysfs_attr_init(new_ct-attr.attr);
new_ct-attr.attr.name = new_ct-name;
new_ct-attr.attr.mode = 0644;
new_ct-attr.show = wf_show_control;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 6c23456..71f5056 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -423,10 +423,12 @@ static void pvr2_sysfs_add_debugifc(struct pvr2_sysfs
*sfp)
dip = kzalloc(sizeof(*dip),GFP_KERNEL);
if (!dip) return;
+sysfs_attr_init(dip-attr_debugcmd.attr);
dip-attr_debugcmd.attr.name = debugcmd;
dip-attr_debugcmd.attr.mode = S_IRUGO|S_IWUSR|S_IWGRP;
dip-attr_debugcmd.show = debugcmd_show;
dip-attr_debugcmd.store = debugcmd_store;
+sysfs_attr_init(dip-attr_debuginfo.attr);
dip-attr_debuginfo.attr.name = debuginfo;
dip-attr_debuginfo.attr.mode = S_IRUGO;
dip-attr_debuginfo.show = debuginfo_show;
@@ -644,6 +646,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
return;
}
+sysfs_attr_init(sfp-attr_v4l_minor_number.attr);
sfp-attr_v4l_minor_number.attr.name = v4l_minor_number;
sfp-attr_v4l_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_minor_number.show = v4l_minor_number_show;
@@ -658,6 +661,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_minor_number_created_ok = !0;
}
+sysfs_attr_init(sfp-attr_v4l_radio_minor_number.attr);
sfp-attr_v4l_radio_minor_number.attr.name = v4l_radio_minor_number;
sfp-attr_v4l_radio_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_radio_minor_number.show = v4l_radio_minor_number_show;
@@ -672,6 +676,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_radio_minor_number_created_ok = !0;
}
+sysfs_attr_init(sfp-attr_unit_number.attr);
sfp-attr_unit_number.attr.name = unit_number;
sfp-attr_unit_number.attr.mode = S_IRUGO;
sfp-attr_unit_number.show = unit_number_show;
@@ -685,6 +690,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-unit_number_created_ok = !0;
}
+sysfs_attr_init(sfp-attr_bus_info.attr);
sfp-attr_bus_info.attr.name = bus_info_str;
sfp-attr_bus_info.attr.mode = S_IRUGO;
sfp-attr_bus_info.show = bus_info_show;
@@ -699,6 +705,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-bus_info_created_ok = !0;
}
+sysfs_attr_init(sfp-attr_hdw_name.attr);
sfp-attr_hdw_name.attr.name = device_hardware_type;
sfp-attr_hdw_name.attr.mode = S_IRUGO;
sfp-attr_hdw_name.show = hdw_name_show;
@@ -713,6 +720,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-hdw_name_created_ok = !0;
}
+sysfs_attr_init(sfp-attr_hdw_desc.attr);
sfp-attr_hdw_desc.attr.name = device_hardware_description;
sfp-attr_hdw_desc.attr.mode = S_IRUGO;
sfp-attr_hdw_desc.show =
Re: [PATCH 08/26] V4L/DVB: Break Remote Controller keymaps into modules
On Sat, 2010-04-10 at 13:06 -0300, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Tue, 2010-04-06 at 15:18 -0300, Mauro Carvalho Chehab wrote: The original Remote Controller approach were very messy: a big file, that were part of ir-common kernel module, containing 64 different RC keymap tables, used by the V4L/DVB drivers. Better to break each RC keymap table into a separate module, registering them into rc core on a process similar to the fs/nls tables. As an userspace program is now in charge of loading those tables, adds an option to allow the complete removal of those tables from kernelspace. Yet, on embedded devices like Set Top Boxes and TV sets, maybe the only available input device is the IR. So, we should keep allowing the usage of in-kernel tables, but a latter patch should change the default to 'n', after giving some time for distros to add the v4l-utils with the ir-keytable program, to allow the table load via userspace. I know I'm probably late on commenting on this. Although this is interesting, it seems like overkill. 1. How will this help move us to the just works case, if now userspace has to help the kernel. Every distro is likely just going to bundle a script which loads them all into the kernel and forgets about them. No. They will either use userspace or kernelspace keymaps. For in-kernel keymaps, there's nothing needed on userspace. 2. How is a driver, which knows the bundled remote, supposed to convey to userspace load this map by default for my IR receiver? Is that covered in another portion of the patch? It is on a separate patch. Basically, by the name. The table name is stored on each IR map entry on kernel. If the table is in kernel, the table will be dynamically loaded, when needed. Userspace can always replace it by another one. For example, this is my current test setup: $ ./ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event8) with: Driver saa7134, raw software decoder, table rc-avermedia-m135a-rm-jx Supported protocols: NEC RC-5 RC-6 Found /sys/class/rc/rc1/ (/dev/input/event9) with: Driver cx88xx, hardware decoder, table rc-pixelview-mk12 Supported protocols: other Current protocols: NEC Found /sys/class/rc/rc2/ (/dev/input/event10) with: Driver em28xx, hardware decoder, table rc-rc5-hauppauge-new Supported protocols: NEC RC-5 Current protocols: RC-5 When ready, ir-keytable udev option will get driver and table info and seek on some files for the proper keymap, if the user wants to replace it by a customized one, or if the kernel keymap is disabled. 3. If you're going to be so remote specific, why not add protocol information in these regarding the remotes? You can tell the core everything to expect from this remote: raw vs. hardware decoder and the RC-5/NEC/RC-6/JVC/whatever raw protocol decoder to use. That gets us closer to just works and avoids false input events from two of the raw deoders both thinking they got a valid code. The table contains the info. 4. /sbin/lsmod is now going to give a very long listing with lots of noise. When these things are registered with the core, is the module's use count incremented when the core knows a driver is using one of them? No. It will just show the used modules, as they're dynamically loaded. For example, with my 3 test device driver loaded, it shows: rc_rc5_hauppauge_new 1100 0 rc_pixelview_mk12953 0 rc_avermedia_m135a_rm_jx 1016 0 Ah OK. Thanks for all your replies. Shame on me for not reading all the patch series. I'll try to do my homework better next time. Regards, Andy 5. Each module is going to consume a page of vmalloc address space and ram, and an addtional page of vmalloc address as a gap behind it. These maps are rather small in comparison. Is it really worth all the page table entries to load all these as individual modules? Memory is cheap, and small allocations can fill in fragmentation gaps in the vmalloc address space, but page table entries are spent on better things. My plan is to merge several keymaps. I'm currently trying to obtain some RC's to write the correct keymaps and try to merge them. I guess I'm not aware of what the return is here for the costs. -- 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
[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 10 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14561:7c0b887911cf git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8b680a770f6bdcd52f6816d7a5fe7aee9a9f7c78 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: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS 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: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS 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: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS 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: [PATCH 4/4] Add RC6 support to ir-core
On Fri, Apr 09, 2010 at 09:12:08PM -0400, Andy Walls wrote:
On Fri, 2010-04-09 at 01:04 +0200, David Härdeman wrote:
diff --git a/drivers/media/IR/ir-rc6-decoder.c
b/drivers/media/IR/ir-rc6-decoder.c
new file mode 100644
index 000..ccc5be2
--- /dev/null
+++ b/drivers/media/IR/ir-rc6-decoder.c
@@ -0,0 +1,412 @@
+/* ir-rc6-decoder.c - A decoder for the RC6 IR protocol
+ *
+ * Copyright (C) 2010 by David Härdeman da...@hardeman.nu
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include ir-core-priv.h
+
+/*
+ * This decoder currently supports:
+ * RC6-0-16(standard toggle bit in header)
+ * RC6-6A-24 (no toggle bit)
+ * RC6-6A-32 (MCE version with toggle bit in body)
+ */
Just for reference for review:
http://slycontrol.ru/scr/kb/rc6.htm
http://www.picbasic.nl/info_rc6_uk.htm
RC6 Mode 0:
prefix mark: 11
prefix space: 00
start bit:10 (biphase encoding of '1')
mode bits:010101 (biphase encoding of '000')
toggle bits: 0011 or 1100 (double duration biphase coding of '0' or '1')
system byte: (biphase encoding of 8 bits)
command byte: (biphase encoding of 8 bits)
RC6 Mode 6A:
prefix mark: 11
prefix space: 00
start bit: 10 (biphase encoding of '1')
mode bits: 101001 (biphase encoding of '110' for '6')
trailer bits: 0011 (double duration biphase encoding of '0' for 'A')
customer len: 01 or 10 (biphase encoding of '0' for 7 bits or '1' for 15
bits)
customer bits: xx (biphase encoding of 7 bits for a short
customer code)
or
xx (biphase encoding of 15 bits
for a long customer code)
system byte: (biphase encoding of 8 bits)
command byte: (biphase encoding of 8 bits)
+#define RC6_UNIT 44 /* us */
+#define RC6_HEADER_NBITS 4 /* not including toggle bit */
+#define RC6_0_NBITS16
+#define RC6_6A_SMALL_NBITS 24
+#define RC6_6A_LARGE_NBITS 32
According to the slycontrol.ru website, the data length is, in theory
OEM dependent for Mode 6A, limited to a max of 24 bits (3 bytes) after a
short customer code and 128 bits (16 bytes) after a long customer code.
I don't know what the reality is for existing remotes.
Would it be better to look for the signal free time of 6 RC6_UNITs to
declare the end of reception, instead of a bit count?
Yes, it might be better from a correctness point of view, and I think it
might be a worthwhile change if we want to support a few more odd
remotes (although the only one I'm aware of - even after trawling
through lots of lirc configs, decodeir.dll configs and remotecentral
configs - is the Sky remote which seems to use a short customer code
and a 12 bit body).
The thing is though, that with the different 32 bit scancodes, we can't
anyway represent anything beyond a 32 bit message body (including the
customer code, which should be included in the scancode). I have a
proposal on changing the scancodes used in ir-code, but I haven't
written up the details yet.
It's also interesting to note that the ProntoEdit NG program, which is
written by Philips, only allows a 24/32 bit body (including the customer
bits).
+#define RC6_PREFIX_PULSE PULSE(6)
+#define RC6_PREFIX_SPACE SPACE(2)
+#define RC6_MODE_MASK 0x07/* for the header bits */
+#define RC6_STARTBIT_MASK 0x08/* for the header bits */
+#define RC6_6A_MCE_TOGGLE_MASK 0x8000 /* for the body bits */
That's an OEM specific toggle bit.
Umm, yes I know? That's why the define includes the _MCE_ part and
also what the comment in the beginning of the decoder says:
* RC6-6A-32 (MCE version with toggle bit in body)
It is likely more properly named
RC6_6A_MS_TOGGLE_MASK. See slide 6 of:
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt
(Although in reality, every remote that wants to work with stock MS
drivers will use it.)
I'm not sure what your point is...it's already called
RC6_6A_MCE_TOGGLE_MASK, as in RC6 6A Windows Media Center Edition
Toggle Mask.
+
+/* Used to register rc6_decoder clients */
+static LIST_HEAD(decoder_list);
+static DEFINE_SPINLOCK(decoder_lock);
+
+enum rc6_mode {
+ RC6_MODE_0,
+ RC6_MODE_6A,
+ RC6_MODE_UNKNOWN,
+};
+
+enum rc6_state {
+
Re: [PATCH 4/4] Add RC6 support to ir-core
On Sat, 2010-04-10 at 21:52 +0200, David Härdeman wrote: On Fri, Apr 09, 2010 at 09:12:08PM -0400, Andy Walls wrote: On Fri, 2010-04-09 at 01:04 +0200, David Härdeman wrote: diff --git a/drivers/media/IR/ir-rc6-decoder.c b/drivers/media/IR/ir-rc6-decoder.c new file mode 100644 index 000..ccc5be2 --- /dev/null +++ b/drivers/media/IR/ir-rc6-decoder.c @@ -0,0 +1,412 @@ +/* ir-rc6-decoder.c - A decoder for the RC6 IR protocol + * + * Copyright (C) 2010 by David Härdeman da...@hardeman.nu + * + * 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 version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include ir-core-priv.h + +/* + * This decoder currently supports: + * RC6-0-16 (standard toggle bit in header) + * RC6-6A-24 (no toggle bit) + * RC6-6A-32 (MCE version with toggle bit in body) + */ Just for reference for review: http://slycontrol.ru/scr/kb/rc6.htm http://www.picbasic.nl/info_rc6_uk.htm RC6 Mode 0: prefix mark: 11 prefix space: 00 start bit:10 (biphase encoding of '1') mode bits:010101 (biphase encoding of '000') toggle bits: 0011 or 1100 (double duration biphase coding of '0' or '1') system byte: (biphase encoding of 8 bits) command byte: (biphase encoding of 8 bits) RC6 Mode 6A: prefix mark: 11 prefix space: 00 start bit: 10 (biphase encoding of '1') mode bits: 101001 (biphase encoding of '110' for '6') trailer bits: 0011 (double duration biphase encoding of '0' for 'A') customer len: 01 or 10 (biphase encoding of '0' for 7 bits or '1' for 15 bits) customer bits: xx (biphase encoding of 7 bits for a short customer code) or xx (biphase encoding of 15 bits for a long customer code) system byte: (biphase encoding of 8 bits) command byte: (biphase encoding of 8 bits) +#define RC6_UNIT 44 /* us */ +#define RC6_HEADER_NBITS 4 /* not including toggle bit */ +#define RC6_0_NBITS 16 +#define RC6_6A_SMALL_NBITS 24 +#define RC6_6A_LARGE_NBITS 32 According to the slycontrol.ru website, the data length is, in theory OEM dependent for Mode 6A, limited to a max of 24 bits (3 bytes) after a short customer code and 128 bits (16 bytes) after a long customer code. I don't know what the reality is for existing remotes. Would it be better to look for the signal free time of 6 RC6_UNITs to declare the end of reception, instead of a bit count? Yes, it might be better from a correctness point of view, and I think it might be a worthwhile change if we want to support a few more odd remotes (although the only one I'm aware of - even after trawling through lots of lirc configs, decodeir.dll configs and remotecentral configs - is the Sky remote which seems to use a short customer code and a 12 bit body). The thing is though, that with the different 32 bit scancodes, we can't anyway represent anything beyond a 32 bit message body (including the customer code, which should be included in the scancode). Yup. I have a proposal on changing the scancodes used in ir-code, but I haven't written up the details yet. It's also interesting to note that the ProntoEdit NG program, which is written by Philips, only allows a 24/32 bit body (including the customer bits). So maybe forget my suggesting of coding to the theoretical limits, if we'll never really encounter one in practice. +#define RC6_PREFIX_PULSE PULSE(6) +#define RC6_PREFIX_SPACE SPACE(2) +#define RC6_MODE_MASK0x07/* for the header bits */ +#define RC6_STARTBIT_MASK0x08/* for the header bits */ +#define RC6_6A_MCE_TOGGLE_MASK 0x8000 /* for the body bits */ That's an OEM specific toggle bit. Umm, yes I know? That's why the define includes the _MCE_ part and also what the comment in the beginning of the decoder says: * RC6-6A-32 (MCE version with toggle bit in body) It is likely more properly named RC6_6A_MS_TOGGLE_MASK. See slide 6 of: http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt (Although in reality, every remote that wants to work with stock MS drivers will use it.) I'm not sure what your point is...it's already called RC6_6A_MCE_TOGGLE_MASK, as in RC6 6A
Re: [PATCH 4/4] Add RC6 support to ir-core
On Fri, Apr 09, 2010 at 09:12:08PM -0400, Andy Walls wrote:
On Fri, 2010-04-09 at 01:04 +0200, David Härdeman wrote:
+again:
+ IR_dprintk(2, RC6 decode started at state %i (%i units, %ius)\n,
+ data-state, u, TO_US(duration));
+
+ if (DURATION(u) == 0 data-state != STATE_FINISHED)
+ return 0;
Isn't there a better way to structure the logic to break up two adjacent
pulse units than with goto's out of the switch back up to here?
A do {} while() loop would have been much clearer.
I just tried it, and I'm not convinced. The main problem is that you'll
end up with:
do {
switch(b) {
case c:
if (x)
break;
else if (y)
continue;
while(a);
Where the break statement will affect the switch() and the continue
statement will affect the do-while() loop which is kinda confusing.
Especially if you're so far down in the function body that the
do-while() and switch() statements aren't visible any more.
--
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: cx18: missing audio for analog recordings
On 15/03/10 07:51 AM, Andy Walls wrote:
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
On 03/02/10 07:40, Andy Walls wrote:
..
after updating to the tip of the v4l2-dvb git tree last week,
I've been hitting the no audio on analog recordings bug much more often.
Digging through google, it appears this problem has been around as long
as the cx18 driver has existed, with no clear resolution. Lots of people
have reported it to you before, and nobody has found a silver bullet fix.
..
Here are all the potential problem areas I can think of:
1. A/V digitizer/decoder audio detection firmware load and init. (I've
added firmware readback verification to try and head this off.)
2. A/V digitizer decoder audio microcontroller hard reset and soft
reset sequencing. (I think the cx18 driver has this wrong ATM.)
3. APU load and init. (The double load is to fix a DTV TS stream bug on
every other APU CPU firmware load sequence. The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)
4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs. (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)
5. A/V decoder audio clock PLL stops operating due to being programmed
out of range. (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)
6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
to a problen Helen Buus reported with cable TV.)
I think #2 is the real problem. I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.
I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:
http://linuxtv.org/hg/~awalls/cx18-audio
If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.
..
Thanks for the troubleshooting and reporting.
..
Back at this again today, after a month away from it -- getting tired
of watching Survivor with closed-captioning instead of audio. :)
I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb. Patch attached for reference.
So far, so good. I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-audio.c
2010-04-05 22:56:43.0 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-audio.c 2010-03-13
22:06:55.0 -0500
@@ -305,14 +305,14 @@
struct cx18_av_state *state = cx-av_state;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
/* stop microcontroller */
v = cx18_av_read(cx, 0x803) ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- /* assert soft reset */
- v = cx18_av_read(cx, 0x810) | 0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
/* Mute everything to prevent the PFFT! */
cx18_av_write(cx, 0x8d3, 0x1f);
@@ -330,16 +330,17 @@
set_audclk_freq(cx, state-audclk_freq);
- /* deassert soft reset */
- v = cx18_av_read(cx, 0x810) ~0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
if (state-aud_input CX18_AV_AUDIO_SERIAL2) {
+ /* start microcontroller */
/* When the microcontroller detects the
* audio format, it will unmute the lines */
v = cx18_av_read(cx, 0x803) | 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
+
+ /* deassert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) ~0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
}
static int get_volume(struct cx18 *cx)
@@ -449,12 +450,13 @@
* changes to the mute register. */
v = cx18_av_read(cx, 0x803);
if (mute) {
- /* disable microcontroller */
+ /* stop microcontroller */
v = ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+ /* mute all of Path 1 */
cx18_av_write(cx, 0x8d3, 0x1f);
} else {
- /* enable microcontroller */
+ /* start microcontroller */
v |= 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
@@ -471,22 +473,29 @@
int retval;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x1;
+
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote: On 15/03/10 07:51 AM, Andy Walls wrote: On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: .. after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. .. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. .. Thanks for the troubleshooting and reporting. .. Back at this again today, after a month away from it -- getting tired of watching Survivor with closed-captioning instead of audio. :) I pulled your (Andy) repository today, and merged the cx18 audio reset changes from it into today's tip from v4l-dvb. Patch attached for reference. So far, so good. I'll keep tabs on it over time, and see if the audio is stable, or if it still fails once in a while. Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? 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
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote: On 15/03/10 07:51 AM, Andy Walls wrote: On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: .. after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. .. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. .. Thanks for the troubleshooting and reporting. .. Back at this again today, after a month away from it -- getting tired of watching Survivor with closed-captioning instead of audio. :) I pulled your (Andy) repository today, and merged the cx18 audio reset changes from it into today's tip from v4l-dvb. Patch attached for reference. So far, so good. I'll keep tabs on it over time, and see if the audio is stable, or if it still fails once in a while. Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? Hey, I just found an OTA analog broadcast on channel 23! I even can reproduce the problem of the audio microcontroller not detecting the audio standard (shoot it just kicked in and figured it out). Anyway this will help me turn around something. 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
[PATCH 2/2] ir-core: Fix the delete logic
Instead of removing an entry, the logic were doing both a deletion and
a key addition, as shown by the log:
[11517.323314] ir_getkeycode: unknown key for scancode 0x0050
[11517.326529] ir_do_setkeycode: #80: Deleting scan 0x0050
[11517.326529] ir_do_setkeycode: #80: New scan 0x0050 with key 0x
[11517.340598] ir_getkeycode: unknown key for scancode 0x0051
[11517.343811] ir_do_setkeycode: #81: Deleting scan 0x0051
[11517.343811] ir_do_setkeycode: #81: New scan 0x0051 with key 0x
[11517.357889] ir_getkeycode: unknown key for scancode 0x0052
[11517.361104] ir_do_setkeycode: #82: Deleting scan 0x0052
[11517.361104] ir_do_setkeycode: #82: New scan 0x0052 with key 0x
[11517.375453] ir_getkeycode: unknown key for scancode 0x0053
[11517.378474] ir_do_setkeycode: #83: Deleting scan 0x0053
[11517.378474] ir_do_setkeycode: #83: New scan 0x0053 with key 0x
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 01bddc4..f0eb680 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -126,7 +126,7 @@ static int ir_do_setkeycode(struct input_dev *dev,
break;
}
- if (old_keycode == KEY_RESERVED) {
+ if (old_keycode == KEY_RESERVED keycode != KEY_RESERVED) {
/* No previous mapping found, we might need to grow the table */
if (ir_resize_table(rc_tab))
return -ENOMEM;
--
1.6.6.1
--
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/2] ir-core: Remove the quotation mark from the uevent names
There's no need to use quotation marks at the uevent names for the driver and table. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c index a222d4f..40d9abf 100644 --- a/drivers/media/IR/ir-sysfs.c +++ b/drivers/media/IR/ir-sysfs.c @@ -159,9 +159,9 @@ static int ir_dev_uevent(struct device *device, struct kobj_uevent_env *env) struct ir_input_dev *ir_dev = dev_get_drvdata(device); if (ir_dev-rc_tab.name) - ADD_HOTPLUG_VAR(NAME=\%s\, ir_dev-rc_tab.name); + ADD_HOTPLUG_VAR(NAME=%s, ir_dev-rc_tab.name); if (ir_dev-driver_name) - ADD_HOTPLUG_VAR(DRV_NAME=\%s\, ir_dev-driver_name); + ADD_HOTPLUG_VAR(DRV_NAME=%s, ir_dev-driver_name); return 0; } -- 1.6.6.1 -- 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: cx18: missing audio for analog recordings
On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Cheers! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.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: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). 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
Re: [ivtv-devel] cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of ^^^ Bah, wrong byte. That should have been the LSN of the MSB of the 0x1101 number. I'm too tired. Regards, Andy the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). Regards, Andy ___ ivtv-devel mailing list ivtv-de...@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- 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
Remote Controller subsystem status
For those that are following the discussions, we're having lots of fun with the Remote Controller support those days ;) We're basically re-writing the entire subsystem, that used to be part of V4L/DVB core and drivers, into a core subsystem that can be used not only by media drivers, but also for separate Remote Controllers, like those media center infra red remote controllers. The idea is to also add support to send raw events to userspace applications like lirc. It started pretending to work just with Infra Red, but it makes sense to be used also with other type of transmission media, so Remote Controller is a more general name. We had some important additions on the kernel drivers those days, and I did some major changes at the userspace tool that is meant to control the keymap tables used by Remote Controllers (ir-keytable). I also fixed yesterday two kernel bugs at ir-core, that affected the userspace app. So, both the kernel driver and the userspace tool are in sync. With this, I hope we don't need to change anymore any existing sysfs attribute (yet, this might happen until kernel 2.6.35, where I expect that those changes will be merged). Currently, only ir-keytable uses those sysfs attributes. The current version of the ir-keytable application is providing full support to all features currently exported via sysfs by the remote controller sysfs class, at: /sys/class/rc Without any parameter, it lists all Remote Controllers on the machine: $ ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event8) with: Driver saa7134, raw software decoder, table rc-avermedia-m135a-rm-jx Supported protocols: NEC RC-5 Enabled protocols: RC-5 Found /sys/class/rc/rc1/ (/dev/input/event9) with: Driver em28xx, hardware decoder, table rc-rc5-hauppauge-new Supported protocols: NEC RC-5 Current protocols: RC-5 Found /sys/class/rc/rc2/ (/dev/input/event10) with: Driver cx88xx, hardware decoder, table rc-pixelview-mk12 Supported protocols: other Current protocols: NEC There are parameters for reading the current table, to add another table to the driver, to clear the drivers table and to change the current protocol (on hardware decoders) or the enabled protocols (on software decoders). The most interesting option is -a or --auto-load. It reads a file with rules that associates a device (by its driver name and by the table name - both info provided by the kernel driver), with a file with the corresponding keymap. The idea is to use it to automatically load a table via udev, with a rule like: ACTION==add, SUBSYSTEM==rc, RUN+=/usr/local/bin/ir-keytable -v -a /etc/rc_maps.cfg -s $name Note: The above rule is not working yet (at least on the very quick test I did here with udev, just before starting writing this email). Currently, it is giving this error message: [16009.232502] ir-keytable[20836]: segfault at 4 ip 08048bb1 sp bf8fb110 error 4 in ir-keytable[8048000+5000] [16009.242716] Process 20836(ir-keytable) has RLIMIT_CORE set to 0 [16009.248744] Aborting core I intend to do enable the core dump and do some tests to check why and fix it, but for sure not today. In fact, it may take some time, since I'm going to travel those days to the Collaboration Summit. Maybe I'll find time to fix it only after my return. Of course, people are welcome to fix it before ;) Anyway, with what we currently have, we have both the IR subsystem and the userspace application in a good shape for testing. There are still lots of things to do. On a very quick brainstorm, this is a non-exhaustive lists of tasks for a TODO list: - Add support for 64 bits scancode tables, using EVIOCGKEYCODEBIG/EVIOCSKEYCODEBIG; - Port the DVB drivers to IR core; - Remove ir-common module from V4L drivers (It currently contains only a few decoders - one of them is pulse-distance - not implemented yet on rc-core); - Add the full scancodes for all RC tables; - Fix the script to get the new table formats and locations (better to port DVB drivers first); - Add lirc_dev; - Add other IR drivers; - Rename IR to RC on all files and move the subsystem to a better location (probably, this will be the final step); - Add support for filtering scancode/keycode maps into different event devices; - Use it with other Remote Controller devices (HID, Bluetooth, radio RC?); - Cleanups; - Add more decoders; - IR blaster/transmitter; - Merge some keymaps; ... Currently, all kernel patches are at the main development tree for V4L/DVB (and, as consequence, being exported to linux-next): http://git.linuxtv.org/v4l-dvb.git The userspace application (ir-keycode) is at: http://git.linuxtv.org/v4l-utils.git The make install will install it at the binary dir and copy the keymaps into /etc/rc_keymaps, together with an automatic mode example file, at /etc/rc_maps.cfg.example. I keep maintaining an experimental tree for new IR patches under testing at:
