X Window Keyboard and around

Dreaming about XKB2

duke_igthorn — Wed, 26 May 2010 22:09:44 GMT

There is a ~~standing joke~~ dream about XKB2. That name is used to refer the idea of breaking annoying limitations of XKB (yes, in incompatible way). New X11 extension, new API.

That thing was mentioned many times. Various people looked at it. Some (very few!) people have skills and knowledge to work at it - but, as all of us, they are busy people, and that project would give nothing but a lot of PITA and a small bit of credits (among those few who can understand the whole issue), so for a moment no timeline, no promises.

There is an idea that even collecting those dreams together in one place could be handy. May be, one day, we'll find the superhero... GSoC 2011?

Anyway, here is the place to express your ideas related to XKB2. The initial set was discussed with Andriy Rysin (the guy who manages XKB stuff in KDE).

a new layout for both hands and one hand writing

rubo77 — Wed, 03 Mar 2010 02:13:42 GMT

i have created a Keyboard Layout that can be operated with both hands and optional with only one hand.
http://www.entikey.z11.de/

i have also packed a deb-packet, but i think it would be better to have it implemented in the X Window project.

could you add my changes from the deb-packet to the repository?

entikey-1.0_i386.deb

Level clarification needed

nazartm8 — Sun, 03 Jan 2010 14:05:03 GMT

Hi guys,

Let me get straight to my problem. The turkmen keyboard has different letters where x, c, v and q are supposed to be. So in the turkmen keyboard layout, I used:

key.type[group1]="ALPHABETIC";

To get ctrl shortcuts (copy, paste, cut, quit) to work. However, after adding these, the altGr doesn't work, we use altGr to get x, c, v which we do need in international words, though not frequently.

I looked at some other layouts they have lines such as FOUR_LEVEL, FOUR_LEVEL_ALPHABETIC. I'm guessing these are the ones to be used, though, if I substitute these, the ctrl shortcuts stop working. I frankly don't understand the mechanism, I got this far with try & fail. If anyone sees my problem, please share some tips :)

XKB options: swap Ctrl and Super (windows) key

mildred593 — Tue, 22 Dec 2009 23:45:01 GMT

Hi, I haven't found a mailing list on the freedesktop wiki, so I assume this place is as good as any other place. I wanted to ask for a feature to be implemented in the xkb layouts. So, let me explain. i have a macintosh (macintel) keyboard and even if I seldom uses Mac OS X, I'd like to have a similar layout as in Mac OS X. Especially around the special keys around the spacebar (control, alt, ...) Here is how my keyboard (a laptop) looks like (on the lowest row of keys):



<LCTL> <LALT> <LWIN> <SPCE> <RWIN> <KPEN>

Here is how a desktop mac keyboard would look like on the same row.



<LCTL> <LALT> <LWIN> <SPCE> <RWIN> <RALT> <RCTL>

Now, on X11, the main modifier key is Control (<LCTL>, <RCTL>), while on Mac OS X, the main modifier key is command (or the windows key, it has the same keycode. <LWIN> <RWIN>). On Mac OS X, we can choose the third level (the equivalent of AltGr on PC keyboards) using any of the alt keys alone (<LALT>, <RALT>). When used in combination with the command key (<LWIN>, <RWIN>), the third level is not chosen. I tried to create an XKB map that would be as close to this behaviour as possible, but I couldn't succeed. The problem is that i couldn't find a way that Alt would trigger the third level if pressed alone, but not if pressed with another modifier. My solution was to map the keys as follows:




key <LCTL> to symbol Super_L and modifier Mod1 (Alt)
key <RCTL> to symbol Super_R and modifier Mod1 (Alt)
key <LALT> to symbol Alt_L and modifier Mod5 (level3 shift)
key <RALT> to symbol Alt_R and modifier Mod5 (level3 shift)
key <LWIN> to symbol Control_L and modifier Control
key <RWIN> to symbol Control_R and modifier Control

