On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson wrote:
> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus
>> wrote:
>> > Hi!
>> >
>> > Jon Smirl "jonsm...@gmail.com" wrote:
>&g
On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus wrote:
> Hi!
>
> Jon Smirl "jonsm...@gmail.com" wrote:
> [...]
>>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>>> decode in-kernel for the life of me. I got lirc
On Mon, Aug 2, 2010 at 11:12 AM, Jarod Wilson wrote:
> On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote:
> ...
>> > Since these two protocols have such close timings that systematic errors
>> > can caus
On Sun, Aug 1, 2010 at 10:00 AM, Jon Smirl wrote:
> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
>>> wrote:
>>>>
On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus wrote:
> Hi Jon,
>
> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
>> wrote:
>>> Hi Jon,
>>>
>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
&
On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote:
> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
>> wrote:
>> > Hi Jon,
>> >
>> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>
On Sat, Jul 31, 2010 at 2:14 PM, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls
>>> wrote:
>>>> I t
On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus wrote:
> Hi Jon,
>
> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls
>> wrote:
>>> I think you won't be able to fix the problem conclusively either way. A
>>
math in calculator and
plugging in 32. Use #defines and do the math in the code.
Maybe something like
#define sample_period (1 / (32768 * 1000))
Then don't store this constant in a variable since it will cause a
round off. Just use it directly in the computation.
>
> Regards,
>
On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
wrote:
> On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
>> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
>> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
>> > > On Fri, Jul 30, 2010 at 8:02 AM,
On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl wrote:
> On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky
> wrote:
>> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky
>>> wrote:
>>> > On Thu, 2
On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky
>> wrote:
>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> >> On Thu, 2010-0
On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky wrote:
> On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> > wrote:
>> > > note that
d add a quirk in the
system boot code to fix the register setting.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t have to use the code.
There are lots of ways to design it. A simple one would be to sit on
each message until the next one arrives. Then make a decision to pass
the previous message up or declare the current edge a glitch and wait
for the next one. It probably needs a timeout so that you don
On Wed, Jul 28, 2010 at 1:21 PM, Andy Walls wrote:
> On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote:
>> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
>> wrote:
>> > Em 28-07-2010 11:41, Jon Smirl escreveu:
>
>>
>> Are there any IR protocols
On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls wrote:
> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 11:53, Jon Smirl escreveu:
>> > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls
>> > wrote:
>> >> On Wed, 2010-07-28 at
On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
wrote:
> Em 28-07-2010 11:41, Jon Smirl escreveu:
>
>> It's possible to build a Linux IR decoder engine that can be loaded
>> with the old LIRC config files.
>
> I think it is a good idea to have a decoder that
On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls wrote:
> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>> Let's be really sure it is NEC and not JVC.
>>
>> > > 8850 4350 525 1575 525 1575
>> > > 525 450 5
On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky
wrote:
> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 07:40, Jon Smirl escreveu:
>> > On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky
>> > wrote:
>> >> On Tue, 2010-0
So the question is, why didn't JVC
decoder get out of state zero?
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky wrote:
> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl wrote:
>> > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky
>> > wrote:
>> >> On Wed, 2010-07-
On Sat, Jun 5, 2010 at 1:24 PM, Andy Walls wrote:
> On Fri, 2010-06-04 at 14:57 -0400, Jon Smirl wrote:
>> On Fri, Jun 4, 2010 at 2:38 PM, Mauro Carvalho Chehab
>> wrote:
>> > Em 04-06-2010 12:51, Christoph Bartelmus escreveu:
>> >> Hi Mauro,
>> >
On Fri, Jun 4, 2010 at 5:17 PM, Jarod Wilson wrote:
> On Fri, Jun 4, 2010 at 4:17 PM, Jarod Wilson wrote:
>> On Fri, Jun 04, 2010 at 02:57:04PM -0400, Jon Smirl wrote:
> ...
>>> > From what I'm seeing, those are the current used ioctls:
>>> >
>>>
hose ioctls are related to config stuff, IMO, using sysfs would be
> better, but
> I haven't a closed opinion about that matter.
In general sysfs is used to set options that are static or only change
infrequently.
If the parameter is set on every request, use an IOCTL.
>
> Btw, a lirc userspace that would work with both the out-of-tree and in-tree
> lirc-dev
> can easily check for the proper sysfs nodes to know what version of the
> driver is being
> used. It will need access sysfs anyway, to enable the lirc decoder.
>
> Cheers,
> Mauro.
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
M does not
have many to 1 mappings. My radio receivers show up as network
devices. So I have multiple devices too.
I don't think we want a 'rc' device. The IR transceiver should be an
'ir' device. My radios are already 'net' devices. So my complaint
really is, I
On Sat, Apr 24, 2010 at 10:15 AM, David Härdeman wrote:
> On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote:
>> On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman wrote:
>> > On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote:
>> >> Not that my commi
ctions could be used to wrap input
parameter setting. Start an input transaction, set the TX variables,
send the pulse data, end the input transaction. I don't remember if I
got around to implementing that.
>
> That same chardev could also be used to implement TX, once a suitable
> int
will want to work with the new in-kernel system
than the compatibility layer to LIRC. Existing users that are happy
with the current LIRC should just keep on using it.
MSMCE is a good device for debugging protocol engines. It's easy to
use and pretty much always captures the pulses correctly.
e just one unsigned int and it is
>> clearly indicated what's mark and what's duration.
>
> If all three of you agree on this approach, I'll write a patch to convert
> ir-core to use it instead.
Fine with me.
>
> --
> David Härdeman
>
--
Jon Smirl
p
pattern match. An enterprising hacker can probably change the firmware
in the existing devices.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
On Fri, Apr 9, 2010 at 10:00 AM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>>>>
>>>> +/* macros for ir decoders */
>>>> +#define PULSE(units) ((units))
>>>> +#define SPACE(units) (-(units
ing something into
> somewhere in sysfs (for the usb controller its attached to) to enable it,
You probably need to tell the USB system to leave the MSMCE's power
turned on during suspend. Maybe the MSMCE driver can tell the USB
subsystem to leave it powered across suspend when the driver loads.
lse)
>> - goto err;
>> - data->code = 1;
>> - data->last_bit = 1;
>> - data->elapsed = 0;
>> - memset(&data->rc5_code, 0, sizeof(data->rc5_code));
>> - data-
edia/IR/ir-raw-event.c 2010-04-06 12:16:27.0
>> +0200
>> +++ ir/drivers/media/IR/ir-raw-event.c 2010-04-07 21:32:13.961850481
>> +0200
>> @@ -15,13 +15,14 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /* Define the max number of bit transitions per IR keycode */
>> #define MAX_IR_EVENT_SIZE 256
>>
>> /* Used to handle IR raw handler extensions */
>> static LIST_HEAD(ir_raw_handler_list);
>> -static spinlock_t ir_raw_handler_lock;
>> +static DEFINE_SPINLOCK(ir_raw_handler_lock);
>
> (just a side note: I had to do the above change already, due to some lock
> troubles I'm
> having - Patch were already send to the -git tree).
>
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- data->code <<= 2;
> -
> - if (data->elapsed >= (RC5_NBITS - 1) * 2) {
> - scancode = data->code;
> -
> - /* Check for the start bits */
> - if ((scancode & 0x
far no
one has complained about it (they have complained about my pilot
errors using it).
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
f the decoders, don't wait for a long space and then feed the
entire message into the decoders.
>
> --
>
> Cheers,
> Mauro
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
}
These delay messages are then fed into the protocol engines which
process the pulses in parallel. Processing in parallel works, because
that's how IR receivers work. When you shine a remote on an equipment
rack, all of the equipment sees the command in parall
lude/media/ir-core.h | 59 +-
> 18 files changed, 1368 insertions(+), 129 deletions(-)
> create mode 100644 drivers/media/IR/ir-nec-decoder.c
> create mode 100644 drivers/media/IR/ir-raw-event.c
>
> --
> To unsubscribe from this list: send the line "
he number of
> event/keymaps
> associated with a given IR. By writing a bigger number, it would create new
> devices.
> By writing a smaller number, it will delete some maps. There's an issue
> though:
> what criteria would be used to delete? The newly created ones?
This is norm
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
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, P
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
&g
ng code would
use the same API as IR to submit it to input.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_dev module integrating it into ir-core and with the
> reviewed API;
>
> (10) depends on EVIO[G|S]KEYCODE discussions we've already started. I
> did a proposal
> about it. I'll review, based on the comments and re-submit it;
>
> (11) if none is aga
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:
>&g
it. For example,
> 16 pulse/space events correspond to 8 bits of data on most protocols,
> so you can wake the kthread only after 16 events for really simple decoders,
> or if a timeout event is detected. The number of events to wake may be
> customized
> per decoder.
>
> Cheers,
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:
>&g
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:
>>
ead
empties the FIFO and sends the pulses in parallel to the decoders.
Code for doing this is in the patches I posted. I wasn't aware of
kfifo when I wrote them so I coded my own fifo.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 Mo
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,
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:
>
other equipments. It happens that
> vendor's "reserved address" can be different between two different vendors,
> but is just an educated guess to say that an address equal to 0x1e is
> Hauppauge.
>
> Cheers,
> Mauro.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 he
.
> Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.
>
>
>
>> Applications
>> expect to query device capabilities and expect them to stay somewhat
>> stable (we do support keymap change but I don't think anyone expectes
>> flip-flopping).
&g
ng down to the scancodes probably
happens over in the networking code.
After an in-kernel IR decoder runs it needs to hand off the scancodes
into the input subsystem. This same API can be used by the networking
code to hand off RF scancodes.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this
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
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 chang
see a semi-complete design for an in-kernel IR system
before anything is merged from any source.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Dec 6, 2009 at 7:12 AM, 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?
>>
>> Assum
On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls wrote:
> On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
>> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus
>> wrote:
>> > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
>> > codes
something like LIRC if you want to transmit.
My goal was to make it simple for people to do really basic tasks like
using a remote to pause their music player. Something like: plug in
MSMCE receiver, program remote to send codes for Sony CR-114 mp3
player, hit pause button, music stops.
--
Jo
ously supplied to all modules. That
will make it easy to work on the protocol converters - just
insmod/rmmod as you make changes. These engines can be extracted from
the LIRC code and turned into modules.
Where are IR repeat bits going to be handled?
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscr
very limited number of changes that
> may be needed:
>
> - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are
> unable to limit ourselves to 32 bits (keeping compatibility of course)
>
> - Maybe adding new ioctl to "zap" the keymap table
>
> - Adding more key EV_KEY/KEY_* definitons, if needed
Aren't EV_IR events needed so that an app for building keymaps can be written?
Normal apps would not use EV_IR events.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
program to
> handle it (lirc or other programs that knows IR keycodes);
>
> 2) to implement Jon's filter idea of splitting one evdev interface into
> several evdevs interface, one for each address.
>
> We should not forget that simple IR's don't have any key to select the
> address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
>
> Cheers,
> Mauro.
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mple use case:
You have a multifunction remote. Press the CABLE key - it sends out
commands that control the cable box, press the TV key - now the
commands control the TV, press CD - now the CD player, etc.
Now imagine a headless Linux box running a music server and a home
automation app. Pre
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
wrote:
> Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>
>>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilso
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>> (for each remote/substream that
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
> wrote:
>> Dmitry Torokhov wrote:
>>>> The raw interface applies only to the devices that doesn't have a hardware
>>>> decoder
>>>>
ach remote.
>
>>>> (for each remote/substream that they can recognize).
>>> I'm assuming that, by remote, you're referring to a remote receiver (and
>>> not to
>>> the remote itself), right?
>>
>> If we could separate by remote t
On Wed, Dec 2, 2009 at 1:23 PM, Dmitry Torokhov
wrote:
> On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
>> wrote:
>> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
>> >&g
f the cheap devices with just raw interfaces, running in-kernel
>> decoders, while it will work if you create one interface per protocol
>> per IR receiver, this also seems overkill. Why to do that? It sounds that it
>> will
>> just create additional complexity at the kernelspace
a /dev/device or be in debugfs. GregKH
sent earlier mail telling me to get the FIFO out of sysfs.
> - we allow registering several data interfaces/decoders that can be bound
> (manually or maybe automatically) to lirc devices. lirc devices may
> provide hints as to which interface(s) be
support enumerating the supported
protocols. I'm not sure if you can write those bits back into evdev to
turn a feature off/on. If not its something that could be added to
evdev.
I agree that there is no consistency in the existing driver implementations.
--
Jon Smirl
jonsm...@gmail.com
--
To uns
thing just works
For these default cases you just have to read enough docs to know what
device to set your universal remote to.
The scenario I'd like to achieve
install TV app
install audio app
install home automation app
use multi-function remote to control in parallel with zero co
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky wrote:
> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>> While reading all of these IR threads another way of handling IR
>> occurred to me that pretty much eliminates the need for LIRC and
>> configuration files in de
ernal support will need to be
installed if the protocol decode engines are in the kernel. The raw
data will come in, run through the engines, and pop out as evdev
messages with a vendor/device/command triplet. Devices that decode in
hardware will just send vendor/device/command triplets.
--
Jon Sm
On Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus wrote:
> Hi Jon,
>
> on 27 Nov 09 at 12:49, Jon Smirl wrote:
> [...]
>> Christoph, take what you know from all of the years of working on LIRC
>> and design the perfect in-kernel system. This is the big chance to
>&g
t;> > after mounting the filesystems and starting the deamons
>> > (e. g. after running inittab).
>> >
>> > So, you cannot catch a key that would be affecting the boot
>> > (for example to ask the kernel to run a different runlevel or entering
>> > o
handy to the user.
>
> So are we optimizing for the embedded/STB and HTPC with no keyboard use
> case, or the desktop or HTPC with a keyboard for maintencance?
>
>
> Regards,
> Andy
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
> On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
>
>> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote:
>>>
>>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>>> leas
is done?
>
> Doing so doesn't block improving input layer IR interface, does it?
> --
> Krzysztof Halasa
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
k here again next year repeating this until IR gets
redesigned into something fairly invisible like keyboard and mouse
drivers.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e the IR over ALSA. But is
attaching an IR diode to the mic input of your sound card really a
device or is it a hack that should be dealt with in user space?
Another type is IR hardware that toggles the DTR output of a serial
port at 40Khz to make a signal. Same thing is done with parallel
ports. Thos
;> + i--;
>> + /* skip leading zeros */
>> + if ((delta > 0) && !first)
>> + continue;
>> +
>> + ir->send.buffer[ir->send.count++] = abs(delta);
>> + }
>> +
>
On Sun, Nov 29, 2009 at 12:14 PM, Greg KH wrote:
> On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
>> Changes to core input subsystem to allow send and receive of IR messages.
>> Encode and decode state machines are provided for common IR porotocols such
>> as So
scancodes into the five apps?
I did it by creating five evdev devices each mapping 40 scancodes.
That's lets me reuse KP_1 for each of the five apps.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bo
On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
>> wrote:
>>> Jon Smirl wrote:
>>>> We have one IR receiver device and multiple remotes. How does the
>>>> input system
On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
>> wrote:
>>> Jon Smirl wrote:
>>>> Also, how do you create the devices for each remote? You would need to
>>>> create the
On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
>> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
>> codes are over 32b. Christoph posted an example that needs 128b.
>
> This only means that the existing interface is li
On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> Also, how do you create the devices for each remote? You would need to
>> create these devices before being able to do EVIOCSKEYCODE to them.
>
> The input subsystem creates devices on behalf of in
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> If these drivers are for specific USB devices it is straight forward
>> to turn them into kernel based drivers. If we are going for plug and
>> play this needs to happen. All USB device drivers can
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap, setkeycode
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky wrote:
> On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
>> What are other examples of user space IR drivers?
>>
>
> many libusb based drivers?
If these drivers are for specific USB devices it is straight forward
to turn t
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap
rd in evdev - put IR on equal footing.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for configuration
Once consensus is reached in those two areas everything else should be
much easier.
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from t
.
Both of these are hobbyist class solutions. They are extremely cheap
but they are unreliable and create large CPU loads. But some people
want to use a $300 CPU to eliminate $2 worth of IR hardware. This type
of hardware will continue to work via event injection. But neither of
these solutions
On Fri, Nov 27, 2009 at 2:03 PM, Ferenc Wagner wrote:
> Jon Smirl writes:
>
>> On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus
>> wrote:
>>
>>>> Maybe we decide to take the existing LIRC system as is and not
>>>> integrate it into th
1 - 100 of 119 matches
Mail list logo
