<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/media/IR/ir-sysfs.c, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/media/IR/ir-sysfs.c?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/media/IR/ir-sysfs.c?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2010-12-29T10:16:36Z</updated>
<entry>
<title>[media] rename drivers/media/IR to drives/media/rc</title>
<updated>2010-12-29T10:16:36Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@redhat.com</email>
</author>
<published>2010-11-10T02:00:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=32cf86f6d16367db5a10039c1dd938a2427d697c'/>
<id>urn:sha1:32cf86f6d16367db5a10039c1dd938a2427d697c</id>
<content type='text'>
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>[media] IR: make sure we register the input device when it is safe to do so</title>
<updated>2010-10-21T09:54:13Z</updated>
<author>
<name>Maxim Levitsky</name>
<email>maximlevitsky@gmail.com</email>
</author>
<published>2010-09-06T21:26:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=58b3dd449feaa997129bde23592c6a31da039e4e'/>
<id>urn:sha1:58b3dd449feaa997129bde23592c6a31da039e4e</id>
<content type='text'>
As soon as input device is registered, it might be accessed (and it is)
This can trigger a hardware interrupt that can access
not yet initialized ir-&gt;raw, (by sending a sample)

This can be reproduced by holding down a remote button and reloading the module.
And this always crashes the systems where hardware decides to send an interrupt
right at the moment it is enabled.

Signed-off-by: Maxim Levitsky &lt;maximlevitsky@gmail.com&gt;
Acked-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>[media] ir: avoid race conditions at device disconnect</title>
<updated>2010-10-21T09:54:01Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@redhat.com</email>
</author>
<published>2010-10-14T15:23:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b4d752b308493b08b51ea04361848ef63d0cad42'/>
<id>urn:sha1:b4d752b308493b08b51ea04361848ef63d0cad42</id>
<content type='text'>
It is possible that, while ir_unregister_class() is handling, some
application could try to access the sysfs nodes, causing an OOPS.

Reviewed-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: IR/streamzap: functional in-kernel decoding</title>
<updated>2010-10-21T03:04:47Z</updated>
<author>
<name>Jarod Wilson</name>
<email>jarod@redhat.com</email>
</author>
<published>2010-08-07T16:31:40Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7a569f524dd36806b995c844f29e28ff40c444b2'/>
<id>urn:sha1:7a569f524dd36806b995c844f29e28ff40c444b2</id>
<content type='text'>
This patch makes in-kernel decoding with the stock Streamzap PC Remote
work out of the box. There are quite a few things going on in this
patch, all related to getting this working:

1) I had to enable reporting of a long space at the end of each signal,
   or I had weird buffering and keybounce issues.

2) The keymap has been reworked slightly to match actual decoded values,
   the first edition was missing the pre-data bits present in the lirc
   config file for this remote.

3) There's a whole new decoder included, specifically for the
   not-quite-RC5 15-bit protocol variant used by the Streamzap PC
   Remote. The decoder, while usable with other recievers (tested with
   an mceusb receiver), will only be loaded by the streamzap driver, as
   its likely not of use in almost all other situations. This can be
   revisited if/when all keytable loading (and disabling of unneeded
   protocol decoder engines) is moved to userspace, but for now, I think
   this makes the most sense.

