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
reports.
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 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:
[...]
In addition to comments, I changed helper function
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.
Christoph
Could
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,
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_MODE
(LIRC_SET_LEARN_MODE will start carrier reports if possible
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,
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
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
Hi Jon,
on 31 Jul 10 at 17:53, 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
Hi Jon,
on 31 Jul 10 at 14:14, 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
Hi!
Jon Smirl jonsm...@gmail.com wrote:
On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus l...@bartelmus.de
wrote:
Hi Jon,
on 31 Jul 10 at 14:14, 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
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 decoder.
Hi Jarod,
on 11 Aug 10 at 10:38, Jarod Wilson wrote:
On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl jonsm...@gmail.com wrote:
On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson ja...@redhat.com wrote:
On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
On Mon, Aug 2, 2010 at 12:42 PM, Christoph
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.
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
Hi,
on 25 Nov 09 at 17:53, Krzysztof Halasa wrote:
Jarod Wilson ja...@wilsonet.com 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,
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 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 always be
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 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
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
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 this
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 works
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
Maxim Levitsky maximlevit...@gmail.com 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
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
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 to update the LIRC design to use the latest kernel
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
irrecord
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
stef...@s5r6.in-berlin.de 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
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox a...@lxorguk.ukuu.org.uk 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
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 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've
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 into
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-conditioner remote.
The entries that you see
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:
Consider passing the decoded data through lirc_dev.
[...]
Consider cases
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 out of
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 current settings for e.g.
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 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.
And I set a
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 world
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 100
41 matches
Mail list logo
