#25 keytouch doesn't work with xorg 7.4

open-accepted
nobody
None
7
2009-04-30
2009-02-14
Anonymous
No

With the upgrade to xorg 7.4, keytouchd doesn't recognize any keypresses anymore. Tried to create a new keyboard definition with keytouch-editor, which worked, but still no response from keytouchd.
Problem is also mentioned here: http://bbs.archlinux.org/viewtopic.php?id=59922&p=1

Discussion

  • Marvin Raaijmakers

    What if you run keytouchd from the command line (after killing the running keytouchd)? Does it give some errors? Please also try to run xev and press the keys. Are events generated?

     
  • Nobody/Anonymous

    No visible error from keytouchd..

    Here's some output from xev (events are generated as usual):
    KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x9a, subw 0x0, time 34223129, (158,-562), root:(1154,229),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

    Weird thing is that keytouch-editor still works as expected.

    Another weird thing: I tried to add the 'a' key to a keyboard definition, and as soon as I started keytouchd, the 'a' key stopped working. It didn't even trigger the keytouch event. After I quit keytouchd, the key still wouldn't work. In fact, all the 'a's in this post are copied and pasted from somewhere else... I'll have to restrt my X server, I think.

     
  • Simon Walter

    Simon Walter - 2009-04-25

    keytouchd gives are warning on startup:
    Warning: Not all keys can be grabbed by this program. This
    can be caused by another program which is already
    grabbing these keys.

    xev reports the keys.

    I'm using xfce4 and can configure the volumn keys of my dell latitude with xfce4-keyboard-settings, so the key events probably get caught by X/the window managers now and never reach keytouch.

     
  • Marvin Raaijmakers

    It seems that the problem is that the evdev X keyboard driver is used instead of the traditional xkb driver. As a result keytouchd has to do a different translation from kernel keycodes to X keycodes.
    At the moment I know how the translation for the evdev driver should be done. However the problem is to detect which of the two drivers is used by the X server.

     
  • Marvin Raaijmakers

    • priority: 5 --> 7
    • status: open --> open-accepted
     
  • Nobody/Anonymous

    Same problem here since upgrading xorg which now uses the evdev module.
    Pressing "Favorites" (keycode 156 BOOKMARKS, scancode 230, X keycode 164) results in stopping amarok which should be assigned to the stop button (keycode 166 STOPCD, scancode 164, X keycode 174).
    And pressing "Shopping" (keycode 221 SHOP, scancode 148, X keycode 229) executes the action of "Search" (keycode 217 SEARCH, scancode 229 , X keycode 225).

    Keytouch seems to mess up scancode and X keycode.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks