Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net writes:
I would also note that RC-6 Mode 6A, used by
Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
a
On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
Good! Please, try to design the decoder as an independent
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
I can setup
Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
I can setup the CX2388[58] hardware to look for both RC-5 and
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll
Mauro Carvalho Chehab mche...@redhat.com writes:
With RC-5, you have no fields describing the remote. So, all the driver could
do is an educated guess.
It can't even do that, e.g. single remotes (even the dumb ones) can send
different code groups (addresses) for different keys.
IMO, the
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
IMO, the better is to have an API to allow creation of multiple interfaces
per IR receiver, based on some scancode matching table and/or on some
matching mask.
I think setting the keytables for each logical device
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon,
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Andy Walls wrote:
On Tue, Dec 8, 2009 at 9:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
Jon Smirl wrote:
This model is complicated by the fact that some remotes that look
like multi-function remotes aren't really multifunction. The remote
bundled with the MS MCE receiver is one. That remote is a single
function device even
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05
On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for
On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote:
On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the
On Tue, Dec 8, 2009 at 11:27 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
Jon Smirl jonsm...@gmail.com writes:
Why do you want to pull the 1KB default mapping table out of the
device driver __init section and more it to a udev script? Now we will
have to maintain a parallel udev script for ever receiver's device
driver.
Of course no. We will need a single program
Krzysztof Halasa wrote:
Jon Smirl jonsm...@gmail.com writes:
Why do you want to pull the 1KB default mapping table out of the
device driver __init section and more it to a udev script? Now we will
have to maintain a parallel udev script for ever receiver's device
driver.
Of course no. We
Dmitry Torokhov wrote:
I am a resonable guy ;) In cases when we can certainly say that there
are 2 separate remotes (and we know characteristics somehow) we need to
create 2 input devices. Otherwise we can't ;)
Only on very few specific cases (a few protocols), you can be (almost) sure.
Even
Jon Smirl wrote:
I don't like the idea of automatically loading 3 different keycodes at the
same time. You may have overlaps between different keycode tables. The
better is to have some userspace GUI that will allow the user to select
what keycode table(s) he want to be available, if he
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net 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
Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Maybe I'm being too conservative here, but I have a personal interest in
keeping Linux free and unencumbered even in the US which, I cannot deny,
has a patent
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net writes:
I would also note that RC-6 Mode 6A, used by most MCE
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus l...@bartelmus.de wrote:
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?
Em Thu, 26 Nov 2009 17:06:03 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
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.
On Thu, Nov 26, 2009 at 09:01:00AM +0100, 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
On 11/26/09 08:28, Christoph Bartelmus wrote:
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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
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:14, Krzysztof
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
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, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
PS.: For those following those discussions that want to know more about
IR protocols, a good reference is at:
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 absolutely
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 to disagree
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 remote
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net 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
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 needs to be
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Gerd Hoffmann wrote:
On 11/25/09 19:20, Devin Heitmueller wrote:
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com
wrote:
Took me a minute to figure out exactly what you were talking
about. You're
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
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 well
as
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 only way, all
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 the
Gerd Hoffmann kra...@redhat.com 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
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
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
Dmitry Torokhov dmitry.torok...@gmail.com 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
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
thread
(maybe I
Krzysztof Halasa wrote:
Dmitry Torokhov dmitry.torok...@gmail.com 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
Mauro Carvalho Chehab mche...@redhat.com 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
Mauro Carvalho Chehab mche...@redhat.com 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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
Andy Walls awa...@radix.net 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
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
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 it by
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa k...@pm.waw.pl wrote:
Dmitry Torokhov dmitry.torok...@gmail.com 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
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 by
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
feature.
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.
Nonsense!
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 Halasa wrote:
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-code =
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 the
Dmitry Torokhov dmitry.torok...@gmail.com 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:
Mauro Carvalho Chehab mche...@redhat.com 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.
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
Dmitry Torokhov dmitry.torok...@gmail.com 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
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
Dmitry Torokhov dmitry.torok...@gmail.com 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.
--
Trent Piepho xy...@speakeasy.org 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.
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 both, do
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
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
double
check the
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com 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.
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 wrote:
On
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com 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,
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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
Andy Walls awa...@radix.net 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 countries but from the
Jarod Wilson ja...@wilsonet.com writes:
The bulk of breakage in lirc I've personally had to deal with has
mostly come in the form of kernel interface changes, which would
definitely be mitigated by not having to maintain the drivers
out-of-tree any longer.
Certainly.
Now, I'm all for
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,
On Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote:
Jarod Wilson ja...@wilsonet.com writes:
...
Now, I'm all for improving things and integrating better with the
input subsystem, but what I don't really want to do is break
compatibility with the existing setups on thousands (and thousands?)
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 needs to be written and tested,
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson ja...@wilsonet.com 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 remotes bundled with capture devices, correct?
Admittedly,
Jarod Wilson ja...@wilsonet.com writes:
Ah, but the approach I'd take to converting to in-kernel decoding[*]
would be this:
1) bring drivers in in their current state
- users keep using lirc as they always have
2) add in-kernel decoding infra that feeds input layer
Well. I think the
Jarod Wilson ja...@wilsonet.com writes:
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 remotes bundled with capture devices, correct?
Yes.
Well, is there any reason most of those
Devin Heitmueller dheitmuel...@kernellabs.com writes:
The other key thing I don't think we have given much thought to is the
fact that in many tuners, the hardware does RC decoding and just
returns NEC/RC5/RC6 codes. And in many of those cases, the hardware
has to be configured to know what
1 - 100 of 144 matches
Mail list logo
