Re: [PATCH 2/2] eeepc-wmi: Add support for T101MT Home/Express Gatekey

[Seth Forshee]

On Fri, Mar 25, 2011 at 03:43:11PM +0000, Corentin Chary wrote:
> > Here is how I envision using these keys. ÂI wanted to map quick press
> > to GNOME3/KDE4/Unity's Activities menu and map press-and-hold to
> > script that rotates screen. ÂI like the repeating of rotates but I
> > didn't really want a rotate to also force a pop up of the activities
> > menu.
> 
> Makes sense.
> 
> >>
> >>> And back to the question of KEY_HOME -- that's not really what you want,
> >>> is it? As in "move cursor to start of line"?
> >>
> >> Ho .. right, that's what mean KEY_HOME :/. So no, I don't want that...
> >> What about:
> >> - KEY_CYCLEWINDOWS
> >> - KEY_COMPUTER
> >> - KEY_HOMEPAGE
> >> - KEY_DASHBOARD
> >>
> >> I think KEY_HOMEPAGE is the best choice.
> >
> > I've only had limited time to look more. ÂSo far, I found under udev a
> > toshiba tablet that maps what is probably a rotate button to
> > KEY_DIRECTION so thats one option for it instead of KEY_PROG2. ÂI
> > couldn't find anybody using that though.
> >
> > I see in /usr/share/X11/symbols/inet:
> >
> >  Âkey <I162>  {   Â[ XF86RotateWindows   ]    };
> >
> > and in /usr/share/X11/xkb/symbols/evdev:
> >
> > xkb/keycodes/evdev: Â Â <I162> = 162; Â // #define KEY_CYCLEWINDOWS Â Â Â Â154
> >
> > Looks like KEY_CYCLEWINDOWS is already hooked up to
> > gnome-settings-daemon to auto-rotate screen?
> 
> XF86RotateWindows is probably more "alt-tab" than "rotate screen".

Gnome at least seems to handle it by doing a screen rotation.

> > I ran into total dead end for finding a pre-existing example of home
> > button usage. ÂI'm really surprised we do not yet have a KEY_LAUNCHER
> > or similar because so many tablet PCs/smartphones/pads do have a
> > button with this specific concept of "bring up your icon based
> > application launcher".
> 
> KEY_LAUNCHER sounds like "Alt-F2" (that means krunner on KDE).
> The advantage over KEY_HOMEPAGE is that it would work even when a
> browser have the focus.
> 
> > - KEY_MENU
> > - KEY_EXIT (smartphones sometime mean this)
> > - KEY_PROG3 (basically all that Windows is doing)
> > - KEY_LAUNCHER (why not be the first to finally create it!)
> >
> > I vote for either KEY_PROG3 or KEY_HOMEPAGE for at least short term.
> 
> So now, I vote (in order):
> - KEY_LAUNCHER
> - KEY_DASHBOARD
> - KEY_PROG3
> 
> With this behavior (I'll use KEY_LAUCHER and KEY_PROG2)
> 
> - On press, do nothing
> - On release, emit KEY_LAUNCHER if KEY_PROG2 wasn't emited
> - On press, emit only one  KEY_PROG2 (I'd like to emit repeated

Do you mean on hold?

> KEY_PROG2, but I understand that it makes things harder for
> userspace).

I have a keyboard that emit repeated press events for hotkeys, so I
think userspace can handle this. It just waits for the release before
doing anything, so as long as it's multiple press events and a single
release I think we're okay.

Since it seems KEY_CYCLEWINDOWS might actually accomplish what a hold is
intended to do, I think I'll proceed with the following slightly amended
version of your plan.

 - On press, do nothing
 - On hold, emit KEY_CYCLEWINDOWS repeatedly
 - On release, emit KEY_LAUNCHER w/ autorelease if KEY_CYCLEWINDOWS
   wasn't released, else emit KEY_CYCLEWINDOWS release

Assuming of course that Dmitry agrees that adding KEY_LAUNCHER makes
sense.

Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/