Red Hat Bugzilla – Bug 158713
vino breaks Right-Alt (ISO_Level3_Shift) + comma => dead_cedilla
Last modified: 2013-03-05 22:43:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050512 Fedora/1.0.4-2 Firefox/1.0.4
Description of problem:
The vino update that recently made to rawhide broke my ability to compose comma with letter `c' to generate the c-cedilla character, extremely common in Portuguese but impossible to generate otherwise in a US keyboard. (pt_BR keyboards have a key for c-cedilla, but this layout is not available in imported notebooks :-/
I have the right alt key configured to be the X compose key, using the us-intl keyboard layout, that enables dead keys for accents and tilde, but not for cedilla, so one has to use X compose sequences to generate c-cedilla.
I can see with xev that the event generated when I press and release the right-alt key is the same when I'm connected to the rawhide-running vnc server and run xev on it, and when I disconnect and run xev on the vnc client.
The X event generated when I press comma, however, is different. On the vino-running host, it's a single comma character, whereas on the disconnected client it's a pair of non-ASCII characters, presumably corresponding to dead_cedilla. The even generated by depressing the c key afterwards is, oddly, the same in both cases, AFAICT. However, if I try to enter a c-cedilla on Firefox or Emacs running on the vnc server host, by pressing the compose comma c sequence on the vncviewer-connected client, it generates a comma as soon as I press the comma, and then an unadorned c when I press the c letter. If I do so on the disconnected client, it generates the expected c-cedilla. Also, if I press this key sequence on the vnc server (i.e., on its console, not through vncviewer), c-cedilla can also be generated.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Connect vncviewer on a rawhide box with us-intl keyboard with a vino server on another rawhide box with us-intl keyboard
2.Enter Compose comma c
Actual Results: You get comma c
Expected Results: You should get c-cedilla
This is a regression from a few days ago, and a major stumbling block for Portuguese users.
Mark, do you know what happened here? Is there perhaps a simple fix?
Okay, I've taken a good long look at this and observed the following. Writing it
all down for future reference ...
- This is all related to XKB. To setup right-alt as the compose key,
go to Preferences->Keyboard->Layout Options->compose
- I haven't looked in enough detail, but what seems to happen is when
you do the right-alt, comma, c sequence, the client gets a series of
key events multi-key, comma, c, c-cedilla
- It seems that if the client knows how to interpret them (an XKB input
method or something?), XFilterEvent() will return True for all but the
- Now, it seems vncviewer makes no attempt to interpret these events
and just sends the multi-key, comma, c sequence
- When right-alt isn't configured as the compose key on the server side,
vncviewer just gets iso-level3-shift, comma, c and dutifully sends that
on to the server
- So, Vino either gets multi, comma, c or level3-shift, comma, c depending
on how the client is configured
- It seems the only way to get the Xserver to generate the c-cedilla event
using XTest is if the Xserver is configured to use right-alt as compose
and you inject the multi, comma, c sequence
All that leads me to believe that Vino can't really do anything more than its
doing already and the only way you can get this to work is if you set up
right-alt as compose on both the client *and* the server.
I've also tested all the combinations - with/without that configuration on the
server/client and with/without the recent fixes - and I don't see any difference
Closing, but please re-open if setting up right-alt as compose on both the
server and client doesn't work for you. Thanks
Err... It *is* set up as compose on both ends, and I think I wrote (or at least
implied) that in the report. Besides, I didn't use xkb at all, this was set up
with the very method you told me to use. And, worse, it worked just fine up to
a week ago, and it broke at about the same time the latest vino build hit
rawhide. So, I don't see why it couldn't do better, since it did in the very
To be fair, I'm not sure the R-Alt is compose setting applies to the client,
that's running a fail-safe session, not a full gnome session like the server, so
perhaps that's just the default setting for us-intl but, again, this worked just
fine about a week ago.
> Besides, I didn't use xkb at all, this was set up with the very method you
> told me to use.
Just to be sure, you're saying you set up the compose key in Preferences ->
Keyboard -> Layout Options ?
If so, that's what I'd presumed. I was just noting to myself above that this
setting is an XKB setting. Sorry for the confusion.
> And, worse, it worked just fine up to a week ago, and it broke at about the
> same time the latest vino build hit rawhide.
I tried hard to reproduce any difference in the behaviour of both versions with
c-cedilla and I couldn't find anything. I'm not going to be able to do anything
until I can reproduce that.
> To be fair, I'm not sure the R-Alt is compose setting applies to the client,
> that's running a fail-safe session, not a full gnome session like the server
Do you mean you're running vncviewer on the client in a fail-safe session?
If so, then the the compose setting is not being applied on the client side and
the client is sending the ISO_Level3_Shift(0xfe03) keysym rather than the
You can confirm this by running xev in the failsafe session on the client.
Now, my testing showed that Vino couldn't handle this situation before or after
the recent fixes. Perhaps I'm wrong, I'll look at it again.
oliva: could you confirm what keysym you get in xev in the failsafe terminal
when you press right-alt?
Created attachment 114904 [details]
Could you also try the attached test program on the server - e.g. to test it in
$> sleep 3 && ./test-xtest
and switch to emacs.
You should also try it with --use-multi.
ISO_Level3_Shift(0xfe03) is what I get on the client, running vncviewer
connected to the server or not. Unfortunately, I'm away from home atm, so I
can't confirm what I get while sitting at the server, nor can I run further
tests. I'll be back tomorrow evening.
It was the Server Layout option that I used to configure RAlt as Compose on the
server, and the client has the same settings in gnome, but I don't know whether
that applies to the fail-safe session. Anyhow, it is possible that us_intl in
xorg.conf enables that by default. Here are my keyboard settings in xorg.conf,
both on client and server:
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl"
I'll run the tests you requested on Sunday, after I get back home and get
physical access to the server and the client again.
As it turned out, right-alt was not mapped to Multi-Key on either box.
Right-Alt was ISO_Level3_Shift that, along with comma, generated a dead_cedilla,
which, followed by the letter c, generated a Ã§. This works on both server and
client X clients, but not when the client is connected to the server over vnc.
Sorry about the confusion, I *know* I had this setting at some point, but some
rawhide update must have disabled it or something.
Still broken in FC4, as well as rawhide (vino-188.8.131.52-1).
It also breaks ISO_Level3_Shift e as a means to generate the Euro character.
Created attachment 118375 [details]
Patch that fixes the bug
This was broken with the patch for bug 134451. It missed the ISO shift keys,
that are not in the standard shift range.
The attached patch fixes the bug when applied on 2.11.90-2, but it should apply
on the FC4 vino as well, if not immediately, at least without any significant
effort. An update for FC4 would be extremely desirable IMHO, since this bug is
a big regression for those who actually depend on ISO_Level3_Shift.
Could you please integrate the patch and push it upstream?
Thanks in advance,
Bug still present in 2.12.0-1, in Fedora devel. I suppose I posted it too late,
but I thought I'd point out that the fix did not make to Gnome 2.12.
Alexandre: I've committed your patch upstream and to rawhide. Could you verify
the rawhide package fixes your problem and I'll push an FC4 update when you confirm?
* Mon Sep 26 2005 Mark McLoughlin <firstname.lastname@example.org> 2.12.0-2
- Add patch from Alexandre Oliva <email@example.com> to fix
more keyboard brokeness (#158713)
Confirmed, it works, thanks,
Okay, FC4 update (vino-2.10.0-4.1) pushed: