Hi Jarod,
on 11 Aug 10 at 10:38, Jarod Wilson wrote:
> On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson wrote:
>>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>>> On Mon, Aug 2, 2010 at 12:42 PM, C
Hi!
Jon Smirl "jonsm...@gmail.com" wrote:
[...]
>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> ported over the weekend, but this remote just won't decode correctly w/the
>> in-kernel RC5 d
Hi!
Jon Smirl "jonsm...@gmail.com" wrote:
> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
>>> wrote:
>>&
Hi Jon,
on 31 Jul 10 at 14:14, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls
>>> wrote:
>>>> I t
Hi Jon,
on 31 Jul 10 at 17:53, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote:
>> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
>>> wrote:
>>>> Hi Jon,
>>>>
&g
Hi Jon,
on 31 Jul 10 at 12:25, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls
> 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.
>
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 clari
Hi!
Maxim Levitsky "maximlevit...@gmail.com" wrote:
> Still missing features: carrier report & timeout reports.
> Will need to pack these into ir_raw_event
Hm, this patch changes the LIRC interface but I can't see the according
patch to the documentation.
[...]
> * @tx_ir: transmit IR
>
Hi!
Maxim Levitsky "maximlevit...@gmail.com" wrote:
> On Thu, 2010-07-29 at 18:58 +0200, Christoph Bartelmus wrote:
>> Hi Maxim,
>>
>> on 29 Jul 10 at 17:41, Maxim Levitsky wrote:
>> [...]
>>>>> Note that I send timeout report with zero valu
Hi!
Maxim Levitsky "maximlevit...@gmail.com" wrote:
[...]
> Could you explain exactly how timeout reports work?
[...]
>>> So, timeout report is just another sample, with a mark attached, that
>>> this is last sample? right?
>>
>> No, a timeout report is just an additional hint for the decoder
Hi Maxim,
on 29 Jul 10 at 19:26, Maxim Levitsky wrote:
> On Thu, 2010-07-29 at 11:38 -0400, Andy Walls wrote:
>> On Thu, 2010-07-29 at 17:41 +0300, Maxim Levitsky wrote:
>>> On Thu, 2010-07-29 at 09:23 +0200, Christoph Bartelmus wrote:
>>>> Hi Maxim,
>>
Hi Maxim,
on 29 Jul 10 at 17:41, Maxim Levitsky wrote:
[...]
>>> Note that I send timeout report with zero value.
>>> I don't think that this value is importaint.
>>
>> This does not sound good. Of course the value is important to userspace
>> and 2 spaces in a row will break decoding.
>>
>> Chris
Hi Andy,
on 29 Jul 10 at 11:38, Andy Walls wrote:
> On Thu, 2010-07-29 at 17:41 +0300, Maxim Levitsky wrote:
>> On Thu, 2010-07-29 at 09:23 +0200, Christoph Bartelmus wrote:
>>> Hi Maxim,
>>>
>>> on 29 Jul 10 at 02:40, Maxim Levitsky wrote:
>>> [...]
&
Hi Maxim,
on 29 Jul 10 at 18:27, Maxim Levitsky wrote:
> On Thu, 2010-07-29 at 09:25 +0200, Christoph Bartelmus wrote:
>> Hi!
>>
>> Maxim Levitsky "maximlevit...@gmail.com" wrote:
>>
>>> Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MO
Hi Maxim,
on 29 Jul 10 at 02:40, Maxim Levitsky wrote:
[...]
> In addition to comments, I changed helper function that processes samples
> so it sends last space as soon as timeout is reached.
> This breaks somewhat lirc, because now it gets 2 spaces in row.
> However, if it uses timeout reports (
Hi!
Maxim Levitsky "maximlevit...@gmail.com" wrote:
> Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE
> (LIRC_SET_LEARN_MODE will start carrier reports if possible, and
> tune receiver to wide band mode)
I don't like the rename of the ioctl. The ioctl should enable carrier
report
Hi Mauro,
on 04 Jun 10 at 01:10, Mauro Carvalho Chehab wrote:
> Em 03-06-2010 19:06, Jarod Wilson escreveu:
[...]
>> As for the compat bits... I actually pulled them out of the Fedora kernel
>> and userspace for a while, and there were only a few people who really ran
>> into issues with it, but I
Hi Andy,
on 07 Dec 09 at 23:10, Andy Walls wrote:
[...]
> (Christoph can correct me if I get anything wrong.)
Just a few additions.
[...]
>> What is the time standard for the data, where does it come from?
> I think it is usec, IIRC.
Yes, it is.
> I know that the hardware I work with has sub
Hi Jon,
on 08 Dec 09 at 08:34, Jon Smirl wrote:
[...]
> The point of those design review questions was to illustrate that the
> existing LIRC system is only partially designed. Subsystems need to be
> fully designed before they get merged.
I'd say that a system that has proven itself in real worl
Hi Dmitry,
on 06 Dec 09 at 23:51, Dmitry Torokhov wrote:
[...]
>>> I suppose we could add MSC_SCAN_END event so that we can transmit
>>> "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by
>>> MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
>>> bit.
>>
Hi Jon,
on 04 Dec 09 at 19:28, Jon Smirl wrote:
>> BTW, I just came across a XMP remote that seems to generate 3x64 bit
>> scan codes. Anyone here has docs on the XMP protocol?
>
> Assuming a general purpose receiver (not one with fixed hardware
> decoding), is it important for Linux to receive IR
Hi Dmitry,
on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
>>
>> This is an air-conditioner remote.
>> The entries that you see in this config file are not really separate
>> buttons. Instead the remote just sends the cu
Hi Dmitry,
on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
> I do not believe you are being realistic. Sometimes we just need to say
> that the device is a POS and is just not worth it. Remember, there is
> still "lirc hole" for the hard core people still using solder to produce
> something ou
Hi Dmitry,
on 04 Dec 09 at 14:07, Dmitry Torokhov wrote:
> On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
>> Hi Mauro,
>>
>> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
>>> Christoph Bartelmus wrote:
>>>>>> Co
Hi Mauro,
on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
>>>> Consider passing the decoded data through lirc_dev.
[...]
>> Consider cases like this:
>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
>>
>> This is an air-
Hi Dmitry,
on 03 Dec 09 at 14:12, Dmitry Torokhov wrote:
[...]
>> Consider passing the decoded data through lirc_dev.
[...]
> I believe it was agreed that lirc-dev should be used mainly for decoding
> protocols that are more conveniently decoded in userspace and the
> results would be looped back
Hi Mauro,
on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
[...]
>>> So the lirc_imon I submitted supports all device types, with the
>>> onboard decode devices defaulting to operating as pure input devices,
>>> but an option to pass hex values out via the lirc interface (which is
>>> how they'
Hi Jon,
on 30 Nov 09 at 16:35, Jon Smirl wrote:
[...]
> It would be interesting to split the lirc daemon. Put the protocol
> decoder stuff in one daemon and the scripting support in the other.
> The scripting daemon would then be optional. What would be the
> relative sizes of the two daemons?
>
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote:
>>> Jon is asking for an architecture discussion, y'know, with use cases.
[...]
> So we're just back to the status quo of last year which is to do
> nothing except some minor clean up.
>
> We'll be back
Hi Krzysztof,
on 28 Nov 09 at 18:21, Krzysztof Halasa wrote:
[...]
>> This remote uses RC-5. But some of the developers must have thought that
>> it may be a smart idea to use 14 bits instead the standard 13 bits for
>> this remote. In LIRC you won't care, because this is configurable and
>> irrec
Hi Stefan,
on 28 Nov 09 at 21:29, Stefan Richter wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
>> wrote:
>>> Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE
Hi Mauro,
on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote:
> Hi Christoph,
>
> Christoph Bartelmus wrote:
>>> Maybe we decide to take the existing LIRC system as is and not
>>> integrate it into the input subsystem. But I think there is a window
>>> here
Hi Jon,
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
> Christoph, take what you know from all of the years of working on LIRC
> and design the perfect in-kernel system. This is the big chance to
> redesign IR support and get rid of any past mistakes. Incorporate any
> useful chunks of code and kn
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky writes:
>> Generic decoder that lirc has is actually much better and more tolerant
>> that protocol specific decoders that you propose,
> Actually, it is not the case. Why do you think it's better (let alone
Hi Jon,
on 27 Nov 09 at 10:57, Jon Smirl 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 works.
>>
>> So the plan is to hav
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
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,
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
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
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 only way, all others will be shot on sight
Hi Gerd,
on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]
>> To sum it up: I don't think this information will be useful at all for
>> lircd or anyone else.
[...]
> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings. Thats why I think there will alway
Hi Gerd,
on 25 Nov 09 at 22:58, 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->code
Hi,
on 25 Nov 09 at 17:53, Krzysztof Halasa wrote:
> Jarod Wilson writes:
[...]
>> nimble. If we can come up with a shiny new way that raw IR can be
>> passed out through an input device, I'm pretty sure lirc userspace can
>> be adapted to handle that.
As Trent already pointed out, adding suppor
Hi Jarod,
on 23 Nov 09 at 14:17, Jarod Wilson wrote:
>> Krzysztof Halasa wrote:
[...]
>> 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 in
Czesc Krzysztof,
on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
[...]
> 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 absolutely unacceptable
for many LIRC users, including myself.
Chris
45 matches
Mail list logo
