Attachment 33378 Details for Bug 26584 – Simplify keycode to keysym mapping

[patch] Simplify keycode to keysym mapping

0003-aiptek-Simplify-keycode-to-keysym-mapping.patch (text/plain), 5.22 KB, created by Olivier Samyn on 2010-02-17 15:24:47 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Olivier Samyn

Created: 2010-02-17 15:24:47 UTC

Size: 5.22 KB

patch

obsolete

>From f6407d008f72c0d17e7f983b0ecbdaa6437337f2 Mon Sep 17 00:00:00 2001
>From: Olivier Samyn <code@oleastre.be>
>Date: Thu, 18 Feb 2010 00:17:07 +0100
>Subject: [PATCH 3/3] aiptek: Simplify keycode to keysym mapping.
>
>Build a specific keysym map based on kernel keycode and xorg keysyms.
>Avoid a loop on the kernel codes to find the correct index.
>
>Signed-off-by: Olivier Samyn <code@oleastre.be>
>---
> src/xf86Aiptek.c |   78 ++++++++++++++----------------------------------------
> 1 files changed, 20 insertions(+), 58 deletions(-)
>
>diff --git a/src/xf86Aiptek.c b/src/xf86Aiptek.c
>index 4ae5f3f..517d9df 100644
>--- a/src/xf86Aiptek.c
>+++ b/src/xf86Aiptek.c
>@@ -150,14 +150,8 @@ _X_EXPORT InputDriverRec AIPTEK =
> #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 7
> /*
>  * This is the map of Linux Event Input system keystrokes sent for
>- * the macro keys. There are discrepancies in the mappings, so for example,
>- * if we wanted to implement full macro key-to-string conversion in the
>- * Linux driver, we'd have to accept 1-to-many keyboard events, several of
>- * whom would not have the same encoding. For this reason, we're biting
>- * the bullet now & implementing a simple lookup/translation scheme.
>- * A simple 'KEY_F1 = XK_F1' layout wouldn't work, because X wants an
>- * offset into the KeySym array above, and it'll look up that this means 
>- * XK_whatever...
>+ * the macro keys. Because X wants an offset in the KeySym array, 
>+ * we construct a KeySym map so that map[KEY_*+8] = XK_*
>  */
> 
> static int linux_inputDevice_keyMap[] =
>@@ -169,30 +163,23 @@ static int linux_inputDevice_keyMap[] =
>     KEY_OPEN, KEY_PASTE
> };
> 
>-/*
>- * Function/Macro keys variables.
>- *
>- * This is a list of X keystrokes the macro keys can send.
>- */
>-static KeySym aiptek_map[] =
>+static int linux_inputDevice_keyMap_len = 32; 
>+
>+static KeySym xorg_aiptek_keyMap[] =
> {
>-    /* 0x00 .. 0x07 */
>-    NoSymbol,NoSymbol,NoSymbol,NoSymbol,NoSymbol,NoSymbol,NoSymbol,NoSymbol,
>-    /* 0x08 .. 0x0f */
>     XK_F1,  XK_F2,  XK_F3,  XK_F4,  XK_F5,  XK_F6,  XK_F7,  XK_F8,
>-    /* 0x10 .. 0x17 */
>     XK_F9,  XK_F10, XK_F11, XK_F12, XK_F13, XK_F14, XK_F15, XK_F16,
>-    /* 0x18 .. 0x1f */
>     XK_F17, XK_F18, XK_F19, XK_F20, XK_F21, XK_F22, XK_F23, XK_F24,
>-    /* 0x20 .. 0x27 */
>     XK_F25, XK_F26, XK_F27, XK_F28, XK_F29, XK_F30, XK_F31, XK_F32
> };
> 
>+static KeySym aiptek_keysyms_map[256] = {0};
>+
> /* minKeyCode = 8 because this is the min legal key code */
> static KeySymsRec keysyms =
> {
>-  /* map        minKeyCode  maxKC   width */
>-  aiptek_map,   8,          0x27,   1
>+  /* map                minKeyCode  maxKC   width */
>+  aiptek_keysyms_map,   8,          0xff,   1
> };
> #endif
> 
>@@ -435,44 +422,12 @@ xf86AiptekSendEvents(LocalDevicePtr local, int r_z)
>      */
>     if (common->currentValues.macroKey != VALUE_NA)
>     {
>-        int i = common->currentValues.macroKey;
>-
>-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 7
>-        /* This is a little silly, but: The Linux Event Input
>-         * system uses a slightly different keymap than does X 
>-         * (it also has more keys defined). So, we have to go
>-         * through a translation process. It's made sillier than
>-         * required because X wants an offset to it's KeySym table,
>-         * rather than an event key -- it'll do it's own lookup.
>-         * It DOES support arbitrary ordering of key events, and
>-         * partial keyboard matrices, so that speaks in favor of this
>-         * scheme.
>-         */
>-        for (i = 0; 
>-             i < sizeof(linux_inputDevice_keyMap)/
>-                 sizeof(linux_inputDevice_keyMap[0]);
>-             ++i)
>-        {
>-            if (linux_inputDevice_keyMap[0]==common->currentValues.macroKey)
>-            {
>-                break;
>-            }
>-        }
>-#endif
>-        /* First available Keycode begins at 8 => macro+7.
>-         * It's pervasive throughout the Xinput drivers, and
>-         * no, I don't know why they purposively waste the first 8
>-         * positions of the KeySym map...
>-         */
>-
>+        int keycode = common->currentValues.macroKey+8;
>+        
>         /* Keyboard 'make' (press) event */
>-        xf86PostKeyEvent(local->dev, i+8, TRUE,
>-                         bAbsolute, 0, 5,
>-                         x, y, common->currentValues.button, xTilt, yTilt);
>+        xf86PostKeyboardEvent(local->dev, keycode, TRUE);
>         /* Keyboard 'break' (depress) event */
>-        xf86PostKeyEvent(local->dev, i+8, FALSE,
>-                         bAbsolute, 0, 5,
>-                         x, y, common->currentValues.button, xTilt, yTilt);
>+        xf86PostKeyboardEvent(local->dev, keycode, FALSE);
>     }
> 
>     /* As the coordinates are ready, we can send events to X */
>@@ -1644,6 +1599,13 @@ xf86AiptekProc(DeviceIntPtr pAiptek, int requestCode)
>             }
> 
> #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 7
>+            /* Fill in aiptek_keysyms_map at indices given by linux key codes. */
>+            for (loop = 0; loop < linux_inputDevice_keyMap_len; ++loop)
>+            {
>+                aiptek_keysyms_map[linux_inputDevice_keyMap[loop]+8] = 
>+                    xorg_aiptek_keyMap[loop];
>+            }
>+            
>             if (InitKeyClassDeviceStruct(pAiptek, &keysyms, NULL) ==FALSE)
>             {
>                 ErrorF("Unable to init Key Class Device\n");
>-- 
>1.6.3.3
>

Actions: View | Splinter Review

Attachments on bug 26584: 33325 | 33338 | 33376 | 33377 | 33378 | 33465 | 33466 | 33514 | 33515 | 33516

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.