Bug 468744 (FedoraXOKeyboard) - OLPC XO needs a new keymap
Summary: OLPC XO needs a new keymap
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: FedoraXOKeyboard
Product: Fedora
Classification: Fedora
Component: hal-info
Version: 10
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 468640
Blocks: FedoraOnXO 465390 467109 467796 468739
TreeView+ depends on / blocked
 
Reported: 2008-10-27 19:43 UTC by Ignacio Vazquez-Abrams
Modified: 2009-11-18 13:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-18 13:58:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Initial OLPC keymap (2.24 KB, text/plain)
2008-10-27 22:24 UTC, Ignacio Vazquez-Abrams
no flags Details

Description Ignacio Vazquez-Abrams 2008-10-27 19:43:55 UTC
A number of keys on the XO are not mapped, and a few others are not mapped correctly. This bug is to create a new keymapping that handles all of them properly.

Comment 1 Peter Robinson 2008-10-27 20:19:36 UTC
Would this one be fixed by any of the patches that are in the OLPC-3 branch of xkeyboard-config?

Comment 2 Ignacio Vazquez-Abrams 2008-10-27 21:14:19 UTC
(In reply to comment #1)
> Would this one be fixed by any of the patches that are in the OLPC-3 branch of
> xkeyboard-config?

They're useful for X, but there's still some missing basic functionality.

Comment 3 Ignacio Vazquez-Abrams 2008-10-27 21:17:57 UTC
After some poking around, here's what I have found.

These keys were identified via xev and will need to be remapped. The keycode is given:
K125: Fn
K97: ×/÷
K181: GPsquare
K136: GPcheck
K225: GPcircle
K164: GPx
K75: Br-
K76: Br+
K95: Vol-
K96: Vol+

These keys were not identified. The setkeycode value returned by atkbd.c is given:
65: GPup
66: GPdown
67: GPleft
68: GPright
69: Rotate
e079: Loupe
e06e: Boards

Comment 4 Ignacio Vazquez-Abrams 2008-10-27 22:24:12 UTC
Created attachment 321663 [details]
Initial OLPC keymap

Here's my initial stab at a keymap. I wasn't sure what to assign each of the buttons to since I only get to choose from KEY_xxxx constants and some of them fall under BTN_xxxx mappings.

Comment 5 Richard Hughes 2008-11-04 13:39:01 UTC
Can you send this to the HAL mailing list please, and I'll commit it after review there. Thanks.

Comment 6 Ignacio Vazquez-Abrams 2008-11-04 13:46:14 UTC
Are the match strings in fact accurate?

Comment 7 Richard Hughes 2008-11-04 13:52:57 UTC
No, I have a patch to add OFW support to HAL to provide these sort of dmi strings (you can find it in hal/devel in cvs) but I think it's a bit late in the day to update HAL before release.

Comment 8 Richard Hughes 2008-11-05 09:58:28 UTC
I've just built http://koji.fedoraproject.org/koji/taskinfo?taskID=918015 which provides the following keys:

/org/freedesktop/Hal/devices/computer:system.hardware.product = C2
/org/freedesktop/Hal/devices/computer:system.hardware.vendor  = OLPC
/org/freedesktop/Hal/devices/computer:system.hardware.version = OLPC C2

I guess that helps.

Comment 9 Jeremy Katz 2008-11-10 19:42:49 UTC
Richard -- I don't see any problems with this upstream and it looks okay to me (with the obvious change for system.* to match what we actually put in hal).  Can you build a new hal-info for F10 or would you prefer that I do it?

Comment 10 Jeremy Katz 2008-11-12 20:18:03 UTC
Hmmm, with the new hal-info, it's definitely taking effect, but the remapping of the keys such as F9, etc doesn't appear to be doing what I'd expect at all.

Comment 11 Ignacio Vazquez-Abrams 2008-11-13 10:24:49 UTC
Well then you're having far better luck than me; I still can't get hal to acknowledge my XO as anything other than Computer/unknown. Perhaps it's because I upgraded to Q2E20...

Comment 12 Jeremy Katz 2008-11-13 15:18:53 UTC
You'll have to have an image with a new enough kernel (2.6.27.5-94) and hal-0.5.12-12.20081027git.fc10

http://katzj.fedorapeople.org/olpc/rawtest.iso is the image I built yesterday with new enough kernel + hal + hal-info (it's scp'ing now; give it until 10:30 or so eastern to finish copying)

Comment 13 David Lang 2008-11-14 09:50:04 UTC
(In reply to comment #3)
> K75: Br-
> K76: Br+
> K95: Vol-
> K96: Vol+

you do not want to change these. they are F9 through F12. the desktop software then maps these keys to the brightness and volume functions, but if you force these keys to be used for that you make it impossible to use them with any software that's expecting the function keys.

Comment 14 Richard Hughes 2008-11-14 11:27:33 UTC
Desktop software shouldn't listen for F9-F12 events, that's insane. Software should listen for XF86XK_MonBrightnessUp and XF86XK_MonBrightnessDown.

If there's software listening for F9-F12, it's relying on OLPC specific keylabels, and is never going to work on any system that isn't an OLPC. If it works, it's because the OLPC has broken key remapping.

Richard.

Comment 15 David Lang 2008-11-14 11:47:31 UTC
(In reply to comment #14)
> Desktop software shouldn't listen for F9-F12 events, that's insane. Software
> should listen for XF86XK_MonBrightnessUp and XF86XK_MonBrightnessDown.
> 
> If there's software listening for F9-F12, it's relying on OLPC specific
> keylabels, and is never going to work on any system that isn't an OLPC. If it
> works, it's because the OLPC has broken key remapping.

inkscape (among other software) uses F11 to switch to fullscreen mode

there is a _lot_ of desktop software around that uses the function keys. even the olpc distro itself uses the function keys _as_ function keys for switching the console (alt+F1, alt+F2, etc)

the olpc keymap leaves the F9-F12 keys as function keys and then has something else decide that when it gets a F9 key it does a XF86XK_MonBrightnessDown. I don't know exactly where in the system it makes this mapping, but I'm arguing that it should not be hard coded into the keymap (which the proposed keymap would do)

the three bars across the top of the olpc keyboard are each a group of four function keys, with funny pictures on them instead of the normal labels. they produce the same keycodes as function keys on standard PC keyboards

some software may want to do a brightness down when it sees a F9, some may want to do it only when it sees a Fn+F9 combination

Comment 16 Bug Zapper 2008-11-26 04:18:54 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Greg DeKoenigsberg 2009-02-26 18:27:26 UTC
Bumping the priority up here, since it seems to block several other XO bugs.

Comment 18 David Lang 2009-02-26 23:56:10 UTC
debxo has a keymap that makes all the keys work on the debian lenny based distro

this same keymap should be able to be used for fedora

http://wiki.laptop.org/go/DebXO

the keymap file they use is at
http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=blob_plain;f=30-keymap-olpc.fdi;hb=9b8968fdf876100b86e3a6ea141bda94450aff9c

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<!-- sticking this into /usr/share/hal/fdi/information/10freedesktop/ should
     enable working keys -->

<deviceinfo version="0.2">
  <device>
    <!-- These are buttons synthesized in atkbd -->
    <match key="@input.originating_device:info.linux.driver" string="atkbd">
          <append key="input.keymap.data" type="strlist">0x65:kp9</append> <!-- Game Key - Up -->
          <append key="input.keymap.data" type="strlist">0x66:kp3</append> <!-- Game Key - Down -->
          <append key="input.keymap.data" type="strlist">0x67:kp7</append> <!-- Game Key - Left -->
          <append key="input.keymap.data" type="strlist">0x68:kp1</append> <!-- Game Key - Right -->

          <append key="input.keymap.data" type="strlist">0xe065:kp8</append> <!-- Game Key - O -->
          <append key="input.keymap.data" type="strlist">0xe066:kp2</append> <!-- Game Key - X -->
          <append key="input.keymap.data" type="strlist">0xe067:kp4</append> <!-- Game Key - [] -->
          <append key="input.keymap.data" type="strlist">0xe068:kp6</append> <!-- Game Key - V -->

          <append key="input.keymap.data" type="strlist">0x73:prog1</append> <!-- mult/div -->
          <append key="input.keymap.data" type="strlist">0x43:brightnessdown</append> <!-- Backlight Down (F9) -->
          <append key="input.keymap.data" type="strlist">0x44:brightnessup</append> <!-- Backlight Up (F10) -->
          <append key="input.keymap.data" type="strlist">0x57:volumedown</append> <!-- Volume Down (F11) -->
          <append key="input.keymap.data" type="strlist">0x58:volumeup</append> <!-- Volume Up (F12) -->

          <append key="input.keymap.data" type="strlist">0x59:fn</append> <!-- Fn -->

          <append key="input.keymap.data" type="strlist">0xe043:f9</append> <!-- Fn+Backlight Down (F9) -->
          <append key="input.keymap.data" type="strlist">0xe044:f10</append> <!-- Fn+Backlight Up (F10) -->
          <append key="input.keymap.data" type="strlist">0xe057:f11</append> <!-- Fn+Volume Down (F11) -->
          <append key="input.keymap.data" type="strlist">0xe058:f12</append> <!-- Fn+Volume Up (F12) -->

          <append key="input.keymap.data" type="strlist">0xe079:search</append> <!-- Search -->
          <append key="input.keymap.data" type="strlist">0xe06e:chat</append> <!-- Chat -->

          <append key="info.capabilities" type="strlist">input.keymap</append>

    </match>
  </device>
</deviceinfo>

Comment 19 Jeremy Katz 2009-02-27 02:41:05 UTC
(In reply to comment #18)
> debxo has a keymap that makes all the keys work on the debian lenny based
> distro
> 
> this same keymap should be able to be used for fedora

Is there any reason the fdi file hasn't been submitted upstream to hal-info rather than having each distro go and find it and suck it in as a patch?

Comment 20 David Lang 2009-02-27 18:00:47 UTC
there is some disagreement over how some of the keys should be mapped (as you can see in the discussion above)

F9-F12 keys (as function keys or as brightness/volume keys)
game buttons (debxo has the diamond of keys be up/down/left/right, OLPC has them pgup/pgdn/home/end with the pad on the left be up/down/left/right)

and some of the others don't have a standard use.

Comment 21 TK009 2009-10-30 16:22:31 UTC
Has this issue been resolved or should this bug be set to F11 so as not to get EOL closed?

Comment 22 Bug Zapper 2009-11-18 07:46:59 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 23 TK009 2009-11-18 13:58:17 UTC
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. 

Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. 

TK009

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


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