Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote:
> This part... Not so wild about. The common thought I'm seeing from people is
> that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> this could be abstracted away so the user never sees it, but it seems to be
> reinventing a way to set up key mapping when setkeycode already exists, and
> is used by a number of existing IR devices in the v4l/dvb subsystem (as well
> as misc things like the ati rf remotes, iirc). Is there some distinct
> advantage to going this route vs. setkeycode that I'm missing?

The configfs scheme and keymaps offer the same abilities. One is an
ancient binary protocol and the other one uses Unix standard commands
like mkdir and echo to build the map. You need special commands -
setkeycodes, getkeycodes, showkey, loadkeys, xmodmap, dump-keys to use
a keymap.  I've been using Linux forever and I can't remember how
these commands work.

Keymaps are a binary protocol written by Risto Kankkunen in 1993.
Configfs was added by Oracle about two years ago but it has not been
used for mapping purposes.

It's another discussion, but if IR goes the configfs route I'd
consider writing a patch to switch keymaps/keycodes onto the configfs
model. It is a huge advantage to get rid of these pointless special
purpose commands that nobody knows how to use. I'd keep the legacy
IOCTLs working and redirect the data structure to a configfs one
instead of the existing structure.

The same idea is behind getting rid of IOCTLs and using sysfs. Normal
Unix commands can manipulate sysfs. IOCTLs have problems with strace,
endianess and the size of int (32/64b).

-- 
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

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux