Hendrik Tews wrote: > 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.
Hi! In the year 2015, I worked remotely with FVWM on Debian Wheezy via VNC for several months. Wheezy was shipped with FVWM 2.5.30, and I used exactly that shipped FVWM version. My VNC solution was vnc4server combined with xvnc4viewer: - Server remote (Wheezy): # apt-cache search vnc > vnc4server - Virtual network computing server software > x11vnc - VNC server to allow remote access to an existing X session # apt-get install vnc4server - Client local (one client Squeeze, another client Lenny): # apt-get install xvnc4viewer The usage of hot keys was very tricky, because I excessively make use of FVWM key bindings, and my goal was to get a computing experience that makes me forget that I work remotely. I reached that goal nearly, but I had to do a lot to get what I wanted. Here is my know-how: While simple key bindings like 'letter' or 'digit' without any shift key worked out of the box, a combination with more advanced shift keys (Shift, Control, Alt, Win, German AltGr) caused problems. As I remember, Shift and Control or Alt worked, but the other shift keys like the Windows keys or the German AltGr key didn't work out of the box. Remotely, I had a virtual server running in a XenCenter environment. I installed that server from the scratch using the common Debian installer software and configuring it the way I usually configure Debian systems. After switching on the remote machine, I had to enter it via SSH to manually start the VNC server. (One can automate that, but I didn't want it). Start script for a VNC session as root: # 1_start_root.sh Content: > #!/bin/bash > > vncserver :1 -desktop root -geometry 1280x1024 -depth 24 Stop script for a VNC session as root: # 2_stop_root.sh Content: > #!/bin/bash > > vncserver -kill :1 Start script for a VNC session as user: # 3_start_user.sh Content: > #!/bin/bash > > vncserver :2 -desktop user -geometry 1280x1024 -depth 24 Stop script for a VNC session as user: # 4_stop_user.sh Content: > #!/bin/bash > > vncserver -kill :2 On the client side, I had these two scripts to get connections to the server: # 1_view_root.sh > #!/bin/bash > > xterm -geometry 160x30\ > -e\ > "xhost -;\ > vncviewer -geometry +0+0 -FullColor -PreferredEncoding ZRLE -MenuKey Pause > 1.2.3.4:1;\ > #bash"& # 2_view_user.sh > #!/bin/bash > > xterm -geometry 160x30\ > -e\ > "xhost -;\ > vncviewer -geometry +0+0 -FullColor -PreferredEncoding ZRLE -MenuKey Pause > 1.2.3.4:2;\ > #bash"& Although, I used VPN to connect remotely to the server and the server's IP address was a private one, --> https://en.wikipedia.org/wiki/Private_network I replaced the IP address by '1.2.3.4' before sending this e-mail message. Well, as you can guess, I had two VNC sessions. One with a red screen background as 'root', where I conveniently could do 'root' things, without having to enter my root password, like mounting drives, updating the server and so on. The other one with a green screen background as 'user', where I worked normally. Both users had to have a '.vnc' directory within their home directory. In the '.vnc' directory, I had to deposit an 'xstartup' file. The content of my 'xstartup' file was that: > #!/bin/bash > > # Uncomment the following two lines for normal desktop: > # unset SESSION_MANAGER > # exec /etc/X11/xinit/xinitrc > > [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup > [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources > > # Tastencodes fuer 'xmodmap' koennen mit 'xev' ermittelt werden > xmodmap -e 'keysym Super_R = Super_R' > xmodmap -e 'keysym ISO_Level3_Shift = ISO_Level3_Shift' > xmodmap -e 'keycode 255 = Super_R' > xmodmap -e 'keycode 253 = ISO_Level3_Shift' > xmodmap -e 'add mod4 = Super_R' > xmodmap -e 'add mod5 = ISO_Level3_Shift' > > xsetroot -solid grey > vncconfig & > echo -e -n "notRestarted\n">~/.vnc/vncHackRestart > export LC_TIME=de_DE@euro > fvwm -f ~/.fvwm/.fvwm2rc_vnc_hack & > # x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & > # x-window-manager & The chief task of an 'xstartup' file is to start some kind of X server and then a window manager after a VNC server gets started via '1_start_root.sh' or '3_start_user.sh'. The last line of my file did the window manager thing: It started FVWM with a Hack configuration. I explain the hack configuration later. The xmodmap lines solved my problem that I had with the special shift keys. Using a tool named 'xev', I pressed a key, and 'xev' gave me some key codes for the key I pressed. With these key codes in mind, I could use 'xmodmap' to make the keys known to the running VNC session. The 'xstartup' file did the make-them-known job every time I started a VNC server. I spent a lot of time to find out how I could use Shift, Control, Alt, Windows and AltGr in a VNC session. But, after I finally got the trick, this problem was solved. Another problem was that some special keys had other key codes in a VNC session than in a normal local session. An example was the ^/° key that exists on the left of the 1/! key on a German keyboard. At a US keyboard, this key is equivalent to the ~/` key (according to Wikipedia). My FVWM config uses this key to update the FVWM config or to show the version number of my FVWM config: - When I press <AltGr>+<Win>+<^/°>, FVWM removes its entire config files from the '~/.fvwm' directory and places new versions of the config files there. - When I press <AltGr>+<Win>+<Shift>+<^/°>, FVWM shows me some data: The base path where it fetches new config files from, the config version number (I have my own version number system to be able to keep track about my changes) and the FVWM use case. Normally, my FVWM config entries for that are the following two: > Key asciicircum A 54 Function RefreshFvwm > Key asciicircum A S54 Function ShowFvwmConfigInfo For each non-working short cut, I had to use 'xev' to find out the VNC specific key codes for that keys. For my <^/°> key, I had to lodge these config lines into the VNC specific part of the FVWM config: > Key Notsign A 54 Function RefreshFvwm > Key Notsign A S54 Function ShowFvwmConfigInfo Other examples of this issue were: - Normal config: > Key Pause A CM Restart > Key Pause A 54 Restart - VNC specific config: > Key Break A CM Restart > Key Break A 54 Restart But, after solving this, there still were some problems with key codes: I worked with OpenOffice/LibreOffice, and there were some keys I noted that they did not always work. For example: When I use OpenCalc to edit a spreadsheet, I go to a cell and want to edit it. What do I do when I want to format a cell (open the 'Format Cells' dialog box)? I can press <Ctrl>+<1> or I press the Window context key, a contect menu opens and I choose 'Format Cells...' from that menu. But, the Windows context menu key did not always work. I searched high and low, because I wanted to find out why this key sometimes worked and sometimes not. Then, there were other keys like German Umlauts that only sometimes worked when I typed text in OpenOffice Text Documents. Or there was the aforementioned <^/°> key, which also only sometimes refreshed my FVWM config and only sometimes called the 'ShowFvwmConfigInfo' function. Eventually, I found out: I have to use these keys, then have to restart FVWM, and then these keys work. Do you remember the line > fvwm -f ~/.fvwm/.fvwm2rc_vnc_hack & in my 'xstartup' file? This is the hack that solves the problem: When I started the VNC server, the VNC server started FVWM in the dirty Hack mode. This was the content of the '.fvwm2rc_vnc_hack' file: > Read > 2_use_case_specific/personalization.configs/1_common/1_virt_level/03_xen/0009_clock.fvwm > > AddToFunc StartFunction > + I Exec exec run_xterm_for_vnc_hack.sh > + I Schedule 2000 vncHack > > DestroyFunc vncHack > AddToFunc vncHack > + I PipeRead 'read VNC_HACK_RESTART <~/.vnc/vncHackRestart;\ > echo "SetEnv VNC_HACK_RESTART ${VNC_HACK_RESTART}"' > + I Test (EnvMatch VNC_HACK_RESTART notRestarted) Schedule 2000 vncHack > + I Test (EnvMatch VNC_HACK_RESTART restart) vncHackRestart > > DestroyFunc vncHackRestart > AddToFunc vncHackRestart > + I PipeRead 'echo restarted>~/.vnc/vncHackRestart' > + I PipeRead 'read VNC_HACK_PID_XTERM <~/.vnc/vncHackPidXterm;\ > kill ${VNC_HACK_PID_XTERM}' > + I Restart fvwm After the VNC server started, a very naked FVWM started without anything but the clock (because the clock was bound to the InitFunction, and the InitFunction is not called when FVWM restarts). This naked FVWM opened an xterm, which in turn started a script named 'run_xterm_for_vnc_hack.sh'. The content of 'run_xterm_for_vnc_hack.sh' was: > #!/bin/bash > > xterm -geometry 211x71 -e "echo 'Drücke die Kontextmenütaste, lösche die > Tilde und gib dann folgenden Code ein: ¬°”’äöüßÄÖÜ';bash"& > echo -e -n "${!}\n">~/.vnc/vncHackPidXterm So, the xterm said to me (in German) that I had to manually do the following: - Press the Windows context key (wich produced a tilde sign) - Delete the tilde sign (using the backspace key) - enter the following code: - ¬°”’äöüßÄÖÜ This basically forced me to press each key I could possibly need during this VNC session at least once. Once a key is pressed, FVWM and OpenOffice would recognize it after FVWM got restarted. In my PATH, I made a script available with the name '¬°”’äöüßÄÖÜ'. So, after I pressed each key at least once, all I had to do was hitting the Return key, and the '¬°”’äöüßÄÖÜ' started working. This was the content of the '¬°”’äöüßÄÖÜ' script: > #!/bin/bash > > echo -e -n "restart\n">~/.vnc/vncHackRestart My 'xstartup' contained this line: > echo -e -n "notRestarted\n">~/.vnc/vncHackRestart After I entered '¬°”’äöüßÄÖÜ' into the xterm, the '¬°”’äöüßÄÖÜ' changed the status from status 1 ('notRestarted') to status 2 ('restart'). The 'vncHack' function, which was started by the scheduler 2000 milliseconds after the start of FVWM, waited until the status was changed to status 2 ('restart'). When it happened, FVWM changed the status to status 3 ('restarted'), killed the xterm that forced me to enter the special key codes (because I didn't need it anymore and I was too lazy to close that xterm manually) and restarted FVWM. Once FVWM restarted, it loaded the normal FVWM config specialized in VNC. Then, there was another problem. The distance between client and server was about 10 kilometers. When I pressed a shift key (Shift, Control, Alt, Windows, AltGr), and holded it down, after a timeframe between 30 seconds and 2 minutes, the shift key stopped sending its key codes. Sometimes, the shift key even stopped sending its key code right after some milliseconds. This had the effect that I pressed a key kombination like <Control>+<C> and the application understood <C>, so instead of making a copy of selected text, the text disappeared and was replaced by a 'c'. Some more sophisticated short cuts sometimes did not work correctly. So, when I pressed <Shift>+<Win>+<Arrow down> to switch to another desktop, FVWM occasionally understood <Win>+<Arrow down> and switched to another page of the same desktop or understood <Shift>+<Arrow down> and marked a line of text instead of switching elsewhere. In Gedit/Pluma, I have the habit to repeatedly and alternately press <Ctrl>+<G> and <Ctrl>+<V> to replace a few occurrences of a word by another word. Via VNC, this process was most certainly always interrupted by the event that the software forgot that <Ctrl> was pressed. For the process of <Ctrl>+<G> and <Ctrl>+<V>, I had a solution: The xvnc4viewer had an option in the menu that I could select via mouse to let latch the Control key via software. All I had to do was pressing repeatedly and alternately <g> and <v> until the work was done. After I was done, I had to unlatch the key. (And yes, text editors have a search and replace option, but these options do not verify whether I really want to replace a particular character string.) OK, there was a workaround. But, this workaround only solved this kind of problems where repetition dominated the process. And some keys were missing: There were no options for <Win> and <AltGr>. And, as I remember, either <Shift> or <Alt> was missing too. I never found a solution for THIS problem. As long as I worked remotely, I was able to work, und the Shift-key-gots-forgotten problem bothered from time time. After some months, I significantly reduced the distance between VNC server and VNC client from 10 kilometers down to approximately 10 or 30 meters. Before reducing the distance, I hoped that this would solve my problem. Surprisingly, after reducing the distance, the problem was NOT solved, it worsened. The bandwidth between VNC server and VNC client was higher now, and there was no VPN anymore, but the shift keys got forgotten after a timeframe between few milliseconds (or nanoseconds) and 5 seconds now. >From now on, working with FVWM via VNC was definitely not reasonable anymore, and I hurriedly did what I hoped that I could take plenty of time with: Setting up an FVWM config on a personal computer, installing and configuring a lot of software there that was actually already installed and configured ready for use on the VNC server. Some software, I forwarded (and still forward) via X forward until it was/will be installed locally. I never figured out why the Shift-key-gots-forgotten problem worsened instead of improved after I significantly reduced the distance and improved the bandwith. This problem at all events stopped me from using FVWM via VNC on a daily basis. But, for about five months, I did 98% of my daily work in such an environment. Well, this was my life experience with FVWM via VNC over VPN. Did I forget some details? If so, ask me. Hendrik, I don't know why you doesn't have any key bindings in your FVWM environment. But, I don't have a VNC environment with the newest FVWM anyway. If you want, you could try a Wheezy with FVWM 2.5.30 and hear / read the warnings from other people to not use old versions of any kind of software. If you have more luck with older versions, then you have something that you can compare (old and working versus new and not working). I do not plan to set up another FVWM via VNC solution in the next years. I only have a life experience that I shared herewith. I hope, it gives somebody some ideas. Enjoy! :-) Michael
