On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <khc@xxxxxxxxx> wrote: > 1. Do we agree that a lirc (-style) kernel-user interface is needed at > least? > > 2. Is there any problem with lirc kernel-user interface? Can you consider sending the raw IR data as a new evdev message type instead of creating a new device protocol? evdev protects the messages in a transaction to stop incomplete messages from being read. You might also want to use evdev capabilities to describe what the hardware can do. These were the capabilities I had made up: #define IR_CAP_RECEIVE_BASEBAND 0 #define IR_CAP_RECEIVE_36K 1 #define IR_CAP_RECEIVE_38K 2 #define IR_CAP_RECEIVE_40K 3 #define IR_CAP_RECEIVE_56K 4 #define IR_CAP_SEND_BASEBAND 5 #define IR_CAP_SEND_36K 6 #define IR_CAP_SEND_38K 7 #define IR_CAP_SEND_40K 8 #define IR_CAP_SEND_56K 9 #define IR_CAP_XMITTER_1 10 #define IR_CAP_XMITTER_2 11 #define IR_CAP_XMITTER_3 12 #define IR_CAP_XMITTER_4 13 #define IR_CAP_RECEIVE_RAW 14 #define IR_CAP_SEND_RAW 15 > If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge > the Jarod's lirc patches (at least the core) so at least the > non-controversial part is done? > > Doing so doesn't block improving input layer IR interface, does it? > -- > Krzysztof Halasa > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
