lkml.org 
[lkml]   [2010]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
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@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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-03-27 09:31    [W:0.256 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site