What do you mean? Where do you need to type to get this? Does it happen with applications too? Are you sure your keyboard is correct?

Steps to reproduce:
1. turn on-screen keyboard on in the accessibility menu.
2. click some text area/field and the on-screen keyboard pops up.
3. switch to the layout with number (clicking the "123" key)
4. click '|' key

What I get (what is typed/shown) in a text area/field is this: '<' instead of this: '|'

Tested in Terminal, gedit, and GNOME Shell (search in Activities overview).

I haven't changed anything. It's completely default settings in Fedora 17 liveCD (default language - English, default on-screen keyboard layout).

It works as expected in Fedora 16 and GNOME 3.2.

Ah, OK, the lacking keyword was "onscreen keyboard".

I can reproduce, but I can't figure out why. My best guess is that it's in GDK, but I'm not sure.

Created attachment 212122 [details] [review]
patch

I think this is a bug of libcaribou.  When looking up keycode by keysym, libcaribou does not expect levels over 1, while "|" may be generated with keycode(94) + ISO_Level3_Shift (aka AltGr) on US keyboards.

The attached patch simply ignores such a keymap entry (which will cause remapping).

Maybe bug 668506 is the same issue.

*** Bug 668506 has been marked as a duplicate of this bug. ***

Any chance that the patch will get review?  Though I wrote "... will cause remapping" in comment 5, it turned out not the case because "|" can also be generated with keycode(51) + Shift on pc104 layout:

$ cat > test-kmk.c
#include <gtk/gtk.h>
#include <gdk/gdkx.h>

int
main (int argc, char **argv)
{
  GdkKeymap *keymap;
  GdkKeymapKey *keys, *best_match = NULL;
  gint n_keys, i;

  gtk_init (&argc, &argv);

  keymap = gdk_keymap_get_default ();

  if (!gdk_keymap_get_entries_for_keyval (keymap, GDK_KEY_bar, &keys, &n_keys))
    return 1;

  for (i = 0; i < n_keys; i++)
    g_print ("keycode = %u, group = %d, level = %d\n",
             keys[i].keycode, keys[i].group, keys[i].level);
  
  return 0;
}
^D
$ gcc -o test-kmk test-kmk.c `pkg-config gtk+-x11-3.0 --cflags --libs`
$ ./test-kmk
keycode = 51, group = 0, level = 1
keycode = 94, group = 0, level = 2
$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

It looks like this is a caribou issue (at least that's what the proposed patch assumes), so reassigning ...

I confirm this problem... A big problem for anyone who use the command line for not be able to use the "pipe".

Perhaps the status should be changed to confirmed ?

Review of attachment 212122 [details] [review]:

This looks good. Sorry nobody reviewed this earlier.

Comment on attachment 212122 [details] [review]
patch

Thanks!

*** Bug 686617 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> *** Bug 686617 has been marked as a duplicate of this bug. ***

Are you sure it's the same bug? Because I reported both. While the bug #673579 is fixed on my machine, the bug #686617 is not.

(In reply to comment #14)
> (In reply to comment #13)
> > *** Bug 686617 has been marked as a duplicate of this bug. ***
> 
> Are you sure it's the same bug? Because I reported both. While the bug #673579
> is fixed on my machine, the bug #686617 is not.

That's strange.  What keycode does xev report when you push "/"?

On my machine, it reports keycode = 94, which actually have "/" on the 3rd level.
(after reverting 348c91015fac1b086abe8a950987835943172e60 and 0e34f29f73c80034882db6547f99313f6a29ad65 for testing)

I get this (the first is one "/" on the keyboard, the second is the other "/" because there are currently two such keys on my onscreen keyboard):

KeyRelease event, serial 32, synthetic NO, window 0x3000001,
    root 0xc6, subw 0x0, time 14129242, (656,760), root:(1938,871),
    state 0x10, keycode 94 (keysym 0x5c, backslash), same_screen YES,
    XLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3000001,
    root 0xc6, subw 0x0, time 14141449, (945,840), root:(2227,951),
    state 0x10, keycode 94 (keysym 0x5c, backslash), same_screen YES,
    XLookupString gives 1 bytes: (5c) "\"
    XmbLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

The "|" key is now correctly mapped on my machine.

(In reply to comment #16)

> KeyPress event, serial 33, synthetic NO, window 0x3000001,
>     root 0xc6, subw 0x0, time 14141449, (945,840), root:(2227,951),
>     state 0x10, keycode 94 (keysym 0x5c, backslash), same_screen YES,
>     XLookupString gives 1 bytes: (5c) "\"
>     XmbLookupString gives 1 bytes: (5c) "\"
>     XFilterEvent returns: False

Thanks.  Assuming that you are trying with the latest git master a8fb1d8fba1e9557a3370edd62501f0a866c6774, it seems Caribou detects 0x10 (MOD2) as level3 shift but it is not working.

Could you run the attached program and tell me the result?

Created attachment 228223 [details]
test program to check lv3 modifiers

Jiri, any update on comment 17?