Jon Smirl wrote:
> On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
> 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 thi
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
> >> wrote:
> >>> [1] Basically, a keycode (like KEY_POWER) could be used to wa
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
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 neither.
On my e
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
>> 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,
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
> 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 progra
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
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 corresponding scan
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
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/stand
On Fri, Apr 9, 2010 at 8:58 AM, Jarod Wilson 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 th
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 mentioned yet, but are there any plans for a sysfs
> > i
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
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 d
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
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 com
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
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
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/var
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
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
> 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 create new
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 do
On Fri, Mar 26, 2010 at 1:22 PM, 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 ta
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 curre
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;
> >>> unsigne
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
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.
> >>
> >>
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
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 EVIOCGKE
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'
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 ano
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 u
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;
>> }
>
>
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
I got some progress about the IR redesign.
I didn't followed the exact order of the tasks, but I think I've reached an
interesting
point where it is now possible to merge lirc_dev driver and to add the decoders
to ir-core.
I've setup an experimental tree with upstream+V4L/DVB development and so
On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote:
>> Untrue. Like ethernets and wifis, bluetooth devices have unique
>> addresses. Communication is bidirectional.
I read a little about how Bluetooth remotes work. Correct me if I get
things w
On Tue 2009-12-15 15:45:14, Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote:
> > On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
> >> On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote:
> >> > On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
> >> >> On Tue, Dec 15, 2009 at 2:58 P
On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote:
> On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
>> On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote:
>> > On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
>> >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote:
>> >> > Hi!
>> >> >
>> >> >>
On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote:
> > On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
> >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> (11) if none is against renaming IR as RC, I'll do it on a
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote:
> On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
>> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> (11) if none is against renaming IR as RC, I'll do it on a next
>> >> patch;
>> >
>> > Call it irc -- infrared rem
On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek 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 diffe
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek 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 characteristics.
How are they different after the scancode
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) http://www.li
Jon Smirl wrote:
> On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
> 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
On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
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 decoder
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-n
> > This sounds like "merge first, think later"...
> >
> > The question is why we need to merge lirc interface right now, before we
> > agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev
> > yet and, looking at the way things are shaping, no drivers will be
> > _directly_ using
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"
Dmitry Torokhov wrote:
> On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
>> Jon Smirl 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
On Sat 2009-11-28 21:21:57, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
> > We have one IR receiver device and multiple remotes. How does the
> > input system know how many devices to create corresponding to how many
> > remotes you have? There is no current mechanism to do that. You need
> > a
On Sun, 6 Dec 2009, Krzysztof Halasa wrote:
Andy Walls 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 tha
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 h
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
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 worl
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.
>>
On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov 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 mul
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
> > 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 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 rep
On Tue, Dec 8, 2009 at 10:49 AM, Mauro Carvalho Chehab
wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab 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
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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 real
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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 key for
Mauro Carvalho Chehab 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, why complicate it?
Mauro Carvalho Chehab 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 list: send the lin
Dmitry Torokhov 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 interface.
>
> For wh
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
>>> 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
On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab
wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab 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
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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.
This is t
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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
Mauro Carvalho Chehab 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 handler,
I wouldn
Mauro Carvalho Chehab 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 enable/disable the pro
Dmitry Torokhov 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 obviously need simult
Jon Smirl 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 linux-media" in
the b
Mauro Carvalho Chehab 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, but I think we
On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
>> 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
>>> media
>>
>> Wha
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 n
Jon Smirl wrote:
> On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
> 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 co
Jon Smirl wrote:
> On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
> 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
>> media
>
> What is the format of the pulse stream data coming out of the lirc device?
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 appr
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 wrote:
> >> Jon Smirl writes:
> >>
> Once again: how about agreement about the LIRC interface
> (ke
On Sun, 2009-12-06 at 16:23 -0500, Jon Smirl wrote:
> On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote:
> > Jon Smirl writes:
> >
> >>> Once again: how about agreement about the LIRC interface
> >>> (kernel-userspace) and merging the actual LIRC code first? In-kernel
> >>> decoding can wait
On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
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 needs to allow for RF rem
On Mon, Dec 7, 2009 at 6:44 PM, 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 wrote:
>>> Jon Smirl writes:
>>>
> Once again: how about agreement about the LIRC interface
> (kernel-userspace)
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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 keyc
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 i
Let me add my view for those questions.
Jon Smirl wrote:
> On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote:
>> Jon Smirl writes:
>>
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wai
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 neede
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
On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov 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 w
Dmitry Torokhov 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 like "merge fi
On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
> Jon Smirl 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
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
> > m
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
to work with bigger scancod
Jon Smirl wrote:
> On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa 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 kernel-user in
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 escreveu:
> evdev does not reall
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 con
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 escreveu:
> >>
> >>> evdev does not really care what you use as sca
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote:
> Jon Smirl 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 l
Jon Smirl 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 system
> be
Jon Smirl 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 list: send the line "
Mauro Carvalho Chehab 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 that returns a
On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa 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 semi-complete design
Mauro Carvalho Chehab 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 electronic co
1 - 100 of 257 matches
Mail list logo