The exact code I used was:




  xkb_symbols   {

      // --------------
      // Default keymap
      // --------------

      include "pc"
      include "macintosh_vndr/fr"
      include "inet(evdev)"

      // ---------------
      // Command (cmd ⌘)
      // ---------------

      include "altwin(ctrl_win)"

      // -------------------
      // Control (ctrl) keys
      // -------------------

      key <LCTL> { [ Super_L, Super_L ] };
      key <RCTL> { [ Super_R, Super_R ] };
      modifier_map Mod1 { <LCTL>, <RCTL> };

      // ----------------
      // Alt (alt ⌥) keys
      // ----------------

      include "level3(lalt_switch)"
      include "level3(ralt_switch)"
  };

Now, my only problem is that I have to use xkbcomp keymap $DISPLAY to install the keymap. And frequently, GNOME reset the keymap to the default keymap configured within GNOME. I'd really welcome these features to be included directly in xkb layouts. Probaaly in the XKB options. I think we could have something like:



partial modifier_keys
xkb_symbols "switch_lwin_lctrl" {
    key <LWIN> { [ Control_L ] };
    key <LCTL> { [ Super_L, Super_L ] };
    modifier_map Control { <LWIN> };
};

partial modifier_keys
xkb_symbols "switch_rwin_rctrl" {
    key <RWIN> { [ Control_R ] };
    key <RCTL> { [ Super_R, Super_R ] };
    modifier_map Control { <RWIN> };
};

partial modifier_keys
xkb_symbols "ctrl_key_as_mod1" {
    modifier_map Mod1 { <LCTL>, <RCTL> };
};

Then we could have something like I have using those three options plus level3(lalt_switch) and level3(ralt_switch) What do you think ? Could that be included ? Thanks. Mildred

andrushka_il — Thu, 22 Oct 2009 22:57:42 GMT

Please help me !

How can i add more than four keyboard layouts on my Ubuntu 9.04 ? Is it fixable in this version of Ubuntu or i just should wait for next version (9.10 , where i hope this bug is fixed?)

Thanx !

European multi-lingual layout

duke_igthorn — Wed, 10 Jun 2009 21:12:30 GMT

The CEN/MEEK worgroup is writing a recommendation for all European countries for implementing their
multilinguage keyboards. In practice these recommendations will end up being used by parties such as Microsoft when implementing their layouts.

The document has just entered the public commenting period (which ends August 28th, 2009), and the workgroup would like to urge all interested parties in the X11 community to submit their comments.

The addresses are
http://www.csc.fi/meek/
and
http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ws+meek.asp

Intro and request for documentation.

dave_pawson — Fri, 10 Oct 2008 14:29:01 GMT

New to keyboard wizardry, I've just spent 3 days wondering round the net trying to figure out how
my Linux (Fedora core 9) gets from keyboard events to glyphs in emacs.

Started when I decided to move to dvorak. I'm in the UK, so I found the us dvorak symbols not quite right.

I've figured it out using
$setxkbmap dvorak (and changing xkb/symbols/us)
Also by modifying /etc/X11/xorg.conf to use the uk keyboard, with the dvorak option (only two changes this time).

I'm looking for documentation (high level presently) which takes me from the xorg.conf file through to
a set of directories (how are these selected?), to matching files from

Section "InputDevice"
# keyboard added by rhpxl
# DP Oct 08. Changed. added grp:, dvorak layout
# SkbModel was "pc105". New one selected from bast.lst
    Identifier "Keyboard0"
    Driver      "kbd"
    Option        "XkbModel" "microsoft"
    Option        "XkbLayout" "gb,dvorak"
    Option      "XkbOptions"    "grp:alt_shift_toggle"
EndSection

