X Accessibility : AccessX

Developed by Dan Linder

Email AccessX

Disability Resources and Educational Services (DRES)

University of Illinois at Urbana/Champaign


Using Mouse Buttons 4 and 5 As MouseKeys

The following is courtesy of Dan Wright, who wanted to use Mouse Buttons 4 and 5 under AccessX:

By the way, I fixed the problem with not having mouse buttons 4 & 5 work as
mousekeys.  It turns out that the file /usr/X11R6/lib/X11/xkb/compat/mousekeys
contains all the KeySym -> X event mappings for accessx, and even though the
keysyms for mouse buttons 4 & 5 are defined elsewhere, there are no
translations for them.  Adding 2 blocks like so

interpret Pointer_Button4 {
  action= PointerButton(button=4);
interpret Pointer_Button5 {
  action= PointerButton(button=5);

to the above file fixed the problem.  Yay for X!

Important Note:

As of version 4.0.2, XFree86 has fixed most of the following problems via a much more elegant patch, so this information is provided for archival purposes only. Many thanks to the XFree86 team for fixing these problems!

"Quick Fix" For XFree86:

The following changes are summarized in this file: xf86xkbfix.tar.gz.

XFree86, even as late as version 4.0.1, has certain keyboard handling problems relating to the PC keyboard's hardware autorepeat. The behavior is most noticable when using the MouseKeys feature of AccessX. When holding down a direction key, the mouse pointer will accelerate for a short time, and will then stop accelerating, jerking along quite slowly. The underlying cause of this problem is the PC keyboard's hardware autorepeat. The mouse pointer accelerates so long as the X Server is not getting additional KeyPress events. Once the hardware autorepeat starts, multiple KeyPress events are generated, and XKEYBOARD must begin the acceleration process all over again with each KeyPress event received. In pre-4.0.1 versions of XFree86, similar problems could be seen in other keyboard-related features, such as the total disfunction of per-key repeat settings in XKEYBOARD.

The XFree86 Group claimed with version 4.0.1 that these problems had been fixed, and indeed some had. However, MouseKeys still exhibits the same old accelerate-then-jerk-along behavior. I have implemented a fix at the source level, within XKEYBOARD. Many would have problems with us tampering with XKEYBOARD, as it is cross-platform code. However, the mere eight or so lines of code that need to be inserted, as well as the fact that the bug is a bug in the interaction between XKEYBOARD and the PC hardware, lead me to conclude that this is the proper fix.

The basic idea behind my fix is to force the PC hardware to behave more like other workstations in terms of keyboard autorepeat. There are two components to my fix. The first is to compile the XKEYBOARD extension with software autorepeat enabled, ie, "#DEFINE XKB_ALWAYS_USES_SOFT_REPEAT". The second is a small bit of glue code to throw away subsequent same keypress events unless an intervening KeyRelease is received. This code should be inserted as follows into "xc/programs/Xserver/xkb/xkbAccessX.c":

Add a global variable:

KeyCode oldKey;

And in AccessXFilterPressEvent():

     * DWL 07/11/2000
     * Attempt to filter out extraneous keypress events to make AccessX
     * and other XKB features work in XF86.

    if(key == oldKey) {
      ignoreKeyEvent = TRUE;
    oldKey = key;

    /* END DWL 07/11/2000 */

And in AccessXFilterReleaseEvent():

   oldKey = 0;   /* Reset keypress if a key is released */

For More Information:

Email questions or comments to: accessx@rehab.uiuc.edu