FVWM: fvwm hotkey problem inside vnc

[Hendrik Tews]

Dear all,

[sorry for crossposting - but I would like to connect different
sources about this problem]

The problem is that fvwm does not install any keybindings when
started inside a vncserver, see Debian bug #784328 or Raphael's
post "Understanding why Key bindings are not installed" on the
fvwm mailing list on March 2, 2015. I have this problem with fvwm
2.6.5 from Debian stable and vnc4server 4.1.1 and tightvncserver
1.3.9. To reproduce the problem, start vncserver on your local
machine and start fvwm without any configuration inside that vnc
X xerver. Then open the FvwmCommand console and do PrintInfo
bindings there.

The work around that I found is using the tigervncserver, in
there, fvwm installs the key bindings as expected. There are deb
packages of tigervncserver (follow releases -> the binary link on
bintray -> Files). They don't install right away on Debian
stable, but when you unpack them (dpkg -x) and make some
symlinks, you can run run the binaries.

However, for me, tigervnc shows the Ctrl-space problem, i.e.,
Ctrl-space is not transmitted correctly to applications inside
vnc, making it quite difficult to work with emacs inside
tigervnc. I am therefore still interested in a solution to the
fvwm key bindings problem.

If anybody has a idea about how to convince fvwm to install key
bindings inside fvwm, please follow up on this email.

Best regards,

Hendrik Tews


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Dan Espen]

Post by Hendrik Tews
Dear all,
[sorry for crossposting - but I would like to connect different
sources about this problem]
The problem is that fvwm does not install any keybindings when
started inside a vncserver, see Debian bug #784328 or Raphael's
post "Understanding why Key bindings are not installed" on the
fvwm mailing list on March 2, 2015. I have this problem with fvwm
2.6.5 from Debian stable and vnc4server 4.1.1 and tightvncserver
1.3.9. To reproduce the problem, start vncserver on your local
machine and start fvwm without any configuration inside that vnc
X xerver. Then open the FvwmCommand console and do PrintInfo
bindings there.
The work around that I found is using the tigervncserver, in
there, fvwm installs the key bindings as expected. There are deb
packages of tigervncserver (follow releases -> the binary link on
bintray -> Files). They don't install right away on Debian
stable, but when you unpack them (dpkg -x) and make some
symlinks, you can run run the binaries.
However, for me, tigervnc shows the Ctrl-space problem, i.e.,
Ctrl-space is not transmitted correctly to applications inside
vnc, making it quite difficult to work with emacs inside
tigervnc. I am therefore still interested in a solution to the
fvwm key bindings problem.
If anybody has a idea about how to convince fvwm to install key
bindings inside fvwm, please follow up on this email.

On the Debian list they say:

So after all, this bug may have been triggered by a change in VNC
rather than in FVWM.

I don't see how Fvwm can help.
Try the VNC folks.

[Hendrik Tews]

Hi,

[reincluding the fvwm list, because I still have the hope that
our observations might trigger an idea that leads to a solution]

Claude, thanks for restating your FreeBSD observation, I was not
aware of that. From that I conclude that the bug is fixed or
introduced by either

- the Debian or FreeBSD patches

- the different fvwm configurations

- the different libraries

Claude, what did you precisely install on the FreeBSD system, the
port or a fvwm package? If it is the port, could you send the
compilation log? If it is the package, was it fvwm-2.6.5_7?

I am asking, because I want to try to compile a fvwm on Debian that
is identical wrt patches and configuration to your FreeBSD
version.

Bye,

Hendrik
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Hendrik Tews]

Post by Dan Espen
So after all, this bug may have been triggered by a change in VNC
rather than in FVWM.
I don't see how Fvwm can help.
Try the VNC folks.

I agree that it looks like the problem is outside fvwm. However,
I expect there are only a few circumstances that can cause
PrintInfo Bindings to not output the default builtin F1
keybinding on fvwm started without configuration. I would have
hoped that the fvwm developers could provide some information
about these circumstances, for instance about presence or absence
of certain X server extensions that can trigger that behavior.

Best regards,

Hendrik
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Dan Espen]

Post by Hendrik Tews

Post by Dan Espen
So after all, this bug may have been triggered by a change in VNC
rather than in FVWM.
I don't see how Fvwm can help.
Try the VNC folks.

I agree that it looks like the problem is outside fvwm. However,
I expect there are only a few circumstances that can cause
PrintInfo Bindings to not output the default builtin F1
keybinding on fvwm started without configuration. I would have
hoped that the fvwm developers could provide some information
about these circumstances, for instance about presence or absence
of certain X server extensions that can trigger that behavior.

