Bug 3021 - Xomap doesn't handle FN key properly (keycodes > 255)
: Xomap doesn't handle FN key properly (keycodes > 255)
Product: Core
X Server
: 5.0/(3.2010.02-8)
: All Linux
: Low minor (vote)
: ---
Assigned To: unassigned
: x-server-bugs
: http://bugs.freedesktop.org/show_bug....
: upstream
  Show dependency tree
Reported: 2008-03-11 17:25 UTC by Tuomas Kulve
Modified: 2011-09-02 21:43 UTC (History)
2 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description Tuomas Kulve (reporter) 2008-03-11 17:25:29 UTC

Modern keyboards on PCs has all kinds of multimedia keys and the KEY_FN on
N810's keyboard could be counted as one.

The FN key uses the standard keycode 0x1d0 (464) defined in
/usr/include/linux/input.h. The problem here is that x11 protocol doesn't
support keycodes over 255.

The Xomap currently does something very odd with the keycode (see [1] for more
details), it takes the lowest 8 bits, increases by 8 and decreases by 0:

key_code = scan_code + KD_MIN_KEYCODE - ki->minScanCode

The result is 216 and this code is used happily in the xkb mappings.

To me this looks like a bug (according to xev also Xorg receives code 216).

Since x12 isn't coming any time soon, I believe the best choice would be to use
HAL and let it remap the keys to some unused keycode explicitly. HAL uses
EVIOCSKEYCODE ioctl with the evdev device to do this but unfortunately it seems
that the Maemo's OMAP keyboard driver doesn't implement this (at least I get
EINVAL while it works on PC).

[1] http://lists.maemo.org/pipermail//maemo-developers/2008-March/014980.html
Comment 1 Daniel Stone nokia 2008-03-18 12:55:21 UTC
ack.  oops, i should know this a bit better. :)
Comment 2 Daniel Stone nokia 2008-03-18 12:55:31 UTC
ack.  oops, i should know this a bit better. :)
Comment 3 Andre Klapper maemo.org 2008-10-29 15:55:53 UTC
Daniel: Is working going on for this? Want to have an internal copy for this
Comment 4 Andre Klapper maemo.org 2008-11-22 17:30:23 UTC
Daniel: Will this be fixed for Fremantle?
Comment 5 Andre Klapper maemo.org 2009-02-04 17:45:30 UTC
Willing to give Fremantle pre-alpha2 a try and add a comment about it?
Comment 6 Tuomas Kulve (reporter) 2009-02-04 19:36:39 UTC
No X.Org in Fremantle sources yet (at least I didn't find it). And probably the
key codes will be completely different for RX-51.

I did get X.Org 1.5.1 working with n810 though with ARM Linux Internet
Platform[1]. Looks like there the xf86-input-evdev 2.0.4 passes the KEY_FN
(464) to X.Org but key codes over 256 are discarded there. 

So, for ALIP I modified the xf86-input-evdev to send Alt Gr (108) instead of
KEY_FB [2]. I also changed the keymap in xkeyboard-config to use the Alt Gr
instead of the old invalid keycode 216[3].

[1] http://linux.onarm.com


Comment 7 Andre Klapper maemo.org 2009-03-26 18:05:09 UTC
(In reply to comment #6)
> No X.Org in Fremantle sources yet

Fremantle SDK alpha now has
 xorg                1:7.3+10.0maemo2
 xorg-server            2:
 xserver-xorg-input-evdev    1:2.1.99-1osso20081107.4
 xserver-xorg-input-tslib    1:0.1.0-2
 xserver-xorg-video-fbdev    1:0.4.0-7

As far as I've been told it's WONTFIX for Diablo (not critical enough to fix).
Comment 8 Tuomas Kulve (reporter) 2009-03-26 18:12:22 UTC
Yes, this is not critical and it's actually upstream issue.
Comment 9 Andre Klapper maemo.org 2009-05-28 14:28:25 UTC
Upstream ticket is http://bugs.freedesktop.org/show_bug.cgi?id=11227 .
Setting version to Fremantle as the upstream ticket is still open.
Comment 10 Andre Klapper maemo.org 2010-08-20 19:12:26 UTC
This is a WONTFIX for Maemo5 as long as it is not fixed upstream, and I don't
expect an upstream fix soon I'd rather recommend to file a report in
bugs.meego.com as MeeGo Handset is where the unstable development is taking
place. (Please note that MeeGo for the Nokia N900 is unstable. If you are
interested, see
for more information and be aware of the risks of trying unstable software.)
Comment 11 Tuomas Kulve (reporter) 2010-08-20 23:40:47 UTC
Comment 12 Tuomas Kulve (reporter) 2011-09-02 21:43:34 UTC
Closing as wontfix.