On the Logitech G13 there are a set of 10 special keys at the top of the
device.
I've written the driver so that it maintains a map from the general keys
(G1-G22) to Linux' input subsystem keys.
The map can be changed on the fly, allowing multiple keymaps to be loaded.
As a side note I haven't provided for this functionality (multiple
keymaps) in the driver since this can be maintained from userspace, but it
does need to know about the currently loaded keymap so that when the raw
HID events are parsed the appropriate EV_KEY events can be input.
I could set it up so that the special keys also map to a KEY_* code.
However, I'd prefer to set things up so that any G1-G22 key can be mapped
to any input subsystem KEY_* code and not reserve a set of 10 from the
current KEY_* codes for the 10 special keys.
One way I was thinking of approaching this was to generate EV_MSC type
events (with a MSC_RAW code) using the value to indicate the state
(pressed/released) and special key.
Another way to approach this would be to extend the KEY_* #defines with a
special set of 10 codes for the 10 special keys.
Any suggestions on the better approach?
Thanks,
Rick
Adding linux-input.
On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
<[email protected]> wrote:
> On the Logitech G13 there are a set of 10 special keys at the top of the
> device.
>
> I've written the driver so that it maintains a map from the general keys
> (G1-G22) to Linux' input subsystem keys.
>
> The map can be changed on the fly, allowing multiple keymaps to be loaded.
>
> As a side note I haven't provided for this functionality (multiple
> keymaps) in the driver since this can be maintained from userspace, but it
> does need to know about the currently loaded keymap so that when the raw
> HID events are parsed the appropriate EV_KEY events can be input.
>
> I could set it up so that the special keys also map to a KEY_* code.
> However, I'd prefer to set things up so that any G1-G22 key can be mapped
> to any input subsystem KEY_* code and not reserve a set of 10 from the
> current KEY_* codes for the 10 special keys.
>
> One way I was thinking of approaching this was to generate EV_MSC type
> events (with a MSC_RAW code) using the value to indicate the state
> (pressed/released) and special key.
>
> Another way to approach this would be to extend the KEY_* #defines with a
> special set of 10 codes for the 10 special keys.
>
> Any suggestions on the better approach?
>
> Thanks,
>
> Rick
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
On Tue, Sep 15, 2009 at 10:41:30PM +0530, Trilok Soni wrote:
> Adding linux-input.
>
> On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
> <[email protected]> wrote:
> > On the Logitech G13 there are a set of 10 special keys at the top of the
> > device.
> >
> > I've written the driver so that it maintains a map from the general keys
> > (G1-G22) to Linux' input subsystem keys.
> >
> > The map can be changed on the fly, allowing multiple keymaps to be loaded.
> >
> > As a side note I haven't provided for this functionality (multiple
> > keymaps) in the driver since this can be maintained from userspace, but it
> > does need to know about the currently loaded keymap so that when the raw
> > HID events are parsed the appropriate EV_KEY events can be input.
> >
> > I could set it up so that the special keys also map to a KEY_* code.
> > However, I'd prefer to set things up so that any G1-G22 key can be mapped
> > to any input subsystem KEY_* code and not reserve a set of 10 from the
> > current KEY_* codes for the 10 special keys.
> >
> > One way I was thinking of approaching this was to generate EV_MSC type
> > events (with a MSC_RAW code) using the value to indicate the state
> > (pressed/released) and special key.
Doesn't HID already generate EV_MSC/MSC_SCAN for exactly this purpose
so userspace knows what keys can be remapped? You may initially map all
keys you don't know the usage to KEY_UNKNOWN.
> >
> > Another way to approach this would be to extend the KEY_* #defines with a
> > special set of 10 codes for the 10 special keys.
> >
No, please don't do this.
--
Dmitry
Dmitry Torokhov wrote:
> On Tue, Sep 15, 2009 at 10:41:30PM +0530, Trilok Soni wrote:
>> Adding linux-input.
>>
>> On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
>> <[email protected]> wrote:
>> > On the Logitech G13 there are a set of 10 special keys at the top of
>> the
>> > device.
>> >
>> > I've written the driver so that it maintains a map from the general
>> keys
>> > (G1-G22) to Linux' input subsystem keys.
>> >
>> > The map can be changed on the fly, allowing multiple keymaps to be
>> loaded.
>> >
>> > As a side note I haven't provided for this functionality (multiple
>> > keymaps) in the driver since this can be maintained from userspace,
>> but it
>> > does need to know about the currently loaded keymap so that when the
>> raw
>> > HID events are parsed the appropriate EV_KEY events can be input.
>> >
>> > I could set it up so that the special keys also map to a KEY_* code.
>> > However, I'd prefer to set things up so that any G1-G22 key can be
>> mapped
>> > to any input subsystem KEY_* code and not reserve a set of 10 from the
>> > current KEY_* codes for the 10 special keys.
>> >
>> > One way I was thinking of approaching this was to generate EV_MSC type
>> > events (with a MSC_RAW code) using the value to indicate the state
>> > (pressed/released) and special key.
>
> Doesn't HID already generate EV_MSC/MSC_SCAN for exactly this purpose
> so userspace knows what keys can be remapped? You may initially map all
> keys you don't know the usage to KEY_UNKNOWN.
As I understand it the EV_MSC/MSC_SCAN is used to trigger a prompting of
the user to map a key, which would be useful for the G1-G22 keys and
perhaps 5 of the 10 special keys. But, that's not the behavior I want for
the M1, M2, M3, MR and backlight keys.
Somehow they need to be distinct from any existing KEY_* codes or not have
a code at all... i.e. only emitting the raw misc events.
Perhaps the BTN_MISC codes are better suited for these keys?
On Tue, 15 Sep 2009, Rick L. Vinyard, Jr. wrote:
> As I understand it the EV_MSC/MSC_SCAN is used to trigger a prompting of
> the user to map a key, which would be useful for the G1-G22 keys and
> perhaps 5 of the 10 special keys. But, that's not the behavior I want for
> the M1, M2, M3, MR and backlight keys.
Why?
> Somehow they need to be distinct from any existing KEY_* codes or not have
> a code at all... i.e. only emitting the raw misc events.
Use KEY_RESERVED for them and in your driver, special case it to not output
EV_KEY events for KEY_RESERVED, but still output the EV_MSC/MSC_SCAN.
This allows userspace to reprogram them to normal keys (or even to
KEY_UNKNOWN) if it wants.
> Perhaps the BTN_MISC codes are better suited for these keys?
That could work too, but are these generic buttons?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Tue, Sep 15, 2009 at 01:05:57PM -0600, Rick L. Vinyard, Jr. wrote:
> Dmitry Torokhov wrote:
> > On Tue, Sep 15, 2009 at 10:41:30PM +0530, Trilok Soni wrote:
> >> Adding linux-input.
> >>
> >> On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
> >> <[email protected]> wrote:
> >> > On the Logitech G13 there are a set of 10 special keys at the top of
> >> the
> >> > device.
> >> >
> >> > I've written the driver so that it maintains a map from the general
> >> keys
> >> > (G1-G22) to Linux' input subsystem keys.
> >> >
> >> > The map can be changed on the fly, allowing multiple keymaps to be
> >> loaded.
> >> >
> >> > As a side note I haven't provided for this functionality (multiple
> >> > keymaps) in the driver since this can be maintained from userspace,
> >> but it
> >> > does need to know about the currently loaded keymap so that when the
> >> raw
> >> > HID events are parsed the appropriate EV_KEY events can be input.
> >> >
> >> > I could set it up so that the special keys also map to a KEY_* code.
> >> > However, I'd prefer to set things up so that any G1-G22 key can be
> >> mapped
> >> > to any input subsystem KEY_* code and not reserve a set of 10 from the
> >> > current KEY_* codes for the 10 special keys.
> >> >
> >> > One way I was thinking of approaching this was to generate EV_MSC type
> >> > events (with a MSC_RAW code) using the value to indicate the state
> >> > (pressed/released) and special key.
> >
> > Doesn't HID already generate EV_MSC/MSC_SCAN for exactly this purpose
> > so userspace knows what keys can be remapped? You may initially map all
> > keys you don't know the usage to KEY_UNKNOWN.
>
> As I understand it the EV_MSC/MSC_SCAN is used to trigger a prompting of
> the user to map a key, which would be useful for the G1-G22 keys and
> perhaps 5 of the 10 special keys. But, that's not the behavior I want for
> the M1, M2, M3, MR and backlight keys.
>
> Somehow they need to be distinct from any existing KEY_* codes or not have
> a code at all... i.e. only emitting the raw misc events.
>
> Perhaps the BTN_MISC codes are better suited for these keys?
>
I am sorry, I don't follow... why would yo not want to assign a standard
code to the M* keys?
--
Dmitry
Dmitry Torokhov wrote:
> On Tue, Sep 15, 2009 at 01:05:57PM -0600, Rick L. Vinyard, Jr. wrote:
>> Dmitry Torokhov wrote:
>> > On Tue, Sep 15, 2009 at 10:41:30PM +0530, Trilok Soni wrote:
>> >> Adding linux-input.
>> >>
>> >> On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
>> >> <[email protected]> wrote:
>> >> > On the Logitech G13 there are a set of 10 special keys at the top
>> of
>> >> the
>> >> > device.
>> >> >
>> >> > I've written the driver so that it maintains a map from the general
>> >> keys
>> >> > (G1-G22) to Linux' input subsystem keys.
>> >> >
>> >> > The map can be changed on the fly, allowing multiple keymaps to be
>> >> loaded.
>> >> >
>> >> > As a side note I haven't provided for this functionality (multiple
>> >> > keymaps) in the driver since this can be maintained from userspace,
>> >> but it
>> >> > does need to know about the currently loaded keymap so that when
>> the
>> >> raw
>> >> > HID events are parsed the appropriate EV_KEY events can be input.
>> >> >
>> >> > I could set it up so that the special keys also map to a KEY_*
>> code.
>> >> > However, I'd prefer to set things up so that any G1-G22 key can be
>> >> mapped
>> >> > to any input subsystem KEY_* code and not reserve a set of 10 from
>> the
>> >> > current KEY_* codes for the 10 special keys.
>> >> >
>> >> > One way I was thinking of approaching this was to generate EV_MSC
>> type
>> >> > events (with a MSC_RAW code) using the value to indicate the state
>> >> > (pressed/released) and special key.
>> >
>> > Doesn't HID already generate EV_MSC/MSC_SCAN for exactly this purpose
>> > so userspace knows what keys can be remapped? You may initially map
>> all
>> > keys you don't know the usage to KEY_UNKNOWN.
>>
>> As I understand it the EV_MSC/MSC_SCAN is used to trigger a prompting of
>> the user to map a key, which would be useful for the G1-G22 keys and
>> perhaps 5 of the 10 special keys. But, that's not the behavior I want
>> for
>> the M1, M2, M3, MR and backlight keys.
>>
>> Somehow they need to be distinct from any existing KEY_* codes or not
>> have
>> a code at all... i.e. only emitting the raw misc events.
>>
>> Perhaps the BTN_MISC codes are better suited for these keys?
>>
>
> I am sorry, I don't follow... why would yo not want to assign a standard
> code to the M* keys?
>
> --
> Dmitry
The M* keys are intended to provide a quick way to switch between key
mappings, with each mode having their own user-defined mappings.
So, if it is intended for the user to potentially program any of the G*
keys to anything within the set of existing keys (KEY_*, BTN_*) then the
M* keys need something outside that set to signal their events.
That's why I was thinking that EV_MSC/MSC_RAW could encode both the key
and the state (Pressed/Released) outside the set of existing keys.
---
Rick
Henrique de Moraes Holschuh wrote:
> On Tue, 15 Sep 2009, Rick L. Vinyard, Jr. wrote:
>> As I understand it the EV_MSC/MSC_SCAN is used to trigger a prompting of
>> the user to map a key, which would be useful for the G1-G22 keys and
>> perhaps 5 of the 10 special keys. But, that's not the behavior I want
>> for
>> the M1, M2, M3, MR and backlight keys.
>
> Why?
>
>> Somehow they need to be distinct from any existing KEY_* codes or not
>> have
>> a code at all... i.e. only emitting the raw misc events.
>
> Use KEY_RESERVED for them and in your driver, special case it to not
> output
> EV_KEY events for KEY_RESERVED, but still output the EV_MSC/MSC_SCAN.
That's how I ended up writing it.
> This allows userspace to reprogram them to normal keys (or even to
> KEY_UNKNOWN) if it wants.
>
>> Perhaps the BTN_MISC codes are better suited for these keys?
>
> That could work too, but are these generic buttons?
Yes. There is a bank of 6 buttons across the top (just beneath the LCD
display). Their purpose is application specific, but their physical
location provides an opportunity for UI's to use them in correlation with
the displayed LCD image... i.e. as an option selector, mode changer, etc.
The four M* keys are just beneath the bank of buttons.
---
Rick
On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
> The M* keys are intended to provide a quick way to switch between key
> mappings, with each mode having their own user-defined mappings.
What I'd do in this case would be this:
1. Initially have the M* level-shift keys assigned KEY_RESERVED
2. Have a big enough keymap to map all keys in all M*-level shift states
possible.
Eg:
START OF KEYMAP
M* keys
1st set of G* keys
2nd set of G* keys
3rd set of G* keys...
...
last set of G* keys
END OF KEYMAP
3. Have the driver special-process M* level-shift keys *as long as they are
still set to KEY_RESERVED* to select which part of the keymap is used to
translate the other keys. Note that this likely means pressing a M* key
would be transparent to userspace in this case, i.e. no events would be
issued when a M* key is doing a level shift.
So, you'd be able to set all mappings you want in the driver, and the M*
keys would do what they're expected to do without any userland help at all,
but you'd still be able to program the M* keys to be normal keys if you
want.
Of course, this assumes you don't do chording on multiple M* keys to end up
with a huge number of keymaps :p
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
> > The M* keys are intended to provide a quick way to switch between key
> > mappings, with each mode having their own user-defined mappings.
>
> What I'd do in this case would be this:
>
> 1. Initially have the M* level-shift keys assigned KEY_RESERVED
>
> 2. Have a big enough keymap to map all keys in all M*-level shift states
> possible.
>
> Eg:
> START OF KEYMAP
> M* keys
> 1st set of G* keys
> 2nd set of G* keys
> 3rd set of G* keys...
> ...
> last set of G* keys
> END OF KEYMAP
>
> 3. Have the driver special-process M* level-shift keys *as long as they are
> still set to KEY_RESERVED* to select which part of the keymap is used to
> translate the other keys. Note that this likely means pressing a M* key
> would be transparent to userspace in this case, i.e. no events would be
> issued when a M* key is doing a level shift.
>
> So, you'd be able to set all mappings you want in the driver, and the M*
> keys would do what they're expected to do without any userland help at all,
> but you'd still be able to program the M* keys to be normal keys if you
> want.
>
> Of course, this assumes you don't do chording on multiple M* keys to end up
> with a huge number of keymaps :p
>
Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
for the M keys and have userspace daemon load alternate keymaps on the
fly in resaponse to KEY_PROGx. The device is just a set of completely
generic buttons... User will have to tell the kernel what to map them
to.
--
Dmitry
On Thu, 17 Sep 2009, Dmitry Torokhov wrote:
> On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
> > > The M* keys are intended to provide a quick way to switch between key
> > > mappings, with each mode having their own user-defined mappings.
> >
> > What I'd do in this case would be this:
> >
> > 1. Initially have the M* level-shift keys assigned KEY_RESERVED
> >
> > 2. Have a big enough keymap to map all keys in all M*-level shift states
> > possible.
> >
> > Eg:
> > START OF KEYMAP
> > M* keys
> > 1st set of G* keys
> > 2nd set of G* keys
> > 3rd set of G* keys...
> > ...
> > last set of G* keys
> > END OF KEYMAP
> >
> > 3. Have the driver special-process M* level-shift keys *as long as they are
> > still set to KEY_RESERVED* to select which part of the keymap is used to
> > translate the other keys. Note that this likely means pressing a M* key
> > would be transparent to userspace in this case, i.e. no events would be
> > issued when a M* key is doing a level shift.
> >
> > So, you'd be able to set all mappings you want in the driver, and the M*
> > keys would do what they're expected to do without any userland help at all,
> > but you'd still be able to program the M* keys to be normal keys if you
> > want.
> >
> > Of course, this assumes you don't do chording on multiple M* keys to end up
> > with a huge number of keymaps :p
>
> Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
> for the M keys and have userspace daemon load alternate keymaps on the
> fly in resaponse to KEY_PROGx. The device is just a set of completely
> generic buttons... User will have to tell the kernel what to map them
> to.
It would work, but it is a big trip through userspace. If quickly pressing
M#+G# is a common use pattern (and it will be, for gaming), i.e. you often
want to access quickly a function on one level then another on a different
level, asking userspace to upload a new keymap to switch levels at every M#
press is going to be way too racy.
If it is to be used like that, I'd advocate either doing the entire
map-switching thing in kernel space, or doing the entire mapping in
userspace. In the later case, you don't issue KEY_* in the kernel driver,
you just issue MSC_SCAN events, and the userspace driver should open the
input device in exclusive mode, do its magic, and use uinput to generate
translated events (KEY_*, and even BTN_*, etc).
I understand the current version allows for an all-userspace enhanced driver
if one sets the entire keymap to KEY_RESERVED, since it will issue MSC_SCAN
events for all keys (if it doesn't, I suggest doing so). That might indeed
be the best option if one doesn't want a more complex kernel driver. And
one could still use the device in degraded mode by not loading the userspace
driver, and uploading a regular keymap to it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Dmitry Torokhov wrote:
> On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh
> wrote:
>> On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
>> > The M* keys are intended to provide a quick way to switch between key
>> > mappings, with each mode having their own user-defined mappings.
>>
>> What I'd do in this case would be this:
>>
>> 1. Initially have the M* level-shift keys assigned KEY_RESERVED
>>
>> 2. Have a big enough keymap to map all keys in all M*-level shift states
>> possible.
>>
>> Eg:
>> START OF KEYMAP
>> M* keys
>> 1st set of G* keys
>> 2nd set of G* keys
>> 3rd set of G* keys...
>> ...
>> last set of G* keys
>> END OF KEYMAP
>>
>> 3. Have the driver special-process M* level-shift keys *as long as they
>> are
>> still set to KEY_RESERVED* to select which part of the keymap is used to
>> translate the other keys. Note that this likely means pressing a M* key
>> would be transparent to userspace in this case, i.e. no events would be
>> issued when a M* key is doing a level shift.
>>
>> So, you'd be able to set all mappings you want in the driver, and the M*
>> keys would do what they're expected to do without any userland help at
>> all,
>> but you'd still be able to program the M* keys to be normal keys if you
>> want.
>>
>> Of course, this assumes you don't do chording on multiple M* keys to end
>> up
>> with a huge number of keymaps :p
>>
>
> Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
> for the M keys and have userspace daemon load alternate keymaps on the
> fly in resaponse to KEY_PROGx. The device is just a set of completely
> generic buttons... User will have to tell the kernel what to map them
> to.
>
Emitting a keycode certainly does simplify things, but that will preclude
the user from programming the G-keys to KEY_PROG1..KEY_PROG4.
Are there any specific use cases where a user would want to program a
G-key to KEY_PROG1..KEY_PROG4?
---
Rick
Henrique de Moraes Holschuh wrote:
> On Thu, 17 Sep 2009, Dmitry Torokhov wrote:
>> On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh
>> wrote:
>> > On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
>> > > The M* keys are intended to provide a quick way to switch between
>> key
>> > > mappings, with each mode having their own user-defined mappings.
>> >
>> > What I'd do in this case would be this:
>> >
>> > 1. Initially have the M* level-shift keys assigned KEY_RESERVED
>> >
>> > 2. Have a big enough keymap to map all keys in all M*-level shift
>> states
>> > possible.
>> >
>> > Eg:
>> > START OF KEYMAP
>> > M* keys
>> > 1st set of G* keys
>> > 2nd set of G* keys
>> > 3rd set of G* keys...
>> > ...
>> > last set of G* keys
>> > END OF KEYMAP
>> >
>> > 3. Have the driver special-process M* level-shift keys *as long as
>> they are
>> > still set to KEY_RESERVED* to select which part of the keymap is used
>> to
>> > translate the other keys. Note that this likely means pressing a M*
>> key
>> > would be transparent to userspace in this case, i.e. no events would
>> be
>> > issued when a M* key is doing a level shift.
>> >
>> > So, you'd be able to set all mappings you want in the driver, and the
>> M*
>> > keys would do what they're expected to do without any userland help at
>> all,
>> > but you'd still be able to program the M* keys to be normal keys if
>> you
>> > want.
>> >
>> > Of course, this assumes you don't do chording on multiple M* keys to
>> end up
>> > with a huge number of keymaps :p
>>
>> Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
>> for the M keys and have userspace daemon load alternate keymaps on the
>> fly in resaponse to KEY_PROGx. The device is just a set of completely
>> generic buttons... User will have to tell the kernel what to map them
>> to.
>
> It would work, but it is a big trip through userspace. If quickly
> pressing
> M#+G# is a common use pattern (and it will be, for gaming), i.e. you often
> want to access quickly a function on one level then another on a different
> level, asking userspace to upload a new keymap to switch levels at every
> M#
> press is going to be way too racy.
>
> If it is to be used like that, I'd advocate either doing the entire
> map-switching thing in kernel space, or doing the entire mapping in
> userspace. In the later case, you don't issue KEY_* in the kernel driver,
> you just issue MSC_SCAN events, and the userspace driver should open the
> input device in exclusive mode, do its magic, and use uinput to generate
> translated events (KEY_*, and even BTN_*, etc).
>
> I understand the current version allows for an all-userspace enhanced
> driver
> if one sets the entire keymap to KEY_RESERVED, since it will issue
> MSC_SCAN
> events for all keys (if it doesn't, I suggest doing so).
It does.
> That might
> indeed
> be the best option if one doesn't want a more complex kernel driver. And
> one could still use the device in degraded mode by not loading the
> userspace
> driver, and uploading a regular keymap to it.
>
A keymap for three modes wouldn't be too bad space wise. I'd prefer to
keep the input events in kernel space.
I was trying to minimize the code in the driver, but I don't think it will
increase it by that much.
On Fri, Sep 18, 2009 at 09:40:23AM -0600, Rick L. Vinyard, Jr. wrote:
> Dmitry Torokhov wrote:
> > On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh
> > wrote:
> >> On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
> >> > The M* keys are intended to provide a quick way to switch between key
> >> > mappings, with each mode having their own user-defined mappings.
> >>
> >> What I'd do in this case would be this:
> >>
> >> 1. Initially have the M* level-shift keys assigned KEY_RESERVED
> >>
> >> 2. Have a big enough keymap to map all keys in all M*-level shift states
> >> possible.
> >>
> >> Eg:
> >> START OF KEYMAP
> >> M* keys
> >> 1st set of G* keys
> >> 2nd set of G* keys
> >> 3rd set of G* keys...
> >> ...
> >> last set of G* keys
> >> END OF KEYMAP
> >>
> >> 3. Have the driver special-process M* level-shift keys *as long as they
> >> are
> >> still set to KEY_RESERVED* to select which part of the keymap is used to
> >> translate the other keys. Note that this likely means pressing a M* key
> >> would be transparent to userspace in this case, i.e. no events would be
> >> issued when a M* key is doing a level shift.
> >>
> >> So, you'd be able to set all mappings you want in the driver, and the M*
> >> keys would do what they're expected to do without any userland help at
> >> all,
> >> but you'd still be able to program the M* keys to be normal keys if you
> >> want.
> >>
> >> Of course, this assumes you don't do chording on multiple M* keys to end
> >> up
> >> with a huge number of keymaps :p
> >>
> >
> > Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
> > for the M keys and have userspace daemon load alternate keymaps on the
> > fly in resaponse to KEY_PROGx. The device is just a set of completely
> > generic buttons... User will have to tell the kernel what to map them
> > to.
> >
>
> Emitting a keycode certainly does simplify things, but that will preclude
> the user from programming the G-keys to KEY_PROG1..KEY_PROG4.
>
> Are there any specific use cases where a user would want to program a
> G-key to KEY_PROG1..KEY_PROG4?
>
I an not sure, but if they want to use KEY_PROG* somewhere else they can
reprogram the M* keys to somethis other as well.
--
Dmitry
On Fri, Sep 18, 2009 at 10:56:01AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 17 Sep 2009, Dmitry Torokhov wrote:
> > On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote:
> > > > The M* keys are intended to provide a quick way to switch between key
> > > > mappings, with each mode having their own user-defined mappings.
> > >
> > > What I'd do in this case would be this:
> > >
> > > 1. Initially have the M* level-shift keys assigned KEY_RESERVED
> > >
> > > 2. Have a big enough keymap to map all keys in all M*-level shift states
> > > possible.
> > >
> > > Eg:
> > > START OF KEYMAP
> > > M* keys
> > > 1st set of G* keys
> > > 2nd set of G* keys
> > > 3rd set of G* keys...
> > > ...
> > > last set of G* keys
> > > END OF KEYMAP
> > >
> > > 3. Have the driver special-process M* level-shift keys *as long as they are
> > > still set to KEY_RESERVED* to select which part of the keymap is used to
> > > translate the other keys. Note that this likely means pressing a M* key
> > > would be transparent to userspace in this case, i.e. no events would be
> > > issued when a M* key is doing a level shift.
> > >
> > > So, you'd be able to set all mappings you want in the driver, and the M*
> > > keys would do what they're expected to do without any userland help at all,
> > > but you'd still be able to program the M* keys to be normal keys if you
> > > want.
> > >
> > > Of course, this assumes you don't do chording on multiple M* keys to end up
> > > with a huge number of keymaps :p
> >
> > Actually I think that the device should just emit KEY_PROG1..KEY_PROG4
> > for the M keys and have userspace daemon load alternate keymaps on the
> > fly in resaponse to KEY_PROGx. The device is just a set of completely
> > generic buttons... User will have to tell the kernel what to map them
> > to.
>
> It would work, but it is a big trip through userspace. If quickly pressing
> M#+G# is a common use pattern (and it will be, for gaming), i.e. you often
> want to access quickly a function on one level then another on a different
> level, asking userspace to upload a new keymap to switch levels at every M#
> press is going to be way too racy.
I'd say it should be pretty quick, compared to what a game needs to do
to render a single frame.
--
Dmitry