Re: [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling

["David Härdeman" <david@hardeman.nu>]

On Wed, Sep 08, 2010 at 10:16:13AM -0400, Jarod Wilson wrote:
> On Wed, Sep 08, 2010 at 07:04:03AM -0700, Brian Rogers wrote:
> > ir_dev->raw is also null. If I check these pointers before using
> > them, and bail out if both are null, then I get a working lircd, but
> > of course the file /sys/devices/virtual/rc/rc0/protocols no longer
> > does anything. On 2.6.35.4, the system never creates the
> > /sys/class/rc/rc0/current_protocol file. Is it the case that the
> > 'protocols' file should never appear, because my card can't support
> > this feature?
> 
> Hm... So protocols is indeed intended for hardware that handles raw IR, as
> its a list of raw IR decoders available/enabled/disabled for the receiver.
> But some devices that do onboard decoding and deal with scancodes still
> need to support changing protocols, as they can be told "decode rc5" or
> "decode nec", etc... My memory is currently foggy on how it was exactly
> that it was supposed to be donee though. :) (Yet another reason I really
> need to poke at the imon driver code again).

This, and a raft of similar bugreports was one of the reasons I wrote 
the rc_dev patch (which gets rid of ir_dev->props, the source of many 
oopses by now).

Hardware decoders should work with the same sysfs file, the driver 
should set ir_dev->props->change_protocol (current) or 
rc->change_protocol (future) and it'll get notified when userspace 
interacts with the sysfs file and the hardware can then react 
accordingly. So the answer is yes - all hardware should have the file.

-- 
David Härdeman
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html