Dmitry Torokhov dmitry.torok...@gmail.com writes:
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
We should not forget that simple IR's don't have any key to select the
address,
so the produced
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 receiver (and
not to
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 receiver (and
not to
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote:
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com 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
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 internally. I
Mauro Carvalho Chehab mche...@redhat.com 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.
They are the same
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com 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).
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com 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
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com 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.
Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl jonsm...@gmail.com escreveu:
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
Dmitry Torokhov wrote:
The interesting thing is that
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
Ferenc Wagner wrote:
Mauro Carvalho Chehab mche...@redhat.com 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.
Jarod Wilson ja...@wilsonet.com 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
Mauro Carvalho Chehab mche...@redhat.com 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
Quoting Jon Smirl jonsm...@gmail.com:
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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
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 to add an
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
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 wrote:
For sure
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 working on
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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, but I
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 Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
mche...@redhat.com 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
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 by remote
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), right?
If we could separate
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl jonsm...@gmail.com wrote:
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
mche...@redhat.com 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
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. But if driver
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 receiver
(and not to
the
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).
I'm assuming that,
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 can recognize).
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 each remote/substream
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 Wilson
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
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
won't be
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 is the
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 lirc daemon.
The fact
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.
Heh, right back
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 completely identical
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 random IR input is
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com 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 assuming
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
not to
the
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/applications
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com 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).
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
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 your
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
for the most part, I
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com 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
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com 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 a
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 are
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.
The
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com 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
Hi Jon,
Jon Smirl wrote:
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com
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
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com 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
Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com 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
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 is to
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.
I did
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab
mche...@redhat.com 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
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.
Mauro,
I
60 matches
Mail list logo
