Dmitry Torokhov writes:
> On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
>> Ferenc Wagner wrote:
>>> Mauro Carvalho Chehab writes:
>>
>> We should not forget that simple IR's don't have any key to select the
>> address,
>> so the produced codes there will never have KEY
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Btw, looking at that code, while it is not impossible to split the
>> IR pulse/space measures from the NEC decoder itself, and make it generic
>> to support other protocols, it is not a trivial task, and may result on
>> a less stable
Quoting Jon Smirl :
Now I understand that if 2 remotes send completely identical signals we
won't be able to separate them, but in cases when we can I think we
should.
I don't have a problem with that, if its a truly desired feature.
But for the most part, I don't see the point. Generally,
Mauro Carvalho Chehab writes:
> Btw, looking at that code, while it is not impossible to split the
> IR pulse/space measures from the NEC decoder itself, and make it generic
> to support other protocols, it is not a trivial task, and may result on
> a less stable driver.
And it's not needed at
Jarod Wilson writes:
> Perhaps we should clarify something here. Are we intending to
> auto-create a new input device for every IR command set we see arrive
> at the IR receiver?
We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
> Ferenc Wagner wrote:
> > Mauro Carvalho Chehab writes:
>
> We should not forget that simple IR's don't have any key to select the address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
Wait, wait, KE
Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl escreveu:
> On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
> wrote:
> > Ferenc Wagner wrote:
> >> Mauro Carvalho Chehab writes:
> >>
> >>> Dmitry Torokhov wrote:
> >>>
> >
> >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KE
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
> Ferenc Wagner wrote:
> > Mauro Carvalho Chehab writes:
>
> We should not forget that simple IR's don't have any key to select the
> address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
Wait, wait, KE
Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson wrote:
>> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
>> ...
>> Now I understand that if 2 remotes send completely identical signals we
>> won't be able to separate them, but in cases when we can I think we
>> should
Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl escreveu:
> On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
> wrote:
> > Ferenc Wagner wrote:
> >> Mauro Carvalho Chehab writes:
> >>
> >>> Dmitry Torokhov wrote:
> >>>
> >
> >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
wrote:
> Ferenc Wagner wrote:
>> Mauro Carvalho Chehab writes:
>>
>>> Dmitry Torokhov wrote:
>>>
>
>> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
>> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever b
Ferenc Wagner wrote:
> Mauro Carvalho Chehab writes:
>
>> Dmitry Torokhov wrote:
>>
> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
> by any remote (ok, I'm stretching it a bit).
Unfortunately,
Mauro Carvalho Chehab writes:
> Dmitry Torokhov wrote:
>
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
>> Now I understand that if 2 remotes send completely identical
>> signals we won't be able to separete them, but in cases when we
>> can I think we should.
>>
>> Th
On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
> > Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> > object intern
Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson wrote:
>> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
>> ...
>> Now I understand that if 2 remotes send completely identical signals we
>> won't be able to separate them, but in cases when we can I think we
>> should.
Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>> On
Andy Walls wrote:
> On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>>
>>> Dmitry Torokhov wrote:
>> ...
>> (for each remote/substream that they can recognize).
> I'm assuming that, by remote, you're referring to a remote re
Andy Walls wrote:
> On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>>
>>> Dmitry Torokhov wrote:
>> ...
>> (for each remote/substream that they can recognize).
> I'm assuming that, by remote, you're referring to a remote re
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson wrote:
> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
> ...
> Now I understand that if 2 remotes send completely identical signals we
> won't be able to separate them, but in cases when we can I think we
> should.
I don't have
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> On 12/2/09 12:30 PM, Jon Smirl
On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
...
Now I understand that if 2 remotes send completely identical signals we
won't be able to separate them, but in cases when we can I think we
should.
>>>
>>> I don't have a problem with that, if its a truly desired feature. But
>>>
On Wed, 2 Dec 2009, Jon Smirl wrote:
> > A bluetooth remote has a specific device ID that the receiver has to pair
> > with. Your usb mouse and keyboard each have specific device IDs. A usb IR
> > *receiver* has a specific device ID, the remotes do not. So there's the
> > major difference from y
Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls:
> On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>
>
> > Didn't Jon posted his example whith programmable remote pretending to be
> > several separate remotes
Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
On 12/2/09 12:30 PM, Jon Smirl wrote:
(for each remote/substream that they can recognize).
On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> Didn't Jon posted his example whith programmable remote pretending to be
> several separate remotes (depending on the mode of operation) so that
> several devices/applicatio
On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>
> > Dmitry Torokhov wrote:
> >>
> ...
> (for each remote/substream that they can recognize).
> >>> I'm assuming that, by remote, you're referring to a remote receiver (and
> >
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>> (for each remote/substream that they can recognize).
I'm a
Jarod Wilson wrote:
> On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote:
>
>> On Wed, 2 Dec 2009, Jarod Wilson wrote:
> My main point is that each of these devices has device ID that can be
> determined without having to first do some protocol analysis and table
> lookups to figure out
On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote:
> On Wed, 2 Dec 2009, Jarod Wilson wrote:
My main point is that each of these devices has device ID that can be
determined without having to first do some protocol analysis and table
lookups to figure out which "device" some ra
Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> Now I understand that if 2 remotes send completel
On Wed, 2 Dec 2009, Jarod Wilson wrote:
> >>
> >> My main point is that each of these devices has device ID that can be
> >> determined without having to first do some protocol analysis and table
> >> lookups to figure out which "device" some random IR input is actually
> >> coming from.
> >>
>
On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote:
...
>> Personally, I've always considered the driver/interface to be the
>> receiver, not the remote. The lirc drivers operate at the receiver
>> level, anyway, and the distinction between different remotes is made by
>> the l
Jon Smirl wrote:
> Some major use cases:
> using IR as a keyboard replacement, controlling X and apps with it in
> via mouse and keyboard emulation.
> using IR to control a headless embedded device possibly running
> multiple apps - like audio and home automation (my app)
> IR during boot when it i
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >>> Now I understand that if 2 remotes send completely identical signals we
> >
Jon Smirl wrote:
> IR devices transmit vendor/device/command triplets. They are easy to
> tell apart and create an evdev device corresponding to each
> vendor/device pair or something else along those lines.
What they transmit depend on the used protocol. With NEC and RC5 (currently, the
most com
On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote:
>
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >>
> >>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod
On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
On 12/2/09 12:30 PM, Jon Smirl wrote:
(for ea
Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
On 12/2/09 12:30 PM, Jon Smirl wrote:
(for each remote/substream that they
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
> > On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> >> On 12/2/09 12:30 PM, Jon Smirl wrote:
> >> (for each remote/substream that they can recognize).
> >>>
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>> (for each remote/substream that they can recognize).
>>>
>>> I'm assuming that, by remote, you're referring to a remote receiv
On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> >> The raw interface applies only to the devices that doesn't have a hardware
> >> decoder
> >> (something between 40%-60% of the currently supported devices).
> >
> > 50% is quite a number I think.
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
> wrote:
>> Dmitry Torokhov wrote:
The raw interface applies only to the devices that doesn't have a hardware
decoder
(something between 40%-60% of the currently supported devi
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> On 12/2/09 12:30 PM, Jon Smirl wrote:
> (for each remote/substream that they can recognize).
>>
>> I'm assuming that, by remote, you're referring to a remote receiver
>> (and not to
>> the remote itself), rig
On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
>>
...
(for each remote/substream that they can recognize).
>>> I'm assuming that, by remote, you're referring to a remote receiver (and
>>> not to
>>> the remote itself), right?
>>
>> If we could separate b
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
wrote:
> Dmitry Torokhov wrote:
>>> The raw interface applies only to the devices that doesn't have a hardware
>>> decoder
>>> (something between 40%-60% of the currently supported devices).
>>
>> 50% is quite a number I think. But if driver d
Dmitry Torokhov wrote:
>> The raw interface applies only to the devices that doesn't have a hardware
>> decoder
>> (something between 40%-60% of the currently supported devices).
>
> 50% is quite a number I think. But if driver does not allow access to
> the raw stream - it will refuse binding to
On 12/2/09 12:30 PM, Jon Smirl wrote:
(for each remote/substream that they can recognize).
>>
>> I'm assuming that, by remote, you're referring to a remote receiver (and
not to
>> the remote itself), right?
>
> If we could separate by remote transmitter that would be the best I
> think, bu
On Wed, Dec 2, 2009 at 1:23 PM, Dmitry Torokhov
wrote:
> On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
>> wrote:
>> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >> > On Tue
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
> wrote:
> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote
On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
wrote:
> On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >>> On Tue, Dec 01, 2009 at 05:00:4
On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov
On Wed, Dec 02, 2009 at 10:37:02AM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
> wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
wrote:
> On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >>> On Tue, Dec 01, 2009 at 03:29:44
Gerd Hoffmann wrote:
> On 12/01/09 22:05, Mauro Carvalho Chehab wrote:
>> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> the device is an IR (or create it is /sys/class/input/IR).
>
> No, you add it to the physical device node.
>
> The usb mouse on the system I'm work
Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrot
On 12/01/09 22:05, Mauro Carvalho Chehab wrote:
So, I would just add the IR sysfs parameters at the /sys/class/input, if
the device is an IR (or create it is /sys/class/input/IR).
No, you add it to the physical device node.
The usb mouse on the system I'm working on is here:
zweiblum kraxel $
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> For sure we need
Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
For sure we need to add an EVIOSETPROTO ioctl to allow the driver
to change the protocol in
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> >> to change the protocol in runtime.
> >>
> >
> > Ma
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab
wrote:
> Due to the lack of an API for it, each driver has their own way to handle the
> protocols, but basically, on almost all drivers, even supporting different
> protocols,
> the driver limits the usage of just the protocol provided by the
Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
>> to change the protocol in runtime.
>>
>
> Mauro,
>
> I think this kind of confuguration belongs to lirc device space,
> not inpu
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
wrote:
> Hi Jon,
> So, what we can do is to have a "default" keycode table mapping several
> different IR's there to be used by drivers that are shipped with an IR
> that can be fully mapped by the default table. However, for devices
> with sc
On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>
> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> to change the protocol in runtime.
>
Mauro,
I think this kind of confuguration belongs to lirc device space,
not input/evdev. This is the same as proto
Patrick Boettcher wrote:
>> The fact that the driver currently uses the same lookup table for both
>> types of remote controls however, was perhaps not the best design
>> choice. It really should be separated out, and merged with the
>> regular ir-functions.c. I just never got around to it.
>
>
Maxim Levitsky wrote:
> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>> While reading all of these IR threads another way of handling IR
>> occurred to me that pretty much eliminates the need for LIRC and
>> configuration files in default cases. The best way to make everything
>> "just work
Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
wrote:
Just taking an example from the dibcom0700 driver (as the same driver
supports several different RC5 and NEC codes at the same time),
the kernel table has several keycodes added there
Devin Heitmueller wrote:
> On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
> wrote:
>> Just taking an example from the dibcom0700 driver (as the same driver
>> supports several different RC5 and NEC codes at the same time),
>> the kernel table has several keycodes added there, all working
>
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
wrote:
> Just taking an example from the dibcom0700 driver (as the same driver
> supports several different RC5 and NEC codes at the same time),
> the kernel table has several keycodes added there, all working
> at the same time. Providing tha
Hi Jon,
Jon Smirl wrote:
> On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky
> wrote:
>> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>>> While reading all of these IR threads another way of handling IR
>>> occurred to me that pretty much eliminates the need for LIRC and
>>> configuration f
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky wrote:
> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>> While reading all of these IR threads another way of handling IR
>> occurred to me that pretty much eliminates the need for LIRC and
>> configuration files in default cases. The best way
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
> While reading all of these IR threads another way of handling IR
> occurred to me that pretty much eliminates the need for LIRC and
> configuration files in default cases. The best way to make everything
> "just work" is to eliminate it.
>
> T
While reading all of these IR threads another way of handling IR
occurred to me that pretty much eliminates the need for LIRC and
configuration files in default cases. The best way to make everything
"just work" is to eliminate it.
The first observation is that the IR profile of various devices ar
72 matches
Mail list logo