Note that I did try to enable handling the streamzap RC5-ish protocol in
the current RC5 decoder, but there's no particularly easy way to tell if
its 14-bit RC5 or 15-bit Streamzap until we see bit 14, and even then,
in testing an attempted decoder merge, only 2/3 of the keys were
properly recognized as being the 15-bit variant and decoded correctly,
the rest were close enough to compliant with 14-bit that they were
decoded as such (but they have overlap with one another, and thus we
can't just shrug and use the 14-bit decoded values).

Also of note in this patch is the removal of the streamzap driver's
internal delay buffer. Per discussion w/Christoph, it shouldn't be
needed by lirc any longer anyway, and it doesn't seem to make any
difference to the in-kernel decoder engine. That being the case, I'm
yanking it all out, as it greatly simplifies the driver code.

Signed-off-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: ir-core: Fix null dereferences in the protocols sysfs interface</title>
<updated>2010-09-30T10:18:37Z</updated>
<author>
<name>Brian Rogers</name>
<email>brian@xyzw.org</email>
</author>
<published>2010-09-22T11:06:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a08c7c68f702e2a2797a4035b6c0a756c4886c26'/>
<id>urn:sha1:a08c7c68f702e2a2797a4035b6c0a756c4886c26</id>
<content type='text'>
For some cards, ir_dev-&gt;props and ir_dev-&gt;raw are both NULL. These cards are
using built-in IR decoding instead of raw, and can't easily be made to switch
protocols.

So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' as
the supported and enabled protocol. Return -EINVAL on any attempts to change
the protocol. And most important of all, don't crash.

Signed-off-by: Brian Rogers &lt;brian@xyzw.org&gt;
Acked-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: IR: Allow not to compile keymaps in</title>
<updated>2010-08-09T02:43:00Z</updated>
<author>
<name>Maxim Levitsky</name>
<email>maximlevitsky@gmail.com</email>
</author>
<published>2010-07-31T14:59:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b378f43fe9466e7712a8b16be64795ffca3a937e'/>
<id>urn:sha1:b378f43fe9466e7712a8b16be64795ffca3a937e</id>
<content type='text'>
Currently, ir device registration fails if keymap requested by driver is not found.
Fix that by always compiling in the empty keymap, and using it as a failback.

Signed-off-by: Maxim Levitsky &lt;maximlevitsky@gmail.com&gt;
Acked-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: IR: add ir-core to lirc userspace decoder bridge driver</title>
<updated>2010-08-02T18:16:20Z</updated>
<author>
<name>Jarod Wilson</name>
<email>jarod@redhat.com</email>
</author>
<published>2010-07-03T04:07:53Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ca4146985db7cbb97816e9b961b8db79e63d9e86'/>
<id>urn:sha1:ca4146985db7cbb97816e9b961b8db79e63d9e86</id>
<content type='text'>
v2: copy of buffer data from userspace done inside this plugin/driver,
keeping the actual drivers minimal, and more flexible in what we can
deliver to them later on (they may be fed from within kernelspace later
on, by an in-kernel IR encoder).

Signed-off-by: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: ir-core: allow specifying multiple protocols at one open/write</title>
<updated>2010-08-02T17:55:05Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@redhat.com</email>
</author>
<published>2010-06-28T16:52:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=de8592bd539b2bb8da2b55b1007562eb1abd1fe6'/>
<id>urn:sha1:de8592bd539b2bb8da2b55b1007562eb1abd1fe6</id>
<content type='text'>
With this change, it is now possible to do something like:
        su -c 'echo "none +rc-5 +nec" &gt; /sys/class/rc/rc1/protocols'

This prevents the need of multiple opens, one for each protocol change,
and makes userspace application easier.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: ir-core: Add support for disabling all protocols</title>
<updated>2010-08-02T17:54:56Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@redhat.com</email>
</author>
<published>2010-06-28T15:58:48Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5f1247972e0fcce6dd4bce94459a9f3db09ae61d'/>
<id>urn:sha1:5f1247972e0fcce6dd4bce94459a9f3db09ae61d</id>
<content type='text'>
Writing "none" to /dev/class/rc/rc*/protocols will disable all protocols.
This allows an easier setup, from userspace, as userspace applications don't
need to disable protocol per protocol, before enabling a different set of
protocols.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
<entry>
<title>V4L/DVB: ir-core: Rename sysfs protocols nomenclature to rc-5 and rc-6</title>
<updated>2010-08-02T17:54:45Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@redhat.com</email>
</author>
<published>2010-06-28T15:43:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a9e55ea9774cc87434b386a7fba63d96af32792d'/>
<id>urn:sha1:a9e55ea9774cc87434b386a7fba63d96af32792d</id>
<content type='text'>
While rc-5 and rc-6 protocols are generally abreviated as "rc5" and "rc6",
previous sysfs nodes uses rc-5 and rc-6 for the Philips protocols. This is
consistent with the protocol nomenclature given by the original Philips
spec: "Remote control system RC-5" (doc. Nr. 9398 706 23011).
Also, rc5 is the name of a widely known cryptography protocol.

So, the better is to keep referring to those protocols as "rc-5" and "rc-6".

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
</content>
</entry>
</feed>
