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 referring to the current in-kernel decoding done on
an ad-hoc basis for assorted remotes bundled with
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 =
(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 =rc5 value
In case the 32bit value
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 userspace.
On Wed, 2009-11-25 at 13:20 -0500, Devin Heitmueller wrote:
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
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. With the
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 Wilsonja...@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
On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote:
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
On Mon, Nov 23, 2009 at 09:51:31PM +0100, Krzysztof Halasa wrote:
Dmitry Torokhov dmitry.torok...@gmail.com 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
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 Chehabmche...@redhat.com writes:
Event input has the advantage that the keystrokes will provide an
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 I have to
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 Chehabmche...@redhat.com writes:
Event input
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 this time worry
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 so
Mauro Carvalho Chehab mche...@redhat.com 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
On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa k...@pm.waw.pl 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. RC5keycode).
Just
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote
control support ?
See http://marc.info/?l=linux-kernelm=122591465821297w=2 and all discussions
around it.
Regards,
Emmanuel.
---
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com:
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
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com:
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
On Mon, Nov 23, 2009 at 12:05 PM, James Mastros ja...@mastros.biz wrote:
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com:
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
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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
Stefan Richter wrote:
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com 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,
James Mastros wrote:
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com:
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
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 mche...@redhat.com writes:
...
Considering
James Mastros ja...@mastros.biz 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
Mauro Carvalho Chehab mche...@redhat.com 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
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 bttv and saa7134 devices
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 the driver generates
Jarod Wilson ja...@wilsonet.com 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,
Dmitry Torokhov dmitry.torok...@gmail.com 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,
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
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 a
On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa k...@pm.waw.pl 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
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
Devin Heitmueller dheitmuel...@kernellabs.com 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
On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Devin Heitmueller dheitmuel...@kernellabs.com 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
Devin Heitmueller dheitmuel...@kernellabs.com 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.
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 would be
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 unacceptable
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
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 Chehabmche...@redhat.com writes:
Event input has the advantage that the keystrokes will provide an unique
representation that is independent of the device.
This
101 - 144 of 144 matches
Mail list logo
