Opened 4 years ago

Closed 4 years ago

#10213 closed enhancement (fixed)

Frame key doesn't work on XO-1.5 HS

Reported by: wad Owned by: dsd
Priority: high Milestone: 10.1.2
Component: sugar Version:
Keywords: Cc: dsd
Blocked By: Blocking: #10229
Deployments affected: Action Needed: no action
Verified: no

Description

On a C-test XO-1.5 High School laptop (CL1C), running build 206 and firmware Q3A41, the frame key (F6) doesn't work in Sugar.

The KM tag is set to olpc2, the KV tag is set to olpc2.

Change History (24)

comment:1 Changed 4 years ago by pgf

  • Action Needed changed from never set to code
  • Component changed from not assigned to sugar
  • Milestone changed from Not Triaged to 1.5-software-update
  • Owner set to dsd
  • Priority changed from normal to high
  • Version changed from not specified to Development source as of this date

i believe this patch is necessary to make the new frame and search keys work in sugar:

in /usr/lib/python2.6/site-packages/jarabe/view:

==xo-a7-5a-ef,olpc(1)>> diff -u /tmp/keyhandler.py.orig keyhandler.py
--- keyhandler.py.orig     2010-07-10 08:53:14.423048715 -0400
+++ keyhandler.py       2010-07-10 08:58:52.000000000 -0400
@@ -47,6 +47,8 @@
     'F2'                   : 'zoom_group',
     'F3'                   : 'zoom_home',
     'F4'                   : 'zoom_activity',
+    'F5'                   : 'open_search',
+    'F6'                   : 'frame',
     'F9'                   : 'brightness_down',
     'F10'                  : 'brightness_up',
     '<alt>F9'              : 'brightness_min',

in the meantime, use alt-shift-f for frame, and alt-shift-o for search.

comment:2 Changed 4 years ago by dsd

Looking at the keyboard here:
http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard

I would say that Frame should not be F6. It should be Fn+F6. The same way that volume up should be Fn+F12 rather than just F12, and so on. This matches behaviour of other laptops that use these keys for dual-purpose F-key and <some other function>, such as the Dell I'm using now. Thoughts?

comment:3 follow-up: Changed 4 years ago by pgf

  • Cc rsmith dsd wad added

i agree. i investigated this on friday.

alas, the keyboard produces nothing at all for Fn+F1 through Fn+F12.

as far as i understand the EC code, the EC is sending up anything that's available. richard, is this your understanding as well?

wad -- are the available character codes set in stone?

for a "high school" machine, having the F-keys available as their natural selves by default would probably make sense, esp. with the increased availability of a "normal" desktop.

comment:4 Changed 4 years ago by wad

The suggestion to use Fn+F6 for frame is fine.

The scan codes are fixed in metal and mylar, but it is the EC that is responsible for translating the scan codes into character codes.

comment:5 in reply to: ↑ 3 Changed 4 years ago by pgf

Replying to pgf:

alas, the keyboard produces nothing at all for Fn+F1 through Fn+F12.

i was wrong about this. the keyboard, and the EC, are both passing up all the bytes we need to do this. it's a kernel or a keyboard mapping problem that "scancode -s" doesn't show any output for the Fn key by itself, or for the Fn+FX combinations.

comment:6 follow-up: Changed 4 years ago by dsd

Does anything appear in dmesg after pressing the keys?

comment:7 in reply to: ↑ 6 Changed 4 years ago by pgf

Replying to dsd:

Does anything appear in dmesg after pressing the keys?

no.

comment:8 Changed 4 years ago by Quozl

  • Blocking 10229 added

