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
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 itself.
The main reason for the input layer I
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 encod
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 i
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
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 Halasa wrote:
>>> [...]
I think we shouldn't at th
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:
Mauro Carvalho Chehab writes:
> Event input h
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 Halasa wrote:
> > [...]
> > > I think we shouldn't at this time worry about IR transmitters.
> >
> > Sorry, but
On Nov 25, 2009, at 10:31 PM, Andy Walls wrote:
> On Wed, 2009-11-25 at 13:07 -0500, 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 pos
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:
>>> Mauro Carvalho Chehab writes:
>>>
Event input has the advantage that the keystrokes will provide an unique
>>
On Mon, Nov 23, 2009 at 09:51:31PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> > Curreently the "scan" codes in the input layer serve just to help users
> > to map whatever the device emits into a proper input event code so that
> > the rest of userspace would not have to care an
On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote:
> Jarod Wilson 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 decod
On Wed, 2009-11-25 at 22:58 +0100, 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
Am Mittwoch, den 25.11.2009, 22:31 -0500 schrieb Andy Walls:
> On Wed, 2009-11-25 at 13:07 -0500, 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.
On Wed, 2009-11-25 at 13:20 -0500, 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 remotes bundl
On Wed, 2009-11-25 at 13:07 -0500, 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 use
(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 = IR_RC5
input_event->value =
In case the 32bit value is too
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
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 remotes bundled with capture devices,
corre
Devin Heitmueller 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 format to receive. We p
Jarod Wilson 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 drivers with
> cur
Jarod Wilson 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 above is fine
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 remotes bundled with capture devices, correct?
>
> Admittedly, unifying those and
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 Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote:
> Jarod Wilson 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?)
>> of Myt
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, everybody is
> happy.
The existing drivers use input laye
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
Jarod Wilson 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 "improving" things
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 countries but from the
technical POV han
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 setup, the suggestions
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
Mauro Carvalho Chehab writes:
Event input has the advantage that the keystrokes will provide an unique
representation that is independent of the device.
This can hardly work as t
On 11/23/2009 04:10 PM, Christoph Bartelmus wrote:
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
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 unacc
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> 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 wo
Devin Heitmueller writes:
> For example, you might want the IR receiver to be listening for codes
> using the "Universal Remote Control XYZ" profile and the IR
> transmitter pretending to be "Cable Company Remote Control ABC" when
> blasting IR codes to the cable box. Ideally, there would be a s
On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa wrote:
> Devin Heitmueller writes:
>
>> There is an argument to be made that since it may be desirable for
>> both IR receivers and transmitters to share the same table of remote
>> control definitions, it might make sense to at least *consider* h
Devin Heitmueller writes:
> There is an argument to be made that since it may be desirable for
> both IR receivers and transmitters to share the same table of remote
> control definitions, it might make sense to at least *consider* how
> the IR transmitter interface is going to work, even if it i
I though about it a bit - my idea:
1. Receivers that can only decode their own remote controllers.
The present code (saa713x etc) can stay mostly unchanged. I'd only
verify that 7 bits (or whatever the number is) is enough for all
cases. The ioctl() should stay unchanged. That means keybo
On Mon, Nov 23, 2009 at 4:46 PM, 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 unacceptabl
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 unacceptable
> for many LIRC users, including myself.
I don't say don't use
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
Dmitry Torokhov writes:
> Curreently the "scan" codes in the input layer serve just to help users
> to map whatever the device emits into a proper input event code so that
> the rest of userspace would not have to care and would work with all
> types of devices (USB, PS/2, etc).
>
> I would not w
Jarod Wilson writes:
> There are quite a few available IR options that are NOT tied to a
> video capture device at all -- the mceusb and imon drivers submitted
> in my patch series are actually two such beasts.
Precisely. This also includes the parallel and serial port receivers,
I'm under impre
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 driver generates artificial pulse code f
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 bttv and saa7134 devices that polls (o
Mauro Carvalho Chehab writes:
> True, but this means that everyone with an IR will need to use lirc.
I think that if the input layer (instead of raw code) is used, a utility
which only sets the mapping(s) would suffice. I.e. no daemon.
> /me thinks that, whatever decided with those lirc drivers
James Mastros writes:
> (This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box. This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)
I'm a bit short on time to write up a more complete reply to anything in this
thread at the moment, but a few quick notes interspersed below.
On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab writes:
...
>>> Considering the common cas
James Mastros wrote:
> 2009/11/23 Devin Heitmueller :
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still happen, if LIRC checks the identif
Stefan Richter wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab writes:
>>
>>> Event input has the advantage that the keystrokes will provide an unique
>>> representation that is independent of the device.
>> This can hardly work as the only means, the remotes have different keys,
>> the
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > Event input has the advantage that the keystrokes will provide an unique
> > representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have diff
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Event input has the advantage that the keystrokes will provide an unique
>> representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to
On Mon, Nov 23, 2009 at 12:05 PM, James Mastros wrote:
> 2009/11/23 Devin Heitmueller :
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still
2009/11/23 Devin Heitmueller :
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device,
2009/11/23 Devin Heitmueller :
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device,
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Event input has the advantage that the keystrokes will provide an unique
>> representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote
control support ?
See http://marc.info/?l=linux-kernel&m=122591465821297&w=2 and all discussions
around it.
Regards,
Emmanuel.
---
Laposte
On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa wrote:
> I think this makes a lot of sense.
> But: we don't need a database of RC codes in the kernel (that's a lot of
> data, the user has to select the RC in use anyway so he/she can simply
> provide mapping e.g. RC5<>keycode).
Just bear in mind
Mauro Carvalho Chehab writes:
> Event input has the advantage that the keystrokes will provide an unique
> representation that is independent of the device.
This can hardly work as the only means, the remotes have different keys,
the user almost always has to provide customized key<>function map
101 - 163 of 163 matches
Mail list logo
