Nabble - LIRC

Re: uinput key range patch

2009-12-06T04:32:00Z

Hi!

Paul Bender "pebender@..." wrote:

> Attached is a patch that fixes the uinput output device key range
> supported. First, rather than limiting the valid keys to something less
> than KEY_UNKNOWN, it checks input_map.inc.

Ok. Can anyone explain what is the practical use for UI_SET_KEYBIT anyway?

> Second, just as is done in
> the commit
> <http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/daemons/hw_devinput.c?r1=5
> .20&r2=5.21>, it discards values between BTN_MISC and BTN_GEAR_UP as they
> are mouse not keyboard values.

Why would you want to hinder the user from generating these events if he
wants to?

Christoph

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: MCEUSB2 on Karmic

2009-12-06T03:51:00Z

Hi!

Josu Lazkano "josu.lazkano@..." wrote:

> Thanks for your reply, this theoutput of the "lircd":
>
> $ lircd
> lircd: can't open or create /var/run/lirc/lircd.pid
> lircd: No such file or directory

mkdir /var/run/lirc

Raise a bug report on the package that you're using. It should have
created the directory for you.

Christoph

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Help!. The alt-F4 key combination is not working for me with Irxevent.

2009-12-06T01:16:36Z

lirc-list@...
Is there a way to archive this combination?
Other Keys like F11, return, Left, Right, works.
I am using LIRC 0.8.6 and Irxevent of the same version number.
Thanks.

Internet Explorer 8 especial para MSN - ¡Gratis! Hacé clic aquí
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: MCEUSB2 on Karmic

2009-12-05T14:52:30Z

Thanks for your reply, this theoutput of the "lircd":

$ lircd
lircd: can't open or create /var/run/lirc/lircd.pid
lircd: No such file or directory
(with sudo, I have same error)

On Ubuntu Jaunty I use to config with mceusb2 and it works.

Thanks for all.

2009/12/5 Travis Tabbal <travis@...>

On Sat, Dec 5, 2009 at 3:03 PM, Josu Lazkano <josu.lazkano@...> wrote:
I can not get working my remote. I configure this way:

hardware.conf: http://pastebin.com/f7e814cc9
lircd.conf: http://pastebin.com/f307b560d

What isn't working? Do you get errors from lirc? try just running lircd from the command line to see what it outputs. It usually tells you what does/doesn't work. You might try changing the module name to "lirc_mceusb" (drop the "2" at the end). That's what I'm using locally, I don't remember seeing a "lirc_mceusb2" module on the system.

--
Josu Lazkano

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: MCEUSB2 on Karmic

2009-12-05T14:03:07Z

I can not get working my remote. I configure this way:

hardware.conf: http://pastebin.com/f7e814cc9
lircd.conf: http://pastebin.com/f307b560d

I have created the lirc0 device:

$ ls -l /dev/ | grep lirc
crw-rw---- 1 root root 61, 0 2009-12-05 22:55 lirc0

But when I try to probe I have this:

$ irw
connect: No such file or directory

I use official repository version software. Can you help with this?

I made work it on Jaunty, but i don't know why in Karmic I can't get working.

Thanks for all and best regards.

2009/12/5 Josu Lazkano <josu.lazkano@...>

Hello everybody! I having problems on configuring my IR receiver on a fresh Ubuntu Karmic install. I have a Philips receiver:

Bus 001 Device 003: ID 0471:0815 Philips eHome Infrared Receiver

I have some questions:

1. Is it a MCEUSB2 one? Or I need to load an other module?
2. Which files I must configure? I must do that automatically (with some script) or manually?
3. I must compile the lir program? or is enough with an "sudo apt-get x"?

Thanks for all and best regards.

--
Josu Lazkano

Re: Can someone help me get the pvr 150 IR blaster patch by Mark Weaver to work with lirc & kernel 2.6.31?

2009-12-05T13:11:22Z

Jarod Wilson wrote:

> On Dec 5, 2009, at 1:39 PM, Rick wrote:
>
>> Jarod Wilson wrote:
>>> On Nov 26, 2009, at 11:08 PM, Rick wrote:
>>>> Jarod Wilson wrote:
>>>>> On 11/26/2009 09:25 PM, Rick wrote:
>>>>>> Jarod Wilson wrote:
>>>>>>> On 11/26/2009 08:25 PM, Rick wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> My myth box of 3+ years has finally bitten the dust. Now that I'm
>>>>>>>> rebuilding a new one, the distro (Mandriva 2010.0) has moved on to
>>>>>>>> kernel 2.6.31. Does anyone know how I can get the PVR 150 IR Blas0ter
>>>>>>>> mod provided by Mark Weaver to work with the newer kernel. His mod was
>>>>>>>> based on lirc 0.8.3 and it doesn't compile with kernel 2.6.31.
>>> ...
>>>>> The driver isn't in the lirc distribution, due to concerns over the pseudo-firmware IR blaster table the driver uses, which is extracted from a Windows driver. Its in my git tree though. The easiest thing to do is download a snapshot of just the lirc subtree of my git tree here:
>>>>> http://wilsonet.com/jarod/junk/lirc-snap-20091027.tar.bz2
>>>>> Unpack it, then (all on one line):
>>>>> make -C /path/to/kernel/headers/ CONFIG_INPUT_LIRC=m \
>>>>> CONFIG_LIRC_ZILOG=m M=$PWD modules
>>>>> Then drop the resulting lirc_dev.ko and lirc_zilog.ko into /lib/modules/<your kernel/extra/ and run depmod. Then try modprobing lirc_zilog, and all should be well.
>>>> Great! I'll do that once I get home. Will the zilog module behave the same way as the old PVR 150 patched module? In my old mythbox I had two pvr 150 cards. By bringing up two LIRC daemons on separate devices, I was able to independently control two set top boxes. Also, will I need that separate firmware file or is that now "built in"?
>>> Everything should be pretty much the same.
>> Hi Jarod,
>>
>> I just tried this at home and got the following error:
>>
>> modprobe lirc_zilog
>> FATAL: Error inserting lirc_zilog (/lib/modules/2.6.31.5-desktop-1mnb/misc/lirc_zilog.ko): Unknown symbol in module, or unknown parameter (see dmesg)
>>
>> Dmesg output:lirc_zilog: disagrees about version of symbol lirc_register_driver
>> lirc_zilog: Unknown symbol lirc_register_driver
>>
>> --- For what it's worth, I compiled the latest lirc-0.8.6 on my host before attempting the zilog stuff. Then I put the zilog tree I downloaded from you in /usr/src/lirc-snap_zilog and compiled it. Then i modprobed and got this error.
>
> You have a mismatch between lirc_dev.ko and lirc_zilog.ko. You probably only dropped the locally built lirc_zilog.ko in place, you need both.
>

