Hi Mauro,
on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
>> because I'm not familiar at all with input layer toolset.
[...]
> I hope it helps for you to better understand how this
Hi Jon,
on 27 Nov 09 at 00:06, Jon Smirl wrote:
[...]
> code for the fun of it, I have no commercial interest in IR. I was
> annoyed with how LIRC handled Sony remotes on my home system.
Can you elaborate on this?
I'm not aware of any issue with Sony remotes.
Christoph
--
To unsubscribe from thi
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following:
- radio: add trivial checks on the tuner and type args.
Thanks,
Hans
diffstat:
radio-aimslab.c|4
radio-aztech.c |4
radio-gemtek-pci.c |4
radio-maestro.c|
Jarod Wilson wrote:
> On 11/26/2009 08:34 PM, Jon Smirl wrote:
>> Raw mode. There are three sysfs attributes - ir_raw, ir_carrier,
>> ir_xmitter. Read from ir_raw to get the raw timing data from the IR
>> device. Set carrier and active xmitters and then copy raw data to
>> ir_raw to send. These att
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
wrote:
>> In the code I posted there is one evdev device for each configured
>> remote. Mapped single keycodes are presented on these devices for each
>> IR burst. There is no device for the IR receiver. A LIRC type process
>> could watch these de
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson wrote:
> >> No, at present we expect 1:1 button->event mapping leaving macro
> >> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
> >> userspace).
> >
> > Hm. So ctrl-x, alt-ta
On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote:
> On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
>> On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>>>
On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wr
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
>> Raw mode. There are three sysfs attributes - ir_raw, ir_carrier,
>> ir_xmitter. Read from ir_raw to get the raw timing data from the IR
>> device. Set carrier and active xmitters and then copy raw data to
>> ir_raw to send. These attributes
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
> This part... Not so wild about. The common thought I'm seeing from people is
> that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> this could be abstracted away so the user never sees it, but it seems to be
> reinven
First up, thank you for reposting this. I believe several of us were
keeping this code in mind for the in-kernel decoding portion of this
discussion, but it hadn't been stated outright in the recent threads here.
On 11/26/2009 08:34 PM, Jon Smirl wrote:
This is a repost of the LIRC input patch
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson wrote:
>> No, at present we expect 1:1 button->event mapping leaving macro
>> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
>> userspace).
>
> Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
> Bummer.
That is
Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho:
> On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> > >> See above. Also, several protocols have a way to check if a keystroke
> > >> were
> > >> properly received. When handling just one protocol, we can use this to
> > >> doubl
On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
On Mon, Nov 23, 2009
Dmitry Torokhov wrote:
> On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry,
>>
>> While lirc is basically a series of input drivers, considering that they
>> have lots
>> in common with the input drivers at V4L/DVB and that we'll need to work on
>> some glue to merge
---
arch/powerpc/boot/dts/dspeak01.dts | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/dspeak01.dts
b/arch/powerpc/boot/dts/dspeak01.dts
index 429bb2f..50cc247 100644
--- a/arch/powerpc/boot/dts/dspeak01.dts
+++ b/arch/powerpc/boo
USB device commonly found on Microsoft Media Center boxes.
Hardware can send and recieve at all common IR frequencies - 36K, 38K, 40K, 56K
---
drivers/input/ir/Kconfig |6
drivers/input/ir/Makefile |1
drivers/input/ir/ir-mceusb2.c | 745 +++
GPT is a GPIO pin that is cable able of measuring the lenght of pulses.
GPTs are common on embedded systems
---
drivers/input/ir/Kconfig |6 +
drivers/input/ir/Makefile |3 +
drivers/input/ir/ir-gpt.c | 184 +
3 files changed, 193 insertions(+)
Now uses configfs to build mappings from remote buttons to key strokes. When
ir-core loads it creates /config/remotes. Make a directory for each remote you
have; this will cause a new input devices to be created. Inside these
directories make a directory for each key on the remote. In the key di
Changes to core input subsystem to allow send and receive of IR messages.
Encode and decode state machines are provided for common IR porotocols such as
Sony, JVC, NEC, Philips, etc.
Received IR messages generate event in the input queue.
IR messages are sent using an input IOCTL.
---
drivers/i
Minimal changes to the core input system. The bulk of IR support loads as a
module. These changes are passive if the rest of IR isn't loaded.
Jon Smirl
---
drivers/input/input.c | 17 +
include/linux/input.h | 75 +++
include/l
This is a repost of the LIRC input patch series I wrote a year ago.
Many of the ideas being discussed in the currect "Should we create a
raw input interface for IR's?" thread have already been implemented
in this code.
---
All of this kernel code i
Trent Piepho writes:
> Then you use the protocol that fits best. For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode. Clearly then the latter is
> most likely to be correct.
Right.
> It also
Dmitry Torokhov writes:
> There is nothing in input layer that precludes you from creating
> multiple input devices per *whatever*.
Of course. I though it was obvious I mean present situation with the
media drivers but I can see now it was far from being obvious.
--
Krzysztof Halasa
--
To unsub
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > Why do you want to replace everything into a single shot?
>
> Why not? It seems simpler to me. We need to change this anyway.
ioctls with a variable argument length are a pain for 32 bit
emulation
Dmitry Torokhov writes:
> There are binary sysfs attributes.
Aren't they to be used for things like ROMs and EEPROMs exclusively?
> For ioctl you also need to open and
> close the device.
Sure, but I do it once.
> Plus, how often do you expect to perform this
> operation? Don't you think you
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> >> One remote per
> >> device only.
> >
> > Why would you want more? One physical device usually corresponds to a
> > logical device. If you have 2 remotes create 2 devices.
>
> I meant "per receiver
Mauro Carvalho Chehab writes:
> Why do you want to replace everything into a single shot?
Why not? It seems simpler to me. We need to change this anyway.
If we change the whole table in a single ioctl, we can easily enumerate
protocols requested and enable then selectively.
But I think it's a m
Dmitry Torokhov writes:
>> One remote per
>> device only.
>
> Why would you want more? One physical device usually corresponds to a
> logical device. If you have 2 remotes create 2 devices.
I meant "per receiver device".
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsub
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>
> Dmitry,
>
> While lirc is basically a series of input drivers, considering that they have
> lots
> in common with the input drivers at V4L/DVB and that we'll need to work on
> some glue to merge both, do you mind if I add
On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote:
>
> (1) ir code (say rc5) -> keycode conversion looses information.
>
> I think this can easily be addressed by adding a IR event type to the
> input layer, which could look like this:
>
> input_event->type = EV_IR
> input_event-
>> Hi Rob
>>
>> would you mind very much posting a patch that implements these two
>> reversions,
>> so I can try it easily? My hg-fu is somewhat lacking...
>> I have the same hardware and noticed what I think is the same issue,
>> just with Channel 9.
>> Another manifestation is huge BER and nonze
On Thu, Nov 26, 2009 at 07:40:01PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> > Why would sysfs write be slower than ioctl?
>
> Sysfs is generally one-value, one-file. open, read/write, close.
> ioctl() OTOH does everything (e.g. a whole key table) in one syscall.
There are bi
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>
> > On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
> >> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
> >>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Hal
On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the who
On Thu, Nov 26, 2009 at 07:05:01PM -0200, Mauro Carvalho Chehab wrote:
>
> For example, the two ioctls to replace a scancode x key code are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> >> that support only pulse/space raw mode and devices that generate scan
> >> codes via the raw mode interface. It does it by generating artificial
> >> pulse codes.
>
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> See above. Also, several protocols have a way to check if a keystroke were
> >> properly received. When handling just one protocol, we can use this to
> >> double
> >> check the key. However, on a multiprotocol mode, we'll need to disable this
On Thursday 26 November 2009 22:37:12 Hans Verkuil wrote:
> This message is generated daily by a cron job that builds v4l-dvb for
> the kernels and architectures in the list below.
>
> Results of the daily build of v4l-dvb:
>
> date:Thu Nov 26 20:48:58 CET 2009
> path:http://www.l
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
>> Christoph Bartelmus wrote:
> [...]
lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the whole table I think), and we can
> have arbitr
Hi Mauro,
on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>>> that support only pulse/space raw mode and devices that generate scan
>>> codes via the raw mode interface. It does it
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa wrote:
Dmitry Torokhov writes:
In what way the key interface is unsufficient for delivering button
events?
At present: 128 different keys only (RC5: one group).
Where did this limitation come from? We have more than 256 keycodes
already _de
On Thursday 26 November 2009 21:04:25 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides the implementation of the TVP7002 decoder
> driver for DM365. Implemented using the V4L2 DV presets API.
> Removed shadow register values. Testing shows that the device
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Thu Nov 26 20:48:58 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13527:b3695bd384cc
gcc version: gcc (
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>>
>> After having it for a while, we should deprecate the in-kernel keyma
Mauro Carvalho Chehab writes:
> No. All the other API functions there work with 32 bits for scancodes.
We don't need them, do we? We need a new ioctl for changing key mappings
anyway (a single ioctl for setting the whole table I think), and we can
have arbitrary length of scan codes there.
> (w
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> see include/linux/input.h:
>>
>> struct input_event {
>> struct timeval time;
>> __u16 type;
>> __u16 code;
>> __s32 value;
>> };
>>
>> extending the value to more than 32 bits require some changes at the
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
> [...]
>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>> that support only pulse/space raw mode and devices that generate scan
>> codes via the raw mode interface. It does
Hi Mauro,
on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
[...]
> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> that support only pulse/space raw mode and devices that generate scan
> codes via the raw mode interface. It does it by generating artificial
> pulse co
Mauro Carvalho Chehab writes:
> see include/linux/input.h:
>
> struct input_event {
> struct timeval time;
> __u16 type;
> __u16 code;
> __s32 value;
> };
>
> extending the value to more than 32 bits require some changes at the
> input layer, probably breaking kern
Mauro Carvalho Chehab writes:
> The removal of the existing keymaps from kernel depends on having an
> application
> to be called from udev to load the proper keymaps when a device is probed.
>
> After having it for a while, we should deprecate the in-kernel keymaps
> and move them to userspace.
From: Santiago Nunez-Corrales
This patch provides menu configuration options for the TVP7002
decoder driver in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/Kconfig | 41 +
drivers/media/video/Makefile |3 +++
2 files chang
From: Santiago Nunez-Corrales
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Signed-off-by: Santiag
From: Santiago Nunez-Corrales
This patch provides the required definitions for the TVP7002 driver
in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002_reg.h | 150 +
include/media/tvp7002.h | 57 ++
2 file
This series of patches provide support for the TVP7002 decoder in DM365.
Support includes:
* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support
This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidha
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/
This series of patches provide support for the TVP7002 decoder in DM365.
Support includes:
* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support
This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidha
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Thu Nov 26 19:00:02 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13520:74ad936bcca2
gcc version: gcc (
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Andy Walls writes:
> >
> >> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >> developed by Philips, but Microsoft has some sort of licensing interest
> >> in it and it is almost sur
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The issue I see is to support at the same time NEC and RC5 protocols. While
>> this may work with some devices, for others, the hardware won't allow.
>
> Sure. We can handle it for the "simple" devices at least.
>
>>> I think the mapp
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Technically, it is not hard to port this solution to the other
>> drivers, but the issue is that we don't have all those IR's to know
>> what is the complete scancode that each key produces. So, the hardest
>> part is to find a way for
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> 1) the developer that adds the hardware also adds the IR code. He has
>> the hardware and the IR for testing, so it means a faster development
>> cycle than waiting for someone else with the same hardware and IR to
>> recode it on some
Dmitry Torokhov writes:
> Why would sysfs write be slower than ioctl?
Sysfs is generally one-value, one-file. open, read/write, close.
ioctl() OTOH does everything (e.g. a whole key table) in one syscall.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-med
Maxim Levitsky writes:
> But devices that send raw pulse/space data should be handled in lirc
> that will feed the data back to the kernel via uinput.
I still do want the in-kernel RCx decoding. And lirc pulse/space.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscri
Mauro Carvalho Chehab writes:
> The issue I see is to support at the same time NEC and RC5 protocols. While
> this may work with some devices, for others, the hardware won't allow.
Sure. We can handle it for the "simple" devices at least.
>> I think the mapping should be: key = proto + group +
Mauro Carvalho Chehab writes:
> Technically, it is not hard to port this solution to the other
> drivers, but the issue is that we don't have all those IR's to know
> what is the complete scancode that each key produces. So, the hardest
> part is to find a way for doing it without causing regress
Mauro Carvalho Chehab writes:
> 1) the developer that adds the hardware also adds the IR code. He has
> the hardware and the IR for testing, so it means a faster development
> cycle than waiting for someone else with the same hardware and IR to
> recode it on some other place. You should remember
Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
>> In what way the key interface is unsufficient for delivering button
>> events?
>
> At present: 128 different keys only (RC5: one group). One remote per
> device only.
>
> The protocol itself doesn't have the above limitations, but has other
Jarod Wilson wrote:
> On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
>> Jarod Wilson wrote:
>>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>>>
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> ...
I generally don't understand the LIRC aversion I perceive in this
Dmitry Torokhov writes:
> In what way the key interface is unsufficient for delivering button
> events?
At present: 128 different keys only (RC5: one group). One remote per
device only.
The protocol itself doesn't have the above limitations, but has others,
with are acceptable for key input.
--
At Thu, 26 Nov 2009 18:38:27 +0100,
Krzysztof Helt wrote:
>
> On Thu, 26 Nov 2009 16:43:15 +0100
> Takashi Iwai wrote:
>
> > At Thu, 26 Nov 2009 13:50:17 +0100,
> > Krzysztof Helt wrote:
> > >
> > > From: Krzysztof Helt
> > >
> > > This is recreated driver for the FM module found on Miro
> >
On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
Jarod Wilson wrote:
On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
...
I generally don't understand the LIRC aversion I perceive in this thread
(maybe I just have a skewed perce
>From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski
Date: Thu, 26 Nov 2009 18:20:45 +0100
Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev pixel and
frame formats
Video subdevices, like cameras, decoders, connect to video bridg
On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:
On 11/26/09 07:23, Jarod Wilson wrote:
Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.
lirc predates the input layer IR drivers by years, maybe even the input
layer it
Hi Andy,
Andy Walls wrote:
I will inspect and test these with my HVR-1850 (CX23888) loaner board
this weekend (hopefully).
if you want me to test something on the Tevii S470 card, please let me know.
Bye,
Matthias
--
"Programming today is a race between software engineers striving to buil
Gerd Hoffmann writes:
> Why not? With RC5 remotes applications can get the device address
> bits for example, which right now are simply get lost in the ir code
> ->
> keycode conversion step.
Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think t
Andy Walls wrote:
> On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
>> I'm not sure if all the existing hardware for TX currently supports only
>> raw pulse/code sequencies, but I still think that, even on the Tx case,
>> it is better to send scancodes to the driver, and let it do
Christoph Bartelmus wrote:
> Hi,
>
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
>> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
>> be this:
> [...]
>> [*] assuming, of course, that it was actually agreed upon that in-kernel
>> decoding was the right way, the o
Jarod Wilson wrote:
>> I guess the question is what is the interface we want the regular
>> userspace (i.e. not lircd) to use. Right now programs has to use 2
>> intercfaces - one lirc for dealing with remotes that are not using
>> the standard event interface and evdev for remotes using it as wel
BTW, we used to have device specific user space interfaces for mouse
and keyboard. These caused all sort of problems. A lot of work went
into unifying them under evdev. It will be years until the old,
messed up interfaces can be totally removed.
I'm not in favor of repeating the problems with a d
On Wed, Nov 25, 2009 at 11:21 AM, Laurent Pinchart
wrote:
> Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers.
>
> Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb-
> cleanup/rev/7a762df57149 ? The patch should be committed to v4l-dvb in time
> for 2.6
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
wrote:
> Gerd Hoffmann wrote:
>> On 11/25/09 19:20, Devin Heitmueller wrote:
>>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>>> wrote:
Took me a minute to figure out exactly what you were talking
about. You're referring to the cur
At Thu, 26 Nov 2009 13:50:17 +0100,
Krzysztof Helt wrote:
>
> From: Krzysztof Helt
>
> This is recreated driver for the FM module found on Miro
> PCM20 sound cards. This driver was removed around the 2.6.2x
> kernels because it relied on the removed OSS module. Now, it
> uses a current ALSA modu
Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>> wrote:
>>> Took me a minute to figure out exactly what you were talking
>>> about. You're referring to the current in-kernel decoding done on
>>> an ad-hoc basis for assorted remot
Hi Guennadi,
Just two things really:
1) Can you move v4l2_mbus_packing and v4l2_mbus_order to a soc-mediabus.h
header or something similar? It's now soc-specific, so it doesn't belong
in the public header.
2) What are your plans for documenting the mediabus pixel codes?
Otherwise it looks great
Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>
>> l...@bartelmus.de (Christoph Bartelmus) writes:
>>
>>> I'm not sure what two ways you are talking about. With the patches posted
>>> by Jarod, nothing has to be changed in userspace.
>>> Everything works, no code ne
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore w
Krzysztof Halasa wrote:
> Andy Walls writes:
>
>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>> developed by Philips, but Microsoft has some sort of licensing interest
>> in it and it is almost surely encumbered somwhow:
>
> I don't know about legal problems in some count
Jarod Wilson wrote:
> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> ...
>> I generally don't understand the LIRC aversion I perceive in this thread
>> (maybe I just have a skewed perception). Aside for a video card's
>> default
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
> >> l...@bartelmus.de (Christoph Bartelmus) writes:
> >>
> I think we shouldn't at this time worry about IR transmitters.
> >>> Sorry, but I have
Andy Walls wrote:
> On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
>> l...@bartelmus.de (Christoph Bartelmus) writes:
>>
I think we shouldn't at this time worry about IR transmitters.
>>> Sorry, but I have to disagree strongly.
>>> Any interface without transmitter support would be
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab writes:
> PS.: For those following those discussions that want to know more about
> IR protocols, a good reference is at:
> http://www.sbprojects.com/knowledge/ir/ir.htm
>
>
Andy Walls wrote:
> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception).
> Regards,
> Andy "LIRC Fan-Boy" Walls
This is not a lirc love or hate thread. We're simply discussing the better
API's for IR, from the technical standpoint,
On Thu, Nov 26, 2009 at 6:12 AM, Alan Ferrero wrote:
> Hi!
>
> I posted yesterday the following message to the mythtv-users mailing
> list, but they answered me it's more suitable to post it in your mailing
> list.
>
> Alan
>
> Hi!
>
> I REALLY need some help with the Hauppauge WinTV HVR-4000
> (h
From: Krzysztof Helt
This is recreated driver for the FM module found on Miro
PCM20 sound cards. This driver was removed around the 2.6.2x
kernels because it relied on the removed OSS module. Now, it
uses a current ALSA module (snd-miro) and is adapted to v4l2
layer.
It provides only basic funct
I am now playing around with the available code for quite some time now
with mixed success, but no solution comes near the term “stable”.
• kernel: nothing in there. Well, reasonable.
• v4l-dvb: nothing in there.
• s2-liplianin: mantis available, but obviously not under
development/bugfixing. IR s
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> If you see patch 3/3, of the lirc submission series, you'll notice a driver
>> that has hardware decoding, but, due to lirc interface, the driver generates
>> pseudo pulse/space code for it to work via lirc interface.
>
> IOW the drive
On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:
>
> > On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
> >> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> >>> Czesc Krzysztof,
> >>>
> >>> on 23 Nov 09 at 15:
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>>> (This is no recommendation for lirc. I have no idea whether a
>>> pulse/space -> scancode -> keycode translation would be practical
>>> there.)
>
> It would, but not exactly in the present shape.
>
>> For example, there are several
> Hi Rob
>
> would you mind very much posting a patch that implements these two
> reversions,
> so I can try it easily? My hg-fu is somewhat lacking...
> I have the same hardware and noticed what I think is the same issue,
> just with Channel 9.
> Another manifestation is huge BER and nonzero REC i
1 - 100 of 114 matches
Mail list logo