Good point.

Current Fvwm is from CVS on the 2_6 branch.
I don't know if there have been changes that affect key bindings
but I can take a look.

Since I'll be looking at current CVS it would be helpful to know
whether the problem exists there.

[Hendrik Tews]

I found the culprit: It's the Debian deprecated.patch, which I
attach below, in case you are interested.

This means it's a Debian packaging bug. Debian applies this
deprecated.patch during build, thereby apparently making fvwm
incompatible with the X xerver running inside vnc.

In retrospect, I should have earlier tried to confirm whether the
problem is present at all in the upstream fvwm version. However,
I was under the wrong impression that Debian distributes an
almost unmodified fvwm (the opposite is true - there are 12
Debian patches). Further, also the email from Raphael in March on
the fvwm list gave me the impression somebody has checked this
with upstream fvwm.

Bye,

Hendrik

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Hendrik Tews]

Here is the patch. To me it looks like these changes have been
introduced in the first 2.6.5 Debian package.

Bye,

Hendrik

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Hendrik Tews]

Post by Hendrik Tews
I found the culprit: It's the Debian deprecated.patch, which I
attach below, in case you are interested.

I analyzed the problem a bit further. The patch deprecated.patch
replaces various occurrences of XKeycodeToKeysym with
XkbKeycodeToKeysym, apparently following various resources
suggesting XkbKeycodeToKeysym should be used instead of the
deprecated XKeycodeToKeysym. The problem is that these
suggestions are wrong wrt. applications running inside X servers
without the XKEYBOARD extension and vnc4server _does not_ have
the XKEYBOARD extension.

The XKEYBOARD doc clearly say, no Xkb function should be called
if the server does not provide XKEYBOARD. And indeed, inside
vnc4server, XkbKeycodeToKeysym does always return 0. (I attach a
small test program that shows this behavior.) Inside the loop in
AddBinding (file libs/Binding.c) this causes all key bindings to
be dropped.

For the behavior of XkbKeycodeToKeysym it is not relevant whether
the XKEYBOARD extension is properly initialized or not (indeed,
the patch uses XkbKeycodeToKeysym without calling
XkbQueryExtension as the documentation requests).

Therefore, I strongly believe that as long as Debian distributes
X servers without the XKEYBOARD extension, such as vnc4server for
example, fvwm should use the deprecated XKeycodeToKeysym instead
of XkbKeycodeToKeysym. As a consequence, the patch
deprecated.patch should be removed.

As conclusion, there are the following solutions to this problem:

- downgrade to Debian fvwm 2.5.30 (as suggested by Claude)
because this uses XKeycodeToKeysym

- use a vnc server with XKEYBOARD, such as tigervnc

- compile fvwm without the offending patch, for instance the
upstream version (the Debian package lists debhelper (>=
9.0.0), autotools-dev, dh-autoreconf, file, fontconfig,
gettext, libfontconfig1-dev | libfontconfig-dev,
libfreetype6-dev, libfribidi-dev (>= 0.10.7), libncurses5-dev,
libreadline-dev | libreadline6-dev | libreadline5-dev,
libpng12-dev | libpng-dev, librplay3-dev, librsvg2-dev (>=
2.13.92), libsm-dev, libstroke0-dev, libx11-dev,
libxcursor-dev, libxext-dev, libxft-dev, libxi-dev,
libxinerama-dev, libxpm-dev, libxrandr-dev, libxrender-dev,
libxt-dev, sharutils, xsltproc as build dependencies).

Bye,

Hendrik


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Claude Krantz]

Dear Thomas,

As far as I understand Hendriks analysis, there is indeed nothing upstream FVWM
can do about this. He included the fvwm mailing list before his analysis showed
that the bug is introduced in Debian.

Hendriks analysis indeed suggests to me that, until all X servers shipped with
Debian support XKEYBOARD, the packaged fvwm should not silently assume that this
extension is present. Optimally, it should dynamically detect at startup which
functions are offered by X and then use them accordingly. More simply - indeed -
it could just stick to the deprecated functions for now, which seem to be
(still) supported by all X servers.

Thanks for pointing out that one can effectively disable the patch also by an
undefine. While this may be technically interesting for the package maintainers,
suggesting that Debian useres should routinely recompile their software on need
is really beyond the scope of a binary distribution.

@Hendrik: Many thanks for your detailed analysis.

Yours,

Claude
--
-----------------------------------
Dr. Claude Krantz