You were right. Thank you. Now on to some testing!

Rick

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

MCEUSB2 on Karmic

2009-12-05T12:34:41Z

Hello everybody! I having problems on configuring my IR receiver on a fresh Ubuntu Karmic install. I have a Philips receiver:

Bus 001 Device 003: ID 0471:0815 Philips eHome Infrared Receiver

I have some questions:

1. Is it a MCEUSB2 one? Or I need to load an other module?
2. Which files I must configure? I must do that automatically (with some script) or manually?
3. I must compile the lir program? or is enough with an "sudo apt-get x"?

Thanks for all and best regards.

--
Josu Lazkano

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Can someone help me get the pvr 150 IR blaster patch by Mark Weaver to work with lirc & kernel 2.6.31?

2009-12-05T11:31:16Z

On Dec 5, 2009, at 1:39 PM, Rick wrote:

> Jarod Wilson wrote:
>> On Nov 26, 2009, at 11:08 PM, Rick wrote:
>>> Jarod Wilson wrote:
>>>> On 11/26/2009 09:25 PM, Rick wrote:
>>>>> Jarod Wilson wrote:
>>>>>> On 11/26/2009 08:25 PM, Rick wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> My myth box of 3+ years has finally bitten the dust. Now that I'm
>>>>>>> rebuilding a new one, the distro (Mandriva 2010.0) has moved on to
>>>>>>> kernel 2.6.31. Does anyone know how I can get the PVR 150 IR Blas0ter
>>>>>>> mod provided by Mark Weaver to work with the newer kernel. His mod was
>>>>>>> based on lirc 0.8.3 and it doesn't compile with kernel 2.6.31.
>> ...
>>>> The driver isn't in the lirc distribution, due to concerns over the pseudo-firmware IR blaster table the driver uses, which is extracted from a Windows driver. Its in my git tree though. The easiest thing to do is download a snapshot of just the lirc subtree of my git tree here:
>>>> http://wilsonet.com/jarod/junk/lirc-snap-20091027.tar.bz2
>>>> Unpack it, then (all on one line):
>>>> make -C /path/to/kernel/headers/ CONFIG_INPUT_LIRC=m \
>>>> CONFIG_LIRC_ZILOG=m M=$PWD modules
>>>> Then drop the resulting lirc_dev.ko and lirc_zilog.ko into /lib/modules/<your kernel/extra/ and run depmod. Then try modprobing lirc_zilog, and all should be well.
>>> Great! I'll do that once I get home. Will the zilog module behave the same way as the old PVR 150 patched module? In my old mythbox I had two pvr 150 cards. By bringing up two LIRC daemons on separate devices, I was able to independently control two set top boxes. Also, will I need that separate firmware file or is that now "built in"?
>> Everything should be pretty much the same.
> Hi Jarod,
>
> I just tried this at home and got the following error:
>
> modprobe lirc_zilog
> FATAL: Error inserting lirc_zilog (/lib/modules/2.6.31.5-desktop-1mnb/misc/lirc_zilog.ko): Unknown symbol in module, or unknown parameter (see dmesg)
>
> Dmesg output:lirc_zilog: disagrees about version of symbol lirc_register_driver
> lirc_zilog: Unknown symbol lirc_register_driver
>
> --- For what it's worth, I compiled the latest lirc-0.8.6 on my host before attempting the zilog stuff. Then I put the zilog tree I downloaded from you in /usr/src/lirc-snap_zilog and compiled it. Then i modprobed and got this error.

You have a mismatch between lirc_dev.ko and lirc_zilog.ko. You probably only dropped the locally built lirc_zilog.ko in place, you need both.

--
Jarod Wilson
jarod@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Can someone help me get the pvr 150 IR blaster patch by Mark Weaver to work with lirc & kernel 2.6.31?

2009-12-05T10:39:11Z

Jarod Wilson wrote:

> On Nov 26, 2009, at 11:08 PM, Rick wrote:
>
>> Jarod Wilson wrote:
>>> On 11/26/2009 09:25 PM, Rick wrote:
>>>> Jarod Wilson wrote:
>>>>> On 11/26/2009 08:25 PM, Rick wrote:
>>>>>> Hi,
>>>>>>
>>>>>> My myth box of 3+ years has finally bitten the dust. Now that I'm
>>>>>> rebuilding a new one, the distro (Mandriva 2010.0) has moved on to
>>>>>> kernel 2.6.31. Does anyone know how I can get the PVR 150 IR Blas0ter
>>>>>> mod provided by Mark Weaver to work with the newer kernel. His mod was
>>>>>> based on lirc 0.8.3 and it doesn't compile with kernel 2.6.31.
> ...
>>> The driver isn't in the lirc distribution, due to concerns over the pseudo-firmware IR blaster table the driver uses, which is extracted from a Windows driver. Its in my git tree though. The easiest thing to do is download a snapshot of just the lirc subtree of my git tree here:
>>> http://wilsonet.com/jarod/junk/lirc-snap-20091027.tar.bz2
>>> Unpack it, then (all on one line):
>>> make -C /path/to/kernel/headers/ CONFIG_INPUT_LIRC=m \
>>> CONFIG_LIRC_ZILOG=m M=$PWD modules
>>> Then drop the resulting lirc_dev.ko and lirc_zilog.ko into /lib/modules/<your kernel/extra/ and run depmod. Then try modprobing lirc_zilog, and all should be well.
>> Great! I'll do that once I get home. Will the zilog module behave the same way as the old PVR 150 patched module? In my old mythbox I had two pvr 150 cards. By bringing up two LIRC daemons on separate devices, I was able to independently control two set top boxes. Also, will I need that separate firmware file or is that now "built in"?
>
> Everything should be pretty much the same.
>

Hi Jarod,

I just tried this at home and got the following error:

modprobe lirc_zilog
FATAL: Error inserting lirc_zilog
(/lib/modules/2.6.31.5-desktop-1mnb/misc/lirc_zilog.ko): Unknown symbol
in module, or unknown parameter (see dmesg)

Dmesg output:lirc_zilog: disagrees about version of symbol
lirc_register_driver
lirc_zilog: Unknown symbol lirc_register_driver

--- For what it's worth, I compiled the latest lirc-0.8.6 on my host
before attempting the zilog stuff. Then I put the zilog tree I
downloaded from you in /usr/src/lirc-snap_zilog and compiled it. Then i
modprobed and got this error.

Rick

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Recommend commercial IR receiver

2009-12-05T10:14:08Z

Angus March schrieb:

