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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
