On Mon, 23 Nov 2009, Krzysztof Halasa wrote:
Devin Heitmueller 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
Jon Smirl wrote:
>> I don't like the idea of automatically loading 3 different keycodes at the
>> same time. You may have overlaps between different keycode tables. The
>> better is to have some userspace GUI that will allow the user to select
>> what keycode table(s) he want to be available, if h
Dmitry Torokhov wrote:
> I am a resonable guy ;) In cases when we can certainly say that there
> are 2 separate remotes (and we know characteristics somehow) we need to
> create 2 input devices. Otherwise we can't ;)
Only on very few specific cases (a few protocols), you can be (almost) sure.
Ev
Krzysztof Halasa wrote:
> Jon Smirl writes:
>
>> Why do you want to pull the 1KB default mapping table out of the
>> device driver __init section and more it to a udev script? Now we will
>> have to maintain a parallel udev script for ever receiver's device
>> driver.
>
> Of course no. We will n
Jon Smirl writes:
> Why do you want to pull the 1KB default mapping table out of the
> device driver __init section and more it to a udev script? Now we will
> have to maintain a parallel udev script for ever receiver's device
> driver.
Of course no. We will need a single program (script etc.) f
On Tue, Dec 8, 2009 at 11:27 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
>> wrote:
>>> Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:3
On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote:
> On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
> > Andy Walls wrote:
> > > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>
> > > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > > end
On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
> > On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> >> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >
> >> > So I'll whip up an RC-6 Mode 6A decoder for cx238
On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> >>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> >>>
> On Thu, 2009-
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
>>> wrote:
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
> wrote:
>> Andy Walls wrote:
>
Mauro Carvalho Chehab writes:
> Jon Smirl wrote:
>
>> This model is complicated by the fact that some remotes that look
>> like multi-function remotes aren't really multifunction. The remote
>> bundled with the MS MCE receiver is one. That remote is a single
>> function device even though it has
On Tue, Dec 8, 2009 at 9:40 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
>> wrote:
>>> Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 7:35
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
>> wrote:
>>> Jon Smirl wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
wrote:
> Andy Walls wrote:
>> On Mon, 2009-12-07 at 20:2
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
>>> wrote:
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
>> On Mon, 2009-12-07 at 20:22 -0800, Dmitr
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>>> wrote:
Andy Walls wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On Mon, Dec 07, 2009 at 09:42:22
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
>> wrote:
>>> Jon Smirl wrote:
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>> IMO, the better is to have an API to allow creation of multiple interfaces
>> per IR receiver, based on some scancode matching table and/or on some
>> matching mask.
>
> I think setting the keytables for each logical device would do.
Yes
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>> wrote:
>>> Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>> So I'
Mauro Carvalho Chehab writes:
> With RC-5, you have no fields describing the remote. So, all the driver could
> do is an educated guess.
It can't even do that, e.g. single remotes (even the dumb ones) can send
different code groups (addresses) for different keys.
> IMO, the better is to have an
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> So I'll whip up an RC-6 Mode 6A
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
> wrote:
>> Andy Walls wrote:
>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c be
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
wrote:
> Andy Walls wrote:
>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of t
Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.
Andy Walls wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>
>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>> end of the month.
>>>
>>> I can setup the CX2388[58] hardware to look for bo
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>
>> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>> > end of the month.
>> >
>> > I can setup th
On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > end of the month.
>
> Good! Please, try to design the decoder as an indepen
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > end of the month.
> >
> > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>>>
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
>>
Andy Walls wrote:
> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>>
>>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
Krzysztof Halasa wrote:
> Andy Walls writes:
>
>> I would also note that RC-6 Mode 6A
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> > On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> >
> > > On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> > >> Krzysztof Halasa wrote:
> > >>> Andy Walls write
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>
> > On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> >> Krzysztof Halasa wrote:
> >>> Andy Walls writes:
> >>>
> I would also note that RC-6 Mode 6A, used by most MCE r
Jarod Wilson wrote:
> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>
>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
>> Maybe I'm being too conservative here, but I have a personal interest in
>> keeping Linux free and unencumbered even in the US which, I cannot deny,
>> has
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
>> Krzysztof Halasa wrote:
>>> Andy Walls writes:
>>>
I would also note that RC-6 Mode 6A, used by most MCE remotes, was
developed by Philips, but Microsoft has some sort of
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
> wrote:
>>> In the code I posted there is one evdev device for each configured
>>> remote. Mapped single keycodes are presented on these devices for each
>>> IR burst. There is no device for the IR
On Saturday 28 November 2009, Mauro Carvalho Chehab wrote:
> After deleting 49 keys, you'll need to add the 55 new keys.
> If we do dynamic table resize for each operation, we'll do 104
> sequences of kmalloc/kfree for replacing one table.
Given that kmalloc only does power-of-two allocations, y
Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
[scancode-to-keycode map size]
>> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for
>> scancode that would be out of bounds for the current table (if using
>> table approach)?
[...]
> Let's suppose, for example that instead of usi
Dmitry Torokhov wrote:
> On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
>> Em Thu, 26 Nov 2009 17:06:03 -0200
>> Mauro Carvalho Chehab escreveu:
>>
>>> Krzysztof Halasa wrote:
Mauro Carvalho Chehab writes:
> Technically, it is not hard to port this solution t
On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Nov 2009 17:06:03 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Krzysztof Halasa wrote:
> > > Mauro Carvalho Chehab writes:
> > >
> > >> Technically, it is not hard to port this solution to the other
> > >> driv
Em Thu, 26 Nov 2009 17:06:03 -0200
Mauro Carvalho Chehab escreveu:
> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab writes:
> >
> >> Technically, it is not hard to port this solution to the other
> >> drivers, but the issue is that we don't have all those IR's to know
> >> what is the comple
On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus wrote:
> Hi Jon,
>
> on 27 Nov 09 at 00:06, Jon Smirl wrote:
> [...]
>> code for the fun of it, I have no commercial interest in IR. I was
>> annoyed with how LIRC handled Sony remotes on my home system.
>
> Can you elaborate on this?
> I'm not
Hi Mauro,
on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
>> because I'm not familiar at all with input layer toolset.
[...]
> I hope it helps for you to better understand how this
Hi Jon,
on 27 Nov 09 at 00:06, Jon Smirl wrote:
[...]
> code for the fun of it, I have no commercial interest in IR. I was
> annoyed with how LIRC handled Sony remotes on my home system.
Can you elaborate on this?
I'm not aware of any issue with Sony remotes.
Christoph
--
To unsubscribe from thi
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
wrote:
>> In the code I posted there is one evdev device for each configured
>> remote. Mapped single keycodes are presented on these devices for each
>> IR burst. There is no device for the IR receiver. A LIRC type process
>> could watch these de
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson wrote:
> >> No, at present we expect 1:1 button->event mapping leaving macro
> >> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
> >> userspace).
> >
> > Hm. So ctrl-x, alt-ta
On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote:
> On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
>> On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>>>
On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wr
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson wrote:
>> No, at present we expect 1:1 button->event mapping leaving macro
>> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
>> userspace).
>
> Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
> Bummer.
That is
Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho:
> On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> > >> See above. Also, several protocols have a way to check if a keystroke
> > >> were
> > >> properly received. When handling just one protocol, we can use this to
> > >> doubl
On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
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
Dmitry Torokhov wrote:
> On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry,
>>
>> While lirc is basically a series of input drivers, considering that they
>> have lots
>> in common with the input drivers at V4L/DVB and that we'll need to work on
>> some glue to merge
Trent Piepho writes:
> Then you use the protocol that fits best. For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode. Clearly then the latter is
> most likely to be correct.
Right.
> It also
Dmitry Torokhov writes:
> There is nothing in input layer that precludes you from creating
> multiple input devices per *whatever*.
Of course. I though it was obvious I mean present situation with the
media drivers but I can see now it was far from being obvious.
--
Krzysztof Halasa
--
To unsub
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > Why do you want to replace everything into a single shot?
>
> Why not? It seems simpler to me. We need to change this anyway.
ioctls with a variable argument length are a pain for 32 bit
emulation
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> >> One remote per
> >> device only.
> >
> > Why would you want more? One physical device usually corresponds to a
> > logical device. If you have 2 remotes create 2 devices.
>
> I meant "per receiver
Mauro Carvalho Chehab writes:
> Why do you want to replace everything into a single shot?
Why not? It seems simpler to me. We need to change this anyway.
If we change the whole table in a single ioctl, we can easily enumerate
protocols requested and enable then selectively.
But I think it's a m
Dmitry Torokhov writes:
>> One remote per
>> device only.
>
> Why would you want more? One physical device usually corresponds to a
> logical device. If you have 2 remotes create 2 devices.
I meant "per receiver device".
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsub
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>
> Dmitry,
>
> While lirc is basically a series of input drivers, considering that they have
> lots
> in common with the input drivers at V4L/DVB and that we'll need to work on
> some glue to merge both, do you mind if I add
On Wed, Nov 25, 2009 at 10:58:29PM +0100, 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-
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
> 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 Hal
On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the who
On Thu, Nov 26, 2009 at 07:05:01PM -0200, Mauro Carvalho Chehab wrote:
>
> For example, the two ioctls to replace a scancode x key code are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> >> that support only pulse/space raw mode and devices that generate scan
> >> codes via the raw mode interface. It does it by generating artificial
> >> pulse codes.
>
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> See above. Also, several protocols have a way to check if a keystroke were
> >> properly received. When handling just one protocol, we can use this to
> >> double
> >> check the key. However, on a multiprotocol mode, we'll need to disable this
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
>> Christoph Bartelmus wrote:
> [...]
lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the whole table I think), and we can
> have arbitr
Hi Mauro,
on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>>> that support only pulse/space raw mode and devices that generate scan
>>> codes via the raw mode interface. It does it
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa wrote:
Dmitry Torokhov writes:
In what way the key interface is unsufficient for delivering button
events?
At present: 128 different keys only (RC5: one group).
Where did this limitation come from? We have more than 256 keycodes
already _de
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>>
>> After having it for a while, we should deprecate the in-kernel keyma
Mauro Carvalho Chehab writes:
> No. All the other API functions there work with 32 bits for scancodes.
We don't need them, do we? We need a new ioctl for changing key mappings
anyway (a single ioctl for setting the whole table I think), and we can
have arbitrary length of scan codes there.
> (w
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> see include/linux/input.h:
>>
>> struct input_event {
>> struct timeval time;
>> __u16 type;
>> __u16 code;
>> __s32 value;
>> };
>>
>> extending the value to more than 32 bits require some changes at the
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
> [...]
>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>> that support only pulse/space raw mode and devices that generate scan
>> codes via the raw mode interface. It does
Hi Mauro,
on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
[...]
> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> that support only pulse/space raw mode and devices that generate scan
> codes via the raw mode interface. It does it by generating artificial
> pulse co
Mauro Carvalho Chehab writes:
> see include/linux/input.h:
>
> struct input_event {
> struct timeval time;
> __u16 type;
> __u16 code;
> __s32 value;
> };
>
> extending the value to more than 32 bits require some changes at the
> input layer, probably breaking kern
Mauro Carvalho Chehab writes:
> The removal of the existing keymaps from kernel depends on having an
> application
> to be called from udev to load the proper keymaps when a device is probed.
>
> After having it for a while, we should deprecate the in-kernel keymaps
> and move them to userspace.
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Andy Walls writes:
> >
> >> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >> developed by Philips, but Microsoft has some sort of licensing interest
> >> in it and it is almost sur
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The issue I see is to support at the same time NEC and RC5 protocols. While
>> this may work with some devices, for others, the hardware won't allow.
>
> Sure. We can handle it for the "simple" devices at least.
>
>>> I think the mapp
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Technically, it is not hard to port this solution to the other
>> drivers, but the issue is that we don't have all those IR's to know
>> what is the complete scancode that each key produces. So, the hardest
>> part is to find a way for
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> 1) the developer that adds the hardware also adds the IR code. He has
>> the hardware and the IR for testing, so it means a faster development
>> cycle than waiting for someone else with the same hardware and IR to
>> recode it on some
Mauro Carvalho Chehab writes:
> The issue I see is to support at the same time NEC and RC5 protocols. While
> this may work with some devices, for others, the hardware won't allow.
Sure. We can handle it for the "simple" devices at least.
>> I think the mapping should be: key = proto + group +
Mauro Carvalho Chehab writes:
> Technically, it is not hard to port this solution to the other
> drivers, but the issue is that we don't have all those IR's to know
> what is the complete scancode that each key produces. So, the hardest
> part is to find a way for doing it without causing regress
Mauro Carvalho Chehab writes:
> 1) the developer that adds the hardware also adds the IR code. He has
> the hardware and the IR for testing, so it means a faster development
> cycle than waiting for someone else with the same hardware and IR to
> recode it on some other place. You should remember
Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
>> In what way the key interface is unsufficient for delivering button
>> events?
>
> At present: 128 different keys only (RC5: one group). One remote per
> device only.
>
> The protocol itself doesn't have the above limitations, but has other
Jarod Wilson wrote:
> On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
>> Jarod Wilson wrote:
>>> 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
Dmitry Torokhov writes:
> In what way the key interface is unsufficient for delivering button
> events?
At present: 128 different keys only (RC5: one group). One remote per
device only.
The protocol itself doesn't have the above limitations, but has others,
with are acceptable for key input.
--
On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
Jarod Wilson wrote:
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 perce
On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:
On 11/26/09 07:23, Jarod Wilson wrote:
Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.
lirc predates the input layer IR drivers by years, maybe even the input
layer it
Gerd Hoffmann writes:
> Why not? With RC5 remotes applications can get the device address
> bits for example, which right now are simply get lost in the ir code
> ->
> keycode conversion step.
Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think t
Andy Walls wrote:
> On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
>> I'm not sure if all the existing hardware for TX currently supports only
>> raw pulse/code sequencies, but I still think that, even on the Tx case,
>> it is better to send scancodes to the driver, and let it do
Christoph Bartelmus wrote:
> Hi,
>
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
>> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
>> be this:
> [...]
>> [*] assuming, of course, that it was actually agreed upon that in-kernel
>> decoding was the right way, the o
Jarod Wilson wrote:
>> I guess the question is what is the interface we want the regular
>> userspace (i.e. not lircd) to use. Right now programs has to use 2
>> intercfaces - one lirc for dealing with remotes that are not using
>> the standard event interface and evdev for remotes using it as wel
BTW, we used to have device specific user space interfaces for mouse
and keyboard. These caused all sort of problems. A lot of work went
into unifying them under evdev. It will be years until the old,
messed up interfaces can be totally removed.
I'm not in favor of repeating the problems with a d
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
wrote:
> Gerd Hoffmann wrote:
>> On 11/25/09 19:20, Devin Heitmueller wrote:
>>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>>> wrote:
Took me a minute to figure out exactly what you were talking
about. You're referring to the cur
Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>> 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 remot
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.
>>> Everything works, no code ne
Krzysztof Halasa wrote:
> Andy Walls writes:
>
>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>> developed by Philips, but Microsoft has some sort of licensing interest
>> in it and it is almost surely encumbered somwhow:
>
> I don't know about legal problems in some count
Jarod Wilson wrote:
> 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
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > 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
Andy Walls wrote:
> 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
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab writes:
> PS.: For those following those discussions that want to know more about
> IR protocols, a good reference is at:
> http://www.sbprojects.com/knowledge/ir/ir.htm
>
>
Andy Walls wrote:
> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception).
> Regards,
> Andy "LIRC Fan-Boy" Walls
This is not a lirc love or hate thread. We're simply discussing the better
API's for IR, from the technical standpoint,
1 - 100 of 164 matches
Mail list logo