> Jarod Wilson wrote:
>> On Dec 3, 2009, at 5:01 PM, Angus March wrote:
>>
>>
>>> I had an RS232 serial IR receiver that seems to be broken. I did purchase it, but I'm sure it qualifies as a homebrew. Can someone recommend a commercial receiver that has just about the same features as an RS232, but won't break? This means I should be able to customize it to any remote, and work w/lirc, of course.
>>>
>>
>> Windows MCE USB Transceiver. (Also marketed as an eHome Infrared Transceiver, and a multitude of other things). They're about $25 new, with a bundled remote and two IR emitters, in addition to the receiver functionality, which works with darned near every IR protocol you can throw at it.
>>
> "Windows", eh? And it'll work in Linux?
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev

With VDR-1.7.9 I use the Philips SRM5100.

cd lirc-0.8.5pre2
./configure --with-driver=mceusb2; make

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: lirc 0.8.6 locks up with IMON USB device and PAD remote

2009-12-04T09:29:20Z

On Wed, Dec 2, 2009 at 6:22 PM, Johnny Walker <johnnyjboss@...> wrote:

> On Tue, Dec 1, 2009 at 8:40 PM, Jarod Wilson <jarod@...> wrote:
>> On 11/30/2009 10:03 AM, Johnny Walker wrote:
>>>
>>> This weekend the LCD has been lockign up in under an hour reliably. I
>>> don't see anything in logs regarding it. The good news is the remote
>>> still works when the LCD locks up. Anything you can suggest?
>>
>> If there's nothing in the logs... Then I'm hesitant to believe its a driver
>> problem. At least, its not hte problem others were having -- they had
>> distinct send_packet failed messages in their system logs.
>>
>> On 12/01/2009 05:44 PM, Johnny Walker wrote:
>>>>>
>>>>> Feedback when using your device with a test patch I posted two or three
>>>>> weeks back would be useful (you should be able to find it in the list
>>>>> archives, needs to be applied to the lirc_imon driver). Basically, so far as
>>>>> we can determine, some LCD/VFD can't keep up with constant writes to the
>>>>> display, so we hack in a delay before returning from any writes, hoping that
>>>>> with delay, the display can then keep up.
>>>
>>> So now that I've corrected the LCD Server setting to localhost I can
>>> see in the mythfrontend.log when the lcd device stops working:
>>>
>>> 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died
>>> unexpectedly.
>>> Trying to reconnect every 10 seconds. . .
>>>
>>> But I don't see any write errors being logged in the kern.log.
>>>
>>> It seems to restart the mythlcdserver and then keep trying...
>>>
>>> 2009-12-01 15:29:17.248 Starting mythlcdserver
>>> QWidget: Cannot create a QWidget when no GUI is being used
>>> 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of
>>> 10)
>>> 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of
>>> 10)
>>> 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of
>>> 10)
>>> 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of
>>> 10)
>>> 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of
>>> 10)
>>> 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of
>>> 10)
>>> 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of
>>> 10)
>>> 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of
>>> 10)
>>> 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of
>>> 10)
>>> 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10
>>> of 10)
>>> 2009-12-01 15:29:27.251 Starting mythlcdserver
>>> 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of
>>> 10)
>>>
>>> Should I take this up on the lcdproc mailing list - or is this handled
>>> by the lirc_imon module?
>>
>> I don't know if that's an lcdproc error or a mythlcdserver error there. But
>> it definitely looks to me like lirc_imon isn't at fault.
>>
> ok - so the last few days I've zeroed in on what's actually happening.
> The pad on the imon remote is what stops. That includes my enter key
> which is on that pad. This is all that's in the logs:
>
> Dec 2 17:31:33 mythliving kernel: [38109.134168] intf0 decoded
> packet: 01 00 00 7f 00 00 00 00
> Dec 2 17:31:33 mythliving kernel: [38109.174168] intf0 decoded
> packet: 01 00 00 7f 00 00 00 00
> Dec 2 17:31:33 mythliving kernel: [38109.206156] intf0 decoded
> packet: 01 00 00 7f 00 00 00 00
> Dec 2 17:31:36 mythliving kernel: [38112.694506] intf0 decoded
> packet: 28 a1 95 b7 00 00 24 01
> Dec 2 17:31:37 mythliving kernel: [38112.862519] intf0 decoded
> packet: 28 a1 d5 b7 00 00 24 01
> Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded
> packet: 28 a1 95 b7 00 00 24 01
> Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded
> packet: 28 a1 d5 b7 ff 00 24 01
>
> These go on and on until they suddenly stop.
>
> The LCD is still updating this time - so it's just the pad on the
> remote that has stopped functioning.
> Actually I just tested it and it seems the entire remote has now
> stopped functioning.

Interestingly - or not - is that I rebooted the machine at this point
to regain remote control and after only 5 or so minutes the LCD
stopped responding - ie: the display forze up and did not continue to
update.

I'm suspecting the USB cable that is part of this case. the
SilverStone LC11SM - the usb cables to connect this device are rather
lengthy and I've wrapped them up to get them out of the way. Is it
possible there's an issue even if I'm not seeing it drop off the USB?

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Lockups after installing MCE USB IR receiver

2009-12-04T08:40:19Z

This is the ID of the reciever:

Bus 004 Device 002: ID 1784:0008 TopSeed Technology Corp.

After getting it running, I get lots of lockups at seemingly random times, right after using the remote. I can't seem to get any logging on the issue, though I have seen posts on an XBMC forum suspecting a chipset/receiver interop issue. After this happens, the machine is hard locked. I don't get any response from a local keyboard, and can't SSH into the machine. It's like the kernel crashes. I was wondering if anyone here has some hints on getting this fixed? I don't know if it's LIRC itself, the mceusb driver, or just faulty hardware. The machine works fine if I just use a keyboard, but that's not really TV friendly. On the XBMC forums, they suggested adding a USB card as a solution. I'm thinking of trying that tonight as I have an old PCI USB card, if I can find it. I have tried different ports on the motherboard USB already.

Distro is Ubuntu 9.10. LIRC installed from packages, version 0.8.6. Motherboard is an Asus M3N78-VM.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-04T08:11:04Z

Dmitry Torokhov <dmitry.torokhov@...> writes:

> On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
>> Ferenc Wagner wrote:
>>> Mauro Carvalho Chehab <mchehab@...> writes:
>>
>> 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.
>
> Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
> media inputs in a device/application. My receiver accepts codes like
> that.

Sorry, my point wasn't the event names, I picked them for their
superficial correspondence to the TV, DVD, SAT etc. buttons found on
multifunction remotes. Obviously I picked wrong.

I was also wrong to assume that remotes with such buttons are always
multifunction remotes in the sense that they are meant to control
separate devices. As Mauro pointed out, (some) bundled remotes with
such buttons aren't; thus I wouldn't consider them multifunction at all.
They simply have some extra buttons labelled TV, DVD etc, which probably
shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
different semantics) but should be mapped to something else. Or not, if
these buttons change some internal decoder state instead, modifying the
mapping or destination input device of the other keys.