(In #10229) Add duplicate.

comment:9 Changed 4 years ago by pgf

the bigger topic of this bug is how to best map the top row of
keys on the "high school" mechanical keyboard, which now has labels
the labels for F1 through F12.

in sugar, we want the things to work pretty much as they did
before -- i.e., the sugar keys and the volume and brightness keys
should ideally function without a modifier. in order to
accomplish this, all that needs to happen is a change to sugar to
support F5 and F6, as mentioned in comment 1, above.

in gnome, however, there's a desire to make all of the F-keys
available to applications. the sugar keys clearly aren't an
issue (sugar isn't running), but olpc-kbdshim steals F9-F12 for
volume and brightness. to make those 4 keys available, we'd like
to move volume and brightness to Fn-F9 through Fn-F12. for
completeness, this implies we want to enable the use of the Fn
key with all of the F-keys (giving us another 12 useable keys).

by default, the FN-modified F-keys generate scan codes which are already
mapped by the kernel to generate evdev codes 466-477. (you can
verify this with the getkeycodes command. don't use
"showkey"/"showkey -s" -- it's unreliable, as per the final
paragraph in its linux man page.)

the default codes of 466-477 (0x1d2-0x1dd) are evdev's FN_F1 to
FN_F12 (see /usr/include/linux/input.h), and are exactly what we
want. but xkb can't use those values -- the max keycode xkb can
deal with is 248, or something like that. so instead we'll add
the following bindings to /etc/init.d/olpc-configure. the values
183 to 194 are the evdev values for F13-F24. (it's safe to add
these bindings for any type of OLPC keyboard, on any platform.)

    setkeycodes e03b 183
    setkeycodes e03c 184
    setkeycodes e03d 185
    setkeycodes e03e 186
    setkeycodes e03f 187
    setkeycodes e040 188
    setkeycodes e041 189
    setkeycodes e042 190
    setkeycodes e043 191
    setkeycodes e044 192
    setkeycodes e057 193
    setkeycodes e058 194

then, we need to tell xkb that the <FKnn> keycodes (which xkb
already defines in /usr/share/X11/xkb/keycodes/evdev) are
generated from the evdev codes on our keyboard. so we'll add
these /usr/share/X11/xkb/symbols/olpc:

    key <FK13> { [ F13 ] };
    key <FK14> { [ F14 ] };
    key <FK15> { [ F15 ] };
    key <FK16> { [ F16 ] };
    key <FK17> { [ F17 ] };
    key <FK18> { [ F18 ] };
    key <FK19> { [ F19 ] };
    key <FK20> { [ F20 ] };
    key <FK21> { [ F21 ] };
    key <FK22> { [ F22 ] };
    key <FK23> { [ F23 ] };
    key <FK24> { [ F24 ] };

finally, once all this is in place, it will be possible to modify
olpc-kbdshim. currently it steals F9 to F12. we'll change that
so that it steals F21 to F24, and doesn't steal F9 to F12 if
sugar isn't running. (olpc-session already has some knowledge of
what environment is being run, and can configure olpc-kbdshim
appropriately.)

comment:10 Changed 4 years ago by pgf

one more thing. we might want the sugar keys to work whether Fn is held or not. this would require 6 more key bindings in view/keyhandler.c, for F13 through F18, to match the current bindings of F1 through F6.

comment:11 Changed 4 years ago by dsd

The usual Linux approach, and the one I think we should take, is mapping the Fn+F12 key to be the "volume up" key and so on.

On Fedora 11 this is done with HAL files in /usr/share/hal/fdi. On newer systems it is done with udev in /lib/udev/keymaps. See for example /lib/udev/keymaps/dell for the file which magically makes my Fn+F11 key be "play/pause" as marked, without me having to configure anything. In both cases we already have configurations for the XO.

comment:12 Changed 4 years ago by pgf

thank you for pointing me to yet another remapping layer in the world of linux character input. i think that makes at least a dozen layers.

a) i'm not sure which part of the problem this will solve.

b) i see no evidence (after disabling olpc-kbdshim) that the current rules in /usr/share/hal/fdi/information/10freedesktop/30-keymap-olpc.fdi have any effect on the current system. am i missing something? (os126)

comment:13 Changed 4 years ago by dsd

yes, sorry, that version of the file is broken. the one you want to change is in /etc/hal/fdi/information

comment:14 Changed 4 years ago by pgf

thanks.

this fills in a gap in my understanding. the initial default scancode --> keycode mapping we see from "getkeycodes" actually comes from that hal file. (/etc/hal/fdi/information/30-keymap-olpc.fdi)

so i could dispense with the proposed new xkb lines, and the proposed new setkeycodes lines, and simply change 4 of the lines in 30-keymap-olpc.fdi from:

        <append key="input.keymap.data" type="strlist">e043:fn_f9</append>
        <append key="input.keymap.data" type="strlist">e044:fn_f10</append>
        <append key="input.keymap.data" type="strlist">e057:fn_f11</append>
        <append key="input.keymap.data" type="strlist">e058:fn_f12</append>

