Re: [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver)
Hi Maxim,
on 31 Jul 10 at 01:01, Maxim Levitsky wrote:
On Fri, 2010-07-30 at 23:22 +0200, Christoph Bartelmus wrote:
[...]
+#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
If you really want this new ioctl, then it should be clarified how it
behaves in relation to LIRC_SET_MEASURE_CARRIER_MODE.
In my opinion, I won't need the LIRC_SET_MEASURE_CARRIER_MODE,
I would just optionally turn that on in learning mode.
You disagree, and since that is not important (besides TX and learning
features are present only at fraction of ENE devices. The only user I
did the debugging with, doesn't seem to want to help debug that code
anymore...)
But anyway, in current state I want these features to be independent.
Driver will enable learning mode if it have to.
Please avoid the term learning mode as to you it probably means
something different than to me.
I'll add the documentation.
Do you have to enable the wide-band receiver explicitly before you can
enable carrier reports or does enabling carrier reports implicitly switch
to the wide-band receiver?
I would implicitly switch the learning mode on, untill user turns off
the carrier reports.
You mean that you'll implicitly switch on the wide-band receiver. Ok.
What happens if carrier mode is enabled and you explicitly turn off the
wide-band receiver?
Wouldn't it be better to have one ioctl for both after all?
There may be hardware that allows carrier measurement but does not have a
wide-band receiver. And there may be hardware that does have a wide-band
receiver but does not allow carrier measurement. irrecord needs to be able
to distinguish these cases, so we need separate ioctls.
I'd say: carrier reports may switch on the wide-band reciever implicitly.
In that case the wide-band receiver cannot be switched off explicitly
until carrier reports are disabled again. It just needs to be documented.
And while we're at interface stuff:
Do we really need LIRC_SETUP_START and LIRC_SETUP_END? It is only used
once in lircd during startup.
I don't think so.
Christoph
--
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
Handling of large keycodes
Hi Mauro,
I finally got a chance to review the patches adding handling of large
scancodes to input core and there are a few things with this approach
that I do not like.
First of all I do not think that we should be working with scancode via
a pointer as it requires additional compat handling when running 32-bit
userspace on 64-bit kernel. We can use a static buffer of sufficient
size (lets say 32 bytes) to move scancode around and simply increase its
size if we come upon device that uses even bigger scancodes. As long as
buffer is at the end we can handle this in a compatible way.
The other issue is that interface is notsymmetrical, setting is done by
scancode but retrieval is done by index. I think we should be able to
use both scancode and index in both operations.
The usefulnes of reserved data elements in the structure is doubtful,
since we do not seem to require them being set to a particular value and
so we'll be unable to distinguish betwee legacy and newer users.
I also concerned about the code very messy with regard to using old/new
style interfaces instea dof converting old ones to use new
insfrastructure,
I below is something that addresses these issues and seems to be working
for me. It is on top of your patches and it also depends on a few
changes in my tree that I have not publushed yet but plan on doing that
tomorrow. I am also attaching patches converting sparse keymap and hid
to the new style of getkeycode and setkeycode as examples.
Please take a look and let me know if I missed something important.
Thank you.
--
Dmitry
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/char/keyboard.c | 31 +++-
drivers/input/evdev.c | 139 +++
drivers/input/input.c | 351 +++
include/linux/input.h | 72 +-
4 files changed, 255 insertions(+), 338 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 54109dc..4dd9fb0 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -175,8 +175,7 @@ EXPORT_SYMBOL_GPL(unregister_keyboard_notifier);
*/
struct getset_keycode_data {
- unsigned int scancode;
- unsigned int keycode;
+ struct keymap_entry ke;
int error;
};
@@ -184,32 +183,50 @@ static int getkeycode_helper(struct input_handle *handle,
void *data)
{
struct getset_keycode_data *d = data;
- d-error = input_get_keycode(handle-dev, d-scancode, d-keycode);
+ d-error = input_get_keycode(handle-dev, d-ke);
return d-error == 0; /* stop as soon as we successfully get one */
}
int getkeycode(unsigned int scancode)
{
- struct getset_keycode_data d = { scancode, 0, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .by_index = false,
+ .len= sizeof(scancode),
+ .keycode= 0,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, scancode, sizeof(scancode));
input_handler_for_each_handle(kbd_handler, d, getkeycode_helper);
- return d.error ?: d.keycode;
+ return d.error ?: d.ke.keycode;
}
static int setkeycode_helper(struct input_handle *handle, void *data)
{
struct getset_keycode_data *d = data;
- d-error = input_set_keycode(handle-dev, d-scancode, d-keycode);
+ d-error = input_set_keycode(handle-dev, d-ke);
return d-error == 0; /* stop as soon as we successfully set one */
}
int setkeycode(unsigned int scancode, unsigned int keycode)
{
- struct getset_keycode_data d = { scancode, keycode, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .by_index = false,
+ .len= sizeof(scancode),
+ .keycode= keycode,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, scancode, sizeof(scancode));
input_handler_for_each_handle(kbd_handler, d, setkeycode_helper);
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 783cdd3..9c7a97b 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -534,6 +534,80 @@ static int handle_eviocgbit(struct input_dev *dev,
}
#undef OLD_KEY_MAX
+static int evdev_handle_get_keycode(struct input_dev *dev,
+ void __user *p, size_t size)
+{
+ struct keymap_entry ke;
+ int error;
+
+ memset(ke, 0, sizeof(ke));
+
+ if (size == sizeof(unsigned int[2])) {
+ /* legacy case */
+ int __user *ip = (int __user *)p;
+
+ if (copy_from_user(ke.scancode, p, sizeof(unsigned int)))
+ return -EFAULT;
+
+ ke.len = sizeof(unsigned int);
+ ke.by_index = false;
+
+ error = input_get_keycode(dev, ke);
+
Re: [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver)
On Sat, 2010-07-31 at 10:10 +0200, Christoph Bartelmus wrote:
Hi Maxim,
on 31 Jul 10 at 01:01, Maxim Levitsky wrote:
On Fri, 2010-07-30 at 23:22 +0200, Christoph Bartelmus wrote:
[...]
+#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
If you really want this new ioctl, then it should be clarified how it
behaves in relation to LIRC_SET_MEASURE_CARRIER_MODE.
In my opinion, I won't need the LIRC_SET_MEASURE_CARRIER_MODE,
I would just optionally turn that on in learning mode.
You disagree, and since that is not important (besides TX and learning
features are present only at fraction of ENE devices. The only user I
did the debugging with, doesn't seem to want to help debug that code
anymore...)
But anyway, in current state I want these features to be independent.
Driver will enable learning mode if it have to.
Please avoid the term learning mode as to you it probably means
something different than to me.
I'll add the documentation.
Do you have to enable the wide-band receiver explicitly before you can
enable carrier reports or does enabling carrier reports implicitly switch
to the wide-band receiver?
I would implicitly switch the learning mode on, untill user turns off
the carrier reports.
You mean that you'll implicitly switch on the wide-band receiver. Ok.
What happens if carrier mode is enabled and you explicitly turn off the
wide-band receiver?
Wouldn't it be better to have one ioctl for both after all?
There may be hardware that allows carrier measurement but does not have a
wide-band receiver. And there may be hardware that does have a wide-band
receiver but does not allow carrier measurement. irrecord needs to be able
to distinguish these cases, so we need separate ioctls.
I'd say: carrier reports may switch on the wide-band reciever implicitly.
In that case the wide-band receiver cannot be switched off explicitly
until carrier reports are disabled again. It just needs to be documented.
No problem.
Best regards,
Maxim Levitsky
--
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: Handling of large keycodes
Hi Dmitry, Em 31-07-2010 06:19, Dmitry Torokhov escreveu: Hi Mauro, I finally got a chance to review the patches adding handling of large scancodes to input core and there are a few things with this approach that I do not like. Thanks for the review! First of all I do not think that we should be working with scancode via a pointer as it requires additional compat handling when running 32-bit userspace on 64-bit kernel. We can use a static buffer of sufficient size (lets say 32 bytes) to move scancode around and simply increase its size if we come upon device that uses even bigger scancodes. As long as buffer is at the end we can handle this in a compatible way. Yes, this is the downside of using a pointer. I'm not aware of a Remote Controller protocol using more than 256 bits for scancode, so 32 bits should be ok. The other issue is that interface is notsymmetrical, setting is done by scancode but retrieval is done by index. I think we should be able to use both scancode and index in both operations. Yes, this also bothered me. I was thinking to do something similar to your approach of having a bool to select between them. This change is welcome. The usefulnes of reserved data elements in the structure is doubtful, since we do not seem to require them being set to a particular value and so we'll be unable to distinguish betwee legacy and newer users. David proposed some parameters that we rejected on our discussions. As we might need to add something similar, I decided to keep it on my approach, since a set of reserved fields wouldn't hurt (and removing it on our discussions would be easy), but I'm ok on removing them. I also concerned about the code very messy with regard to using old/new style interfaces instea dof converting old ones to use new insfrastructure, Good cleanup at the code! I below is something that addresses these issues and seems to be working for me. It is on top of your patches and it also depends on a few changes in my tree that I have not publushed yet but plan on doing that tomorrow. I am also attaching patches converting sparse keymap and hid to the new style of getkeycode and setkeycode as examples. Please take a look and let me know if I missed something important. It seems to work for me. After you add the patches on your git tree, I'll work on porting the RC core to the new approach, and change the ir-keycode userspace program to work with, in order to be 100% sure that it will work, but I can't foresee any missing part on it. Currently, I'm not using my input patches, as I was waiting for your review. I just patched the userspace application, in order to test the legacy mode. 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote: On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky maximlevit...@gmail.com wrote: + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) 4) + + (ene_hw_read_reg(dev, ENE_PLLFRL) 2); I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right. This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.) The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by 4 bits, not by 2. Of course, the KB3700 isn't the exact same chip. 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: [PULL] soc-camera, sh-vou, v4l2 for 2.6.36
Hi Mauro On Fri, 30 Jul 2010, Mauro Carvalho Chehab wrote: Em 29-07-2010 06:31, Guennadi Liakhovetski escreveu: Hi Mauro The following changes since commit c57fd88318988f17731e446fe1d8498f506fdd44: V4L/DVB: uvcvideo: Add support for Manta MM-353 Plako (2010-07-05 19:47:16 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.36 Guennadi Liakhovetski (8): mediabus: fix ambiguous pixel code names V4L2: avoid name conflicts in macros This patch is incomplete, as other macros use sd without declaring it as an argument, like: #define v4l2_device_call_all(v4l2_dev, grpid, o, f, args...)\ __v4l2_device_call_subdevs(v4l2_dev,\ !(grpid) || sd-grp_id == (grpid), o, f , ##args) To make things even worse, some drivers have their own opinion about it, like: #define cx18_call_hw(cx, hw, o, f, args...) \ __v4l2_device_call_subdevs((cx)-v4l2_dev, \ !(hw) || (sd-grp_id (hw)), o, f , ##args) The result is that this patch breaks the compilation on several drivers. It is not your patch's fault. the problem is that those macros have something to hide. If sd is a parameter of the macro, they should have being declaring sd into their lists of arguments. nice... Please provide a version that will properly address those problems. As the other patches don't seem to need this change (at least, all compiled fine here), I'll drop this patch and apply the remaining ones. Thanks, that's a perfect solution for now! I'll think, if I can solve this probelm(s) properly. I'm on a holiday for the next 2 weeks, so, don't know when I'll be able to provide a new version. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote: On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote: On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky maximlevit...@gmail.com wrote: + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) 4) + + (ene_hw_read_reg(dev, ENE_PLLFRL) 2); I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right. This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.) The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by 4 bits, not by 2. Of course, the KB3700 isn't the exact same chip. You are right about that, thanks! Best regards, Maxim Levitsky -- 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote: On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote: On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky maximlevit...@gmail.com wrote: + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) 4) + + (ene_hw_read_reg(dev, ENE_PLLFRL) 2); I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right. This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.) The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by 4 bits, not by 2. Of course, the KB3700 isn't the exact same chip. You are right about that, thanks! I looked at KB3700 manual. It says it is trying to make a 32Mhz clock by multiplying 32.768Khz * 1000. 32,768 * 1000 = 32.768Mhz is a 2.4% error. When you are computing the timings of the pulses did you assume a 32Mhz clock? It looks like the clock is actuall 32.768Mhz. Best regards, Maxim Levitsky -- 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: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 10:37 -0400, Jon Smirl wrote: On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote: On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote: On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky maximlevit...@gmail.com wrote: + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) 4) + + (ene_hw_read_reg(dev, ENE_PLLFRL) 2); I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right. This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.) The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by 4 bits, not by 2. Of course, the KB3700 isn't the exact same chip. You are right about that, thanks! I looked at KB3700 manual. It says it is trying to make a 32Mhz clock by multiplying 32.768Khz * 1000. 32,768 * 1000 = 32.768Mhz is a 2.4% error. When you are computing the timings of the pulses did you assume a 32Mhz clock? It looks like the clock is actuall 32.768Mhz. No, I just take the samples hardware give me. Lets just leave this as is. Best regards, Maxim Levitsky -- 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/9 v4] IR: few fixes, additions and ENE driver
Hi, 4th revision of my patches below: Changes: * more carefull repeat support in NECX protocol * added documentation for wide band mode ioctl * fix for 64 bit divide * updated summary of patches, and preserved few * Acked/Reviewed by tags you gave me. Best regards, Maxim Levitsky -- 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 01/13] IR: Kconfig fixes
Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/Kconfig | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index e557ae0..fc48a3f 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -1,8 +1,10 @@ -config IR_CORE - tristate +menuconfig IR_CORE + tristate Infrared remote controller adapters depends on INPUT default INPUT +if IR_CORE + config VIDEO_IR tristate depends on IR_CORE @@ -16,7 +18,7 @@ config LIRC Enable this option to build the Linux Infrared Remote Control (LIRC) core device interface driver. The LIRC interface passes raw IR to and from userspace, where the - LIRC daemon handles protocol decoding for IR reception ann + LIRC daemon handles protocol decoding for IR reception and encoding for IR transmitting (aka blasting). source drivers/media/IR/keymaps/Kconfig @@ -102,3 +104,5 @@ config IR_MCEUSB To compile this driver as a module, choose M here: the module will be called mceusb. + +endif #IR_CORE -- 1.7.0.4 -- 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 05/13] IR: JVC: make repeat work
Currently, jvc decoder will attempt misdetect next press as a repeat
of last keypress, therefore second keypress isn't detected.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-jvc-decoder.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 8894d8b..77a89c4 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -32,6 +32,7 @@ enum jvc_state {
STATE_BIT_SPACE,
STATE_TRAILER_PULSE,
STATE_TRAILER_SPACE,
+ STATE_CHECK_REPEAT,
};
/**
@@ -60,6 +61,7 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
IR_dprintk(2, JVC decode started at state %d (%uus %s)\n,
data-state, TO_US(ev.duration), TO_STR(ev.pulse));
+again:
switch (data-state) {
case STATE_INACTIVE:
@@ -149,8 +151,18 @@ static int ir_jvc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
}
data-count = 0;
- data-state = STATE_BIT_PULSE;
+ data-state = STATE_CHECK_REPEAT;
return 0;
+
+ case STATE_CHECK_REPEAT:
+ if (!ev.pulse)
+ break;
+
+ if (eq_margin(ev.duration, JVC_HEADER_PULSE, JVC_UNIT / 2))
+ data-state = STATE_INACTIVE;
+ else
+ data-state = STATE_BIT_PULSE;
+ goto again;
}
out:
--
1.7.0.4
--
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 06/13] IR: nec decoder: fix repeat.
Repeat space is 4 units, not 8. Current code would never trigger a repeat. However that isn't true for NECX, so repeat there must be handled differently. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Reviewed-by: Andy Walls awa...@md.metrocast.net --- drivers/media/IR/ir-nec-decoder.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c index 52e0f37..1c0cf03 100644 --- a/drivers/media/IR/ir-nec-decoder.c +++ b/drivers/media/IR/ir-nec-decoder.c @@ -20,7 +20,7 @@ #define NEC_HEADER_PULSE (16 * NEC_UNIT) #define NECX_HEADER_PULSE (8 * NEC_UNIT) /* Less common NEC variant */ #define NEC_HEADER_SPACE (8 * NEC_UNIT) -#define NEC_REPEAT_SPACE (8 * NEC_UNIT) +#define NEC_REPEAT_SPACE (4 * NEC_UNIT) #define NEC_BIT_PULSE (1 * NEC_UNIT) #define NEC_BIT_0_SPACE(1 * NEC_UNIT) #define NEC_BIT_1_SPACE(3 * NEC_UNIT) -- 1.7.0.4 -- 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 07/13] IR: NECX: support repeat
This adds support for repeat detecting for NECX variant
Tested with uneversal remote
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |2 ++
drivers/media/IR/ir-nec-decoder.c | 23 +--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 84c7a9a..502d477 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -45,6 +45,8 @@ struct ir_raw_event_ctrl {
int state;
unsigned count;
u32 bits;
+ bool is_nec_x;
+ bool necx_repeat;
} nec;
struct rc5_dec {
int state;
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 1c0cf03..d597421 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -26,6 +26,7 @@
#define NEC_BIT_1_SPACE(3 * NEC_UNIT)
#defineNEC_TRAILER_PULSE (1 * NEC_UNIT)
#defineNEC_TRAILER_SPACE (10 * NEC_UNIT) /* even longer in
reality */
+#define NECX_REPEAT_BITS 1
enum nec_state {
STATE_INACTIVE,
@@ -67,8 +68,12 @@ static int ir_nec_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
if (!ev.pulse)
break;
- if (!eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2)
- !eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT / 2))
+ if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2)) {
+ data-is_nec_x = false;
+ data-necx_repeat = false;
+ } else if (eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT /
2))
+ data-is_nec_x = true;
+ else
break;
data-count = 0;
@@ -105,6 +110,17 @@ static int ir_nec_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (ev.pulse)
break;
+ if (data-necx_repeat data-count == NECX_REPEAT_BITS
+ geq_margin(ev.duration,
+ NEC_TRAILER_SPACE, NEC_UNIT / 2)) {
+ IR_dprintk(1, Repeat last key\n);
+ ir_repeat(input_dev);
+ data-state = STATE_INACTIVE;
+ return 0;
+
+ } else if (data-count NECX_REPEAT_BITS)
+ data-necx_repeat = false;
+
data-bits = 1;
if (eq_margin(ev.duration, NEC_BIT_1_SPACE, NEC_UNIT / 2))
data-bits |= 1;
@@ -159,6 +175,9 @@ static int ir_nec_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
IR_dprintk(1, NEC scancode 0x%04x\n, scancode);
}
+ if (data-is_nec_x)
+ data-necx_repeat = true;
+
ir_keydown(input_dev, scancode, 0);
data-state = STATE_INACTIVE;
return 0;
--
1.7.0.4
--
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 11/13] IR: report unknown scancodes the in-kernel decoders found.
This way it is possible to use evtest to create keymap for unknown remote.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-keytable.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 34b9c07..ba7678a 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -339,6 +339,8 @@ void ir_repeat(struct input_dev *dev)
spin_lock_irqsave(ir-keylock, flags);
+ input_event(dev, EV_MSC, MSC_SCAN, ir-last_scancode);
+
if (!ir-keypressed)
goto out;
@@ -370,6 +372,8 @@ void ir_keydown(struct input_dev *dev, int scancode, u8
toggle)
spin_lock_irqsave(ir-keylock, flags);
+ input_event(dev, EV_MSC, MSC_SCAN, scancode);
+
/* Repeat event? */
if (ir-keypressed
ir-last_scancode == scancode
@@ -383,9 +387,11 @@ void ir_keydown(struct input_dev *dev, int scancode, u8
toggle)
ir-last_toggle = toggle;
ir-last_keycode = keycode;
+
if (keycode == KEY_RESERVED)
goto out;
+
/* Register a keypress */
ir-keypressed = true;
IR_dprintk(1, %s: key down event, key 0x%04x, scancode 0x%04x\n,
@@ -480,6 +486,8 @@ int __ir_input_register(struct input_dev *input_dev,
set_bit(EV_KEY, input_dev-evbit);
set_bit(EV_REP, input_dev-evbit);
+ set_bit(EV_MSC, input_dev-evbit);
+ set_bit(MSC_SCAN, input_dev-mscbit);
if (ir_setkeytable(input_dev, ir_dev-rc_tab, rc_tab)) {
rc = -ENOMEM;
--
1.7.0.4
--
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 10/13] IR: extend interfaces to support more device settings
LIRC: add new IOCTL that enables learning mode (wide band receiver)
Still missing features: carrier report timeout reports.
Will need to pack these into ir_raw_event
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
.../DocBook/v4l/lirc_device_interface.xml | 16 +++
drivers/media/IR/ir-core-priv.h|1 +
drivers/media/IR/ir-lirc-codec.c | 112
include/media/ir-core.h| 12 ++-
include/media/lirc.h |5 +-
5 files changed, 125 insertions(+), 21 deletions(-)
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml
b/Documentation/DocBook/v4l/lirc_device_interface.xml
index 0413234..68134c0 100644
--- a/Documentation/DocBook/v4l/lirc_device_interface.xml
+++ b/Documentation/DocBook/v4l/lirc_device_interface.xml
@@ -229,6 +229,22 @@ on working with the default settings initially./para
and LIRC_SETUP_END. Drivers can also choose to ignore these
ioctls./para
/listitem
/varlistentry
+ varlistentry
+termLIRC_SET_WIDEBAND_RECEIVER/term
+listitem
+ paraSome receivers are equipped with special wide band receiver which
is intended
+ to be used to learn output of existing remote.
+ Calling that ioctl with (1) will enable it, and with (0) disable it.
+ This might be useful of receivers that have otherwise narrow band
receiver
+ that prevents them to be used with some remotes.
+ Wide band receiver might also be more precise
+ On the other hand its disadvantage it usually reduced range of reception.
+ Note: wide band receiver might be implictly enabled if you enable
+ carrier reports. In that case it will be disabled as soon as you disable
+ carrier reports. Trying to disable wide band receiver while carrier
+ reports are active will do nothing./para
+/listitem
+ /varlistentry
/variablelist
/section
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 8053e3b..a85a8c7 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -79,6 +79,7 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
+ int carrier_low;
} lirc;
};
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 8ca01fd..77b5946 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -46,7 +46,6 @@ static int ir_lirc_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
TO_US(ev.duration), TO_STR(ev.pulse));
-
sample = ev.duration / 1000;
if (ev.pulse)
sample |= PULSE_BIT;
@@ -96,13 +95,14 @@ out:
return ret;
}
-static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd,
+ unsigned long __user arg)
{
struct lirc_codec *lirc;
struct ir_input_dev *ir_dev;
int ret = 0;
void *drv_data;
- unsigned long val;
+ unsigned long val = 0;
lirc = lirc_get_pdata(filep);
if (!lirc)
@@ -114,47 +114,106 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
drv_data = ir_dev-props-priv;
- switch (cmd) {
- case LIRC_SET_TRANSMITTER_MASK:
+ if (_IOC_DIR(cmd) _IOC_WRITE) {
ret = get_user(val, (unsigned long *)arg);
if (ret)
return ret;
+ }
+
+ switch (cmd) {
+
+ /* legacy support */
+ case LIRC_GET_SEND_MODE:
+ val = LIRC_CAN_SEND_PULSE LIRC_CAN_SEND_MASK;
+ break;
+
+ case LIRC_SET_SEND_MODE:
+ if (val != (LIRC_MODE_PULSE LIRC_CAN_SEND_MASK))
+ return -EINVAL;
+ break;
- if (ir_dev-props ir_dev-props-s_tx_mask)
+ /* TX settings */
+ case LIRC_SET_TRANSMITTER_MASK:
+ if (ir_dev-props-s_tx_mask)
ret = ir_dev-props-s_tx_mask(drv_data, (u32)val);
else
return -EINVAL;
break;
case LIRC_SET_SEND_CARRIER:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
- if (ir_dev-props ir_dev-props-s_tx_carrier)
+ if (ir_dev-props-s_tx_carrier)
ir_dev-props-s_tx_carrier(drv_data, (u32)val);
else
return -EINVAL;
break;
- case LIRC_GET_SEND_MODE:
- val = LIRC_CAN_SEND_PULSE LIRC_CAN_SEND_MASK;
- ret = put_user(val, (unsigned long *)arg);
+ case
[PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
MAINTAINERS |6 +
drivers/media/IR/Kconfig | 14 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ene_ir.c | 595 +
drivers/media/IR/ene_ir.h | 51 ++---
5 files changed, 265 insertions(+), 402 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 56a36d7..587785a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2188,6 +2188,12 @@ F: drivers/misc/cb710/
F: drivers/mmc/host/cb710-mmc.*
F: include/linux/cb710.h
+ENE KB2426 (ENE0100/ENE020XX) INFRARED RECEIVER
+M: Maxim Levitsky maximlevit...@gmail.com
+S: Maintained
+F: drivers/media/IR/ene_ir.c
+F: drivers/media/IR/ene_ir.h
+
EPSON 1355 FRAMEBUFFER DRIVER
M: Christopher Hoover c...@murgatroid.com
M: Christopher Hoover c...@hpl.hp.com
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index fc48a3f..3f62bf9 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -105,4 +105,18 @@ config IR_MCEUSB
To compile this driver as a module, choose M here: the
module will be called mceusb.
+config IR_ENE
+ tristate ENE eHome Receiver/Transciever (pnp id: ENE0100/ENE02xxx)
+ depends on PNP
+ depends on IR_CORE
+ ---help---
+ Say Y here to enable support for integrated infrared receiver
+ /transciever made by ENE.
+
+ You can see if you have it by looking at lspnp output.
+ Output should include ENE0100 ENE0200 or something similiar.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ene_ir.
+
endif #IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..3262a68 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_ENE) += ene_ir.o
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 9d11caf..5447750 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -1,5 +1,5 @@
/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
*
* Copyright (C) 2010 Maxim Levitsky maximlevit...@gmail.com
*
@@ -25,20 +25,20 @@
#include linux/io.h
#include linux/interrupt.h
#include linux/sched.h
-#include linux/uaccess.h
-#include lirc_ene0100.h
+#include linux/slab.h
+#include linux/input.h
+#include media/ir-core.h
+#include media/ir-common.h
+#include ene_ir.h
static int sample_period = -1;
static int enable_idle = 1;
-static int enable_duty_carrier;
static int input = 1;
static int debug;
static int txsim;
-static void ene_rx_set_idle(struct ene_device *dev, int idle);
static int ene_irq_status(struct ene_device *dev);
-static void ene_send_sample(struct ene_device *dev, unsigned long sample);
/* read a hardware register */
static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
@@ -85,6 +85,7 @@ static int ene_hw_detect(struct ene_device *dev)
u8 hw_revision, old_ver;
u8 tmp;
u8 fw_capabilities;
+ int pll_freq;
tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
ene_hw_write_reg(dev, ENE_HW_UNK, tmp ~ENE_HW_UNK_CLR);
@@ -96,6 +97,17 @@ static int ene_hw_detect(struct ene_device *dev)
hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+ pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) 4) +
+ (ene_hw_read_reg(dev, ENE_PLLFRL) 4);
+
+ if (pll_freq != 1000)
+ dev-rx_period_adjust = 4;
+ else
+ dev-rx_period_adjust = 2;
+
+
+ ene_printk(KERN_NOTICE, PLL freq = %d\n, pll_freq);
+
if (hw_revision == 0xFF) {
ene_printk(KERN_WARNING, device seems to be disabled\n);
@@ -160,7 +172,7 @@ static int ene_hw_detect(struct ene_device *dev)
}
/* this enables/disables IR input via gpio40*/
-static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
+static void ene_enable_gpio40_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, enable ?
0 : ENE_CIR_CONF2_GPIO40DIS,
@@ -168,13 +180,13 @@ static void ene_enable_gpio40_recieve(struct ene_device
*dev, int enable)
}
/* this enables/disables IR via standard input */
-static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
+static void ene_enable_normal_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_RX_ON : 0);
}
/* this enables/disables IR input via unused fan tachtometer input */
-static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
+static
[PATCH 09/13] IR: add helper function for hardware with small o/b buffer.
Some ir input devices have small buffer, and interrupt the host
each time it is full (or half full)
Add a helper that automaticly handles timeouts, and also
automaticly merges samples of same time (space-space)
Such samples might be placed by hardware because size of
sample in the buffer is small (a byte for example).
Also remove constness from ir_dev_props, because it now contains timeout
settings that driver might want to change
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
Acked-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 +-
drivers/media/IR/ir-raw-event.c | 84 +++
include/media/ir-core.h | 23 +-
4 files changed, 106 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index be68172..8053e3b 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -41,6 +41,7 @@ struct ir_raw_event_ctrl {
/* raw decoder state follows */
struct ir_raw_event prev_ev;
+ struct ir_raw_event this_ev;
struct nec_dec {
int state;
unsigned count;
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
*/
int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props,
+ struct ir_dev_props *props,
const char *driver_name)
{
struct ir_input_dev *ir_dev;
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index d0c18db..43094e7 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -140,6 +140,90 @@ int ir_raw_event_store_edge(struct input_dev *input_dev,
enum raw_event_type typ
EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
/**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders with
some processing
+ * @input_dev: the struct input_dev device descriptor
+ * @type: the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) works
+ * in similiar manner to ir_raw_event_store_edge.
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+
+ if (!raw || !ir-props)
+ return -EINVAL;
+
+ /* Ignore spaces in idle mode */
+ if (ir-idle !ev-pulse)
+ return 0;
+ else if (ir-idle)
+ ir_raw_event_set_idle(input_dev, 0);
+
+ if (!raw-this_ev.duration) {
+ raw-this_ev = *ev;
+ } else if (ev-pulse == raw-this_ev.pulse) {
+ raw-this_ev.duration += ev-duration;
+ } else {
+ ir_raw_event_store(input_dev, raw-this_ev);
+ raw-this_ev = *ev;
+ }
+
+ /* Enter idle mode if nessesary */
+ if (!ev-pulse ir-props-timeout
+ raw-this_ev.duration = ir-props-timeout)
+ ir_raw_event_set_idle(input_dev, 1);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+ ktime_t now;
+ u64 delta;
+
+ if (!ir-props)
+ return;
+
+ if (!ir-raw)
+ goto out;
+
+ if (idle) {
+ IR_dprintk(2, enter idle mode\n);
+ raw-last_event = ktime_get();
+ } else {
+ IR_dprintk(2, exit idle mode\n);
+
+ now = ktime_get();
+ delta = ktime_to_ns(ktime_sub(now, ir-raw-last_event));
+
+ WARN_ON(raw-this_ev.pulse);
+
+ raw-this_ev.duration =
+ min(raw-this_ev.duration + delta,
+ (u64)IR_MAX_DURATION);
+
+ ir_raw_event_store(input_dev, raw-this_ev);
+
+ if (raw-this_ev.duration == IR_MAX_DURATION)
+ ir_raw_event_reset(input_dev);
+
+ raw-this_ev.duration = 0;
+ }
+out:
+ if (ir-props-s_idle)
+ ir-props-s_idle(ir-props-priv, idle);
+ ir-idle = idle;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_set_idle);
+
+/**
* ir_raw_event_handle() - schedules the decoding of stored ir data
* @input_dev: the
Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote:
I think you won't be able to fix the problem conclusively either way. A
lot of how the chip's clocks should be programmed depends on how the
GPIOs are used and what crystal is used.
I suspect many designers will use some reference design layout from ENE,
but it won't be good in every case. The wire-up of the ENE of various
motherboards is likely something you'll have to live with as unknowns.
This is a case where looser tolerances in the in kernel decoders could
reduce this driver's complexity and/or get rid of arbitrary fudge
factors in the driver.
The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%). The crystals used in electronics are accurate to
0.0001%+. The 4% error in this driver is because the hardware is not
being programmed accurately. This needs to be fixed in the driver and
not in the upper layers.
How is sample period being computed, where is the complete source to
this driver?
dev-tx_period = 32;
Where is sample_period computed?
@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
pulse = !(hw_value ENE_SAMPLE_SPC_MASK);
hw_value = ENE_SAMPLE_VALUE_MASK;
hw_sample = hw_value * sample_period;
+
+ if (dev-rx_period_adjust) {
+ hw_sample *= (100 - dev-rx_period_adjust);
+ hw_sample /= 100;
+ }
}
I suspect sample_period is set to 32us. For 32.768Mhz the period needs
to be 30.5us. I don't see the code for how it was computed.
You have to be careful with rounding errors when doing this type of
computation. What looks like a minor error can amplify into a large
error. Sometimes I do the math in 64b ints just to keep the round off
errors from accumulating. Instead of doing the math in calculator and
plugging in 32. Use #defines and do the math in the code.
Maybe something like
#define sample_period (1 / (32768 * 1000))
Then don't store this constant in a variable since it will cause a
round off. Just use it directly in the computation.
Regards,
Andy
--
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
[PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx - cx23885: prepare the cx23885 makefile for alsa support - cx23885: merge mijhail's header changes for alsa - cx23885: ALSA support - cx23885: core changes requireed for ALSA - cx23885: add definitions for HVR1500 to support audio - cx23885: correct the contrast, saturation and hue controls - cx23885: hooks the alsa changes into the video subsystem - cx23885: convert call clients into subdevices - cx23885: replaced spinlock with mutex - cx23885: minor function renaming to ensure uniformity - cx23885: setup the dma mapping for raw audio support - cx23885: mute the audio during channel change - cx23885: add two additional defines to simplify VBI register bitmap handling - cx23885: initial support for VBI with the cx23885 - cx23885: initialize VBI support in the core, add IRQ support, register vbi device - cx23885: minor printk cleanups and device registration - cx25840: enable raw cc processing only for the cx23885 hardware - cx23885: vbi line window adjustments - cx23885: add vbi buffer formatting, window changes and video core changes - cx23885: Ensure the VBI pixel format is established correctly. - cx23885: convert from snd_card_new() to snd_card_create() - cx23885: ensure video is streaming before allowing vbi to stream - cx23885: vbi related codingstyle cleanups - cx23885: removal of VBI and earlier VBI printk debugging - cx23885: removal of redundant code, this is no longer required. - cx23885: remove channel dump diagnostics when a vbi buffer times out. - cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. - cx23885: coding style violation cleanups - cx23885: Convert a mutex back to a spinlock - cx23885: Name an internal i2c part and declare a bitfield by name - cx25840: Enable support for non-tuner LR1/LR2 audio inputs - cx23885: Allow the audio mux config to be specified on a per input basis. - cx23885: remove a line of debug - cx23885: Enable audio line in support from the back panel - cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. - cx23885: Initial support for the MPX-885 mini-card - cx23885: fixes related to maximum number of inputs and range checking - cx23885: add generic functions for dealing with audio input selection - cx23885: hook the audio selection functions into the main driver - cx23885: v4l2 api compliance, set the audioset field correctly - cx23885: Removed a spurious function cx23885_set_scale(). - cx23885: Avoid stopping the risc engine during buffer timeout. - cx23885: Avoid incorrect error handling and reporting - cx23885: Stop the risc video fifo before reconfiguring it. b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/video/cx23885/Makefile |2 linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- linux/drivers/media/video/cx23885/cx23885-i2c.c|1 linux/drivers/media/video/cx23885/cx23885-reg.h|3 linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ linux/drivers/media/video/cx23885/cx23885.h| 65 + linux/drivers/media/video/cx25840/cx25840-audio.c |9 linux/drivers/media/video/cx25840/cx25840-core.c | 21 13 files changed, 1257 insertions(+), 247 deletions(-) A pretty large patch set which adds a number of important features to the cx23885 driver. Some early patches for the HVR1500 with add support for analog audio (very rough, much rework on these). The University of California sponsored work for the HVR1800 and HVR1850 and raw video and raw audio and VBI support. The Belac Group sponsored changes related to the MPX cx23885 8 input design, adding raw video and audio support. Mencoder now works correctly with the raw video and audio portions of the driver. GStreamer now works correctly using the v4l interfaces from the driver, live video and audio viewing are now possible. NTSC-ZZ-VBI now works correctly for RAW VBI decoding (although TVTime still refuses to work correctly - tvtime bug) Regards, - Steve -- Steven Toth - 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote: I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used. I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns. This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver. The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. The 4% error in this driver is because the hardware is not being programmed accurately. This needs to be fixed in the driver and not in the upper layers. Let me explain again. I get samples in 4 byte buffer. each sample is a count of sample periods. Sample period is programmed into hardware, at 'ENE_CIR_SAMPLE_PERIOD' (it is in us) Default sample period is 50 us. The error source isn't 'electronics' fault. The device is microprocessor. I don't read the samples 'directly' from hardware, but rather from ram of that microprocessor. I don't know how it samples the input. A expiration of sample period might just cause a IRQ inside that microprocessor, and it can't process it instantly. That is probably the source of the delay. Or something like that. Best regards, Maxim Levitsky -- 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote:
On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote:
I think you won't be able to fix the problem conclusively either way. A
lot of how the chip's clocks should be programmed depends on how the
GPIOs are used and what crystal is used.
I suspect many designers will use some reference design layout from ENE,
but it won't be good in every case. The wire-up of the ENE of various
motherboards is likely something you'll have to live with as unknowns.
This is a case where looser tolerances in the in kernel decoders could
reduce this driver's complexity and/or get rid of arbitrary fudge
factors in the driver.
The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%). The crystals used in electronics are accurate to
0.0001%+. The 4% error in this driver is because the hardware is not
being programmed accurately. This needs to be fixed in the driver and
not in the upper layers.
How is sample period being computed, where is the complete source to
this driver?
dev-tx_period = 32;
Where is sample_period computed?
@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
pulse = !(hw_value ENE_SAMPLE_SPC_MASK);
hw_value = ENE_SAMPLE_VALUE_MASK;
hw_sample = hw_value * sample_period;
+
+ if (dev-rx_period_adjust) {
+ hw_sample *= (100 - dev-rx_period_adjust);
+ hw_sample /= 100;
+ }
}
I suspect sample_period is set to 32us. For 32.768Mhz the period needs
to be 30.5us. I don't see the code for how it was computed.
You have to be careful with rounding errors when doing this type of
computation. What looks like a minor error can amplify into a large
error. Sometimes I do the math in 64b ints just to keep the round off
errors from accumulating. Instead of doing the math in calculator and
plugging in 32. Use #defines and do the math in the
There is no reason to worry about rounding here.
hw_sample is maximum of 127 * 50, so when I muliply by 100 I get exact
result.
Then I do one divide.
Best regards,
Maxim Levitsky
--
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] IR keymap: Add print button for HP OEM version of MCE remote
This patch adds a defintion for the Print button found on HP OEM
versions of the MCE remote. All of the other keys found on the HP OEM
version of the remote match the other keys as already defined.
Because, who doesn't need remote printing, while one is sitting on the
couch across from one's PC? ;)
Signed-off-by: Andy Walls awa...@md.metrocast.net
diff --git a/drivers/media/IR/keymaps/rc-rc6-mce.c b/drivers/media/IR/keymaps/rc
index c6726a8..3edda53 100644
--- a/drivers/media/IR/keymaps/rc-rc6-mce.c
+++ b/drivers/media/IR/keymaps/rc-rc6-mce.c
@@ -74,6 +74,8 @@ static struct ir_scancode rc6_mce[] = {
{ 0x800f045a, KEY_SUBTITLE }, /* Caption/Teletext */
{ 0x800f044d, KEY_TITLE },
+ { 0x800f044e, KEY_PRINT }, /* Print - HP OEM version of remote */
+
{ 0x800f040c, KEY_POWER },
{ 0x800f040d, KEY_PROG1 }, /* Windows MCE button */
--
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 13/13] IR: Port ene driver to new IR subsystem and enable it.
Hi Jon, on 31 Jul 10 at 12:25, Jon Smirl wrote: On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote: I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used. I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns. This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver. The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%. I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes. For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22 4%. Christoph -- 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus l...@bartelmus.de wrote: Hi Jon, on 31 Jul 10 at 12:25, Jon Smirl wrote: On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote: I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used. I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns. This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver. The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%. I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes. For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22 4%. There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC. I think he said lirc was misclassifying it too. So we both did the same thing. Christoph -- 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: [PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
On Sat, 2010-07-31 at 12:31 -0400, Steven Toth wrote: Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx - cx23885: prepare the cx23885 makefile for alsa support - cx23885: merge mijhail's header changes for alsa - cx23885: ALSA support - cx23885: core changes requireed for ALSA - cx23885: add definitions for HVR1500 to support audio - cx23885: correct the contrast, saturation and hue controls - cx23885: hooks the alsa changes into the video subsystem - cx23885: convert call clients into subdevices - cx23885: replaced spinlock with mutex - cx23885: minor function renaming to ensure uniformity - cx23885: setup the dma mapping for raw audio support - cx23885: mute the audio during channel change - cx23885: add two additional defines to simplify VBI register bitmap handling - cx23885: initial support for VBI with the cx23885 - cx23885: initialize VBI support in the core, add IRQ support, register vbi device - cx23885: minor printk cleanups and device registration - cx25840: enable raw cc processing only for the cx23885 hardware - cx23885: vbi line window adjustments - cx23885: add vbi buffer formatting, window changes and video core changes - cx23885: Ensure the VBI pixel format is established correctly. - cx23885: convert from snd_card_new() to snd_card_create() - cx23885: ensure video is streaming before allowing vbi to stream - cx23885: vbi related codingstyle cleanups - cx23885: removal of VBI and earlier VBI printk debugging - cx23885: removal of redundant code, this is no longer required. - cx23885: remove channel dump diagnostics when a vbi buffer times out. - cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. - cx23885: coding style violation cleanups - cx23885: Convert a mutex back to a spinlock - cx23885: Name an internal i2c part and declare a bitfield by name - cx25840: Enable support for non-tuner LR1/LR2 audio inputs - cx23885: Allow the audio mux config to be specified on a per input basis. - cx23885: remove a line of debug - cx23885: Enable audio line in support from the back panel - cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. - cx23885: Initial support for the MPX-885 mini-card - cx23885: fixes related to maximum number of inputs and range checking - cx23885: add generic functions for dealing with audio input selection - cx23885: hook the audio selection functions into the main driver - cx23885: v4l2 api compliance, set the audioset field correctly - cx23885: Removed a spurious function cx23885_set_scale(). - cx23885: Avoid stopping the risc engine during buffer timeout. - cx23885: Avoid incorrect error handling and reporting - cx23885: Stop the risc video fifo before reconfiguring it. b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/video/cx23885/Makefile |2 linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- linux/drivers/media/video/cx23885/cx23885-i2c.c|1 linux/drivers/media/video/cx23885/cx23885-reg.h|3 linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ linux/drivers/media/video/cx23885/cx23885.h| 65 + linux/drivers/media/video/cx25840/cx25840-audio.c |9 linux/drivers/media/video/cx25840/cx25840-core.c | 21 13 files changed, 1257 insertions(+), 247 deletions(-) A pretty large patch set which adds a number of important features to the cx23885 driver. I have a few cx25840 related comments: 1. Please don't abuse CX25840_AUDIOn and make it mean something other than its current usage of specifying which input the SIF audio is coming in on. The cx25840 module has enough confusion in it already. Let's not overload the current enumerations. Also the current cx25840 keys off of CX25840_AUDIOn vs CX25840_AUDIO_SERIAL to set up a number of things: sample rate convertors and the Baseband Path 1 routing for the CX23885 family at least. It would be better to add new enumaerated values for CX23885_AUDIO_LR1, or whatever, to achieve your desired audio input configuration tasks. 2. The raw VBI startup you added in the cx25840 module is not going to serve you well. It is true that it is harmless to existing non-CX2388[578] boards. However, any app action that causes cx25840_std_setup() to be called will change register 0x474 to probably something you are not expecting. It would be better for you, in the long run, to fix up cx25840_std_setup() and cx25840_s_raw_fmt() to suit your needs, rather than a one off setting
Re: [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
From: Philipp Wiesner p.wies...@phytec.de
Added this info to Kconfig and mt9m111.c, some comment cleanup,
replaced 'mt9m11x'-statements by clarifications or driver name.
Driver is fully compatible to mt9m131 which has only additional functions
compared to mt9m111. Those aren't used anyway at the moment.
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
---
drivers/media/video/Kconfig |5 +++--
drivers/media/video/mt9m111.c | 37 +++--
2 files changed, 26 insertions(+), 16 deletions(-)
[snip]
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index d35f536..e934559 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
[snip]
@@ -970,21 +976,24 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd,
data = reg_read(CHIP_VERSION);
switch (data) {
- case 0x143a: /* MT9M111 */
+ case 0x143a: /* MT9M111 or MT9M131 */
mt9m111-model = V4L2_IDENT_MT9M111;
+ dev_info(client-dev,
+ Detected a MT9M111/MT9M131 chip ID %x\n, data);
break;
case 0x148c: /* MT9M112 */
mt9m111-model = V4L2_IDENT_MT9M112;
+ dev_info(client-dev, Detected a MT9M112 chip ID %x\n, data);
break;
default:
ret = -ENODEV;
dev_err(client-dev,
- No MT9M11x chip detected, register read %x\n, data);
+ No MT9M111/MT9M112/MT9M131 chip detected,
+ register read %x\n,
Please, join the strings onto one line. Don't worry about 80 characters.
+ data);
goto ei2c;
}
- dev_info(client-dev, Detected a MT9M11x chip ID %x\n, data);
-
ei2c:
return ret;
}
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 02/20] mt9m111: init chip after read CHIP_VERSION
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
Moved mt9m111_init after the chip version detection passage: I
don't like the idea of writing on a device we haven't identified
yet.
In principle it's correct, but what do you do, if a chip cannot be probed,
before it is initialised / enabled? Actually, this shouldn't be the case,
devices should be available for probing without any initialisation. So, we
have to ask the original author, whether this really was necessary,
Robert?
Thanks
Guennadi
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/media/video/mt9m111.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index e934559..39dff7c 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -969,10 +969,6 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd,
mt9m111-swap_rgb_even_odd = 1;
mt9m111-swap_rgb_red_blue = 1;
- ret = mt9m111_init(client);
- if (ret)
- goto ei2c;
-
data = reg_read(CHIP_VERSION);
switch (data) {
@@ -994,6 +990,8 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd,
goto ei2c;
}
+ ret = mt9m111_init(client);
+
ei2c:
return ret;
}
--
1.7.1
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
Michael Grzeschik m.grzesc...@pengutronix.de writes: From: Philipp Wiesner p.wies...@phytec.de Added this info to Kconfig and mt9m111.c, some comment cleanup, replaced 'mt9m11x'-statements by clarifications or driver name. Driver is fully compatible to mt9m131 which has only additional functions compared to mt9m111. Those aren't used anyway at the moment. zip - dev_info(client-dev, Detected a MT9M11x chip ID %x\n, data); - Why this one ? It signals a sensor was successfully detected. Maybe a replacement from MT9M11x to MT9M1xx would be better ? Or if your real intention is to remove the message, then transform it to dev_dbg(), and say why you did it in the commit message. Cheers. -- Robert -- 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 05/20] mt9m111: added default row/col/width/height values
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/media/video/mt9m111.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index aeb2241..5f0c55e 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -133,6 +133,10 @@
#define MT9M111_MIN_DARK_COLS24
#define MT9M111_MAX_HEIGHT 1024
#define MT9M111_MAX_WIDTH1280
+#define MT9M111_DEF_DARK_ROWS12
+#define MT9M111_DEF_DARK_COLS30
+#define MT9M111_DEF_HEIGHT 1024
+#define MT9M111_DEF_WIDTH1280
Don't think this split makes sense. Please, call them DEFAUL: DEF is
too ambiguous, and unite with patch 08/20. In general, you're exaggerating
splitting og patches. Many of them make little sense with this kind of a
split and have to be merged.
/* MT9M111 has only one fixed colorspace per pixelcode */
struct mt9m111_datafmt {
--
1.7.1
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 03/20] mt9m111: register cleanup hex to dec bitoffset
Michael Grzeschik m.grzesc...@pengutronix.de writes: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de OK for me (the formal ack will be once we finish the review). Cheers. -- Robert -- 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
[PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Mauro, Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200 and HVR2250 cards. Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l - saa7164: basic definitions for -encoder.c - saa7164: Add some encoder firmwares message types and structs - saa7164: convert buffering structs to be more generic - saa7164: add various encoder message functions - saa7164: Implement encoder irq handling in a deferred work queue. - saa7164: command dequeue fixup to clean the bus after error. - saa7164: allow the encoder GOP structure to be configured - saa7164: generate a fixed kernel warning if the irq is 'late' - saa7164: add support for encoder CBR and VBR optionally. - saa7164: allow the IBP reference distance to be configurable - saa7164: implement encoder peak bitrate feature - saa7164: allow encoder output format to be user configurable - saa7164: allow variable length GOP sizes and switch encoder default to CBR - saa7164: patches to monitor TS payload for inconsistencies - saa7164: allow the number of encoder buffers to be user configurable - saa7164: measure via histograms various irq and queue latencies - saa7164: add guard bytes around critical buffers to detect failure. - saa7164: buffer crc checks and ensure we use the correct PCIe IO memcpy func - saa7164: adjust the PS pack size handling to fill buffers 100% - saa7164: Implement resolution control firmware command - saa7164: mundane buffer debugging changes to track issues - saa7164: irqhandler cleanup and helper function added - saa7164: code cleanup - saa7164: allow DMA engin buffers to vary in size between analog and digital - saa7164: New firmware changes, new size, new filename - saa7164: Avoid spurious error after firmware starts - saa7164: rename a structure for readability - saa7164: add NTSC VBI support - saa7164: add firmware debug message collection and procfs changes - saa7164: VBI irq cleanup and V4L VBI raw pitch adjustments - saa7164: Monitor the command bus and check for inconsistencies - saa7164: enforce the march 10th firmware is used. - saa7164: collect/show the firmware debugging via a thread - saa7164: monitor the RISC cpu load via a thread - saa7164: video_is_registered() func change - saa7164: change debug to saa_debug - saa7164: Add missing saa7164-vbi.c file. - saa7164: fix vbi compiler warnings - saa7164: if 0/1 cleanups b/linux/drivers/media/video/saa7164/saa7164-encoder.c | 23 b/linux/drivers/media/video/saa7164/saa7164-vbi.c | 1459 ++ linux/drivers/media/video/saa7164/Makefile|4 linux/drivers/media/video/saa7164/saa7164-api.c | 1143 - linux/drivers/media/video/saa7164/saa7164-buffer.c| 204 linux/drivers/media/video/saa7164/saa7164-bus.c | 231 - linux/drivers/media/video/saa7164/saa7164-cards.c | 56 linux/drivers/media/video/saa7164/saa7164-cmd.c | 21 linux/drivers/media/video/saa7164/saa7164-core.c | 2103 ++ linux/drivers/media/video/saa7164/saa7164-dvb.c | 109 linux/drivers/media/video/saa7164/saa7164-encoder.c | 1872 linux/drivers/media/video/saa7164/saa7164-fw.c| 35 linux/drivers/media/video/saa7164/saa7164-i2c.c |2 linux/drivers/media/video/saa7164/saa7164-reg.h | 70 linux/drivers/media/video/saa7164/saa7164-types.h | 183 linux/drivers/media/video/saa7164/saa7164-vbi.c | 53 linux/drivers/media/video/saa7164/saa7164.h | 328 + 17 files changed, 6421 insertions(+), 1475 deletions(-) Regards, -- Steven Toth - 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 04/20] mt9m111: added new bit offset defines
Michael Grzeschik m.grzesc...@pengutronix.de writes: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de OK for me. Cheers. -- Robert -- 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 06/20] mt9m111: changed MAX_{HEIGHT,WIDTH} values to silicon pixelcount
Michael Grzeschik m.grzesc...@pengutronix.de writes: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- drivers/media/video/mt9m111.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 5f0c55e..2080615 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -131,8 +131,8 @@ #define MT9M111_MIN_DARK_ROWS8 #define MT9M111_MIN_DARK_COLS24 -#define MT9M111_MAX_HEIGHT 1024 -#define MT9M111_MAX_WIDTH1280 +#define MT9M111_MAX_HEIGHT 1032 +#define MT9M111_MAX_WIDTH1288 If we're going down that path, my specification says in chapter Pixel Data Format/Pixel Array Structure that there are : - 1289 optical active pixels in width - 1033 optical active pixels in height So why don't we use the real values here ? Cheers. -- Robert -- 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 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 17:53 -0400, Jon Smirl wrote: On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls awa...@md.metrocast.net wrote: On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote: On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus l...@bartelmus.de wrote: Hi Jon, on 31 Jul 10 at 12:25, Jon Smirl wrote: On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls awa...@md.metrocast.net wrote: I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used. I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns. This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver. The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%. I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes. For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22 4%. There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error Hi Jon, Hmmm. Leader marks are, by protocol design, there to give time for the receiver's AGC to settle. We should make it OK to miss somewhat large portions of leader marks. I'm not sure what the harm is in accepting too long of a leader mark, but I'm pretty sure a leader mark that is too long will always be due to systematic error and not noise errors. However, if we know we have systematic errors caused by unknowns, we should be designing and implementing a decoding system that reasonably deals with those systematic errors. Again the part of the system almost completely out of our control is the remote controls, and we *have no control* over systematic errors introduced by remotes. We haven't encountered remotes with systematic errors. If remotes had large errors in them they wouldn't be able to reliably control their target devices. Find a remote that won't work with the protocol engines and a reasonably accurate receiver. Obviously we want to reduce or eliminate systematic errors by determining the unknowns and undoing their effects or by compensating for their overall effect. But in the case of the ENE receiver driver, you didn't seem to like the Maxim's software compensation for the systematic receiver errors. I would be happier if we could track down the source of the error instead of sticking a bandaid on at the end of the process. This isn't a bandaid. Windows driver programs the period to 52 but treats it as a 50. (I don't do that because I set period to 75 - otherwise leading pulse of NEC/JVC is almost missing. I know the reason for that, and it isn't important). and caused the JVC code to be misclassified as NEC. I still have not heard why we need protocol discrimination/classifcation in the kernel. Doing discrimination between two protocols with such close timings is whose requirement again? If we don't do protocol engines we have to revert back to raw recording and having everyone train the system with their remotes. The goal is to eliminate the training step. We would also have to have large files (LIRC configs) for building the keymaps and a new API to deal with them. With the engines the key presses are identified by short strings. A use case: install mythtv, add an IR receiver. Myth UI says to set your universal remote to a Motorola DVR profile. Remote works - no training step needed. LIRC has protocol engines too. irrecord first tries to fit the remote into a protocol engine. If it can't it reverts to raw mode. Let's analyze those cases where lirc ends up in raw mode and see if we can figure out what's going wrong. For example I know of two things that will trip up irrecord that are fixed in the kernel system 1) the ene driver. we know now it had a 4% error in the reported periods No it doesn't It even works if leading large pulse is missing. I would never ever think of doing the adjustments, because lircds tolerance is much better. I am tired of this discussion. My ENE receiver does work now, it gives correct samples, it applies same
[PATCH 1/7] V4L/DVB: Partially revert commit da7251dd0bca6c17571be2bd4434b9779dea72d8
By mistake, changeset da7251dd0bca6c17571be2bd4434b9779dea72d8
reverted the following commits:
commit 6795f9a1ac9e85deb96a49e46b29c809214bf5ea
commit d69861a25a54ef1cd6ee92f5ceb6ff2c01d84803
commit 1ba30538e2d125ce821622ac1f5e7ef31d856077
This patch partially reverts the original commit, to return the
code to its original state.
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 a841e51..c533d8b 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -33,6 +33,21 @@ static struct class ir_input_class = {
.devnode= ir_devnode,
};
+static struct {
+ u64 type;
+ char*name;
+} proto_names[] = {
+ { IR_TYPE_UNKNOWN, unknown },
+ { IR_TYPE_RC5, rc-5 },
+ { IR_TYPE_NEC, nec },
+ { IR_TYPE_RC6, rc-6 },
+ { IR_TYPE_JVC, jvc },
+ { IR_TYPE_SONY, sony },
+ { IR_TYPE_LIRC, lirc },
+};
+
+#define PROTO_NONE none
+
/**
* show_protocols() - shows the current IR protocol(s)
* @d: the device descriptor
@@ -50,6 +65,7 @@ static ssize_t show_protocols(struct device *d,
struct ir_input_dev *ir_dev = dev_get_drvdata(d);
u64 allowed, enabled;
char *tmp = buf;
+ int i;
if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
enabled = ir_dev-rc_tab.ir_type;
@@ -63,35 +79,12 @@ static ssize_t show_protocols(struct device *d,
(long long)allowed,
(long long)enabled);
- if (allowed enabled IR_TYPE_UNKNOWN)
- tmp += sprintf(tmp, [unknown] );
- else if (allowed IR_TYPE_UNKNOWN)
- tmp += sprintf(tmp, unknown );
-
- if (allowed enabled IR_TYPE_RC5)
- tmp += sprintf(tmp, [rc5] );
- else if (allowed IR_TYPE_RC5)
- tmp += sprintf(tmp, rc5 );
-
- if (allowed enabled IR_TYPE_NEC)
- tmp += sprintf(tmp, [nec] );
- else if (allowed IR_TYPE_NEC)
- tmp += sprintf(tmp, nec );
-
- if (allowed enabled IR_TYPE_RC6)
- tmp += sprintf(tmp, [rc6] );
- else if (allowed IR_TYPE_RC6)
- tmp += sprintf(tmp, rc6 );
-
- if (allowed enabled IR_TYPE_JVC)
- tmp += sprintf(tmp, [jvc] );
- else if (allowed IR_TYPE_JVC)
- tmp += sprintf(tmp, jvc );
-
- if (allowed enabled IR_TYPE_SONY)
- tmp += sprintf(tmp, [sony] );
- else if (allowed IR_TYPE_SONY)
- tmp += sprintf(tmp, sony );
+ for (i = 0; i ARRAY_SIZE(proto_names); i++) {
+ if (allowed enabled proto_names[i].type)
+ tmp += sprintf(tmp, [%s] , proto_names[i].name);
+ else if (allowed proto_names[i].type)
+ tmp += sprintf(tmp, %s , proto_names[i].name);
+ }
if (allowed enabled IR_TYPE_LIRC)
tmp += sprintf(tmp, [lirc] );
@@ -116,6 +109,7 @@ static ssize_t show_protocols(struct device *d,
* Writing +proto will add a protocol to the list of enabled protocols.
* Writing -proto will remove a protocol from the list of enabled protocols.
* Writing proto will enable only proto.
+ * Writing none will disable all protocols.
* Returns -EINVAL if an invalid protocol combination or unknown protocol name
* is used, otherwise @len.
*/
@@ -129,67 +123,62 @@ static ssize_t store_protocols(struct device *d,
const char *tmp;
u64 type;
u64 mask;
- int rc;
+ int rc, i, count = 0;
unsigned long flags;
- tmp = skip_spaces(data);
-
- if (*tmp == '+') {
- enable = true;
- disable = false;
- tmp++;
- } else if (*tmp == '-') {
- enable = false;
- disable = true;
- tmp++;
- } else {
- enable = false;
- disable = false;
- }
-
- if (!strncasecmp(tmp, unknown, 7)) {
- tmp += 7;
- mask = IR_TYPE_UNKNOWN;
- } else if (!strncasecmp(tmp, rc5, 3)) {
- tmp += 3;
- mask = IR_TYPE_RC5;
- } else if (!strncasecmp(tmp, nec, 3)) {
- tmp += 3;
- mask = IR_TYPE_NEC;
- } else if (!strncasecmp(tmp, rc6, 3)) {
- tmp += 3;
- mask = IR_TYPE_RC6;
- } else if (!strncasecmp(tmp, jvc, 3)) {
- tmp += 3;
- mask = IR_TYPE_JVC;
- } else if (!strncasecmp(tmp, sony, 4)) {
- tmp += 4;
- mask = IR_TYPE_SONY;
- } else if (!strncasecmp(tmp, lirc, 4)) {
- tmp += 4;
- mask = IR_TYPE_LIRC;
- } else {
- IR_dprintk(1, Unknown
[PATCH 2/7] V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key
dvb-usb has its own IR handle code. Now that we have a Remote
Controller subsystem, we should start using it. So, remove this
struct, in favor of the similar struct defined at the RC subsystem.
This is a big, but trivial patch. It is a 3 line delect, plus
lots of rename on several dvb-usb files.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index b6cbb1d..5580383 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -37,7 +37,7 @@ static int a800_identify_state(struct usb_device *udev,
struct dvb_usb_device_pr
return 0;
}
-static struct dvb_usb_rc_key ir_codes_a800_table[] = {
+static struct ir_scancode ir_codes_a800_table[] = {
{ 0x0201, KEY_PROG1 }, /* SOURCE */
{ 0x0200, KEY_POWER }, /* POWER */
{ 0x0205, KEY_1 }, /* 1 */
diff --git a/drivers/media/dvb/dvb-usb/af9005-remote.c
b/drivers/media/dvb/dvb-usb/af9005-remote.c
index b41fa87..696207f 100644
--- a/drivers/media/dvb/dvb-usb/af9005-remote.c
+++ b/drivers/media/dvb/dvb-usb/af9005-remote.c
@@ -33,7 +33,7 @@ MODULE_PARM_DESC(debug,
#define deb_decode(args...) dprintk(dvb_usb_af9005_remote_debug,0x01,args)
-struct dvb_usb_rc_key ir_codes_af9005_table[] = {
+struct ir_scancode ir_codes_af9005_table[] = {
{0x01b7, KEY_POWER},
{0x01a7, KEY_VOLUMEUP},
@@ -133,7 +133,7 @@ int af9005_rc_decode(struct dvb_usb_device *d, u8 * data,
int len, u32 * event,
for (i = 0; i ir_codes_af9005_table_size; i++) {
if (rc5_custom(ir_codes_af9005_table[i]) ==
cust
rc5_data(ir_codes_af9005_table[i]) ==
dat) {
- *event = ir_codes_af9005_table[i].event;
+ *event =
ir_codes_af9005_table[i].keycode;
*state = REMOTE_KEY_PRESSED;
deb_decode
(key pressed, event %x\n, *event);
diff --git a/drivers/media/dvb/dvb-usb/af9005.h
b/drivers/media/dvb/dvb-usb/af9005.h
index 088e708..3c1fbd1 100644
--- a/drivers/media/dvb/dvb-usb/af9005.h
+++ b/drivers/media/dvb/dvb-usb/af9005.h
@@ -3490,7 +3490,7 @@ extern u8 regmask[8];
/* remote control decoder */
extern int af9005_rc_decode(struct dvb_usb_device *d, u8 * data, int len,
u32 * event, int *state);
-extern struct dvb_usb_rc_key ir_codes_af9005_table[];
+extern struct ir_scancode ir_codes_af9005_table[];
extern int ir_codes_af9005_table_size;
#endif
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 2fb24c3..c63134c 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -735,7 +735,7 @@ error:
struct af9015_setup {
unsigned int id;
- struct dvb_usb_rc_key *rc_key_map;
+ struct ir_scancode *rc_key_map;
unsigned int rc_key_map_size;
u8 *ir_table;
unsigned int ir_table_size;
@@ -1063,7 +1063,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
{
u8 buf[8];
struct req_t req = {GET_IR_CODE, 0, 0, 0, 0, sizeof(buf), buf};
- struct dvb_usb_rc_key *keymap = d-props.rc_key_map;
+ struct ir_scancode *keymap = d-props.rc_key_map;
int i, ret;
memset(buf, 0, sizeof(buf));
@@ -1078,7 +1078,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
for (i = 0; i d-props.rc_key_map_size; i++) {
if (!buf[1] rc5_custom(keymap[i]) == buf[0]
rc5_data(keymap[i]) == buf[2]) {
- *event = keymap[i].event;
+ *event = keymap[i].keycode;
*state = REMOTE_KEY_PRESSED;
break;
}
diff --git a/drivers/media/dvb/dvb-usb/af9015.h
b/drivers/media/dvb/dvb-usb/af9015.h
index 63b2a49..c8e9349 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -123,7 +123,7 @@ enum af9015_remote {
/* LeadTek - Y04G0051 */
/* Leadtek WinFast DTV Dongle Gold */
-static struct dvb_usb_rc_key ir_codes_af9015_table_leadtek[] = {
+static struct ir_scancode ir_codes_af9015_table_leadtek[] = {
{ 0x001e, KEY_1 },
{ 0x001f, KEY_2 },
{ 0x0020, KEY_3 },
@@ -227,7 +227,7 @@ static u8 af9015_ir_table_leadtek[] = {
};
/* TwinHan AzureWave AD-TU700(704J) */
-static struct dvb_usb_rc_key ir_codes_af9015_table_twinhan[] = {
+static struct ir_scancode ir_codes_af9015_table_twinhan[] = {
{ 0x053f, KEY_POWER },
{ 0x0019, KEY_FAVORITES },/* Favorite List */
{ 0x0004, KEY_TEXT }, /* Teletext */
@@ -338,7 +338,7 @@ static u8 af9015_ir_table_twinhan[] = {
};
/* A-Link DTU(m) */
-static struct
[PATCH 3/7] V4L/DVB: dvb-usb: prepare drivers for using rc-core
This is a big patch, yet trivial. It just move the RC properties
to a separate struct, in order to prepare the dvb-usb drivers to
use rc-core. There's no change on the behavior of the drivers.
With this change, it is possible to have both legacy and rc-core
based code inside the dvb-usb-remote, allowing a gradual migration
to rc-core, driver per driver.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index 5580383..a5c3637 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -146,10 +146,12 @@ static struct dvb_usb_device_properties a800_properties =
{
.power_ctrl = a800_power_ctrl,
.identify_state = a800_identify_state,
- .rc_interval = DEFAULT_RC_INTERVAL,
- .rc_key_map = ir_codes_a800_table,
- .rc_key_map_size = ARRAY_SIZE(ir_codes_a800_table),
- .rc_query = a800_rc_query,
+ .rc.legacy = {
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_key_map = ir_codes_a800_table,
+ .rc_key_map_size = ARRAY_SIZE(ir_codes_a800_table),
+ .rc_query = a800_rc_query,
+ },
.i2c_algo = dibusb_i2c_algo,
diff --git a/drivers/media/dvb/dvb-usb/af9005.c
b/drivers/media/dvb/dvb-usb/af9005.c
index 9856463..8ecba88 100644
--- a/drivers/media/dvb/dvb-usb/af9005.c
+++ b/drivers/media/dvb/dvb-usb/af9005.c
@@ -1025,10 +1025,12 @@ static struct dvb_usb_device_properties
af9005_properties = {
.i2c_algo = af9005_i2c_algo,
- .rc_interval = 200,
- .rc_key_map = NULL,
- .rc_key_map_size = 0,
- .rc_query = af9005_rc_query,
+ .rc.legacy = {
+ .rc_interval = 200,
+ .rc_key_map = NULL,
+ .rc_key_map_size = 0,
+ .rc_query = af9005_rc_query,
+ },
.generic_bulk_ctrl_endpoint = 2,
.generic_bulk_ctrl_endpoint_response = 1,
@@ -1072,10 +1074,10 @@ static int __init af9005_usb_module_init(void)
rc_keys_size = symbol_request(ir_codes_af9005_table_size);
if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) {
err(af9005_rc_decode function not found, disabling remote);
- af9005_properties.rc_query = NULL;
+ af9005_properties.rc.legacy.rc_query = NULL;
} else {
- af9005_properties.rc_key_map = rc_keys;
- af9005_properties.rc_key_map_size = *rc_keys_size;
+ af9005_properties.rc.legacy.rc_key_map = rc_keys;
+ af9005_properties.rc.legacy.rc_key_map_size = *rc_keys_size;
}
return 0;
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index c63134c..ea1ed3b 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -847,8 +847,8 @@ static void af9015_set_remote_config(struct usb_device
*udev,
}
if (table) {
- props-rc_key_map = table-rc_key_map;
- props-rc_key_map_size = table-rc_key_map_size;
+ props-rc.legacy.rc_key_map = table-rc_key_map;
+ props-rc.legacy.rc_key_map_size = table-rc_key_map_size;
af9015_config.ir_table = table-ir_table;
af9015_config.ir_table_size = table-ir_table_size;
}
@@ -878,8 +878,8 @@ static int af9015_read_config(struct usb_device *udev)
deb_info(%s: IR mode:%d\n, __func__, val);
for (i = 0; i af9015_properties_count; i++) {
if (val == AF9015_IR_MODE_DISABLED) {
- af9015_properties[i].rc_key_map = NULL;
- af9015_properties[i].rc_key_map_size = 0;
+ af9015_properties[i].rc.legacy.rc_key_map = NULL;
+ af9015_properties[i].rc.legacy.rc_key_map_size = 0;
} else
af9015_set_remote_config(udev, af9015_properties[i]);
}
@@ -1063,7 +1063,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
{
u8 buf[8];
struct req_t req = {GET_IR_CODE, 0, 0, 0, 0, sizeof(buf), buf};
- struct ir_scancode *keymap = d-props.rc_key_map;
+ struct ir_scancode *keymap = d-props.rc.legacy.rc_key_map;
int i, ret;
memset(buf, 0, sizeof(buf));
@@ -1075,7 +1075,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
*event = 0;
*state = REMOTE_NO_KEY_PRESSED;
- for (i = 0; i d-props.rc_key_map_size; i++) {
+ for (i = 0; i d-props.rc.legacy.rc_key_map_size; i++) {
if (!buf[1] rc5_custom(keymap[i]) == buf[0]
rc5_data(keymap[i]) == buf[2]) {
*event = keymap[i].keycode;
@@ -1354,8 +1354,10 @@ static struct dvb_usb_device_properties
af9015_properties[] = {
[PATCH 4/7] V4L/DVB: dvb-usb: add support for rc-core mode
Allows dvb-usb drivers to use rc-core, instead of the legacy
implementation.
No driver were ported yet to rc-core, so, some small adjustments
may be needed, when starting to migrate the drivers.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
index 7951076..b579fed 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
@@ -8,7 +8,7 @@
#include dvb-usb-common.h
#include linux/usb/input.h
-static int dvb_usb_getkeycode(struct input_dev *dev,
+static int legacy_dvb_usb_getkeycode(struct input_dev *dev,
unsigned int scancode, unsigned int *keycode)
{
struct dvb_usb_device *d = input_get_drvdata(dev);
@@ -25,7 +25,7 @@ static int dvb_usb_getkeycode(struct input_dev *dev,
/*
* If is there extra space, returns KEY_RESERVED,
-* otherwise, input core won't let dvb_usb_setkeycode
+* otherwise, input core won't let legacy_dvb_usb_setkeycode
* to work
*/
for (i = 0; i d-props.rc.legacy.rc_key_map_size; i++)
@@ -38,7 +38,7 @@ static int dvb_usb_getkeycode(struct input_dev *dev,
return -EINVAL;
}
-static int dvb_usb_setkeycode(struct input_dev *dev,
+static int legacy_dvb_usb_setkeycode(struct input_dev *dev,
unsigned int scancode, unsigned int keycode)
{
struct dvb_usb_device *d = input_get_drvdata(dev);
@@ -78,7 +78,7 @@ static int dvb_usb_setkeycode(struct input_dev *dev,
*
* TODO: Fix the repeat rate of the input device.
*/
-static void dvb_usb_read_remote_control(struct work_struct *work)
+static void legacy_dvb_usb_read_remote_control(struct work_struct *work)
{
struct dvb_usb_device *d =
container_of(work, struct dvb_usb_device, rc_query_work.work);
@@ -154,15 +154,114 @@ schedule:
schedule_delayed_work(d-rc_query_work,msecs_to_jiffies(d-props.rc.legacy.rc_interval));
}
+static int legacy_dvb_usb_remote_init(struct dvb_usb_device *d,
+ struct input_dev *input_dev)
+{
+ int i, err, rc_interval;
+
+ input_dev-getkeycode = legacy_dvb_usb_getkeycode;
+ input_dev-setkeycode = legacy_dvb_usb_setkeycode;
+
+ /* set the bits for the keys */
+ deb_rc(key map size: %d\n, d-props.rc.legacy.rc_key_map_size);
+ for (i = 0; i d-props.rc.legacy.rc_key_map_size; i++) {
+ deb_rc(setting bit for event %d item %d\n,
+ d-props.rc.legacy.rc_key_map[i].keycode, i);
+ set_bit(d-props.rc.legacy.rc_key_map[i].keycode,
input_dev-keybit);
+ }
+
+ /* setting these two values to non-zero, we have to manage key repeats
*/
+ input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval;
+ input_dev-rep[REP_DELAY] = d-props.rc.legacy.rc_interval + 150;
+
+ input_set_drvdata(input_dev, d);
+
+ err = input_register_device(input_dev);
+ if (err)
+ input_free_device(input_dev);
+
+ rc_interval = d-props.rc.legacy.rc_interval;
+
+ INIT_DELAYED_WORK(d-rc_query_work,
legacy_dvb_usb_read_remote_control);
+
+ info(schedule remote query interval to %d msecs., rc_interval);
+ schedule_delayed_work(d-rc_query_work,
+ msecs_to_jiffies(rc_interval));
+
+ d-state |= DVB_USB_STATE_REMOTE;
+
+ return err;
+}
+
+/* Remote-control poll function - called every dib-rc_query_interval ms to see
+ * whether the remote control has received anything.
+ *
+ * TODO: Fix the repeat rate of the input device.
+ */
+static void dvb_usb_read_remote_control(struct work_struct *work)
+{
+ struct dvb_usb_device *d =
+ container_of(work, struct dvb_usb_device, rc_query_work.work);
+ int err;
+
+ /* TODO: need a lock here. We can simply skip checking for the remote
control
+ if we're busy. */
+
+ /* when the parameter has been set to 1 via sysfs while the
+* driver was running, or when bulk mode is enabled after IR init
+*/
+ if (dvb_usb_disable_rc_polling || d-props.rc.core.bulk_mode)
+ return;
+
+ err = d-props.rc.core.rc_query(d);
+ if (err)
+ err(error %d while querying for an remote control event.,
err);
+
+ schedule_delayed_work(d-rc_query_work,
+ msecs_to_jiffies(d-props.rc.core.rc_interval));
+}
+
+static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d,
+ struct input_dev *input_dev)
+{
+ int err, rc_interval;
+
+ d-props.rc.core.rc_props.priv = d;
+ err = ir_input_register(input_dev,
+d-props.rc.core.rc_codes,
+d-props.rc.core.rc_props,
+d-props.rc.core.module_name);
+
[PATCH 5/7] V4L/DVB: Add a keymap file with dib0700 table
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
create mode 100644 drivers/media/IR/keymaps/rc-dib0700-big.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..85330d1 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-budget-ci-old.o \
rc-cinergy-1400.o \
rc-cinergy.o \
+ rc-dib0700-big.o \
rc-dm1105-nec.o \
rc-dntv-live-dvb-t.o \
rc-dntv-live-dvbt-pro.o \
diff --git a/drivers/media/IR/keymaps/rc-dib0700-big.c
b/drivers/media/IR/keymaps/rc-dib0700-big.c
new file mode 100644
index 000..2e83820
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-dib0700-big.c
@@ -0,0 +1,314 @@
+/* rc-dvb0700-big.c - Keytable for devices in dvb0700
+ *
+ * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.com
+ *
+ * TODO: This table is a real mess, as it merges RC codes from several
+ * devices into a big table. It also has both RC-5 and NEC codes inside.
+ * It should be broken into small tables, and the protocols should properly
+ * be indentificated.
+ *
+ * The table were imported from dib0700_devices.c.
+ *
+ * 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
+
+static struct ir_scancode dib0700_table[] = {
+ /* Key codes for the tiny Pinnacle remote*/
+ { 0x0700, KEY_MUTE },
+ { 0x0701, KEY_MENU }, /* Pinnacle logo */
+ { 0x0739, KEY_POWER },
+ { 0x0703, KEY_VOLUMEUP },
+ { 0x0709, KEY_VOLUMEDOWN },
+ { 0x0706, KEY_CHANNELUP },
+ { 0x070c, KEY_CHANNELDOWN },
+ { 0x070f, KEY_1 },
+ { 0x0715, KEY_2 },
+ { 0x0710, KEY_3 },
+ { 0x0718, KEY_4 },
+ { 0x071b, KEY_5 },
+ { 0x071e, KEY_6 },
+ { 0x0711, KEY_7 },
+ { 0x0721, KEY_8 },
+ { 0x0712, KEY_9 },
+ { 0x0727, KEY_0 },
+ { 0x0724, KEY_SCREEN }, /* 'Square' key */
+ { 0x072a, KEY_TEXT }, /* 'T' key */
+ { 0x072d, KEY_REWIND },
+ { 0x0730, KEY_PLAY },
+ { 0x0733, KEY_FASTFORWARD },
+ { 0x0736, KEY_RECORD },
+ { 0x073c, KEY_STOP },
+ { 0x073f, KEY_CANCEL }, /* '?' key */
+ /* Key codes for the Terratec Cinergy DT XS Diversity, similar to
cinergyT2.c */
+ { 0xeb01, KEY_POWER },
+ { 0xeb02, KEY_1 },
+ { 0xeb03, KEY_2 },
+ { 0xeb04, KEY_3 },
+ { 0xeb05, KEY_4 },
+ { 0xeb06, KEY_5 },
+ { 0xeb07, KEY_6 },
+ { 0xeb08, KEY_7 },
+ { 0xeb09, KEY_8 },
+ { 0xeb0a, KEY_9 },
+ { 0xeb0b, KEY_VIDEO },
+ { 0xeb0c, KEY_0 },
+ { 0xeb0d, KEY_REFRESH },
+ { 0xeb0f, KEY_EPG },
+ { 0xeb10, KEY_UP },
+ { 0xeb11, KEY_LEFT },
+ { 0xeb12, KEY_OK },
+ { 0xeb13, KEY_RIGHT },
+ { 0xeb14, KEY_DOWN },
+ { 0xeb16, KEY_INFO },
+ { 0xeb17, KEY_RED },
+ { 0xeb18, KEY_GREEN },
+ { 0xeb19, KEY_YELLOW },
+ { 0xeb1a, KEY_BLUE },
+ { 0xeb1b, KEY_CHANNELUP },
+ { 0xeb1c, KEY_VOLUMEUP },
+ { 0xeb1d, KEY_MUTE },
+ { 0xeb1e, KEY_VOLUMEDOWN },
+ { 0xeb1f, KEY_CHANNELDOWN },
+ { 0xeb40, KEY_PAUSE },
+ { 0xeb41, KEY_HOME },
+ { 0xeb42, KEY_MENU }, /* DVD Menu */
+ { 0xeb43, KEY_SUBTITLE },
+ { 0xeb44, KEY_TEXT }, /* Teletext */
+ { 0xeb45, KEY_DELETE },
+ { 0xeb46, KEY_TV },
+ { 0xeb47, KEY_DVD },
+ { 0xeb48, KEY_STOP },
+ { 0xeb49, KEY_VIDEO },
+ { 0xeb4a, KEY_AUDIO }, /* Music */
+ { 0xeb4b, KEY_SCREEN }, /* Pic */
+ { 0xeb4c, KEY_PLAY },
+ { 0xeb4d, KEY_BACK },
+ { 0xeb4e, KEY_REWIND },
+ { 0xeb4f, KEY_FASTFORWARD },
+ { 0xeb54, KEY_PREVIOUS },
+ { 0xeb58, KEY_RECORD },
+ { 0xeb5c, KEY_NEXT },
+
+ /* Key codes for the Haupauge WinTV Nova-TD, copied from nova-t-usb2.c
(Nova-T USB2) */
+ { 0x1e00, KEY_0 },
+ { 0x1e01, KEY_1 },
+ { 0x1e02, KEY_2 },
+ { 0x1e03, KEY_3 },
+ { 0x1e04, KEY_4 },
+ { 0x1e05, KEY_5 },
+ { 0x1e06, KEY_6 },
+ { 0x1e07, KEY_7 },
+ { 0x1e08, KEY_8 },
+ { 0x1e09, KEY_9 },
+ { 0x1e0a, KEY_KPASTERISK },
+ { 0x1e0b, KEY_RED },
+ { 0x1e0c, KEY_RADIO },
+ { 0x1e0d, KEY_MENU },
+ { 0x1e0e, KEY_GRAVE }, /* # */
+ { 0x1e0f, KEY_MUTE },
+ { 0x1e10, KEY_VOLUMEUP },
+ { 0x1e11, KEY_VOLUMEDOWN },
+ { 0x1e12, KEY_CHANNEL },
+ { 0x1e14, KEY_UP },
+ { 0x1e15, KEY_DOWN },
+ { 0x1e16, KEY_LEFT },
+ { 0x1e17, KEY_RIGHT },
+ { 0x1e18, KEY_VIDEO },
+ {