It's just a different scenario, where the kernel could reasonably give
rather different representations to simple applications aiming at
plug&play: letting through the function change events untouched, or
masking and using them internally.

True multifunction devices don't send such events, the TV, DVD etc
buttons on them change their internal state and the scan codes sent by
the other keys, if I understand this correctly.

I'd prefer if these two behaviours could be abstacted from, and the
input layer interface would provide destination selection events +
generic events, or (to be defined) device specific events only in either
case. Is that possible or even reasonable?
--
Thanks,
Feri.

Ps: I'm writing this in the hope to clean up the landscape and possibly
help in choosing the best design. I'm not at all familiar with IR, and
the above distinction was pretty surprising for me. Also, I'm just
lurking here, so don't take me too seriously. :)

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Recommend commercial IR receiver

2009-12-04T07:04:58Z

Jarod Wilson wrote:

On Dec 3, 2009, at 5:01 PM, Angus March wrote:

I had an RS232 serial IR receiver that seems to be broken. I did purchase it, but I'm sure it qualifies as a homebrew. Can someone recommend a commercial receiver that has just about the same features as an RS232, but won't break? This means I should be able to customize it to any remote, and work w/lirc, of course.


Windows MCE USB Transceiver. (Also marketed as an eHome Infrared Transceiver, and a multitude of other things). They're about $25 new, with a bundled remote and two IR emitters, in addition to the receiver functionality, which works with darned near every IR protocol you can throw at it.

"Windows", eh? And it'll work in Linux?

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Recommend commercial IR receiver

2009-12-04T05:58:57Z

On Dec 3, 2009, at 5:01 PM, Angus March wrote:

> I had an RS232 serial IR receiver that seems to be broken. I did purchase it, but I'm sure it qualifies as a homebrew. Can someone recommend a commercial receiver that has just about the same features as an RS232, but won't break? This means I should be able to customize it to any remote, and work w/lirc, of course.

Windows MCE USB Transceiver. (Also marketed as an eHome Infrared Transceiver, and a multitude of other things). They're about $25 new, with a bundled remote and two IR emitters, in addition to the receiver functionality, which works with darned near every IR protocol you can throw at it.

Ex:

http://www.newegg.com/Product/Product.aspx?Item=N82E16880121003
http://www.newegg.com/Product/Product.aspx?Item=N82E16880121001

Both even have review comments that say "works under linux and/or with mythtv".

--
Jarod Wilson
jarod@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

uinput key range patch

2009-12-03T19:29:49Z

Attached is a patch that fixes the uinput output device key range
supported. First, rather than limiting the valid keys to something less
than KEY_UNKNOWN, it checks input_map.inc. Second, just as is done in
the commit
<http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/daemons/hw_devinput.c?r1=5.20&r2=5.21>,
it discards values between BTN_MISC and BTN_GEAR_UP as they are mouse
not keyboard values.

diff -Naur lirc-0.8.6-old/daemons/input_map.c lirc-0.8.6-new/daemons/input_map.c
--- lirc-0.8.6-old/daemons/input_map.c 2008-10-26 08:10:17.000000000 -0700
+++ lirc-0.8.6-new/daemons/input_map.c 2009-12-01 20:57:41.000000000 -0800
@@ -25,6 +25,21 @@
{NULL, 0}
};

+int get_input_code_by_index(int index, linux_input_code *code)
+{
+ int i;
+
+ for (i=0; input_map[i].name != NULL; i++)
+ {
+ if (i == index)
+ {
+ *code = input_map[i].code;
+ return i;
+ }
+ }
+ return -1;
+}
+
int get_input_code(const char *name, linux_input_code *code)
{
int i;
diff -Naur lirc-0.8.6-old/daemons/input_map.h lirc-0.8.6-new/daemons/input_map.h
--- lirc-0.8.6-old/daemons/input_map.h 2008-10-26 08:10:17.000000000 -0700
+++ lirc-0.8.6-new/daemons/input_map.h 2009-12-01 20:57:41.000000000 -0800
@@ -28,6 +28,7 @@
typedef unsigned short linux_input_code;
#endif

+int get_input_code_by_index(int index, linux_input_code *code);
int get_input_code(const char *name, linux_input_code *code);
void fprint_namespace(FILE *f);
int is_in_namespace(const char *name);
diff -Naur lirc-0.8.6-old/daemons/lircd.c lirc-0.8.6-new/daemons/lircd.c
--- lirc-0.8.6-old/daemons/lircd.c 2009-08-29 00:46:44.000000000 -0700
+++ lirc-0.8.6-new/daemons/lircd.c 2009-12-01 20:57:51.000000000 -0800
@@ -417,6 +417,8 @@
#if defined(__linux__)
int fd;
int key;
+ linux_input_code code;
+ int i;
struct uinput_user_dev dev;

fd = open("/dev/input/uinput", O_RDWR);
@@ -445,12 +447,16 @@
goto setup_error;
}

- for(key = KEY_RESERVED; key <= KEY_UNKNOWN; key++)
+ for(i = 0; get_input_code_by_index(i, &code) >= 0; i++)
{
- if(ioctl(fd, UI_SET_KEYBIT, key) != 0)
+ key = (int)code;
+ if ((key < BTN_MISC) || (key > BTN_GEAR_UP))
{
- goto setup_error;
- }
+ if(ioctl(fd, UI_SET_KEYBIT, key) != 0)
+ {
+ goto setup_error;
+ }
+ }
}

if(ioctl(fd, UI_DEV_CREATE) != 0)

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

patch for Linux 2.6.32

2009-12-03T19:14:55Z

Attached is a patch that enables LIRC to compile against Linux 2.6.32.
As I do not have an i2c dependent receiver, I do not know whether or not
i2c dependent receivers work with the patch, but at least it compiles.

diff -Naur lirc-0.8.6-old/drivers/lirc_i2c/lirc_i2c.c lirc-0.8.6-new/drivers/lirc_i2c/lirc_i2c.c
--- lirc-0.8.6-old/drivers/lirc_i2c/lirc_i2c.c 2009-08-30 09:59:53.000000000 -0700
+++ lirc-0.8.6-new/drivers/lirc_i2c/lirc_i2c.c 2009-12-03 16:52:05.000000000 -0800
@@ -399,7 +399,9 @@
.name = "i2c ir driver",
},
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 32)
.id = I2C_DRIVERID_EXP3, /* FIXME */
+#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 31)
.attach_adapter = ir_probe,
.detach_client = ir_remove,

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR (Also: Fixed protocol reciever suggestions)

2009-12-03T15:59:09Z

On Thursday 03 December 2009 00:08:13 Jon Smirl wrote:

