Comment 3 for bug 35080

Discussion on #ubuntu-devel with sladen, Mithrandir and henrik, no real conclusion.

  The actual bug is with the ThinkPad designs who never expected anyone to use 'Shift-NumLock' so didn't design around it. (Note, the new LenovoPads use Fn-ScrLck instead of Shift-ScrLck).

  Shift+NumLock is an accessibility feature, it's also for when you don't have a mouse, so shouldn't need a mouse to activate it.

  Off-topic, the gnome-menu can't be opened with Ctrl-Escape of the 'Logo' key---which would allow the following to be reached:

  System->Settings->Keyboard->Accessibility->Mouse can be used to toggle the current MouseKeys state.

Options:

  Remove the X policy decision of mapping Shift-NumLock by default to an action. (eg. allow it only to be enabled through the GUI menu, with NumLock five-times-in-row, or via ticking a box "[x] Make Shift-NumLock activate Mousekeys".

  Remap '77' to something completely different on ThinkPads in 'hotkey-setup' and then unremap it again with a new entry in the X keymap. (Note, any solution like this breaks Shift-NumLock on an external [eg. USB] keyboard anyway).

  If keymaps could be placed on only 'atkbd' input device then remapping/fiddling would only set the internal ThinkPad keyboard. This could do some fiddling like eat the key-stroke then send: shift-up, numlock down, numlock up, shift-down.

Simplest:

  Remove 'Pointer_EnableKeys' in all cases and see if anyone actually complains.

  Detect if it's a ThinkPad in 'xserver-xorg' postinst and add/remove an extra:
      -option "mousekeys:shiftnumlock"