From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Rick L. Vinyard, Jr." <rvinyard@cs.nmsu.edu>
Cc: liux-input@vger.kernel.org, Jiri Kosina <jkosina@suse.cz>,
Linux <linux-kernel@vger.kernel.org>,
Linux USB <linux-usb@vger.kernel.org>
Subject: Re: Handling macros with input devices
Date: Wed, 14 Apr 2010 15:56:08 -0700 [thread overview]
Message-ID: <20100414225608.GB12143@core.coreip.homeip.net> (raw)
In-Reply-To: <054d04d6a47f4ba368c8d75f8d8fb08f.squirrel@intranet.cs.nmsu.edu>
Hi Rick,
On Wed, Apr 14, 2010 at 12:19:30PM -0600, Rick L. Vinyard, Jr. wrote:
> One of the sticking points I have with the G13 driver is that I'd like it
> to have support for macros. The reason I'd like to support macros is that
> the G13's raison d'etre is to allow the end user to customize the device
> with their own macros.
>
> However, I've been looking around and I can't find any support for macros
> within the kernel.
>
> In particular, I have support for getkeycode and setkeycode ioctl's. I was
> thinking of supporting at least setkeycode to allow a standard way to set
> a one key macro. Supporting getkeycode and setting keybit are more
> problematic.
>
> If someone has already brought this issue up I apologize, but I couldn't
> find any discussion on the linux-input list relating to macros (at least
> other than preprocessor macros).
>
> Any suggestions?
>
I consider macro handling to be userspace task. If needed, macro
sequences can be injected back into the kernel via uinput devices to be
consumed by regualar applications.
--
Dmitry
next prev parent reply other threads:[~2010-04-14 22:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 18:19 Handling macros with input devices Rick L. Vinyard, Jr.
2010-04-14 19:08 ` Rick L. Vinyard, Jr.
2010-04-14 22:56 ` Dmitry Torokhov [this message]
2010-04-15 15:20 ` Rick L. Vinyard, Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100414225608.GB12143@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=liux-input@vger.kernel.org \
--cc=rvinyard@cs.nmsu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.