Manu Abraham wrote: > On Thu, Feb 11, 2010 at 11:44 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxxxxx> wrote: >> Manu Abraham wrote: >> >>> changeset 14166 >>> http://jusst.de/hg/mantis-v4l-dvb/rev/c2391fa88112 >>> Mantis: Remote Control for Mantis >> + ir_input_init(rc_dev, rc_state, IR_TYPE_OTHER); >> >> ... >> >> +struct ir_scancode_table ir_codes_mantis_vp2040_table = { >> + .scan = ir_codes_mantis_vp2040, >> + .size = ARRAY_SIZE(ir_codes_mantis_vp2040), >> +}; >> +EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2040_table); >> >> The non-declaration of the IR protocol and the definition of >> incomplete IR codes is deprecated. Please, create a table with >> the IR protocol type and add the IR address to each IR scancode >> at the ir codes tables. >> >> Please look at em28xx-input to see how to implement it right. >> The change is minimal: >> - at the driver, you'll need to make sure that you're >> using the full IR scan code, instead of just the 8 bits for IR cmd; >> >> - at the table: you need to use IR address+command scan code, >> and declare the protocol associated with the table; > > > Huh ? em28xx uses a I2C based implementation for the IR. > There's no address associated with the IR stuff on the mantis, which > is on something say like COM 0/1, which is more similar, rather than > an I2C device or a polling based device. This is true only for the old devices. The em2860/em2880 devices support NEC and RC5. Newer chips (like em2884) also support RC6. Anyway, the changes are not in the way the device communicates with the chip, but the way it is presented to IR core, and how the keycodes are decoded. If you take a look on em28xx-input, you'll see, for example: static int default_polling_getkey(struct em28xx_IR *ir, struct em28xx_ir_poll_result *poll_result); This routine gets 4 bytes from the device and stores both the RC address and RC command (at rc_address and rc_data[0] fields). The routine that generates the keypress events is: static void em28xx_ir_handle_key(struct em28xx_IR *ir); As the driver still work with the legacy keytables, it is easy to check where's the difference between handling an incomplete or a complete keycode: if (ir->full_code) ir_input_keydown(ir->input, &ir->ir, poll_result.rc_address << 8 | poll_result.rc_data[0]); else ir_input_keydown(ir->input, &ir->ir, poll_result.rc_data[0]); So, basically, new drivers and new keycodes should use the entire RC code (address + data) to the input subsystem. > > Also the protocol is not something that can be seen externally, It > is all internal to the firmware on the micro. The micro auto detect's > the relevant protocol. ie, what it outputs is all data, no messages. That's even better. Yet, if you're using just the IR cmd, people won't be able to use another IR with the device. > > I don't follow what you tend to imply .. > > >> - at the driver: instead of using IR_TYPE_OTHER, just pass the >> value that comes from the IR table. >> >> A correct implementation allows the replacement of the IR by >> universal ones, at userspace, the key re-definition and, if >> the driver supports more protocol, the protocol changes, >> all provided by the new IR input class. > > > > Ah, i now understand what you are trying to say.. Unfortunately you > can't do a protocol conversion or anything likewise on the Mantis IR > device. It is all in hardware and the protocol type is all auto > detected. All what you can change is the UART settings such as BPS, > Parity and STOP bit. There's nothing the user can do to change > anything in there. > > To put it short: whatever remote you use, if it is a supported remote > by the firmware, it will output the relevant keycode directly, not > messages such that the message needs to be decoded further. Yes, but the IR core allows replacing the keycode <-> scancode from the driver. This allows some usecases, like: - using a different IR; - using the same IR, but customizing the keys; - using a different IR to control several different devices, where only some keys will be handled by the device. >> I think I need to add add a macro to export the IR table, replacing >> all *_table definitions, in order to avoid patches submitted with >> the legacy way (and to remove a false-positive on checkpatch.pl). >> >> Also there are some coding style troubles here, including bad >> whitespaces. By running make whitespace, you'll be clearing most >> of the warnings. > > > Ok, I will take a look, tomorrow evening. > > Regards, > Manu -- Cheers, Mauro -- 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