through to file gb, 'variant' (if that's the right word) ?

How can I find out what values are 'valid' within an Option?

Any documentation appropriate to Fedora / Redhat would be appreciated.

Second, I'm using a variant of the microsoft 'natural' keyboard.
Marked 'natural ergonomic keyboard 4000'

$xkbprint $DISPLAY keyboard.ps

Seems not to have this model in it's repertoire.

Is there any way I could contribute this?

TIA DaveP
www.dpawson.co.uk

Business as usual: pre-release freeze in xkeyboard-config

duke_igthorn — Tue, 16 Sep 2008 16:55:44 GMT

Yesterday I've committed last changes to the project before the pre-release freeze. The POT file is sent to the Translation Project. No more new models/layouts/variants/options, just bugfixes - till 29.09.

one more time about RMLVO

duke_igthorn — Fri, 12 Sep 2008 09:57:18 GMT

There is an interesting blog post once again explaining some details of the XKB internals. It does not go too deep, does not touch "dark corners", but can be a good starting point. Highly recommended.

ISO codes: request for review

duke_igthorn — Mon, 21 Apr 2008 11:33:29 GMT

TWIMC

Please help reviewing the ISO codes, submit bugs either here or in fd.o bugzilla. Thanks, thanks, thanks.

Xkb and Combining Characters

thinfox — Thu, 06 Mar 2008 23:40:09 GMT

I need to implement keyboard layouts for several african languages, some with complex tonal marks: acute, grave, grave with dot below, acute with dot below (these are the ones i know now, but there may be others). many of these characters do not have unicode code points of their own but they can be represented using combining diacritical marks: ie S with acute and dot below is S + U+0300 U+0323 - this is what i understand but i may be wrong so please correct me.
My question is how do you implement such solution on linux? looking at the Compose file for en_US.utf8 it seems composing sequence characters can only be mapped to another unicode code point: eg. <Multi_Key> <U10001100> <U10001100> : "'' " U1101
How do you compose keys with multi_key or dead keys that emit more than one code point?
Can this be implemented in the xkb keyboard layout/variant file? if so, how?

Thanks
Chris

kean — Thu, 13 Dec 2007 04:29:36 GMT

Where should I put geometry for IBM ThinkPad Z60m, to geometry/thinkpad or geometry/lenovo? Or some other place?
And how should be model named? Currently I choose thinkpadz60m, but this geometry also applies to most of 60/61 series (as I can see on photos).

The rules to follow...

duke_igthorn — Sat, 15 Sep 2007 23:18:47 GMT

These days a lot of people contribute new layouts/variants/models to xkeyboard-config. Usually it is done through the freedesktop.org's bugzilla. Quite often that contributed code requires manual "polishing" which would be unnecessary if authors would follow some simple rules. Till today, they really could not be blamed - because these rules existed only in my head. Now, these rules are published. So do not tell me you were not warned ;)

PS I still highly appreciate every contribution to the project. I just would like to make my life a bit easier. Thanks for understanding.

grp:ctrl_shift_toggle and other hotkeys starting with ctrl+shift

linx56 — Sat, 15 Sep 2007 13:02:53 GMT

When enabled group changing for ctrl+shift other hotkeys such ctrl+shift+left stop working...

Does anybody know a solution for this problem?

... libwhat?

duke_igthorn — Mon, 09 Apr 2007 17:23:55 GMT

There is probably a bit too many libraries related to the keyboard - in X Window System in general, and GNOME in particular. In order to explain their not-too-complex relationships and their places in the whole puzzle, I am giving some short reference here.

libxkbfile

Language: C
Licence: X11
Bugzilla: Xorg

Strictly speaking, this library does not exist. Well, technically it does - but it was never meant to be public. Well, unfortunately it is de facto public now - for a long while. Why? Because there are several things in XKB which have never got proper network-transparent solution. In particular - dealing with keyboard configuration in terms of rules/models/layouts/variants/options (RMLVO). In the reference X Window System implementation, libxkbfile is handling RMLVO. It was originally designed as internal library linked to X server and several command line utilities like xkbcomp and setxkbmap. It was never network-transparent, it works with local keyboard configuration database files directly - which means it cannot properly support with remote X server (except for special environments using NFS etc).

This is one of many dark corners of X - the library which should not be used by anything but X implementation internally - but it is actually used quite often.

This library is installed as a part of standard Xorg or XFree86 installation.

Commercial implementations of X may be shipped without this library. Or have this library broken. Or have XKB implementation which does not use this library. All these scenarios create a lot of troubles for "bad" (from X Window architecture POV) applications using it. The authors of these applications usually realize this fact - but they have no choice (the only alternative for them is some kind of functional regression).
In the long run, the applications will use new version of XKB protocol which would provide network-transparent solution. But for the "old" servers, they'd have to link to libxkbfile for many years to come.

libxklavier

Language: C
Licence: LGPL
Bugzilla: none

This library was created in attempt to generalize (and make environment-independent) the code dealing with XKB, from the GNOME keyboard indicator applet. It contains a lot of utility code for accessing the keyboard configuration in terms of RMLVO, tracking the keyboard state etc. Its purpose is to provide a foundation for applications like keyboard layout indicators and monitors, keyboard configurators, layout-aware window managers etc.

Initially the library depended on X Window and libxml2 APIs only. Later (during the GNOME 2.15 release cycle), it was ported to gobject-based architecture.

Currently, it is used in production in GNOME only - but it is also used in ongoing KDE4 development (as optional dependency).

The library uses libxkbfile internally, it also accesses keyboard configuration registry file locally. This makes applications using it "bad citizens" in X Window world (there is standing bug report in GNOME bugzilla). Once new version of XKB is provided, the network transparency is going to be restored (for conformant X servers).

The compatibility with original X Window keyboard handling ("xmodmap") is maintained but with low priority.

libgnomekbd

Language: C
Licence: LGPL
Bugzilla: GNOME

The internal GNOME library emerged from two virtual modules in GNOME CVS: libgswitchit and libkbdraw. The merger was performed during 2.17 development cycle, the original modules were immediately declared deprecated. The library contains GNOME code related to the keyboard: keyboard indicator widget (including plugin management), keyboard drawing widget, saving/loading configuration to GConf etc.

XKB and GTK shortcuts

michaelbaranov — Sat, 09 Dec 2006 13:05:24 GMT

Greetings!

I'm new to the community and, as all newbies, I'm seeking answers ;-)