> On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
> A fixed protocol receiver is more of a challenge. You have to figure
> out how to make a universal remote transmit device codes for a device
> you don't already own that is also encoded in the protocol your
> hardware supports. There's nothing we can do about that problem in
> Linux, its a side effect of fixed protocol decode hardware. You're
> just going to have to start guessing devices in the remote until you
> find one that uses your fixed protocol and doesn't also activate the
> devices you own. We can put suggestions in the doc when working
> devices are discovered.

Well for the currently supported (lirc creative driver) Creative Infra
Receiver I've found that some Toshiba protocols/remotes/etc. seem to work
great. I've been reading this discussion and while i like whats going on I'd
certainly want to make sure that such fixed protocol devices would still be
supported and possible to use since much of the discussion seems to be talking
about receivers that can handle multiple protocols and remotes natively.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Recommend commercial IR receiver

2009-12-03T14:01:07Z

I had an RS232 serial IR receiver that seems to be broken. I did purchase it, but I'm sure it qualifies as a homebrew. Can someone recommend a commercial receiver that has just about the same features as an RS232, but won't break? This means I should be able to customize it to any remote, and work w/lirc, of course.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T12:54:28Z

Krzysztof Halasa wrote:

> Mauro Carvalho Chehab <mchehab@...> writes:
>
>> Btw, looking at that code, while it is not impossible to split the
>> IR pulse/space measures from the NEC decoder itself, and make it generic
>> to support other protocols, it is not a trivial task, and may result on
>> a less stable driver.
>
> And it's not needed at all.
> Protocol decoders can be easily run in parallel, I've done it on saa713x
> and this is trivial at least there. Can do that when the lirc interface
> is available.

>> The advantage of the NEC decoding approach on saa7134 is that you know for
>> sure how much time it is required to get the entire code. So, the code
>> can easily abort the reception of a bad code. The disadvantage is that
>> only one protocol can be decoded at the same time.
>
> This isn't a hard thing to fix.

Good to know. We're open to patches to improve it.

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it
happens too often.

>
>> The same problem also happens with almost all in-kernel drivers: the decoders
>> for raw mode were constructed to work with just one pulse/space code at the
>> same time. A conversion into a generic code can happen, but it will require
>> several tests to be sure that they won't cause undesirable side-effects.
>
> IOW any such receiver has to be tested, sure.
>
>> The advantage of hardware decoders is that you don't need to be polling the
>> IR serial port at a high rate, as you'll get directly the code. So, you'll
>> free the CPU to do something else.
>
> Which device requires polling the port?
> Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven.

Cheers,
Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T11:48:00Z

Quoting Jon Smirl <jonsmirl@...>:

>>> Now I understand that if 2 remotes send completely identical signals we
>>> won't be able to separate them, but in cases when we can I think we
>>> should.
>>
>> I don't have a problem with that, if its a truly desired feature.
>> But for the most part, I don't see the point. Generally, you go
>> from having multiple remotes, one per device (where "device" is
>> your TV, amplifier, set top box, htpc, etc), to having a single
>> universal remote that controls all of those devices. But for each
>> device (IR receiver), *one* IR command set. The desire to use
>> multiple distinct remotes with a single IR receiver doesn't make
>> sense to me. Perhaps I'm just not creative enough in my use of IR. :)

From a hobbiest's perspective there's likely rarely any reason to be
able to do the same thing with two different remotes that send
different signals, but i could see it come up - For example if you
wanted to have both a feature-rich, busy/complicated remote but also
wanted to provide a simpler remote with a relatively small number of
large buttons on it for basic functions, as for children or people
with poor eyesight or poor motor control.

From a business perspective, I've worked for a company that sold
turn-key video training systems, and depending on the whims of our
so-called business partners and the desires of customers, there were
as many as three distinct remotes that might get shipped with the
training system, and they all sent different signals.

That was a less than ideal situation, and if we had been really on top
of things we'd have just declined to use any of those remotes and
bought custom remotes from any of the numerous vendors that sell them
which would allow us to have one set of IR signals used by remotes
with different features - but for whatever reason that wasn't how
management decided to do things.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T10:18:03Z

Mauro Carvalho Chehab <mchehab@...> writes:

> Btw, looking at that code, while it is not impossible to split the
> IR pulse/space measures from the NEC decoder itself, and make it generic
> to support other protocols, it is not a trivial task, and may result on
> a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

> The advantage of the NEC decoding approach on saa7134 is that you know for
> sure how much time it is required to get the entire code. So, the code
> can easily abort the reception of a bad code. The disadvantage is that
> only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

> The same problem also happens with almost all in-kernel drivers: the decoders
> for raw mode were constructed to work with just one pulse/space code at the
> same time. A conversion into a generic code can happen, but it will require
> several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

> The advantage of hardware decoders is that you don't need to be polling the
> IR serial port at a high rate, as you'll get directly the code. So, you'll
> free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
--
Krzysztof Halasa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T10:06:02Z

Jarod Wilson <jarod@...> writes:

> Perhaps we should clarify something here. Are we intending to
> auto-create a new input device for every IR command set we see arrive
> at the IR receiver?

We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part of the same or different
command set.

Sharing the protocol and e.g. group code doesn't mean it's the same
remote.

Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
--
Krzysztof Halasa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-03T09:31:20Z

lirc@... (Christoph Bartelmus) writes:

> Currently I would tend to an approach like this:
> - raw interface to userspace using LIRC
> - fixed set of in-kernel decoders that can handle bundled remotes

I'd modify it a bit:
- raw interface to userspace using LIRC
- fixed set of in-kernel decoders

Longer term:

Removing the key assignment tables from the kernel. Plug-and-play can be
then achieved with udev. The only thing needed from the kernel is
indicating the tuner/sensor type, udev can guess the bundled remote type.

Porting the in-kernel drivers (such as ir-common) to LIRC interface
(while not removing the input layer mode).
--
Krzysztof Halasa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T09:31:06Z

On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
> Ferenc Wagner wrote:
> > Mauro Carvalho Chehab <mchehab@...> writes:
>
> 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.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.

--
Dmitry

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T09:19:56Z

Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl <jonsmirl@...> escreveu:

