Bug 31300 - Add XF86XK_TouchpadOn/Off
Summary: Add XF86XK_TouchpadOn/Off
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Protocol/Core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 31333
  Show dependency treegraph
 
Reported: 2010-11-01 11:23 UTC by Bastien Nocera
Modified: 2010-11-17 20:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Add XF86XK_TouchpadOn/Off (1.13 KB, patch)
2010-11-01 11:23 UTC, Bastien Nocera
no flags Details | Splinter Review
kernel: Add touchpad on/off (1.25 KB, patch)
2010-11-01 12:09 UTC, Bastien Nocera
no flags Details | Splinter Review

Description Bastien Nocera 2010-11-01 11:23:23 UTC
Those keysyms will be used to report events from the hardware.

Hardware like the HP laptops emit 2 separate keycodes when the touchpad is enabled or disabled. So we can catch those in user-space and display a popup.
Comment 1 Bastien Nocera 2010-11-01 11:23:51 UTC
Created attachment 39964 [details] [review]
Add XF86XK_TouchpadOn/Off

Those keysyms will be used to report events from the hardware. Hardware
like the HP laptops emit 2 separate keycodes when the touchpad is enabled
or disabled. So we can catch those in user-space and display a popup.
Comment 2 Bastien Nocera 2010-11-01 12:09:28 UTC
Created attachment 39965 [details] [review]
kernel: Add touchpad on/off

For completeness sake (and so that it doesn't get lost), this is the kernel patch we'd use if X.org could handle > 255-8 keycodes.

Still TODO (for short-term):
- Fix udev to use F21, F22, F23 keys consistently (touchpad toggle, on, off for example)
- Fix evdev keymap to map linux' F2X keys to the newly added keysyms
Comment 3 Julien Cristau 2010-11-01 13:20:21 UTC
> --- Comment #1 from Bastien Nocera <hadess@hadess.net> 2010-11-01 11:23:51 PDT ---
> Add XF86XK_TouchpadOn/Off
> 
Shouldn't that be XK_TouchpadOn/Off?  Or is there a reason to add it to
the XFree86 vendor-specific group?
Comment 4 Bastien Nocera 2010-11-01 14:01:59 UTC
The include is called XF86KeySym, and all the keys are XF86 prefixed. We should probably hide them in display though.
Comment 5 Julien Cristau 2010-11-01 15:32:07 UTC
> --- Comment #4 from Bastien Nocera <hadess@hadess.net> 2010-11-01 14:01:59 PDT ---
> The include is called XF86KeySym, and all the keys are XF86 prefixed. We should
> probably hide them in display though.
> 
Not the ones in <X11/keysymdef.h>
Comment 6 Bastien Nocera 2010-11-01 16:16:10 UTC
(In reply to comment #5)
> > --- Comment #4 from Bastien Nocera <hadess@hadess.net> 2010-11-01 14:01:59 PDT ---
> > The include is called XF86KeySym, and all the keys are XF86 prefixed. We should
> > probably hide them in display though.
> > 
> Not the ones in <X11/keysymdef.h>

And I'm not adding anything there.

The ones in XF86KeySym.h are the addition past the original set of keys used by all vendors of X11 implementations.

FWIW, this isn't my first addition to the list of keysyms. See also https://bugs.freedesktop.org/show_bug.cgi?id=16519
Comment 7 James Cloos 2010-11-01 16:46:55 UTC
> Shouldn't that be XK_TouchpadOn/Off?
> Or is there a reason to add it to the XFree86 vendor-specific group?

The consensus a while back was to leave the XF86 prefix to XFree86.

The only reason to add thses keys their, per that consensus, would be
if XFree86 first added them to their own dist.
Comment 9 Peter Hutterer 2010-11-17 20:46:14 UTC
commit 5d3428de974d15357b0ad407f4c5222cfaa8f9f3
Author: Bastien Nocera <hadess@hadess.net>
Date:   Mon Nov 8 15:24:55 2010 +1000

    Add XF86XK_TouchpadOn/Off


Peter Hutterer:
"Tricky situation, mostly my fault. I added XF86XK_TouchpadToggle a year or
so ago to the XF86keysym database. That probably shouldn't have happened,
but given it's already in, adding those two here instead of keysymdef.h
seems to be the better thing to do."
http://lists.freedesktop.org/archives/xorg-devel/2010-November/015035.html


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.