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

Reply via email to