to:

        <append key="input.keymap.data" type="strlist">e043:brightnessdown</append>
        <append key="input.keymap.data" type="strlist">e044:brightnessup</append>
        <append key="input.keymap.data" type="strlist">e057:volumedown</append>
        <append key="input.keymap.data" type="strlist">e058:volumeup</append>

then kbdshim would bind to KEY_BRIGHTNESSUP/DOWN and KEY_VOLUMEUP/DOWN instead of KEY_F21-KEYF24. the remaining Fn-Fkeys would continue to be inaccessible from X. (well, at least as inaccessible as they are today. i can't seem to get them through xkb.)

i agree this is a simpler change. is this sort of what you had in mind?

comment:15 follow-up: Changed 4 years ago by dsd

yep, exactly! plus the following additions:

  • fn+f6 (frame) -- 139 menu (and modify sugar to listen for this)
  • fn+f5 (journal) -- 217 search (and modify sugar)

For the zoom levels on F1-F4, I guess we should make them work either as Fx or as FN-Fx. This could be done in the same file, by making the FN-F1 (through F4) map to F1 through F4.

comment:16 in reply to: ↑ 15 Changed 4 years ago by pgf

Replying to dsd:

  • fn+f6 (frame) -- 139 menu (and modify sugar to listen for this)
  • fn+f5 (journal) -- 217 search (and modify sugar)

For the zoom levels on F1-F4, I guess we should make them work either as Fx or as FN-Fx. This could be done in the same file, by making the FN-F1 (through F4) map to F1 through F4.

i guess. if they could be seen through xkb i'd say leave them alone and let sugar bind to FN_F1 through FN_F6. i'd rather bind them to something generic (and unique) so they can be used more naturally in gnome. (and i'd bind them all, rather than just Fn-F1 through Fn-F6, to make then all available.)

comment:17 Changed 4 years ago by dsd

sounds reasonable, as long as we can convince the sugar folks

comment:18 Changed 4 years ago by Quozl

  • Milestone changed from 10.1.1 to 10.1.2

comment:19 Changed 4 years ago by pgf

should all of these changes be for the new keyboard only? on the membrane keyboard i think the only interesting case is whether the brightness/volume keys should require the Fn modifier when you're in gnome.

  • pro: the new behavior makes F11/F12 available to apps under gnome. those keys aren't labeled on the membrane keyboard, but the savvy user will likely figure out that that's what they are.
  • con: current releases of XO-1.5 make brightness/volume available unmodified under either desktop, so this will be a change.

comment:20 Changed 4 years ago by pgf

final resolution of this is as described here: http://lists.laptop.org/pipermail/devel/2010-July/029384.html

the F-keys will all be double mapped to their unmodified values, making them all available as Fkeys whether Fn is pressed or not, _except_ that the unmodified brightness and volume keys will be dedicated to that purpose only. F9-F12 will only be available via the Fn key.

comment:21 Changed 4 years ago by pgf

  • Action Needed changed from code to test in build
  • Cc rsmith wad removed

olpc-utils 1.0.26 and olpc-kbdshim 14 have the fix for the F-key part of this, and are both in os302, for both laptops.

waiting on sugar fix to support F5/F6. dsd says soon.

comment:22 Changed 4 years ago by Quozl

  • Action Needed changed from test in build to diagnose

Tested XO-1.5 HS with os302, olpc-utils-1.0.26 and olpc-kbdshim-14 ... didn't have a test case, wasn't sure what to test.

F1 through to F4 with and without fn modifier correctly activate Sugar functions. F5 and F6 do not, though in Terminal preceded by Ctrl/V they echo [[15~ and [[17~ respectively. F9 and F10 correctly change backlight brightness. F11 and F12 correctly change volume as viewed by alsamixer.

comment:23 Changed 4 years ago by dsd

  • Action Needed changed from diagnose to test in build

test sugar-0.84.19 in next build

comment:24 Changed 4 years ago by Quozl

  • Action Needed changed from test in build to no action
  • Resolution set to fixed
  • Status changed from new to closed
  • Type changed from defect to enhancement
  • Version Development source as of this date deleted

Tested XO-1.5 HS with os303, F5 displays journal, F6 toggles frame. No test case, but frame key does work on XO-1.5 HS, closing.

Note: See TracTickets for help on using tickets.