Red Hat Bugzilla – Full Text Bug Listing
|Summary:||OLPC XO needs a new keymap|
|Product:||[Fedora] Fedora||Reporter:||Ignacio Vazquez-Abrams <ivazqueznet>|
|Component:||hal-info||Assignee:||Richard Hughes <richard>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||david, gdk, john.brown009, martin, rhughes, richard, sascha-web-bugzilla.redhat.com|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-18 08:58:17 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||468640|
|Bug Blocks:||461806, 465390, 467109, 467796, 468739|
Description Ignacio Vazquez-Abrams 2008-10-27 15:43:55 EDT
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 16:19:36 EDT
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 17:14:19 EDT
(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 17:17:57 EDT
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 18:24:12 EDT
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 08:39:01 EST
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 08:46:14 EST
Are the match strings in fact accurate?
Comment 7 Richard Hughes 2008-11-04 08:52:57 EST
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 04:58:28 EST
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 14:42:49 EST
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 15:18:03 EST
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 05:24:49 EST
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 10:18:53 EST
You'll have to have an image with a new enough kernel (184.108.40.206-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 04:50:04 EST
(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 06:27:33 EST
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 06:47:31 EST
(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-25 23:18:54 EST
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 13:27:26 EST
Bumping the priority up here, since it seems to block several other XO bugs.
Comment 18 David Lang 2009-02-26 18:56:10 EST
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-26 21:41:05 EST
(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 13:00:47 EST
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 12:22:31 EDT
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 02:46:59 EST
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 08:58:17 EST
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