> On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
> <mchehab@...> wrote:
> > Ferenc Wagner wrote:
> >> Mauro Carvalho Chehab <mchehab@...> writes:
> >>
> >>> Dmitry Torokhov wrote:
> >>>
> >
> >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
> >> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
> >> by any remote (ok, I'm stretching it a bit).
> >
> > Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.
> >
> > On those remotes, if you press TV and then press for example Channel UP
> > and press Radio, then press Channel UP, the channel UP code will be the same.
> >
> > For example, on Hauppauge Grey IR, we have:
> >
> > <TV>
> > [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
> > [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
> > [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0
> >
> > <CHANNEL UP>
> > [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> > [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> > [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
> >
> > <Radio>
> > [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
> > [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
> > [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0
> >
> > <CHANNEL UP>
> > [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> > [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> > [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
> >
> > In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
> > shipped IR's.
>
> The remote is treating everything as a single integrated device which
> is not inconsistent with what has been said. In this case there really
> is only one multi-function device not two independent ones.
>
> If you want to control two independent devices you need to buy a
> different remote. Remotes are cheap so that's not a big deal.
>
> If you really want to use this remote to control two independent
> devices you need user space scripting to split the single device into
> two devices and then inject new events into the input layer. This is a
> complex case and not in the goal of getting 90% of users to "just
> work".

This remote is a typical example of the IR's that are provided together with media boards.
On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and
this event doesn't change the status of subsequent keys.

100% of the users of such boards will have the shipped IR. Some amount will be happy of
just using the provided IR to control different applications at their computer or embedded
hardware, and some amount will prefer to buy a multi-purpose IR that will allow him
to control not only his computer, but also, his TV, his Air conditioning, etc.

Both usages should be supported.

All I'm saying is that, in the case where people have only the shipped IR, if he wants to
see TV, the produced keycode will be KEY_TV, and then to change a channel, it will
receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB,
he will press KEY_DVB and then KEY_PLAY to play his movie.

So, an application like MythTV should be able to work with those keys.

I don't see the need to create a separate code for KEY_PLAYDVB, as this can be simply mapped
as KEY_DVB and KEY_PLAY.

--

Cheers,
Mauro

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T08:50:04Z

On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
<mchehab@...> wrote:

> Ferenc Wagner wrote:
>> Mauro Carvalho Chehab <mchehab@...> writes:
>>
>>> Dmitry Torokhov wrote:
>>>
>
>> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
>> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
>> by any remote (ok, I'm stretching it a bit).
>
> Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.
>
> On those remotes, if you press TV and then press for example Channel UP
> and press Radio, then press Channel UP, the channel UP code will be the same.
>
> For example, on Hauppauge Grey IR, we have:
>
> <TV>
> [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
> [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
> [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0
>
> <CHANNEL UP>
> [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
>
> <Radio>
> [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
> [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
> [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0
>
> <CHANNEL UP>
> [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
>
> In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
> shipped IR's.

The remote is treating everything as a single integrated device which
is not inconsistent with what has been said. In this case there really
is only one multi-function device not two independent ones.

If you want to control two independent devices you need to buy a
different remote. Remotes are cheap so that's not a big deal.

If you really want to use this remote to control two independent
devices you need user space scripting to split the single device into
two devices and then inject new events into the input layer. This is a
complex case and not in the goal of getting 90% of users to "just
work".

>
>> Instead, a multifunction
>> remote (or two distinct remotes) would send different scan codes[1],
>> which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
>> Btw. the former is already defined, besides the generic KEY_PLAY.
>>
>> Even if all this worked, user space would need integration with
>> hal/devicekit to open the new input devices appearing on the fly (if
>> it's initiated by the arrival of a scan code belonging to some new
>> protocol), and also be able to decide whether the new event source is
>> for it or not.
>>
>> Given that commodity home appliances manage not to be confused by
>> multiple or multifunction remotes, decent software should be able to do
>> so as well.
>>
>> [1] scan codes in the broadest possible sense, containing vendor,
>> address and whatever, and only treating the case which is possible to
>> handle in principle.
>
> I see two alternatives for it:
> 1) to map a multifunction scancode Address=TV/command=channel up as two
> separate events: KEY_TV | KEY_CHANNELUP and let some userspace 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
jonsmirl@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T08:33:56Z

Ferenc Wagner wrote:
> Mauro Carvalho Chehab <mchehab@...> writes:
>
>> Dmitry Torokhov wrote:
>>

> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
> by any remote (ok, I'm stretching it a bit).

Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.

On those remotes, if you press TV and then press for example Channel UP
and press Radio, then press Channel UP, the channel UP code will be the same.

For example, on Hauppauge Grey IR, we have:

<TV>
[13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
[13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
[13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0

<CHANNEL UP>
[13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
[13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
[13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0

<Radio>
[13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
[13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
[13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0

<CHANNEL UP>
[13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
[13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
[13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0

In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
shipped IR's.

> Instead, a multifunction
> remote (or two distinct remotes) would send different scan codes[1],
> which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
> Btw. the former is already defined, besides the generic KEY_PLAY.
>
> Even if all this worked, user space would need integration with
> hal/devicekit to open the new input devices appearing on the fly (if
> it's initiated by the arrival of a scan code belonging to some new
> protocol), and also be able to decide whether the new event source is
> for it or not.
>
> Given that commodity home appliances manage not to be confused by
> multiple or multifunction remotes, decent software should be able to do
> so as well.
>
> [1] scan codes in the broadest possible sense, containing vendor,
> address and whatever, and only treating the case which is possible to
> handle in principle.

I see two alternatives for it:
1) to map a multifunction scancode Address=TV/command=channel up as two
separate events: KEY_TV | KEY_CHANNELUP and let some userspace 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.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T08:03:16Z

Mauro Carvalho Chehab <mchehab@...> writes:

> Dmitry Torokhov wrote:
>
>>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>>>
>>>>>> Now I understand that if 2 remotes send completely identical
>>>>>> signals we won't be able to separete them, but in cases when we
>>>>>> can I think we should.
>>
>> They are the same key events (Lets's say KEY_PLAY) but one is
>> supposed to affect CD player while another DVD player
>> application. Evdev will not be able to distinguish them but if we had
>> 2 separate devices then applications could read from the one thet
>> user assigned to them.
>
> This is clear, but the point is that the two distinguish scancodes can
> (and, in practice, will) be generated by the same IR. For example, my
> Satellite IR produces two different sets of codes. if you press <SAT>,
> all keys you press after that will have the "sat" address. If you
> press <TV>, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit). Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
--
Regards,
Feri.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T04:02:49Z

On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

> > Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> > object internally. I was going to write lirc_v4l glue between the
> > v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
> >
> > As for the the I2C chips, I was going to go back and encapsulate those
> > in the v4l2_subdevice object as well, so then my notional lirc_v4l could
> > pick those up too. The I2C subsystem only allows one binding to an I2C
> > client address/name on a bus. So without some new glue like a notional
> > lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
> > lirc_zilog.
>
> Maybe you're having a bad time because you may be trying to integrate lirc
> at the wrong place.

These were just ideas. I haven't done *anything* yet. ;)

> All devices at V4L tree including ir-kbd-i2c use ir-common.ko
> (at /drivers/media/common tree) module to communicate to IR's.
> I'm preparing some patches to extend this also to dvb-usb devices
> (that uses a close enough infrastructure).
>
> Also, most of the decoding code are there, in a form of helper routines.
>
> As the idea is to provide lirc interface to all devices that can work with
> raw pulse/space, the proper place is to write a subroutine there that, once
> called, will make those pulse/space raw codes available to lirc and will
> call the needed decoders to export them also to evdev.
>
> The code at ir-common module was originally built to be used by V4L, but I'm
> porting the code there to be generic enough to be a library that can be used
> by other drivers. So, lirc_zilog and other lirc devices that will need to open
> evdev interfaces after running a decoder can use them.

I think I see what you are saying (I wish could see look at a whiteboard
somewhere...). Wherever we come through internally to split to 2
different userspace interfaces is fine, if you've got a big picture plan
you think is feasible.

That seems like a bit of perturbation to lirc_zilog and lirc_i2c. My
thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops
interface, and maybe some new calls associted with v4l2_device, could
subsume/unify all the functionality of lirc_i2c, lirc_zilog, ...
lirc_whatever.

Maybe that's just a poorly thought out dream though...

> Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
> a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
> be implemented as a separate module.

The v4l_subdevice just abstracted the IR hardware into a nice (mental)
box for me -- easier to keep hardware separate from software decoders
and userspace interface logic.

Also, since v4l2_subdevices may have per subdevice /dev nodes and
the /dev/../mcN nodes providing a discovery mechanism due to the Meda
Controller framework, wrapping things in v4l2_subdevice may be handy for
development and debug. Or ... as an additional operational interface to
userspace. :D *ducks and runs for cover*

Regards,
Andy

> Cheers,
> Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T03:20:57Z

Jon Smirl wrote:

> On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson <jarod@...> wrote:
>> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
>> ...
>>>>>> Now I understand that if 2 remotes send completely identical signals we
>>>>>> won't be able to separate them, but in cases when we can I think we
>>>>>> should.
>>>>> I don't have a problem with that, if its a truly desired feature. But
>>>>> for the most part, I don't see the point. Generally, you go from
>>>>> having multiple remotes, one per device (where "device" is your TV,
>>>>> amplifier, set top box, htpc, etc), to having a single universal remote
>>>>> that controls all of those devices. But for each device (IR receiver),
>>>>> *one* IR command set. The desire to use multiple distinct remotes with
>>>>> a single IR receiver doesn't make sense to me. Perhaps I'm just not
>>>>> creative enough in my use of IR. :)
>>> Most universal remotes I'm familiar with emulate multiple remotes. I.e.
>>> my tv remote generates one set of scancodes for the numeric keys. The DVD
>>> remote generates a different set. The amplifier remote in "tv mode"
>>> generates the same codes as the tv remote, and in "dvd mode" the same codes
>>> as the dvd remote. From the perspective of the IR receiver there is no
>>> difference between having both the DVD and TV remotes, or using the
>>> aplifier remote to control both devices.
>> Okay, in the above scenario, you've still got a single input device...
>>
>>> Now, my aplifier remote has a number of modes. Some control devices I
>>> have, like "vcr mode", and there is nothing I can do about that. Some,
>>> like "md mode" don't control devices I have. That means they are free to
>>> do things on the computer. Someone else with the same remote (or any
>>> number of remotes that use the same protocol and scancodes) might have
>>> different devices.
>>>
>>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
>>> "JVC VCR #yyy" yets. Someone with an MD player and not a VCR would want to
>>> opposite. Rather than force everyone to create custom keymaps, it's much
>>> easier if we can use the standard keymaps from a database of common remotes
>>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
>> Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...).
>>
>>> It sounds like you're thinking of a receiver that came bundled with a
>>> remote and that's it. Not someone with a number of remotes that came with
>>> different pieces of AV gear that they want to use with their computer.
>> No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one.
>>
>> Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it.
>
> Simple 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. Press the CD key - commands get routed to the music
> server, press the AUX key - commands get routed to the home automation
> app.
>
> This is accomplished by recognizing the device code part of the IR
> signal and figuring out that there are two different device codes in
> use. The commands of then routed to two evdev devices corresponding to
> the two different device codes.
>
> Using things like Alt-Tab to switch apps is impossible. There's no
> screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups.

Also, as you're thinking on 64 bits scancodes, this also means that the
current evdev KABI and API will require changes to support bigger scancodes.

Anyway, IMO, this subject should be handled as a different requirement than
integrating the lirc drivers.

Cheers,
Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T03:09:36Z

Andy Walls wrote:

> On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>>
>>> Dmitry Torokhov wrote:
>> ...
>>>>>> (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 transmitter that would be the best I
>>>> think, but I understand that it is rarely possible?
>>> IMHO, the better is to use a separate interface for the IR transmitters,
>>> on the devices that support this feature. There are only a few devices
>>> I'm aware of that are able to transmit IR codes.
>> If I'm thinking clearly, there are only three lirc kernel drivers that
>> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
>> driver was posted, so I won't rehash what it is here. The zilog driver
>> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
>> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
>> etc). The serial driver is fairly self-explanatory as well.
>>
>> There are also a few userspace-driven devices that do transmit, but
>> I'm assuming they're (currently) irrelevant to this discussion.
>
>
> I've got the CX23888 integrated IR Rx done and Tx nearly done. I was
> waiting to see how kfifo and lirc_dev panned out before making the
> interface to userspace.
>
> The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
> I hope to have CX23885 IR done by Christmas.
>
> Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> object internally. I was going to write lirc_v4l glue between the
> v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
>
> As for the the I2C chips, I was going to go back and encapsulate those
> in the v4l2_subdevice object as well, so then my notional lirc_v4l could
> pick those up too. The I2C subsystem only allows one binding to an I2C
> client address/name on a bus. So without some new glue like a notional
> lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
> lirc_zilog.

The better is to add the lirc glue at ir-common module. There, we have the support
functions used by all V4L devices, and they'll be expanded to cover also
dvb-usb, as soon as I can find some time to do a patch for it.

Cheers,
Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T03:09:14Z

Jon Smirl wrote:

> On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
> <mchehab@...> wrote:
>> Jon Smirl wrote:
>>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod@...> 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 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 transmitter that would be the best I
>>>>>>>>> think, but I understand that it is rarely possible?
>>>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>>>> keycodes. Each remote was its own evdev device.
>>>>>> Note, of course, that you can only do that iff each remote uses distinct
>>>>>> triplets. A good portion of mythtv users use a universal of some sort,
>>>>>> programmed to emulate another remote, such as the mce remote bundled
>>>>>> with mceusb transceivers, or the imon remote bundled with most imon
>>>>>> receivers. I do just that myself.
>>>>>>
>>>>>> Personally, I've always considered the driver/interface to be the
>>>>>> receiver, not the remote. The lirc drivers operate at the receiver
>>>>>> level, anyway, and the distinction between different remotes is made by
>>>>>> the lirc daemon.
>>>>> The fact that lirc does it this way does not necessarily mean it is the
>>>>> most corerct way.
>>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>>>
>>>>> Do you expect all bluetooth input devices be presented
>>>>> as a single blob just because they happen to talk to the sane receiver
>>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>>>> together just because they end up being serviced by the same host
>>>>> controller? If not why remotes should be any different?
>>>> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.
>>> Actually remotes do have an ID. They all transmit vendor/device pairs
>>> which is exactly how USB works.
>>>
>> Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm
>> doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders
>> I have.
>
> Some of the protocols were not intended to be multi-vendor - the
> vendor is implicit in the protocol encoding. You don't have to split
> the IR codes into vendor/device/command triplets. I just do that
> because it is convenient to think of them that way. It is equally
> valid to treat them as a 64b integers and use four bits of the int to
> encode the protocol. It should really be a quad
> protocol/vendor/device/command and some of the fields may be missing.
> Bottom line, you are looking for unique codes how the fields are split
> up doesn't really matter.

Currently, there aren't any in-kernel driver that support 64 bit IR's.
They support only up to 16 bits. So, we have only address (device)/command.
As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits.

As pointed by Andy, it is risky to support such protocol in kernel,
since you won't be able to ship the kernel to countries where RC6 patents
got accepted, or you would need.

> A fixed protocol receiver is more of a challenge. You have to figure
> out how to make a universal remote transmit device codes for a device
> you don't already own that is also encoded in the protocol your
> hardware supports.
> There's nothing we can do about that problem in
> Linux, its a side effect of fixed protocol decode hardware.

With hardware decoders, you're limited to the supported protocols, but yet,
you can use a different scancode than the one that comes with the shipped
device.

If you take a look, for example, at the NEC protocol decoder we have on
drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the
tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able
to receive the entire sequence at the GPIO port. Fortunately, on the device
where this decoder is called (Avermedia M135A), we can trigger the start
of the IR code via IRQ.

[1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD

In this specific decoder I've implemented it some time ago. I think
I tried first to get the pulse/space width using just IRQ without the tasklet,
but the lengths weren't precise enough for decoding. Also, if you have a bad
contact at the IR sensor connector, as it is directly connected to an IRQ pin,
you may end by hanging the machine, if the code is not carefully written.

I remember I had some bad time due to the bad contacts at the IR sensor
with the sample I had available for implementing that IR.

Btw, looking at that code, while it is not impossible to split the
IR pulse/space measures from the NEC decoder itself, and make it generic
to support other protocols, it is not a trivial task, and may result on
a less stable driver. Without splitting the protocol decoder, even being
able to store raw pulse/space data on some fifo, the driver will still
limit the protocol for that board to NEC (there is a similar code for RC5
there also, using some generic functions [2]).

[2]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/common/ir-functions.c;h=16792a68a44951e1bc1c2cbb1c9da27a2b6b2722;hb=HEAD

The advantage of the NEC decoding approach on saa7134 is that you know for
sure how much time it is required to get the entire code. So, the code
can easily abort the reception of a bad code. The disadvantage is that
only one protocol can be decoded at the same time.

The same problem also happens with almost all in-kernel drivers: the decoders
for raw mode were constructed to work with just one pulse/space code at the
same time. A conversion into a generic code can happen, but it will require
several tests to be sure that they won't cause undesirable side-effects.

The advantage of hardware decoders is that you don't need to be polling the
IR serial port at a high rate, as you'll get directly the code. So, you'll
free the CPU to do something else.

> You're just going to have to start guessing devices in the remote until you
> find one that uses your fixed protocol and doesn't also activate the
> devices you own. We can put suggestions in the doc when working
> devices are discovered. With a universal receiver the problem is
> simpler, just pick a device you don't own - the encoding protocol
> doesn't matter. These are generic problems with IR that are the same
> no matter how things get implemented in Linux.

Yes, provided that we can successfully change the drivers to split decoders from
pulse/space counting.

Cheers,
Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-03T02:00:45Z

Andy Walls wrote:

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko
(at /drivers/media/common tree) module to communicate to IR's.
I'm preparing some patches to extend this also to dvb-usb devices
(that uses a close enough infrastructure).

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

Cheers,
Mauro.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: [RFC v2] Another approach to IR

2009-12-02T21:18:54Z

On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson <jarod@...> wrote:

> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
> ...
>>>>> Now I understand that if 2 remotes send completely identical signals we
>>>>> won't be able to separate them, but in cases when we can I think we
>>>>> should.
>>>>
>>>> I don't have a problem with that, if its a truly desired feature. But
>>>> for the most part, I don't see the point. Generally, you go from
>>>> having multiple remotes, one per device (where "device" is your TV,
>>>> amplifier, set top box, htpc, etc), to having a single universal remote
>>>> that controls all of those devices. But for each device (IR receiver),
>>>> *one* IR command set. The desire to use multiple distinct remotes with
>>>> a single IR receiver doesn't make sense to me. Perhaps I'm just not
>>>> creative enough in my use of IR. :)
>>
>> Most universal remotes I'm familiar with emulate multiple remotes. I.e.
>> my tv remote generates one set of scancodes for the numeric keys. The DVD
>> remote generates a different set. The amplifier remote in "tv mode"
>> generates the same codes as the tv remote, and in "dvd mode" the same codes
>> as the dvd remote. From the perspective of the IR receiver there is no
>> difference between having both the DVD and TV remotes, or using the
>> aplifier remote to control both devices.
>
> Okay, in the above scenario, you've still got a single input device...
>
>> Now, my aplifier remote has a number of modes. Some control devices I
>> have, like "vcr mode", and there is nothing I can do about that. Some,
>> like "md mode" don't control devices I have. That means they are free to
>> do things on the computer. Someone else with the same remote (or any
>> number of remotes that use the same protocol and scancodes) might have
>> different devices.
>>
>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
>> "JVC VCR #yyy" yets. Someone with an MD player and not a VCR would want to
>> opposite. Rather than force everyone to create custom keymaps, it's much
>> easier if we can use the standard keymaps from a database of common remotes
>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
>
> Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...).
>
>> It sounds like you're thinking of a receiver that came bundled with a
>> remote and that's it. Not someone with a number of remotes that came with
>> different pieces of AV gear that they want to use with their computer.
>
> No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one.
>
> Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it.

Simple 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. Press the CD key - commands get routed to the music
server, press the AUX key - commands get routed to the home automation
app.

This is accomplished by recognizing the device code part of the IR
signal and figuring out that there are two different device codes in
use. The commands of then routed to two evdev devices corresponding to
the two different device codes.

Using things like Alt-Tab to switch apps is impossible. There's no
screen to look at.

>
> --
> Jarod Wilson
> jarod@...
>
>
>
>

--
Jon Smirl
jonsmirl@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev