On Fri, Mar 26, 2010 at 06:37:41PM -0400, Jon Smirl wrote: > On Fri, Mar 26, 2010 at 1:22 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> wrote: > > 2) create a read/write sysfs node that would indicate the number of > > event/keymaps > > associated with a given IR. By writing a bigger number, it would create new devices. > > By writing a smaller number, it will delete some maps. There's an issue though: > > what criteria would be used to delete? The newly created ones? > > This is normally handled a sysfs node on the core, something like > 'adddev'. You echo '1' to this node and a new interface is created. > > Each interface has a sysfs node, make a 'remove' attribute in it. Echo > '1' to remove to make it disappear. > > You have to implement the code behind these interfaces but this > convention is used in other subsubsystems. > > BTW - you're recreating everything the configfs interface did. it > achieved the same results with mkdir/rmdir. I liked the configfs > scheme since there are no obscure commands to learn. Everybody can > make files and directories. I've looked at your configfs interface, it was the inspiration for suggesting that each irrcv device should have more than one keymap with one input device for each keytable. However, I don't agree that the configfs interface would somehow be more user-friendly than an ioctl based one. Getting the correct "scancode" (e.g, protocol, device, function values), finding a corresponding keycode (is it KEY_0, no wait, it's KEY_NUMERIC_0), etc are bigger hurdles than mkdir/rmdir/echo or calling a tool similar to input-utils which does the ioctl. mount -t configfs blabla /somewhere (distros don't seem to mount configfs per default) cd /somewhere/somewhere-else mkdir something echo gibberish1 > yada1 echo gibberish2 > yada2 echo gibberish3 > yada3 Doesn't seem all that much less obscure than the command line interface to an ioctl based interface: ir-util load_keytable /usr/share/remotes/blah or ir-util load_keyentry "gibberish1,gibberish2 = gibberish3" Assume the user provides an invalid (e.g. out-of-bounds value for the device field of a RC5 ir command) scancode. With the configfs approach the user will get a standard perror reply from echo/cat. With a dedicated tool the user can get a much more informative error message. But in the end, the majority of users are going to use some GUI to do all of this anyway (and they'll only do it once)....start GUI, ask user to press all keys on remote one by one, provide them with a list of possible descriptions (i.e. input.h type keycodes) for each detected key on the remote (something like the keymapping interface most quake-like computer games provide). Once done, save keymap. Load keymap at boot. Configfs or ioctl or sysfs or netlink or blorkfs is a detail which won't matter to those users. -- David Härdeman -- 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
