On Thu, Mar 19, 2015 at 09:50:11PM +0000, Sean Young wrote: >This patch series tries to fix the lirc interface and extend it so it can >be used to send/recv scancodes in addition to raw IR: > > - Make it possible to receive scancodes from hardware that generates > scancodes (with rc protocol information) > - Make it possible to receive decoded scancodes from raw IR, from the > in-kernel decoders (not mce mouse/keyboard). Now you can take any > remote, run ir-rec and you will get both the raw IR and the decoded > scancodes plus rc protocol information. > - Make it possible to send scancodes; in kernel-encoding of IR > - Make it possible to send scancodes for hardware that can only do that > (so that lirc_zilog can be moved out of staging, not completed yet) > - Possibly the lirc interface can be used for cec? > >This requires a little refactoring. > - All rc-core devices will have a lirc device associated with them > - The rc-core <-> lirc bridge no longer is a "decoder", this never made > sense and caused confusion IIRC, it was written that way to make the lirc module optional. >This requires new API for rc-core lirc devices. > - New feature LIRC_CAN_REC_SCANCODE and LIRC_CAN_SEND_SCANCODE > - REC_MODE and SEND_MODE do not enable LIRC_MODE_SCANCODE by default since > this would confuse existing userspace code > - For each scancode we need: > - rc protocol (RC_TYPE_*) > - toggle and repeat bit for some protocols > - 32 bit scancode I haven't looked at the patches in detail, but I think exposing the scancodes to userspace requires some careful consideration. First of all, scancode length should be dynamic, there are protocols (NEC48 and, at least theoretically, RC6) that have scancodes > 32 bits. Second, if we expose protocol type (which we should, not doing so is throwing away valuable information) we should tackle the NEC scancode question. I've already explained my firm conviction that always reporting NEC as a 32 bit scancode is the only sane thing to do. Mauro is of the opinion that NEC16/24/32 should be essentially different protocols. Third, we should still have a way to represent the protocol in the keymap as well. And on a much more general level...I still think we should start from scratch with a rc specific chardev with it's own API that is generic enough to cover both scancode / raw ir / future / other protocols (not that such an undertaking would preclude adding stuff to the lirc API of course). Re, David PS Thanks for your continued RC efforts Sean! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
