lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 25 Mar 2011 11:17:24 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Corentin Chary <corentin.chary@...il.com>
Cc:	Chris Bagwell <chris@...bagwell.com>,
	Matthew Garrett <mjg@...hat.com>,
	acpi4asus-user@...ts.sourceforge.net,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH 2/2] eeepc-wmi: Add support for T101MT Home/Express Gate
 key

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