My biggest problem after migration from Windpws to Linux was the keyboard in GTK-based GUI applications (Eclipse, Firefox). The problems is that while in non-latin group (for me it's 'ru'), key combinations with CTRL and ALT do not work correctly. I get CTRL+Я instead of CTRL+Z ...

Some people on the net say it's a bug in GTK, some say it's a trouble of each of the GTK-based applications. All I know it that it renders those applications barely useful!

I was wondering if there exists a pure XKB solution? The basic idea is to use latin letter if Control or Alt (Mod1) are present. What about xmodmap?

Thanks!

Keyboard configuration UI (not too GNOME-specific)

duke_igthorn — Sat, 12 Aug 2006 22:01:55 GMT

There is an interesting discussion here:

Again, layouts, countries, languages - what would be the most usable representation for the user. Everyone is welcome with ideas and comments.

IRC meeting regarding the keyboard (slightly GNOME-specific)

duke_igthorn — Sat, 08 Jul 2006 00:59:20 GMT

Yesterday, there was an interesting meeting on IRC regarding the input methods. Here is its log. Big thanks to everyone.

setting layout per application

jdevelop — Thu, 27 Apr 2006 07:02:50 GMT

Hello! I heard it is possible to configure xkb to serve keyboard layout for each application, so for example i can type in russian in browser and keep typing in english in xterm without switching between locales each time i switch to another window.

XKB: The Way To Be

duke_igthorn — Sun, 05 Mar 2006 03:39:22 GMT

Daniel Stone made an excellent presentation on XKB. Strongly recommended.

xkb directions and feature-removing changes

dottedmag — Sun, 29 Jan 2006 13:33:12 GMT

XKB configs seems to be very flexible (and arcane, too, of course) system. I deduced from the different sources (such as this community, and Keith Packard's papers) that it's very possible to have this system redesigned and wonder, won't the resulting system will be less flexible than current (as GNOME folks do, removing features as "confusing").

If the question is too wide, I might narrow it: is there active effort in redesigning xkb, and if it is, is there way to suggest particular features which should be supported in the result: I have the xkb config written nearly from scratch (due to the fact I was unable to figure out how to compose and tweak existing layouts to make it work exactly as I wanted), and it will be very frustrating if I unable to tweak future configuration to resemble my current settings.

Compose map for SuSE/KDE

pbw — Sun, 29 Jan 2006 11:13:47 GMT

My keyboard configuration in SuSE 10.0, using KDE, is missing the composition of 'v' with upper and lower case 's' and 'z' (s and z with caron), and no doubt others. My locale is en_US.UTF-8. These characters are available at the VT consoles (although there is a long-term problem with the flakness of compose in the consoles), but not in KDE.

Can I access the compose mappings? If so, how?

Keyboard configuration in GNOME

simosx — Sat, 28 Jan 2006 17:40:44 GMT

It is very encouraging that the keyboard configuration in GNOME works rather seamlessly, for the languages that the X Input Method is suitable to use. For example, to get a stock installation of Ubuntu Linux 5.10 to support both US English and Brazilian Portuguese, simply follow the steps at
How to enable US English and Brazilian Portuguese in GNOME

Still, there are some users that either encounter bugs in the X Input Method or simply stumble upon usability issues in the applet, and need extra support.
I envision the work carried out in the keyboard applet will solve these issues and will be able to be used collectively as the single point of reference for end-users to set/configure the input methods for their languages.

libxklavier: to glib or not to glib? Part 2

duke_igthorn — Sat, 28 Jan 2006 14:14:31 GMT

After yesterday's discussion on IRC, we found that actually we have 3 options for introducing complex data structures to libxklavier:
1. Add dependency on glib.
Pros:
glib is an actively maintained library
glib, properly used, has a lot of cross-platform functions which can be used
Cons:
KDE people do not like the idea of having dependency on glib. Though some optional software has already introduced that dependency
2. Add dependency on "independent" (neither G nor K) 3rd party C library (with compatible licence).
Pros:
Both G and K people will be happy
Cons:
We need to find something reliable, stable and licence-compatible
3. Create own data structures
Pros:
Minimal footprint, only necessary stuff etc etc
Cons:
Some major effort. New series of bug would be introduced. Overall - looks just another NIH-syndrom thingie...

My personal preferences:
#1, #2, #3.

XKB configuration

pbw — Tue, 24 Jan 2006 23:20:40 GMT

I haven't looked into the code for xkbcomp, so much I this will be speculation. Some things I know.

The XKB configuration system is irretrievably arcane. The semanatics of the XKB configuration files is, to the casual user who wants to implement their new keyboard, incomprehensible.

I first attempted this in 2000 for a Dell laptop with a GB keyboard. I managed to get something working, and to retain my sanity. I've ventured in a few times since, most recently to generate a keyboard for a ThinkPad G41. I managed by replacing all of the relevant configuration files with new, minimal versions designed around the thinkpad, and had this working in Gentoo. However, when I switched to SuSE, any attempt to invoke my keyboard files resulted in the complete loss of keyboard function.

What it seems to me is required is the rewriting of the whole of the configuration database in terms that the casual keyboard configurer can comprehend. Start from the output of xkbcomp and work back, developing a consistent way of expressing and redefining key values. Keep it as simple as possible. Write it in a higher level language. For defining a keyboard, computing efficiency is not a priority. Sort out performance issues afterwards., remembering that the vast majority of users are getting their X keyboard services from their own desktop.

I don't know wheter this approach is feasible, but I do know that a radical redesign of configuration is needed.