Bug 400520

I can somewhat reproduce this. In xev I get (keysym 0x0, NoSymbol) for the umlauts. The reason is that by default us keyboard layout is used.

# setxkbmap -print
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us" };
        xkb_geometry  { include "pc(pc105)"     };
};

After switching to german the umlauts work again.

--> setxkbmap "de(nodeadkeys)"

The VNC Server on 10.3 didn't support the XKB extension. Therefore you didn't run into this problem. Disabling XKB extension in Xvnc ("-kb") makes the situation worse. So this is not an option. Desktops like KDE/Gnome have frontends for keyboard configuration via XKB, so I don't think this is a big deal. Otherwise use setxkbmap.

Does this help?

Martin?

sorry, made some other tests ...

Yes, this helps, but well, this is not good at all. If you see no other option i will write an SDB article about it.

btw: windows -> linux crashes the server, let me look into it a little bit more and i open a new bug. Seems that there is some work needed anyway :-)

Unfortunately I don't see another option at the moment. Reassigning to you and lower severity for the SDB article. IIRC I've already got a report for the Xvnc crash when using a Windows VNC client. But since I don't have access to Windows
I closed it (Bug #390468).

setxkbmap is not really working, i have umlauts, but <,- or ß are still on the wrong place. 

The KDE quickselector for language is even worse, it allows me only to use uppercase umlauts, the above error is also there.

 

(In reply to comment #5 from Martin Lasarsch)
> setxkbmap is not really working, i have umlauts, but <,- or ß are still on
> the wrong place. 

I can reproduce this.

Any update on this? I really need a working VNC with a complete and correct German keyboard layout.

No difference with xorg-x11-Xvnc from STABLE^WFACTORY, by the way.

As apparently nobody upstream (i.e., x.org and tightvnc projects) cares about fixing Xvnc / vncserver for non-US keyboards: Xvfb and x11vnc can be an alternative in some cases. Xvfb lacks most X11 extensions, but that's definitely better than a totally unusable keyboard. Plus, x11vnc implements clipboard communication, vncserver does not.

My experience is that when using the same keyboard layout on Xvnc and on the Xserver on the local machine (set it with setxkbmap) you don't run into such
issues. But this is with Linux on both sides.

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

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

(In reply to comment #11)
> My experience is that when using the same keyboard layout on Xvnc and on the
> Xserver on the local machine (set it with setxkbmap) you don't run into such
> issues. But this is with Linux on both sides.

OK I adjusted the keyboard layouts on my KDE3 system by setxkbmap, but the remote session remained unaware of caps lock. (I use openSUSE 11.1)


I suspect that it's not even a bug in Xvnc, but in the display managers (kdm/gdm) and desktop environments in some way, because the keyboard layout behaves differently before login:

-With kdm, the initial screen (running kdm) handles the keyboard layout almost correctly The only problem is that after pressing any accentuated character, that accentuated character will be the only working accentuated character. All the other accentuated characters become disfunctional.

-With gdm the accentuated characters work without problems.

-With kdm, caps lock changes between upper/lowercase letters, but kdm does not give any warning popup message about the state of caps lock.

-gdm cat detect the state of caps lock, so it send warning messages, but caps lock cannot make letters upper/lowercase.



In addition to this, I realized, that KDE keyboard layout management cannot be used to do the workaround by setxkbmap. Maybe it calls setxkbmap with wrong options. How can I extract the keyboard layout informations (injected by setxkbmap) from the running X server?

BTW, everything worked fine in openSUSE 10.3. Does it use xf4vnc like openSUSE 11.0 ans 11.1?

kdm/gdm issues need to be handled seperately in a different bugreport. 

openSUSE 10.3 was using a different VNC implementation. Seperate package xorg-x11-Xvnc instead of a patch for X.Org. But I'm happy we're back to xf4vnc.

New experiences. If I configure xinetd to call Xvnc with the -kb option (disable the X Keyboard Extension) then even after logging in, KDE will behave identically as before the login. I don't exactly know what XKB is, but can you imagine that this XKB thing gets activated during the login process? If so, then it's probably not a KDE/GNOME bug. In addition I tested it with xdm (without kdm), and it behaved the same way.

Other peaple also had problems with XKB:
http://sourceforge.net/tracker/index.php?func=detail&aid=1174414&group_id=48178&atid=452220

And keyboard layouts, too:
http://sourceforge.net/tracker/index.php?func=detail&aid=979091&group_id=48178&atid=452220


So, when I disable XKB, than apart from that KDE will not show its keyboard layout indicator, the keyboard will behave correctly, except that I will have only one accentuated character, so I must carefully choose ;) (Remember this:
With kdm, the initial screen (running kdm) handles the keyboard layout almost
correctly The only problem is that after pressing any accentuated character,
that accentuated character will be the only working accentuated character. All
the other accentuated characters become disfunctional.)

Disabling XDM even makes caps lock work correctly after logging in. Moreover, if I change the layout on my local machine, the remote machine correctly follows it. Changing to US layout gives a FULLY FUNCTIONAL (although american) keyboard to the remote desktop.


So, it seems to me that XKB in Xvnc is quite severely broken, but Xvnc without XKB (called with the -kb option only has a minor, but very annoying bug).


BTW, I've get Xvnc to write some logs into a file following these instructions:
"Create the directory /usr/adm and chmod adm so that the user nobody will have write permission. Xvnc started with -inetd option will create logs there. "
But that didn't help me.

(In reply to comment #11)
> My experience is that when using the same keyboard layout on Xvnc and on the
> Xserver on the local machine (set it with setxkbmap) you don't run into such
> issues. But this is with Linux on both sides.

It seems to me, like it's better to set the local machine's layout to US, and the remote machine's layout to the physical layout of the local machine (HU in my case).

BTW, I realized, that the Xvnc version of openSUSE10.3 doesn't let KDE to enable keyboard layout. It makes me think that that Xvnc totally lacks this XKB thing. One more reason to disable it?

(In reply to comment #15)
> But I'm happy we're back to xf4vnc.

But why? In practice I cannot use any other keyboard layout than US english, and in addition, tight encoding is also broken, so I cannot use krdc as a client. The current Xvnc server of openSUSE lacks some very important features, to the extent that it's almost unusable for me (and I think for many other users, too).

> > But I'm happy we're back to xf4vnc.
> But why?

Because it's a maintenance nightmare to do security updates for an additional X tree.

(In reply to comment #19)
> > > But I'm happy we're back to xf4vnc.
> > But why?
> 
> Because it's a maintenance nightmare to do security updates for an additional X
> tree.

I accept your point of view, but it makes openSUSE rather a technological testbed instead of the world's most usable Linux. However, I admit that I should either contribute more or change to SLED to improve my situation, so I don't really complain. Anyway, thank you for your efforts.

Well, I would assume that SLED10/SLED11 suffer from the same issue. Both use xf4vnc.

(In reply to comment #21)
> Well, I would assume that SLED10/SLED11 suffer from the same issue. Both use
> xf4vnc.

I wanted to test SLES 11, so I downloaded a 32 bit evaluation version, and installed it with KDE, but I when I connected to its TCP port 5901, I got nothing else but the default black and white grid of the X server, no kdm. Anyway, that grid wasn't distorted in color at least...

This is unrelated to the initial issue and possibly a user configuration error (remote administration not enabled?) or bug in kdm(3/4).

Created attachment 285273 [details]
kdm4

I know, that it's unrelated, but it prevented me from testing the original subject. I found this. I give it up for now, and I will continue next week. Frohe Ostern!

Dear Stefan!

I realized that removing the "-from localhost" option from the server_args list in the /etc/xinetd.d/vnc file (like in openSUSE11.1) solves the problem mentioned in comment #22. Separate bugreport?

In addition to this, adding the "-kb" option in the same place improves (but still leaves umlauts unusable) the behaviour described by this bugreport (see comment #16).

In addition to this, using bgr233 format solves https://bugzilla.novell.com/show_bug.cgi?id=469734 .

Sorry, I've forgotten to mention, that SLES11 is also effected by this this bug, and by https://bugzilla.novell.com/show_bug.cgi?id=469734 , too. (And SLES also has the additional problem mentioned in comments #22 and #25). Why "Enterprise", then?

(In reply to comment #25)
> I realized that removing the "-from localhost" option from the server_args list
> in the /etc/xinetd.d/vnc file (like in openSUSE11.1) solves the problem
> mentioned in comment #22. Separate bugreport?

Already tracked in Bug #462283.

> In addition to this, using bgr233 format solves
> https://bugzilla.novell.com/show_bug.cgi?id=469734 .

Probably when specifying '-bgr233' the broken jpeg compression in tight encoding is no longer used or something similar.

As far as I understand it, the root cause for this problem is
that there are two keyboard devices in Xvnc now, an id=0
"Virtual core keyboard" and an id=2 VNC XExtensionKeyboard.

Keycodes for the umlaut keys are dynamically added to
the id=2 XExtensionKeyboard, but the gui applications
use the keysym mapping table from the id=0
"Virtual core keyboard".


$ xinput list
"Virtual core keyboard" id=0    [XKeyboard]
        Num_keys is 248
        Min_keycode is 8
        Max_keycode is 255
"Virtual core pointer"  id=1    [XPointer]
        Num_buttons is 32
        Num_axes is 2
        Mode is Relative
        Motion_buffer is 256
        Axis 0 :
                Min_value is 0
                Max_value is -1
                Resolution is 0
        Axis 1 :
                Min_value is 0
                Max_value is -1
                Resolution is 0
""      id=2    [XExtensionKeyboard]
        Num_keys is 248
        Min_keycode is 8
        Max_keycode is 255
""      id=3    [XExtensionPointer]
        Num_buttons is 5
        Num_axes is 2
        Mode is Relative
        Motion_buffer is 8
        Axis 0 :
                Min_value is 0
                Max_value is -1
                Resolution is 0
        Axis 1 :
                Min_value is 0
                Max_value is -1
                Resolution is 0


A possible fix is to change Xvnc file hw/vnc/kbdptr.c
function KbdAddEvent() to use "inputInfo.keyboard"
(= id0 core keyboard) instead of "kbdDevice"
(= id2 VNC keyboard).  That way the new dynamically
added keycode/keysyms entries for the umlaut keys
are seen by X clients.

With such a fixed applied to the opensuse 11.1 Xvnc 
server the umlaut keys start to work.

Since you have it already running. Any chance to provide a patch for the openSUSE community?

I do not have a proper patch.

What I've been doing is unpack the xorg-x11-server-7.4-17.4.1.src.rpm
with "unrpm", change the xorg-server-xf4vnc.patch file
and use the "build" command to compile everything.

You have working sources, so it should be trivial to create a patch, right?

Created attachment 292659 [details]
Xvnc patch to add dynamically allocated keycodes to the core keyboard's mapping

I'm not a linux rpm expert, I hope the attached patch is in a usable format.

Perfect. Thanks!

I've added the patch now to obs://X11:XOrg/sle11. New xorg-x11-server packages should be available shortly via

  http://download.opensuse.org/repositories/X11:/XOrg:/sle11/

Build date is May 18 or later. RPM changelog:

* Mon May 18 2009 sndirsch@suse.de
- xorg-server-xf4vnc-keyboard.diff
  * add dynamically allocated keycodes to the core keyboard's
  mapping (Jürgen Keil, bnc #400520)

Joerg, Herve, Tamás, could you give it a try?

(In reply to comment #34)
> I've added the patch now to obs://X11:XOrg/sle11. New xorg-x11-server packages
> should be available shortly via
> 
>   http://download.opensuse.org/repositories/X11:/XOrg:/sle11/
> 
> Build date is May 18 or later. RPM changelog:
> 
> * Mon May 18 2009 sndirsch@suse.de
> - xorg-server-xf4vnc-keyboard.diff
>   * add dynamically allocated keycodes to the core keyboard's
>   mapping (Jürgen Keil, bnc #400520)
> 
> Joerg, Herve, Tamás, could you give it a try?

OK, I've tried it. My experiences are the following:

It is definitely better, but enabled  X keyboard extensions + changing keyboard layout in the Xvnc server can still confuse these dynamically allocated keycodes. I have X keyboard extensions enabled in KDE and my default layout is not US English, which can lead to some keycode confusion.

However, if I use this patch AND disable X keyboard extensions (I issue the '-kb' option for every Xvnc server instance in /etc/xinetd.d/vnc), then Xvnc becomes almost perfect. The only problem was that the the ő,Ő,ű and Ű characters didn't work when I used UltraVNC from windows. It may relate to the fact that ő,Ő,ű and Ű character are somehow different in iso-8859-2, iso-8859-1 and in windows-1250. Vncclient on Linux works perfectly.

To sum up again: this patch anf the '-kb' option in /etc/xinetd.d/vnc TOGETHER makes the keyboard handling of this Xvnc ALMOST perfect. I suggest to use both.

Thanks for the feedback, Tamás.

Some questions:

-When I press a key in the VNC client, it will send some code to the Xvnc server, right? So, what is this code exactly? Is it closer to the code (e.g. UTF-8) of the character in my actual keyboard layout (i.e. hungarian-104 or what), or is it closer to the code of the key itself (scancode or keycode as shown by showkey)?

-Does the Xvnc know the actual X server keyboard layout used on the machine running vncviewer?

-What information does vncviewer get when the user presses a key? Keycode or character code? (See my first question.)

-When Xvnc starts up, what keyboard layout does it use? My system default read from /etc/X11/xorg.conf, or us-english? (If it uses us-english, the starting desktop environment (i.e. KDE) will force it to change to hungarian, because XKB is enablend both in Xvnc (unless I disable it) and in KDE.) As I said before, this layout change may confuse the dinamically added keycodes.



Knowing the answers for all of these questions, what do you think? Isn't it dangerous to create an Xvnc server which supports XKB (and thus keyboard layout changing) and dinamically creates keycodes?

(In reply to comment #37)

> -When I press a key in the VNC client, it will send some code to the Xvnc
> server, right? So, what is this code exactly? Is it closer to the code (e.g.
> UTF-8) of the character in my actual keyboard layout (i.e. hungarian-104 or
> what), or is it closer to the code of the key itself (scancode or keycode as
> shown by showkey)?

The viewer sends X keysyms.

Xvnc has an internal US layout keysym<->keycode mapping table.

I case the keysym received from the viewer is found in the US english
layout mapping table, the keycode from that table is used. Otherwise a
new keycode is dynamically allocated for the unknown keysym and added
to table.  Keycodes are allocated by looking for empty mapping entries,
starting from 255 and going down.

> -Does the Xvnc know the actual X server keyboard layout used on the machine
> running vncviewer?

AFAIK: No.


> -What information does vncviewer get when the user presses a key? Keycode or
> character code? (See my first question.)
> 
> -When Xvnc starts up, what keyboard layout does it use?

Should be US english layout. (The Xvnc hardcoded US english layout map)


> My system default read
> from /etc/X11/xorg.conf, or us-english?

I think /etc/X11/xorg.conf should be ignored by Xvnc.


> (If it uses us-english, the starting
> desktop environment (i.e. KDE) will force it to change to hungarian, because
> XKB is enablend both in Xvnc (unless I disable it) and in KDE.) As I said
> before, this layout change may confuse the dinamically added keycodes.


I think it's best when the guest doesn't try to load
keyboard mappings into Xvnc, because of the dynamically 
added keycodes.  They don't match any predefined keyboard
mapping table.  And the keycodes that get assigned to
the "unknown" keysyms can change with every login; they
depend on the order the user uses these keys.


> Knowing the answers for all of these questions, what do you think? Isn't it
> dangerous to create an Xvnc server which supports XKB (and thus keyboard layout
> changing) and dinamically creates keycodes?


Isn't there a way for KDE to keep it's fingers off
the keyboard mapping?  I think the Suse 11.0 Gnome
desktop session doesn't mess with the keyboard mappings,
so it works ok with Xvnc + XKB.

(In reply to comment #38)
> (In reply to comment #37)

I'm not much more than a user, and this VNC/X misery makes me a bit confused:

According to http://www.charvolant.org/~doug/xkb/html/node3.html and http://pascal.tsu.ru/en/xkb/internals.html and http://www.x.org/wiki/KeySyms the X server sends keycodes (which is rather close to scancodes) to the applications, which are also able to fethc the symbol table from the X server in order to be able to compute the keysims (which are rather close to unicode codepoints) from these keycodes by themselves (using Xlib).

Now, according to http://www.realvnc.com/docs/rfbproto.pdf (page 23) RFB protocol send keysyms, so the Xvnc server has to do a reverse computation of the keycode in order to be able to send it to the client programs. But how does it this computation when not knowing the keyboard layout of the remote VNC client machine? This must be that dynamyc mapping, what you have written about, but in this case the server has to instruct all the applications to refetch the modified symbol table after every dynamic mapping event (when the user pressed a key not in the hardcoded us_english layout) as far as I can understand.

But what it the user instructs the X server to replace the symbol table (like me when turning on XKB in KDE)? I think, in this case the server should forget all the dynamically created reverse keysym->keycode mappings, in order to make use of the newly loaded symbol tables (and avoid confusion). Or something like that.

Anyway, if Xvnc were using /etc/X11/xorg.conf and the keyboard layout in it, then it would have a bigger chance to avoid dynamycal mappings. Or not?

I can turn off XKB in KDE, but why would I? I use it in the real X server, and Xvnc also claims to support it, so KDE enables it. My workaround to disable XKB in Xvnc itself, but why does it claim to support XKB then?

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Update released for: Mesa, Mesa-debuginfo, Mesa-debugsource, Mesa-devel, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debuginfo-x86, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, Mesa-x86, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debuginfo-x86, xorg-x11-driver-video-debugsource, xorg-x11-driver-video-x86, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11 (i386, x86_64)
SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)

And with openSUSE 11.2 we're back where we started. I cannot get a working German keymap at all.

With +kb, I have the correct layout, but no umlauts or other special characters at all. setxkbmap "de(nodeadkeys)" results in the umlauts being present at the right places, but an otherwise quite messed up layout...

With -kb, I get the umlaut-a where it belongs, but no umlaut-o, umlaut-ü, or any other character not present on an American keyboard.

With .Xmodmap I can get as far as with -kb.

It's independent from the VNC client implementation.


Am I the only person on this planet who's using VNC with a non-American keyboard or what?!

I'm currently using Xfvb/x11vnc, but it lets kwin crash (so I'm using xfce4 now) and tends to develop focus and "sticky key" problems after a while. Tigervnc from buildservice crashes as soon as I press some key. NX is a pile of stinkin'... which I cannot use in my environment. Can someone PLEASE fix Xvnc/tightvnc?

(In reply to comment #44)
> And with openSUSE 11.2 we're back where we started. I cannot get a working
> German keymap at all.


Using the NX technology seems to be a quite good workaround, however, you should use the closed source product, freely downloadable from http://nomachine.com, because FreeNX available from http://download.opensuse.org/repositories/X11:/RemoteDesktop/openSUSE_11.2 handles the keyboard even worse than VNC, even after applying the workarounds from http://daniel-lange.com/archives/45-Fixing-FreeNX-NoMachine-NX-keyboard-glitches-e.g.-ALTGr.html I can't even use the up/down keys with that FreeNX version.

The "commercial" one works perfectly and is easy to install, but be careful! Sometimes it generates tremendous traffic, I even have to pay bandwidth penalty for my ISP, because it generated several gigabytes of traffic in a few hours on a 3D GSM modem.

This problem is solved in SLES11 (Isn't that GPL?): https://bugzilla.novell.com/show_bug.cgi?id=562090

SLES's Xvnc with the "-kb" commandline option seems to be absolutely perfect for me, except this issue: https://bugzilla.novell.com/show_bug.cgi?id=562093

Sorry, I had to report SLES bugs this way, because my SLES registration code (our University now owns 100 per server licenses of virtually any Novell product and 16 000 per user licenses of virtually any Novell products, too) does not let me to send a support request from the support module of YaST (I cannot choose the product).

Tamás, for SUSE Linux Enterprise products please open a service request with Novell Technical Services.

For details on how to place a call please refer to http://support.novell.com/contact/getsupport.html?maintab=2

This issue is not fixed. The _only one_ scenario where it works is when the remote machine has got a US keyboard layout. When you change the keyboard to any other language (including en_GB), the keyboard in the vncviwer is unusable.

This bug exists on openSUSE 11.2/11.3 M3 and on SLES/SLED 11 SP1 RC1.

Is there a version of this bug for SLE, and if not, shouldn't there be?  We have customers who have reported this and who are waiting for a resolution.  I can clone this and get the L3 process going if that is appropriate but if we can resolve SLE issues in SP1 that would be best.

Public forum post where this has come up.  The first customer had an SR (10599141001) and the second is looking for an update:

http://forums.novell.com/novell-product-support-forums/suse-linux-enterprise-server-sles/sles-install-boot/402998-sles11-64-bit-vnc-german-characterset.html#post1970920

Also, by definition, the inability to use VNC in German sounds like a major loss of functionality.

Will there be a fix for openSUSE 11.2?
I'm fine with a separate repo with the fixed package(s).

(In reply to bug comment #51)
> This issue is not fixed. The _only one_ scenario where it works is when the
> remote machine has got a US keyboard layout.

I run into this problem on a SLE-11-SP1... When I set US keyboard on the
remote side, z, y and AFAIS most of the punctuation marks are in right
place, but the umlauts do not work then.

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

I have a similar problem using vncserver(Xvnc) with swedish keyboard using openSuSE 11.3. It worked fine in openSuSE 11.2.

Lots of symbols cannot be typed or are in the wrong place.

Created attachment 391485 [details]
Proposed patch for Xvnc

This patch should fix the issues with umlauts for Xvnc based on Xserver 1.6 and up. Apparently the way keyboard mapping is handled changed there.

You can find SLE11-SP1 packages in http://www.suse.de/~mhopf/vnc_umlaut/ , they might even run on 11.2. Probably not on 11.3, though.

(In reply to comment #59)
> You can find SLE11-SP1 packages in http://www.suse.de/~mhopf/vnc_umlaut/ , they
> might even run on 11.2. Probably not on 11.3, though.

http://www.suse.de/~mhopf/vnc_umlauts/

> > might even run on 11.2. Probably not on 11.3, though.
> 
> http://www.suse.de/~mhopf/vnc_umlauts/

I can confirm: it works! 
SuSE 11.3 64 Bit / Linux 2.6.34.7-0.3-desktop #1 SMP PREEMPT x86_64 

Great, many thanks Stefan :-)

I did some test with different keyboard layouts chosen at installation.
In my virtual machine, i installed several opensuse 11.3:
    - 2 times german language and german keyboard
    - 2 times english language and english keyboard
Now, the result testing vncserver is:
    - english to english system works fine
    - english to german system works fine
    - german to english does NOT work
    - german to german does not work
I also tried a connection from my windows system (german keyboard) with thight
vnc version 1.3.10. This did neither work with a german suse nor with the
english suse.

Now, after using the package Matthias provided here: http://www.suse.de/~mhopf/vnc_umlauts/
the issues have gone!!
Everything is working now.

I can confirm that on french keyboards, this improves a lot the keyboard
mapping, but does not solve the full issue.

I'm using Open Suse 11.3 x86_64 and a french keyboard.
I'm connecting from an Open Suse 11.2 and KRDC with VNC.
Both are up to date.

The installation of this package requires libsmbios that can be found in 
the packman repository. It installs without any problem.

All the main keys now work fine : min Maj, AltGr.

I still have a problem with the numeric keypad.
Funny enough, this depends on the application :

With terminal, the 4 and 6 keys always work as left and right arrow
and the 0 works like enter. The other keys are ok.
Pressing Num Lock key does not help.

With KWrite, no numeric key works except 5, just as if the numeric
keypad was in non-numeric mode. Pressing Num Lock key does not help.

Since this does not applies to german keyboards, I am not sure this is the 
right place for this post.
Please correct me and forgive me if this is the case.

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

Jean-Marc, it *probably* is a different issue, however, as long as the fix is not submitted to factory (still waiting for the original L3 bugreporter to validate), it doesn't make sense to open another bug.

I'll have to check here first, in any case.

Please also verify whether the "tigervnc" viewer (check openSUSE buildservice for rpms) has the same issue.

(In reply to comment #65)
> Please also verify whether the "tigervnc" viewer (check openSUSE buildservice
> for rpms) has the same issue.

Jean-Marc?

Hi, 

sorry for the delay, I installed tigervnc, (which asked for the removal of Freenx).
And I checked.
It works just the same, with the same issue.
I also launched a new "fresh" instance of OpenSuse 11.3 in a virtual machine, just to test, and again, I faced the same issue.

Thanks and best regards.

Jean-Marc

So in that case the bug is even upstream...
Jean-Marc, the fastest solution is probably to open a bug at the upstream project. Choosing the tigervnc project might even be better, because they show more progress lately, and we're thinking about switching to tigervnc in the future ourselves.

(In reply to comment #59)
> Created an attachment (id=391485) [details]
> Proposed patch for Xvnc
> 
> This patch should fix the issues with umlauts for Xvnc based on Xserver 1.6 and
> up. Apparently the way keyboard mapping is handled changed there.
> 
> You can find SLE11-SP1 packages in http://www.suse.de/~mhopf/vnc_umlaut/ , they
> might even run on 11.2. Probably not on 11.3, though.

Apparently they do (see comment #61). The patch does not apply for xorg-server 1.9 though (openSUSE 11.4). Things have changed there massively, but didn't fix the issue either. :-(

(In reply to comment #69)
> (In reply to comment #59)
> > Created an attachment (id=391485) [details] [details]
> > Proposed patch for Xvnc
> > 
> > This patch should fix the issues with umlauts for Xvnc based on Xserver 1.6 and
> > up. Apparently the way keyboard mapping is handled changed there.
> > 
> > You can find SLE11-SP1 packages in http://www.suse.de/~mhopf/vnc_umlaut/ , they
> > might even run on 11.2. Probably not on 11.3, though.
> 
> Apparently they do (see comment #61). The patch does not apply for xorg-server
> 1.9 though (openSUSE 11.4). Things have changed there massively, 

Same issue with xorg-server 1.8 (openSUSE 11.3).

>but didn't fix the issue either. :-(

I didn't verify that, but I expect the same results.

So at the moment we can only provide a fix for xorg-server 1.6 (openSUSE 11.2), but not for xorg-server 1.8/1.9 (openSUSE 11.3/11.4).

The patch applies for xorg-server 1.5.2 (openSUSE 11.1) and I guess it would work, but at the time we could provide such an update openSUSE 11.1 will be out of maintenance (end of this  year).

Can I add my support for a fix for this.  I have OS 11.2 & 11.3 servers, and access them from a variety of UK keyboards and platforms.  Remote administration (tightvnc as client on OS 10.3, 11.2 WinXP & Vista) keyboard works fine for 11.2 and doesn't work for 11.3.

Some keys are reassigned (e.g. #, £ & ~) and some have disappeared (e.g. | & \).  On the laptop the extended keys don't work.  The numeric pad is non-functional.

I was hoping to upgrade all the servers to 11.3 but this will now have to wait until this is fixed.  I can't spend my time running both a vnc session (for the graphical bits) and an ssh session (for command line) to the same server.

Is there a patch or workround I can apply?

(In reply to comment #73)
> Some keys are reassigned (e.g. #, £ & ~) and some have disappeared (e.g. | &
> \).  On the laptop the extended keys don't work.  The numeric pad is
> non-functional.

An update: I've changed the keyboard on the login screen (gdm) on the server to US and now I have the | & \ back but the £ sign is still missing.

It seems to me that vnc should (in some way) be passing the keyboard layout (or allowed keyset) to the Xvnc server (and from there to xdm / gdm / kdm.

David, have you tried the tigervnc viewer (not tightvnc)? The issue is split, there is a fix for the server (as in comment 59), and an issue in the viewer (which is fixed in tigervnc).
The server has to be set to en_US in any case.

I've just tried tigervnc viewer from Vista.  Same problem with missing £ sign.

Sorry, didn't completely answer the question.
With tigervnc viewer the numeric pad behaves inconsistently.  If I press a key with num-lock on (e.g. 2) then I get the movement (one line down) instead of the character.  If I hold down the key until it repeats I get the number repeated.
Odd.

Thanks for testing.

Your results are weird indeed :-]

For openSUSE 11.4 we plan to switch to a wrapper script using Xvfb/x11vnc, which doesn't suffer from this issue. For openSUSE 11.2/11.3 this is becoming a WONTFIX.

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

(In reply to comment #79)
> For openSUSE 11.4 we plan to switch to a wrapper script using Xvfb/x11vnc,
> which doesn't suffer from this issue. For openSUSE 11.2/11.3 this is becoming a
> WONTFIX.

What happened to the 11.4 plans?
It's still broken.

(In reply to comment #81)
> (In reply to comment #79)
> > For openSUSE 11.4 we plan to switch to a wrapper script using Xvfb/x11vnc,
> > which doesn't suffer from this issue. For openSUSE 11.2/11.3 this is 
> becoming a WONTFIX.
> 
> What happened to the 11.4 plans?
> It's still broken.

Unfortunately we needed to postpone these, since we ran into a lot of issues
with the wrapper. :-(

(In reply to comment #59)
> Created an attachment (id=391485) [details]
> Proposed patch for Xvnc
> 
> This patch should fix the issues with umlauts for Xvnc based on Xserver 1.6 and
> up. Apparently the way keyboard mapping is handled changed there.
> 
> You can find SLE11-SP1 packages in http://www.suse.de/~mhopf/vnc_umlaut/ , they
> might even run on 11.2. Probably not on 11.3, though.

Does anyone still have these packages? They solved the problem for me on 11.3, but I seem to have installed different ones again.

Thomas, unfortunately we have no fix for openSUSE 11.3 and later. See also my comment #71.

You can say what you want, but the packages that were provided in comment #59 did fix all problems for me on 11.3, I just forgot to save the RPMs.

The "solution" might not have been complete or entirely correct, but I was without issues until I upgraded my system without looking too closely at the package list and then restarting my VNC. In other words: The state with these packages installed was better than the state with the stock 11.3 packages.

(In reply to comment #85)
> You can say what you want, but the packages that were provided in comment #59
> did fix all problems for me on 11.3, I just forgot to save the RPMs.

Sure, they were based on Xserver sources we used for openSUSE 11.2 or earlier.

(In reply to comment #84)
> Thomas, unfortunately we have no fix for openSUSE 11.3 and later. See also my
> comment #71.

No fix? Do you mean VNC is rendered unusable for all future with opensuse?

Anybody reading here: Is this the case with all other linux distributions too?

Michael, this bug is about umlauts.

(In reply to comment #88)
> Michael, this bug is about umlauts.

It's about VNC not funtioning properly with umlauts and some practically never used characters like "&" and "|". Does anybody really need these?

(In reply to comment #89)
> It's about VNC not funtioning properly with umlauts and some practically never
> used characters like "&" and "|". Does anybody really need these?

I would say every second line which I write contains one or more "&, | or /" and
I don't care about Umlauts.
Moreover also some special keys like shift or ALT are sometimes locked so you have to guess it and then hit it again to get even the mouse working again.


Why this bug is still WONTFIX and how could it become WONTFIX at all?

(In reply to comment #86)
> (In reply to comment #85)
> > You can say what you want, but the packages that were provided in comment #59
> > did fix all problems for me on 11.3, I just forgot to save the RPMs.
> 
> Sure, they were based on Xserver sources we used for openSUSE 11.2 or earlier.

I still don't care what these packages were based on, and how the solution may have been incorrect for 11.3.

Let me summarize what I want:
1) Right now, VNC is broken for me.
2) The link in comment #59 lead to packages that fixed the problem for me.
3) I accidently "lost" the fixed packages.
4) The link is now dead.
5) Somebody might still have those package files and might provide them to me (maybe even the guy who originally posted them). This bug report is the most likely place to find a person who still has them.

Re-explaining to me what I already read further above in this bug report doesn't help me at all.

I hope you now understood the nature of my request.

(In reply to comment #89)
> 
> It's about VNC not funtioning properly with umlauts and some practically never
> used characters like "&" and "|". Does anybody really need these?

Bad joke. Yes there is a need for a working keyboard with a complete layout mapping. Otherwise lets just drop keyboard support in VNC completely - there is still a mouse to use the system...

At least 20 people using systems I administer need Umlauts and these "practically never used characters".

Matthias Hopf: Do you still have your old packages or patches somewhere?
Can you point us to any location where the problem is so we could help here?

Matthias is on vacation until sunday. Reopen.

This was found in 11.3, so the 'Product' should be 11.3.  The target can be changed to 11.4 if desired, but finding the problem in a subsequent version does not justify ignoring that it was found in a previous version.

I've set 'Platform' to 11.4 for now in order to show it's in that version as well.

Why do you think product specifies the version on which the issue was found and platform a version on which the problem still is reproducable? Can't it be the other way round? Is there any Bugzilla policy available, where this is specified?

I have just updated from 11.2 to 11.4. Now I cannot enter '/' in a vnc screen (Using UltraVNC on XP to connect to 11.4 vncserver).
I have exactly the same symptoms from #639777.
For me this is a crutial thing, and I am a bit worried, that this issue seems to have been found in 11.3 and it is still not fixed.

As the error is still in 11.4, should the error be moved to 11.4 ?

Believe us, nobody is happy about the current situation.

> As the error is still in 11.4, should the error be moved to 11.4 ?

That's what I've tried, but it has been reverted. See the comments #94/95 and
"View Bug Activity".

I am also unhappy with the priority level. For people using a German keyboard vnc is practically unusable. I rate this bug P1-Urgend / Major (if not Critical).

I am remotely administering 3 openSUSE servers, that I just wanted to upgrade to 11.4. For me vnc access to these systems is critical and being unable to enter a '/' makes it more than difficult to do simple things like "cd /home/..." or enter a URL.

And I am a bit worried, that the error was detected in June 2008 and still has not been fixed. So I am afraid, that there will not be a quick fix for this. Which might render me switching to a different distribution, if this is not fixed in a few weeks.

It should not be too difficult, as I have no problems with recent Ubuntu (10.04, 10.10) and fedora (9,11,13,14). They might use different vnc packages though.

Is it possible to find out, if somebody is working on a fix?
Or when it might be fixed?

Keyboard handling in Xvnc (from tightvnc) never had support for Iso-Level3-Shift (AltGr), and keyboard device usage broke with the introduction of XInput.

Attaching fixes for xorg-x11-server now.

For the record: the L3 bug by which fixing this was triggered was bug 660797.


Ubuntu and Fedora use different vnc servers, indeed (tigervnc). Given the code basis is completely different to the tightvnc (which only is a patch to the regular server), I don't know how they deal with security updates...

After fixing Factory, we'll discuss whether and how to do maintenance updates for 11.3 and 11.4.


Note that you still might have to use vncviewer from tigervnc (available in build service) - haven't double checked keyboard handling in vncviewer from tightvnc yet.

Created attachment 426119 [details]
Fix keyboard handling for XInput enabled servers

This patch fixes keyboard handling for XInput enabled servers. W/o this patch the wrong keyboard was used for adding new KeyCodes.

This should basically already enable the use of other keyboards, if the remote keyboard stays at US.

Created attachment 426122 [details]
Fix keycode lookup and ISO-Level3-Shift handling

This patch fixes keycode lookup (not using any static keyboard layout any more) and ISO-Level3-Shift handling (enabling the use of keyboard layouts that use AltGr for reaching certain characters).

Note that the implementation is still imperfect. Keyboard layouts that use a different key than AltGr for ISO-Level3-Shift will show some weird behavior. Mode_Switch is also not supported, so keyboard switching via Mode_Switch might not work as intended either. Suggesting the use of input methods in these cases (they will hopefully work).

Pushed to X11:XOrg.
SR'ed to Factory.

Please test the xorg-X11-Xvnc package from X11:XOrg (as soon as it is published)! Of course, the package from X11:XOrg is not based upon 11.3 or 11.4, but should be compatible and installable.


Maintenance, I'd suggest to create a maintenance update for 11.3 and 11.4, as a lot of customers are hitting this issue. Partially, it was a regression from 11.2, partially it's working better now than ever before.

(In reply to comment #103)
> Pushed to X11:XOrg.
> SR'ed to Factory.
> 
> Please test the xorg-X11-Xvnc package from X11:XOrg (as soon as it is
> published)! 

Please verify that the RPM changelog contains the following entry:

Thu Apr 21 14:16:01 UTC 2011 - mhopf@novell.com
- bnc #605015
  - Enable use of all keyboard layouts, independent of remotely set layout
  - Remove obsolete xorg-server-xf4vnc-bug605015-vnc-umlauts.diff
  - xorg-server-xf4vnc-bug605015-fix-keyboard-handling-xinput.diff
    This should basically already enable the use of other keyboards, if the
    remote keyboard stays at US.
  - xorg-server-xf4vnc-bug605015-fix-keycode-lookup-and-isolevel3shift.diff
    This patch fixes keycode lookup (not using any static keyboard layout any
    more) and ISO-Level3-Shift handling (enabling the use of keyboard layouts
    that use AltGr for reaching certain characters).

Just verified: it also works fine with tightvnc :-)

would be ok I guess +1

The SWAMPID for this issue is 40461.
This issue was rated as low.
Please submit fixed packages until 2011-05-24.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/40461

Thanks a lot for that fix!

+1, update running

Find fixed packages in home:mhopf:branches:openSUSE:11.3:Update:Test and home:mhopf:branches:openSUSE:11.4:Update:Test (as soon as they are built).

Anybody who is having this issue: Please test, I will SR as soon as I get a positive confirmation that this fixes the bug.

seems to be fine, tested  opensuse 11.4

 68554  State:new     By:mhopf        When:2011-04-27T14:21:16
        submit:       home:mhopf:branches:openSUSE:11.4:Update:Test/xorg-x11-server  ->  openSUSE:11.4:Update:Test   
 68553  State:new     By:mhopf        When:2011-04-27T14:20:49
        submit:       home:mhopf:branches:openSUSE:11.3:Update:Test/xorg-x11-server  ->  openSUSE:11.3:Update:Test   

Also created Patchinfo for 11.3 (i586 x86_64) 11.4 (i586 x86_64) - xorg-x11-Xvnc

Update released for: xorg-x11-Xvnc
Products:
openSUSE 11.3 (debug, i586, x86_64)
openSUSE 11.4 (debug, i586, x86_64)

This bug is not resolved. In fact the problem got worse. With the updated packages on 11.3 I can not use any key combinations with the Shift key.

For instance, Shift+Left or Shift+Right to mark text in an editor. I also use a program that requires Shift+Return a lot, and this is not recognized as well. The shift key is ignored entirely here. Uppercase letters do work though.

Will try to reproduce.

I was able to reproduce. It was on SLE11SP1, but there's no doubt that 11.3 is affected equivalently.

Have to analyze now.

Analysis for shift/level3 event faking was bonkers, I seem to have a working patch.
Expect an update soon.

Check xorg-x11-Xvnc in home:mhopf:branches:X11:XOrg , as soon as it's built.

I still can't see the package anywhere, is that normal?

We found a regression. Could you read comments #114-118? Thanks.

(In reply to comment #118)
> Check xorg-x11-Xvnc in home:mhopf:branches:X11:XOrg , as soon as it's built.

Matthias, there is still no package in home:mhopf:branches:X11:XOrg.

the home:mhopf:branches:X11:XOrg meta prj has:

  <publish>
    <disable/>
  </publish>


osc meta prj -e home:mhopf:branches:X11:XOrg

and delete the disable/ lne

It was even worse - due to some internal build server inconsistencies, build was blocked for some 4 days. In the meantime I have an improved patch, which also reworks modifier handling (thus only the new patch should be tested). However, it doesn't apply to factory yet.

I'll post when I have something to test.

After _literally_ days of staring at code and trying (and sometimes failing) to understand the mess that XKB resembles I think I have a working solution now.

Given the fallout we had last time, I'd like to have it tested more than last time before actually shipping updates.

I also fixed a major memory leak that was introduced with the original Xserver 1.9 enabling patches. A legacy keymap was created on every keypress, and not cleaned up afterwards.

Created attachment 431597 [details]
Make keyboard layout handling XKB aware

This patch replaces
  - xorg-server-xf4vnc-bug660797-fix-keycode-lookup-and-isolevel3shift.diff
  - xorg-server-xf4vnc-bug660797-multilayout.diff
  - xorg-server-xf4vnc-bug605015-fix-keyboard-handling-xinput.diff


Overview:

- Use virtual core keyboard for events and key state lookup:
  Make layout changes work again - see discussion on
  https://defect.opensolaris.org/bz/show_bug.cgi?id=8687
- keycode lookup:
  Don't use any static keyboard layout any more.
- ISO-Level3-Shift handling:
  Enable the use of keyboard layouts that use AltGr for 3rd and 4th level.
- Make keyboard handling more XKB aware:
  Previous code was e.g. not multi-group aware.
- Nuke use of legacy keymap as far as possible:
  Creating legacy keymap takes time, and it has to be freed again afterwards.
- Free index lookup:
  Make XKB aware.
- Ignore calls for NoSymbol:
  This destroys otherwise valid entries.
- Fix analysis for shift/level3 event faking:
  Previous broken version lead to e.g. Shift+PgUp not being recognized.
- Add tons of debug output (disabled).

I committed updated packages to home:mhopf:branches:X11:XOrg, and enabled publishing.
Currently, in X11:XOrg many packages are blocked, so expect the build to take a while.

To all users who had issues in the past: Please test as soon as the package is available.
Last Changelog entry is 'Thu May 26 2011 mhopf@novell.com'

The packages are available, so please do test. Remember, only xorg-x11-Xvnc has to be updated, and this should also work for 11.4 and 11.3 (possibly even 11.2).

(In reply to comment #127)
> The packages are available, so please do test. Remember, only xorg-x11-Xvnc has
> to be updated, and this should also work for 11.4 and 11.3 (possibly even
> 11.2).

The packages don't work on 11.3. After the xorg-x11-Xvnc update (from 7.5_1.8.0-10.11.1 to 7.6_1.9.3-153.1), I get this when trying to start VNC:

$ vncserver -geometry 1200x600 :1
Couldn't start Xvnc; trying default font path.
Please set correct fontPath in the vncserver script.
Couldn't start Xvnc process.

30/05/2011 15:44:22 Xvnc version X.org/xf4vnc custom version
30/05/2011 15:44:22 Copyright (C) 2001-2004 Alan Hourihane.
30/05/2011 15:44:22 Copyright (C) 2000-2004 Constantin Kaplinsky
30/05/2011 15:44:22 Copyright (C) 1999 AT&T Laboratories Cambridge
30/05/2011 15:44:22 All Rights Reserved.
30/05/2011 15:44:22 See http://www.tightvnc.com/ for information on TightVNC
30/05/2011 15:44:22 See http://xf4vnc.sf.net for xf4vnc-specific information
30/05/2011 15:44:22 Desktop name 'X' (emmy:1)
30/05/2011 15:44:22 Protocol versions supported: 3.7, 3.3
30/05/2011 15:44:22 RGB format 8 8 8
30/05/2011 15:44:22 Listening for VNC connections on TCP port 5901
30/05/2011 15:44:22 Listening for HTTP connections on TCP port 5801
30/05/2011 15:44:22   URL http://emmy:5801
[dix] Could not init font path element /usr/share/fonts/misc:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/local, removing from list!
[dix] Could not init font path element /usr/share/fonts/75dpi:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/100dpi:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/URW, removing from list!
[dix] Could not init font path element /usr/share/fonts/Speedo, removing from list!
[dix] Could not init font path element /usr/share/fonts/truetype, removing from list!
[dix] Could not init font path element /usr/share/fonts/uni, removing from list!
[dix] Could not init font path element /usr/share/fonts/CID, removing from list!
[dix] Could not init font path element built-ins, removing from list!

Fatal server error:
could not open default font 'fixed'
30/05/2011 15:44:23 Xvnc version X.org/xf4vnc custom version
30/05/2011 15:44:23 Copyright (C) 2001-2004 Alan Hourihane.
30/05/2011 15:44:23 Copyright (C) 2000-2004 Constantin Kaplinsky
30/05/2011 15:44:23 Copyright (C) 1999 AT&T Laboratories Cambridge
30/05/2011 15:44:23 All Rights Reserved.
30/05/2011 15:44:23 See http://www.tightvnc.com/ for information on TightVNC
30/05/2011 15:44:23 See http://xf4vnc.sf.net for xf4vnc-specific information
30/05/2011 15:44:23 Desktop name 'X' (emmy:1)
30/05/2011 15:44:23 Protocol versions supported: 3.7, 3.3
30/05/2011 15:44:23 RGB format 8 8 8
30/05/2011 15:44:23 Listening for VNC connections on TCP port 5901
30/05/2011 15:44:23 Listening for HTTP connections on TCP port 5801
30/05/2011 15:44:23   URL http://emmy:5801
[dix] Could not init font path element /usr/share/fonts/misc:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/TTF/, removing from list!
[dix] Could not init font path element /usr/share/fonts/OTF/, removing from list!
[dix] Could not init font path element /usr/share/fonts/Type1/, removing from list!
[dix] Could not init font path element /usr/share/fonts/100dpi:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/75dpi:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/URW/, removing from list!
[dix] Could not init font path element /usr/share/fonts/cyrillic:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/misc/sgi:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/truetype/, removing from list!
[dix] Could not init font path element built-ins, removing from list!

Fatal server error:
could not open default font 'fixed'

I tried the OpenSuSE 11.4 package xorg-x11-Xvnc-7.6_1.9.3-153.1 in home:mhopf:branches:X11:XOrg and all the symbols I tried seemed to work as they should with Swedish keyboard.

@Gustav:
Thanks for testing. Are you using Kde or Gnome?
Can you post the output of 'setxkbmap -print'?


@Thomas:
Hm. Too bad. I remember that there's something changed with the font path in X11:XOrg, though not the path itself. Beats me ATM.

I adapted the patch for 11.3 and 11.4. Find according packages (as soon as they are built) in home:mhopf:branches:openSUSE:11.3:Update:Test (and *:11.4:*, of course).
Yes, I enabled publishing this time :-)

I use KDE.

Output from "setxkbmap -print"

xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(pc105)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

In my last comment the results from setxkbmap -print is from a VNC session initiated from a windows 7 machine.

From a normal session (sitting at the keyboard at the suse machine) I get this instead:
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+se+inet(evdev)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

Installed xorg-x11-Xvnc 7.5_1.8.0-13.1.x86_64 from home:mhopf:branches:openSUSE:11.3:Update:Test. I tested with us, de and de-nodeadkeys keyboards on the client side (another Linux machine, not SuSE, tightvnc viewer), everything works as expected.

setxkbmap -print inside the VNC gives:
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(pc105)"     };
        xkb_geometry  { include "pc(pc105)"     };
};


(I did get a weird problem at first when switching keyboards on the client side with setxkbmap - it seemed like caps lock was stuck on inside the VNC. However, I could not reproduce this behaviour with another VNC session, might as well be one of the keyboard problems the tightvnc viewer has on occasion.)

Thanks for testing!

There are still a number of issues regarding vnc and its viewers, most of them difficult to reproduce (as the stuck keys example you mentioned). And luckily occurring seldom only.


Maintenance, the previous "fix" of this package resulted in quite a number of fallout issues, which seem to be solved now. We'd require another online update.
Shall the same patchinfo/swampid be used for this update?
The SWAMPID for the first update in this issue was 40461.

no, the old one is closeds already.

we should do an update (with new swamp) +1

SR'ed to 11.3 and 11.4:

 72265  State:new        By:mhopf        When:2011-05-31T14:27:03
        submit:          home:mhopf:branches:openSUSE:11.4:Update:Test/xorg-x11-server  -> openSUSE:11.4:Update:Test
        Descr: - xorg-server-xf4vnc-fix-keyboard-layout-handling.diff
               Consolidate adapted patches for bugs 400520, 605015, and 660797
               into   single patch:   - xorg-server-xf4vnc-bug660797-fix-
               keycode-lookup-and-isolevel3shift.diff   - xorg-server-xf4vnc-
               bug605015-fix-keyboard-handling-xinput.diff - Fix fallout of
               keyboard fixes:   - Keyboard handling was not XKB aware, which
               lead to a multitude of issues.     Situation with this patch is
               not perfect, but way better.   - Analysis for shift/level3 event
               faking was broken, leading to e.g     Shift+PgUp not being
               recognized correctly. - Fix *major* memory leak introduced by
               original 1.9 enabling patch 

 72264  State:new        By:mhopf        When:2011-05-31T14:26:40
        submit:          home:mhopf:branches:openSUSE:11.3:Update:Test/xorg-x11-server  -> openSUSE:11.3:Update:Test
        Descr: - xorg-server-xf4vnc-fix-keyboard-layout-handling.diff
               Consolidate adapted patches for bugs 400520, 605015, and 660797
               into   single patch:   - xorg-server-xf4vnc-bug660797-fix-
               keycode-lookup-and-isolevel3shift.diff   - xorg-server-xf4vnc-
               bug605015-fix-keyboard-handling-xinput.diff - Fix fallout of
               keyboard fixes:   - Keyboard handling was not XKB aware, which
               lead to a multitude of issues.     Situation with this patch is
               not perfect, but way better.   - Analysis for shift/level3 event
               faking was broken, leading to e.g     Shift+PgUp not being
               recognized correctly. - Fix *major* memory leak introduced by
               original 1.9 enabling patch

next try +1

The SWAMPID for this issue is 41240.
This issue was rated as moderate.
Please submit fixed packages until 2011-06-14.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/41240

Patchinfo has been created, packages SR'ed.
Also SR'ed to factory.

Update released for: xorg-x11-Xvnc, xorg-x11-Xvnc-debuginfo, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-extra-debuginfo, xorg-x11-server-sdk
Products:
openSUSE 11.3 (debug, i586, x86_64)
openSUSE 11.4 (debug, i586, x86_64)

All: note that in the meantime another bug has surfaced, this time in vncviewer of openSUSE 11.3. The version in 11.4 is fixed, and installable on 11.3. So if you see strange behavior regarding AltGr, use the vncviewer from 11.4.

Internal: Analysis of this bug is tracked in bug 698694.