Hi,
On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
Comments?
I haven't seen this mentioned yet, but are there any plans for a sysfs
interface to set up waking from suspend/standby on a particular IR scancode
(for hardware decoders that support masking of comparing of the IR
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
Hi,
On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
Comments?
I haven't seen this mentioned yet, but are there any plans for a sysfs
interface to set up waking from suspend/standby on a particular IR scancode
(for
On Fri, Apr 9, 2010 at 8:58 AM, Jarod Wilson ja...@redhat.com wrote:
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote:
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
Hi,
On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
Comments?
I haven't seen this
Hi James,
Andy Walls wrote:
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
Hi,
On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
Comments?
I haven't seen this mentioned yet, but are there any plans for a sysfs
interface to set up waking from suspend/standby on a
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote:
If you're waiting for me to get that working, I'll advise you to plan on
getting off the couch and pushing the power switch for some time to
come. ;)
:-)
On Friday 09 April 2010 14:01:46 Mauro Carvalho Chehab wrote:
The additions at
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Basically, a keycode (like KEY_POWER) could be used to wake up the
machine. So, by
associating some scancode to KEY_POWER via ir-core, the driver can program
the hardware
to wake up the machine with the
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Basically, a keycode (like KEY_POWER) could be used to wake up the
machine. So, by
associating some scancode to KEY_POWER via ir-core, the driver
Andy Walls wrote:
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Basically, a keycode (like KEY_POWER) could be used to wake up the
machine. So, by
associating some scancode to KEY_POWER via
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software
decoder, the IR IRQ might be used to wake, but this means that everything,
even a glitch, would wake the hardware, so this won't work
Hi!
Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab:
Andy Walls wrote:
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Basically, a keycode (like KEY_POWER) could be used
Jon Smirl wrote:
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
[1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a
software
decoder, the IR IRQ might be used to wake, but this means that everything,
even a glitch, would wake the
David Härdeman wrote:
On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote:
I spoke too soon... removing the index causes a problem at the read ioctl:
there's no way
to retrieve just the non-sparsed values.
There's one solution that would allow both read/write and compat to
On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote:
I spoke too soon... removing the index causes a problem at the read ioctl:
there's no way
to retrieve just the non-sparsed values.
There's one solution that would allow both read/write and compat to work
nicely,
but
On Sun, Mar 28, 2010 at 08:22:31PM -0300, Mauro Carvalho Chehab wrote:
I also noticed another problem: kernel should have some way to report
the expected
size of the scancode to userspace, especially if we want to have the
compatibility
code (since, with compat, a scancode maximum size need
David Härdeman wrote:
On Sun, Mar 28, 2010 at 08:22:31PM -0300, Mauro Carvalho Chehab wrote:
I also noticed another problem: kernel should have some way to report
the expected
size of the scancode to userspace, especially if we want to have the
compatibility
code (since, with compat, a
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
On Fri, Mar 26, 2010 at 06:37:41PM -0400, Jon Smirl wrote:
On Fri, Mar 26, 2010 at 1:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
2) create a read/write sysfs node that would indicate the number of
event/keymaps
associated with a given IR. By writing a bigger number, it would
On Thu, Mar 25, 2010 at 07:32:59PM +0100, Pavel Machek wrote:
struct keycode_table_entry {
unsigned keycode;
int len;
char scancode[];
}
? gcc extension, but commonly used around kernel.
Flexible array members are ok in C99, aren't they?
--
David Härdeman
--
To
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
2) add current_protocol support on other drivers;
Done. Patch were already merged upstream.
The current_protocol attribute shows the protocol(s) that the device is
accepting
and allows changing it to another
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04,
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
2) add current_protocol support on other drivers;
Done. Patch were already merged upstream.
The current_protocol attribute shows the protocol(s) that the device is
accepting
and allows
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
On Fri, Mar 26, 2010 at 02:22:51PM -0300, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned
On Fri, Mar 26, 2010 at 12:17:34PM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
2) add current_protocol support on other drivers;
Done. Patch were already merged upstream.
The current_protocol
Hi!
Anyway, one simple way to avoid
resetting the hardware for every new parameter change would be to use a
timer
for reset. This way, an userspace application or script that is touching on
several parameters would just send the complete RX init sequence and
after some dozens of
Hi!
This were the original plan we've discussed, back in December:
Seems sane.
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
What about
struct keycode_table_entry {
Pavel Machek wrote:
Hi!
This were the original plan we've discussed, back in December:
Seems sane.
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
What about
struct
On Sun 2009-12-06 12:59:00, Christoph Bartelmus wrote:
Hi Dmitry,
on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
I do not believe you are being realistic. Sometimes we just need to say
that the device is a POS and is just not worth it. Remember, there is
still lirc hole for the
Pavel Machek wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.
I've committed already some IR restruct code on my linux-next -git
On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Pavel Machek wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available
Jon Smirl wrote:
On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Pavel Machek wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one
Hi!
(11) if none is against renaming IR as RC, I'll do it on a next patch;
Call it irc -- infrared remote control. Bluetooth remote controls will
have very different characteristics.
Pavel
--
(english)
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
(11) if none is against renaming IR as RC, I'll do it on a next
patch;
Call it irc -- infrared remote control. Bluetooth remote controls will
have very different
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
(11) if none is against renaming IR as RC, I'll do it on a next
patch;
Call it irc -- infrared
On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
(11) if none is against renaming IR as RC, I'll do
On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:45:14, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
On Tue, Dec 15, 2009
On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl jonsm...@gmail.com wrote:
On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
Untrue. Like ethernets and wifis, bluetooth devices have unique
addresses. Communication is bidirectional.
I read a little about how Bluetooth remotes work.
Dmitry Torokhov wrote:
On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't
On Sun, 6 Dec 2009, Krzysztof Halasa wrote:
Andy Walls awa...@radix.net writes:
Yes, I agree. I do not know what percentage of current Linux users are
technical vs non-technical, so I cannot gauge the current improtance.
I can see the trend line though: as time goes by, the percentage of
Dmitry Torokhov a écrit :
On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fusté wrote:
Mauro Carvalho Chehab wrote:
In summary,
While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up
to 16 bytes
(since a read loop for 2^16 is not that expensive), the current
Jon Smirl wrote:
On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available
Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
What about capabilities of the receiver, what frequencies?
If a receiver has multiple frequencies, how do you report what
frequency the data came in on?
IMO, via sysfs.
We probably need to think
On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Where is the documentation for the protocol?
I'm not sure what you're meaning here. I've started a doc about IR at
Mauro Carvalho Chehab mche...@redhat.com writes:
What is the interface for attaching an in-kernel decoder?
IMO, it should use the kfifo for it. However, if we allow both raw data and
in-kernel decoders to read data there, we'll need a spinlock to protect the
kfifo.
This may be an option,
Jon Smirl jonsm...@gmail.com writes:
Data could be sent to the in-kernel decoders first and then if they
don't handle it, send it to user space.
Nope. It should be sent to all of them, they aren't dependent.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe
Dmitry Torokhov dmitry.torok...@gmail.com writes:
Why woudl we want to do this? Quite often there is a need for observer
that maybe does not act on data but allows capturing it. Single-user
inetrfaces are PITA.
Lircd can work as a multiplexer. IMHO single-open lirc interface is ok,
though we
Mauro Carvalho Chehab mche...@redhat.com writes:
I don't think we need an userspace interface for the in-kernel
decoders.
Of course we need it, to set (and probably retrieve) scancode-keycode
mappings. This could probably be, ATM, the existing input layer channel.
All
it needs is to
Mauro Carvalho Chehab mche...@redhat.com writes:
Yes, an opaque type for scancode at the userspace API can be better, but
passing a pointer to kernel will require some compat32 logic (as pointer
size is different on 32 and 64 bits).
Yes. I think we can't avoid that, but it's a single compat
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
What is the interface for attaching an in-kernel decoder?
IMO, it should use the kfifo for it. However, if we allow both raw data and
in-kernel decoders to read data there, we'll need a spinlock to protect the
kfifo.
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
I don't think we need an userspace interface for the in-kernel
decoders.
Of course we need it, to set (and probably retrieve) scancode-keycode
mappings. This could probably be, ATM, the existing input layer channel.
On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
What is the interface for attaching an in-kernel decoder?
IMO, it should use the kfifo for it. However, if we allow both raw data and
Jon Smirl wrote:
On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Where is the documentation for the protocol?
I'm not sure what you're meaning here. I've started
Dmitry Torokhov dmitry.torok...@gmail.com writes:
No, the IR core responsible for registering receivers and decoders.
Well. This makes me think now that LIRC can be just another decoder.
Those are simple things. The only part which needs to be stable is the
(in this case LIRC) kernel-user
Mauro Carvalho Chehab mche...@redhat.com writes:
The enable/disable protocol decoder enable/disable interface is needed anyway,
due to the needs for the hardware IR decoders
Why do they need it exactly?
The key tables say all they need I hope?
--
Krzysztof Halasa
--
To unsubscribe from this
Mauro Carvalho Chehab mche...@redhat.com writes:
If you use a kfifo to store the event (space_or_mark, timestamp),
the IRQ handler can return immediately, and a separate kernel thread
can do the decode without needing to touch at the IRQ.
But the decoding itself is a really simple thing,
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
The enable/disable protocol decoder enable/disable interface is needed
anyway,
due to the needs for the hardware IR decoders
Why do they need it exactly?
The key tables say all they need I hope?
You can't upload a
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
If you use a kfifo to store the event (space_or_mark, timestamp),
the IRQ handler can return immediately, and a separate kernel thread
can do the decode without needing to touch at the IRQ.
But the decoding itself
On Tue, Dec 8, 2009 at 10:49 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
If you use a kfifo to store the event (space_or_mark, timestamp),
the IRQ handler can return immediately, and a separate kernel thread
can
On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
What about capabilities of the receiver, what frequencies?
If a receiver has multiple frequencies, how do you report what
On Tue, Dec 08, 2009 at 09:17:42AM -0200, Mauro Carvalho Chehab wrote:
Jon Smirl wrote:
On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Where is the documentation for the protocol?
I'm not sure what you're meaning here. I've started a doc about IR at the
On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote:
Dmitry Torokhov dmitry.torok...@gmail.com writes:
Why woudl we want to do this? Quite often there is a need for observer
that maybe does not act on data but allows capturing it. Single-user
inetrfaces are PITA.
Lircd can
Hi Dmitry,
on 06 Dec 09 at 23:51, Dmitry Torokhov wrote:
[...]
I suppose we could add MSC_SCAN_END event so that we can transmit
scancodes of arbitrary length. You'd get several MSC_SCAN followed by
MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
bit.
And I set a
Hi Jon,
on 08 Dec 09 at 08:34, Jon Smirl wrote:
[...]
The point of those design review questions was to illustrate that the
existing LIRC system is only partially designed. Subsystems need to be
fully designed before they get merged.
I'd say that a system that has proven itself in real world
Hi Andy,
on 07 Dec 09 at 23:10, Andy Walls wrote:
[...]
(Christoph can correct me if I get anything wrong.)
Just a few additions.
[...]
What is the time standard for the data, where does it come from?
I think it is usec, IIRC.
Yes, it is.
I know that the hardware I work with has sub 100
On Tue, 2009-12-08 at 23:30 +0100, Christoph Bartelmus wrote:
Hi Andy,
on 07 Dec 09 at 23:10, Andy Walls wrote:
[...]
(Christoph can correct me if I get anything wrong.)
Just a few additions.
Christoph,
Thanks for the corrections and additions. :)
[...]
I know that the hardware I
Dmitry Torokhov wrote:
On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not
Jon Smirl wrote:
On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first?
That's fine for me.
In-kernel
decoding can wait a bit, it doesn't change any
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
Scancodes in input system never been real scancodes. Even if you look
into atkbd it uses some synthetic data composed out of real scancodes
sent to the keyboard, and noone cares. If you are unsatisfied with
mapping
On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user
Dmitry Torokhov dmitry.torok...@gmail.com writes:
There is only one thing which needs attention before/when merging LIRC:
the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
actually, making a correct IR core design without the LIRC merged can be
only harder.
This sounds
On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote:
Dmitry Torokhov dmitry.torok...@gmail.com writes:
There is only one thing which needs attention before/when merging LIRC:
the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
actually, making a correct IR
Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
Scancodes in input system never been real scancodes. Even if you look
into atkbd it uses some synthetic data composed out of real scancodes
sent to the keyboard, and noone cares. If you are
Emmanuel Fusté wrote:
Mauro Carvalho Chehab wrote:
In summary,
While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes
up to 16 bytes
(since a read loop for 2^16 is not that expensive), the current approach
won't scale with bigger scancode spaces. So, it is needed expand it
Let me add my view for those questions.
Jon Smirl wrote:
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
Christoph Bartelmus wrote:
Hi Jon,
on 04 Dec 09 at 19:28, Jon Smirl wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit
scan codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose receiver (not one with fixed hardware
decoding), is it important
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
struct input_keytable_entry {
u16 index;
u64 scancode;
u32 keycode;
} __attribute__ ((packed));
(the attribute packed avoids needing a compat for 64 bits)
Maybe { u64 scancode; u32
On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Let me add my view for those questions.
Jon Smirl wrote:
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC
On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.
The core
On Sun, 2009-12-06 at 16:23 -0500, Jon Smirl wrote:
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:
Let me add my view for those questions.
Jon Smirl wrote:
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
How related lirc-core to the current lirc code? If it is not the same
maybe we should not call it lirc to avoid confusion.
Just for better illustrate what I'm seeing, I broke the IR generic
code into
Dmitry Torokhov wrote:
Hi,
On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
Hi,
Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de
wrote:
BTW, I just came across a XMP remote that seems to
Hi Dmitry,
on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
I do not believe you are being realistic. Sometimes we just need to say
that the device is a POS and is just not worth it. Remember, there is
still lirc hole for the hard core people still using solder to produce
something out of
Hi Dmitry,
on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
http://lirc.sourceforge.net/remotes/lg/6711A20015N
This is an air-conditioner remote.
The entries that you see in this config file are not really separate
buttons. Instead the remote just sends the current settings for e.g.
Hi Jon,
on 04 Dec 09 at 19:28, Jon Smirl wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit
scan codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose receiver (not one with fixed hardware
decoding), is it important for Linux to receive IR
On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus l...@bartelmus.de wrote:
Hi Jon,
on 04 Dec 09 at 19:28, Jon Smirl wrote:
BTW, I just came across a XMP remote that seems to generate 3x64 bit
scan codes. Anyone here has docs on the XMP protocol?
Assuming a general purpose receiver (not
Andy Walls awa...@radix.net writes:
Yes, I agree. I do not know what percentage of current Linux users are
technical vs non-technical, so I cannot gauge the current improtance.
I can see the trend line though: as time goes by, the percentage of all
linux users that have a technical bent
Mauro Carvalho Chehab mche...@redhat.com writes:
I do not believe you are being realistic. Sometimes we just need to say
that the device is a POS and is just not worth it. Remember, there is
still lirc hole for the hard core people still using solder to produce
something out of the spare
On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
I'd like to see a
Mauro Carvalho Chehab mche...@redhat.com writes:
All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way
to implement
EVIO[S|G]KEYCODE.
I know, however, one i2c chip
Jon Smirl jonsm...@gmail.com writes:
The in-kernel support can start small and add protocols and maps over
time.
Protocols, yes. Maps - we certainly don't want megatons of maps in the
kernel. The existing ones have to be removed, some time.
--
Krzysztof Halasa
--
To unsubscribe from this
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
I'd like to see a semi-complete design for an in-kernel IR
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
Jon Smirl jonsm...@gmail.com writes:
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user
On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you
On Sun, Dec 06, 2009 at 12:58:00PM +0100, Christoph Bartelmus wrote:
Hi Dmitry,
on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
http://lirc.sourceforge.net/remotes/lg/6711A20015N
This is an air-conditioner remote.
The entries that you see in this config file are not really
1 - 100 of 221 matches
Mail list logo
