| Summary: | Merge OLPC es / olpc2 keyboard map | ||
|---|---|---|---|
| Product: | xkeyboard-config | Reporter: | Martin Langhoff <martin> |
| Component: | General | Assignee: | xkb |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | Keywords: | NEEDINFO |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Martin Langhoff
2011-02-25 12:11:30 UTC
Why do you need this in rules: + olpc es = olpc+es(%v) I thought it should be covered by olpc * = olpc+%l%(v) Isn't it? We probably should just remove es from $olpclayouts, right? Also, what's your plan regarding es(olpc2)? It is not in rules, not in base.xml.in. I think I dropped it accidentally from rules and base.xml.in . Thanks for spotting this. We do have 3 layouts, olpc (rubber membrane kb), olpc2 (to force special deadkey modes on us int'l layout of the rubber membrane kb) and olpcm (actually a mechanical keyboard). What do you recommend? Again, THANKS for the review and sanity check. > We do have 3 layouts, olpc (rubber membrane kb), olpc2 (to force special > deadkey modes on us int'l layout of the rubber membrane kb) and olpcm (actually > a mechanical keyboard). > > What do you recommend? That's tough one. Could you elaborate more on their usage? What's most popular of those 3? How do people decide which one to use? > Again, THANKS for the review and sanity check. I am just trying to keep the codebase as sane as possible - but it is insane project anyway:) I'll explain the usage a bit, maybe that clarifies. Apologies for the perhaps inaccurate terminology. OLPC ships 2 physical keyboards: - membrane keyboards, XKV_MODEL=olpc -- pictures and links at http://wiki.laptop.org/go/Keyboards_and_key_bindings - mechanical keyboard, XKV_MODEL=olpcm -- pictures at http://blog.laptop.org/2010/07/24/xo-1-5-hackably-sweet/ Most our users, and the users we care the most about, are not English speakers, so to help in cases where we don't (yet) have a custom layout, our us/olpc keyboard is actually mapped somewhat similar to a "us international" keyboard with "composing" unicode chars. Not sure about the term but if you hit a then ´ you get unicode composed á. Our main userbase is in LatAm, and while most have the correct es/olpc layout, due to awkward logistics some deployments we have en/olpc keyboards. Worse even, some have a mix. es/olpc does a more conventional dead-key sequence: ´ then a for á. Our es/olpc with XKV_VARIANT olpc2 is an attempt at implementing ´ then a for á for users that unfortunately have that (us) keyboard. About how users select the variant -- they don't. We have an init script that sets all that based on data read from the BIOS. See code at http://dev.laptop.org/git/projects/olpc-utils/tree/etc/rc.d/init.d/olpc-configure#n160 Some more info about the data recorded in the BIOS - and how it drives keyboard settings http://wiki.laptop.org/go/Manufacturing_data#Keyboards Advanced users can perhaps set their XKB variables, but those are not the users we work hard for... :-) OMG. That's tough. What we can do: 1. Just add the variants as they are, no special advertising in evdev.xml. We have the model olpc - so we can make sure that "model olpc, layout es" chooses es/olpc. 2. We can (if there is a need) create a model olpcm for xo1.5. Would you foresee other xo1.5-specific variants? In any case, people can call these variants using setxkbmap - they just won't be explicitly visible in gui tools using evdev.xml. What do you think? This has never been easy :-) To the best of my (limited) knowledge: "1. Just add the variants as they are, no special advertising in evdev.xml. We have the model olpc - so we can make sure that "model olpc, layout es" chooses es/olpc." Not sure I follow. We currently have "model olpc, layout es" for the real spanish keyboard, with "normal deadkeys". Users see this silkscreen print http://wiki.laptop.org/go/OLPC_Spanish_Keyboard We would like to have "model olpc, layout es, variant olpc2" that actually is based on olpc/en with deadkeys for some combining glyphs like ´ . Users see this silkscreen http://wiki.laptop.org/go/OLPC_English_Keyboard The patch we have seems to achieve this. Perhaps there is a better way? "2. We can (if there is a need) create a model olpcm for xo1.5. Would you foresee other xo1.5-specific variants?" We need a new model, as the keyboard is very different. See http://wiki.laptop.org/go/OLPC_English_Non-membrane_Keyboard http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard We may need another model in the future, as we are experimenting with other materials. But we cannot tell at this time. Is it different if we later need 'olpcX'? "In any case, people can call these variants using setxkbmap - they just won't be explicitly visible in gui tools using evdev.xml " This is ok with OLPC's immediate needs. Other users and enthusiasts may want to run a generic distro on the XO. They might want to pick a kb layout from gnome. Low pri for us, but important to others... What do you recommend? > The patch we have seems to achieve this. Perhaps there is a better way? Yes, I guess it does > We need a new model, as the keyboard is very different. See Ok, that makes sense. > We may need another model in the future, as we are experimenting with other > materials. But we cannot tell at this time. Is it different if we later need > 'olpcX'? Not really. > What do you recommend? Ok, I will take your patch for olpc2 (except the rules, unneeded change). commited. Thanks! I agree, this olpc2 variant is ok to not have in evdev.xml . About the olpcm model, I guess discussion continues in #34738 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.