When setting mousekeys, xkbset reports "XKB not supported"

Bug #215496 reported by Sam Hart
16
Affects Status Importance Assigned to Milestone
Debian
Fix Released
Unknown
xkbset (Ubuntu)
Incomplete
Undecided
Unassigned
xorg-server (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: xkbset

In the current Hardy branch, a recent X.org upgrade seems to have somehow nuked XKB. Running xkbset to enable mousekeys results in the following errors:

$ xkbset m
XKB not supported for display :0.0
$ xkbset exp =m
XKB not supported for display :0.0

This was working just a week ago. Expected result is that mousekeys will be enabled.

Not 100% certain what is needed to help isolate this problem, and I'm pretty certain the problem is elsewhere outside of xkbset. But since this is where I see the problem, filing the bug here.

$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

# apt-cache policy xkbset
xkbset:
  Installed: 0.5-5.1
  Candidate: 0.5-5.1
  Version table:
 *** 0.5-5.1 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status
# apt-cache policy x11-common
x11-common:
  Installed: 1:7.3+10ubuntu8
  Candidate: 1:7.3+10ubuntu8
  Version table:
 *** 1:7.3+10ubuntu8 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
onyxrev (entp) wrote :

I am having the same issue. I use xkbset to define a right click for my Macbook and it stopped working after updating today.

lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

apt-cache policy xkbset
xkbset:
  Installed: 0.5-5.1
  Candidate: 0.5-5.1
  Version table:
 *** 0.5-5.1 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

apt-cache policy x11-common
x11-common:
  Installed: 1:7.3+10ubuntu10
  Candidate: 1:7.3+10ubuntu10
  Version table:
 *** 1:7.3+10ubuntu10 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

Same error about not working on display 0. Running stock Compiz and X11.

Revision history for this message
emmeelle (manulotta) wrote :

I had the same problem.

Revision history for this message
eric3chang (eric3chang) wrote :

Me too. I also use xkbset to simulate right click on my Macbook Pro. Until this is fixed, I can't upgrade from Kubuntu 7.10

Revision history for this message
AJ Slater (aj-slater) wrote :

Same here. Macbook Pro.

'xkbset m' strace attached.

Revision history for this message
AJ Slater (aj-slater) wrote :

While xkbset still reports 'not supported for display', from a practical perspective:

Ctrl-Alt-Shift-Numlock does toggle on and off my mouse keys, so I'm rollin' with context menus on my MBP again.

Revision history for this message
eric3chang (eric3chang) wrote :

Well, I found another way around it. It turns out mouseemu is installed by default on Kubuntu 8.04 machines. Mouseemu, on MBP and probably MB, sets F12 to right click and F11 to middle click by default. You're supposed to be able to change the right click and middle click to something else, but I haven't been able to do that successfully.

Revision history for this message
AJ Slater (aj-slater) wrote :

I run this in my (gnome) session startup:

xmodmap /home/aj/.xmodmap

aj@hooloovoo % cat .xmodmap
keycode 116 = Pointer_Button2
keycode 108 = Pointer_Button3

That's 116 is Right-Fan and 108 is Enter on MBP.

I don't seem to have mouseemu installed.

And again, Ctrl-Alt-Shift-Numlock turns those buttons as acting as mousekeys on and off.

Revision history for this message
eric3chang (eric3chang) wrote :

Oh, I see. So basically Ctrl+Alt+Shift+Numlock takes the place of xkbset -m
The .xmodmap method wasn't working for me. Maybe it's because I'm using KDE :-/. But I put the following script inside the ~/.kde/Autostart folder to make it work.

#!/bin/sh
xmodmap -e "keycode 116 = Pointer_Button2"
xmodmap -e "keycode 108 = Pointer_Button3"
#xkbset -m

Originally the third line would be uncommented if xkbset worked, but I guess I can press Ctrl+Alt+Shift+Numlock to enable it every time. Thanks, AJ, this works better than mouseemu, there is a delay when I use the F12 and F11 buttons for the first time for right click and middle click.

Revision history for this message
Sam Hart (criswellious) wrote :

Ctrl+Alt+Shift+Numlock does work for me as well.

I guess my question now is; has xkbset become deprecated?

Looking at the changelog from upstream (http://changelogs.ubuntu.com/changelogs/pool/universe/x/xkbset/xkbset_0.5-5.1/changelog) the last update to the Debian package was in Jan 2006 and was a non-maintainer upload. So, at least upstream in Debian, it seems unmaintained. If you look even further upstream (http://www.math.missouri.edu/~stephen/software/xkbset/) you see that the original maintainer of the app itself hasn't released anything since 2002.

So, it seems to be unmaintained all the way up. This problem we're encountering could easily be a change in X.org that has made the way xkbset handles these things no longer correct (I've not looked at it, I'm just stabbing in the dark here).

Revision history for this message
onyxrev (entp) wrote :

Thought I'd chime in that Ctrl+Alt+Shift+Numlock works for me too.

Revision history for this message
eric3chang (eric3chang) wrote :

Actually, I think it's just Ctrl+Shift+NumLock. But xkbset is no longer necessary because using Ctrl+Shift+NumLock turns mousekeys on and leaves it on through reboot. The only way I've gotten xkbset to (sorta) work is by placing it in a script inside ~/.kde/Autostart , which is the startup folder under kde. But it seems like a waste of time now that mousekeys persist through reboots.

Revision history for this message
Sam Hart (criswellious) wrote :

""The only way I've gotten xkbset to (sorta) work is by placing it in a script inside ~/.kde/Autostart , which is the startup folder under kde. But it seems like a waste of time now that mousekeys persist through reboots.""

It's only a waste of time if you're using KDE :-)

I use Fluxbox, and I traditionally used xkbset. Now, I have to do CTRL+SHIFT+NUMLOCK, which works, and I'm fine with that.

I'm just wondering if xkbset is orphaned and one of us should suggest to have it removed upstream so it isn't in the next Ubuntu release's universe repo.

Revision history for this message
pauls (paulatgm) wrote :

I found (and added to this description) the same bug in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480021

Perhaps Sam can change the source package to xserver-xorg-core or xkb-data to get the right dev's involved.

In the meantime, I also have the same experience on hardy with xkbset.

Revision history for this message
pauls (paulatgm) wrote :

OK, this is definitely in the source package xorg-server (I added this to this bug) and specifically in xserver-xorg-core. The changelog shows:

xorg-server (2:1.4.1~git20080131-1ubuntu7) hardy; urgency=low

  * 159_xkb_default_to_null.diff:
    When copying the keymap, make sure the structs default to 0/NULL.
    (LP: #184651)

  < snipped others >

 -- Timo Aaltonen <email address hidden> Wed, 09 Apr 2008 11:06:04 +0300

I rebuilt it without this patch and am running it now and xkbset is working ok. So, something about the bug fix to #184651 is the problem here.

Revision history for this message
Marf (lpad-o-sirtwist) wrote :

I experienced the same problem with Xubuntu 8.04. I need xkbset for setting the 'bouncekeys' option.

Finally i got it working again by first setting the keyboard layout via 'setxkbmap'.

#!/bin/sh
setxkbmap -layout <your_layout>
xkbset <whatever_you_want>

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi criswellious,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

Changed in xorg-server:
status: New → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in xorg-server:
status: Incomplete → Invalid
Revision history for this message
Jamie Bainbridge (superjamie) wrote :

It seems 'xkbset m' and Ctrl+Alt+Shift+Numlock both toggle mousekeys on the numpad. I imagine most laptop users wouldn't see this behaviour, due to their integrated Fn+ key numpads. A sideffect for me is that Ins0 Numpad5 and Numpad+ become right click whilst this state is active. 'xev' confirms Pointer_Button3 is registered on those keypresses.

However, I found 'setxkbmap' does fix the "XKB not supported" error, you specify a language for layout. Here's the script I use to make a keyboard button do middle-click paste:

#!/bin/bash
setxkbmap -layout us
xkbset m
xkbset exp =m
xmodmap -e "keycode 135 = Pointer_Button2"

I'd say either features in X or xkbset changed, and 'setxkbmap' is the correct way of using 'xkbset'.

-- Ubuntu 8.04.1, xorg 7.3+10ubuntu10.2, xkbset 0.5-5.1

Out of interest, 'xkbset' runs without 'setxkbmap' on Intrepid on my Dell Vostro 1200 laptop with Intel 965 video. I have not tried Intrepid on my desktop with nVidia FX5200 video and Microsoft Comfort Curve 2000 keyboard.

Daniel T Chen (crimsun)
Changed in xkbset:
status: New → Incomplete
Revision history for this message
Corona (stefaniefauconnier) wrote :

I solved this by running

xhost local:username

on startup. Replace username with your own username of course.

Changed in debian:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.