Für das
Max-Planck-Institut fuer Kernphysik
Saupfercheckweg 1
D-69117 Heidelberg

Email: ***@mpi-hd.mpg.de

[Hendrik Tews]

Hi,

Post by Hendrik Tews
The XKEYBOARD doc clearly say, no Xkb function should be called
if the server does not provide XKEYBOARD. And indeed, inside
vnc4server, XkbKeycodeToKeysym does always return 0. (I attach a
small test program that shows this behavior.) Inside the loop in
AddBinding (file libs/Binding.c) this causes all key bindings to
be dropped.

So? There is nothing FVWM can do about this. Nor should it. If you

Fvwm could and should use the XKEYBOARD extension properly, which
means, check at runtime if XKEYBOARD is supported in the server
and disable all XKEYBOARD calls if the result is negative. I
believe the XKEYBOARD documentation is very clear on this. The
Debian version of Fvwm has definitely a deficiency on this point.
And, as far as I understand, your github Fvwm version could also
be improved here.

really don't want to use XKB at all with FVWM, then you can undefine
'HAVE_X11_XKBLIB_H' -- which will force FVWM to use
XKeycodeToKeysym().

This is not a solution, because it would require me to keep two
compiled versions of Fvwm around. One for using on ordinary
displays and one for using inside vnc.

Post by Hendrik Tews
- downgrade to Debian fvwm 2.5.30 (as suggested by Claude)
because this uses XKeycodeToKeysym

No. See suggestion above.

This is definitely a solution. And for Debian users it is still
the simplest one.

Post by Hendrik Tews
- compile fvwm without the offending patch, for instance the

No. Just use CVS. Oh, and see above.

What do you mean by no? This is of course a solution. And you are
contradicting yourself here, because using CVS means compiling
Fvwm without the offending patch.

Bye,

Hendrik
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Michael Großer]

This post might be inappropriate. Click to display it.

[Claude Krantz]

Dear Hendrik,

On my FreeBSD system, fvwm is installed from the ports collection, by
compilation on-site. The presently used version is internally labelled
"2.6.5_7". The system is FreeBSD 9.3 (amd64). All software installed from the
ports is updated fairly regularly (every two weeks or so), i.e., the versions of
all libraries should reasonably match their latest release in the ports collection.

fvwm 2.6.5 is compiled with the following build options (cf.
http://www.freshports.org/x11-wm/fvwm2/ ):

BIDI=off: Asian bi-directional text support
ICONS=on: Install icon theme(s)
ICONV=on: Encoding conversion support via iconv
NLS=on: Native Language Support
PNG=on: PNG image format support
RPLAY=off: RPlay support in FvwmEvent
SESSION_MGMT=on: Session Management support
STROKE=on: support for mouse gestures
SVG=on: SVG vector image format support

The so-built version of fvwm runs inside tighvncserver and I have yet to find
any key-binding that does not work.

From what I can see, three patches are applied by the FreeBSD maintainers
(attached). I also attached the configure log and the make output as requested.
Please note that my knowledge of the internals of X11 window managers is next to
non-existing and I have not tried to decipher the logs myself. If I can be of
any further help, please say so.

Dear Michael,

Thanks for sharing your very detailed report (which I still have to digest in
detail.)

I have no Debian wheezy system anymore, so I can not reproduce your observations
concerning that. However, as stated several times, I have several fully updated
Jessie set-ups alive. The systems are headless and run their desktop in
tighvncserver 1.3.9. All software is installed from the jessie repositories. If
I install the fvwm-2.6.5.ds-3 packaged for jessie, my hotkeys (ctrl-shift-arows)
do not work.

If just replace the jessie fvwm package with the one from wheezy (2.5.30.ds-1.1)
and restart fvwm, the hotkeys start working immediately, including
shift-ctrl-arrows, ctrl-space and german deadkeys like ^-a or `-e (I cannot
remember that I ever had to fiddle to get those working, btw.). I do not even
need to restart the vncserver. This behaviour is observed on four jessie systems
(i386 and amd64).

From this I (once more) conclude that the behaviour MUST be caused by a change
in the Debian package when going from fvwm-2.5.30 to fvwm-2.6.5. This is not
saying that the actual bug must necessarily reside within fvwm, but it does mean
that a change in fvwm triggers it.

Yours,

Claude
--
-----------------------------------
Dr. Claude Krantz

Für das
Max-Planck-Institut fuer Kernphysik
Saupfercheckweg 1
D-69117 Heidelberg

Email: ***@mpi-hd.mpg.de