Bug 158713

Mark, do you know what happened here? Is there perhaps a simple fix?

Thanks,
David

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
    c-cedilla event

  - 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
in behaviour.

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
recent past.

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
Multi_key(0xff20) keysym.

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]
test-xtest.c

Could you also try the attached test program on the server - e.g. to test it in
emacs do

  $> 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-2.11.1.2-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 <markmc> 2.12.0-2
- Add patch from Alexandre Oliva <oliva.unicamp.br> to fix
  more keyboard brokeness (#158713)

Confirmed, it works, thanks,

Okay, FC4 update (vino-2.10.0-4.1) pushed:

  http://www.redhat.com/archives/fedora-announce-list/2005-September/msg00118.html