id,summary,reporter,owner,description,type,status,component,version,resolution,keywords,cc,guest,host 6134,With guest additions control-S can't be typed into guest: guest linux and host XP. 3.1.2 -> guest configuration issue,ci-zephyurus,,"I have had the same problem mentioned in bug 5832 But here is a twist. In my case, I can't type control-S to the terminal window in guest linux somehow. This makes it very difficult to use Emacs editor where control-S is used for incremental search and saving a buffer is control-X and control-S, etc.. I am attaching below the description of the problem I had before I realized bug 5832 posting. The major problem was the stuck mouse, and then this failure to input control-S :-( --- Strange failure of mouse/desktop integration during upgrade to 3.1.2 I experienced the following strange problem which was eventually cleared up more or less (except for control-S input problem to emacs). I am reporting it here so that others who experience something similar may be able to follow my lead to get out of the pit, so to speak. Also, this may warn developers that something is fishy in the way the current tool distributed with 3.0.12 may handle mouse/desktop integration. Symptom and Background: I have used 3.0.10 for a while to run Debian linux under Win XP host. I recently downloaded 3.1.2 (three days ago.) and upgraded to it. I ran guest linux inside the new 3.1.2 virtualbox, and noticed that the mouse integration (the feature to move mouse cursor over vbox and the underlying host window background without the need to ""capture"" or hit right-control to move in between these windows.) no longer works. I now had to hit right-control to release the mouse focus from virtualbox to move to other applications under XP host. I figured that the virtual box support tool installed in guest linux must be outdated or incompatible with 3.1.2. So I re-installed the NEW tool in the guest linux. (Caution: I vaguely recalled seeing that the installation process stated that the script didn't update xorg.conf since it believed the script was generated by virtualbox script, and no change was necessary. This may be the cause of the proble detailed below, but I am not sure.) I rebooted the guest so that the new tool drivers, etc. will be effective to make the mouse integration work again. *Now, the funny behavior.* (*) I could enter username and password to gnome login box. Again, so fa, so good. (This is the correct working part which I found rather strange considering the later behavior.) *BUT* once the gnome desktop appears, I can't click on the linux icons or desktop background to invoke programs. There was nothing I could do because I could not invoke any program at all using mouse clicks! (My initial desktop has no terminal open and so I could not type anything to it. Then I wonder if I could type something under this strange behavior anyway. But I digress.U) Also, I noticed that the mouse movement was rather flakey. It seemed to move up and down mostly no matter how hard I tried to move it horizontally. The only place where mouse button is recognized is when I move the cursor out of virtualbox window in the downward direction and trying moving it upward again into the gnome desktop shown inside virtual box [I forgot to metion that the newly installed toolbox now seemed to handle the resizing of the guest linux window, at least], and then somehow the virtual desktop switcher, which allows me to switch among four saved desktops offered to show the pop-up menu. But then again, I could not choose any of the menu items or mark on/off any of the check boxes therein. So I could not do a thing. I have seen strange behavior of mouse that rendered GUI useless when the mouse driver was not correct for the particular mouse used under X. So I figured that maybe the newly installed virtualbox tool was to blame, since this type of pointing device error is often to blam on incorrect mouse driver, etc., I decided to remove the new tool. I rebooted the guest OS : luckily, from the virtualbox menu, I could invoke ACPI power-off, which in turn started the guest linux OS shutdown in one minute. Otherwise, I was at a loss what to do. Firstly, I downgraded virtual box to 3.0.10 to see if this helps. No. Unfotunately, the strange symptom of inffective mouse handling continued now with the older 3.0.10, too. So I really thought the new tool was to blame and decided to remove it. But without being able to interact with GUI, how do we manage removing the tool for the time being. I shutdowned the linux guest by ACPI power-off again. When I booted the guest linux again, I entered into single user mode from grub menu, and once I log in as superuser, I removed /lib/modules/*my-linux-kernel-vesiond*/vbox*.ko There were to such ko modules. I left the vfs-related modules since I needed file sharing between host XP and guest linux very much although I can live with non-integration of mouse. Unfortunately, when I entered the multi-user mode, the lack of mouse integration also means that the we lack the auto resizing of desktop of guest linux to the virtualbox window under XP desktop. This is VERY inconvenient since I wanted to use the full screen occasionally from within guest linux, but this time when I enlarge virtualbox window, the gnome desktop in the linux guest remained in the original size and thus very small inside the enlarged virtualbox window. So I need the working .ko for desktop integration. I got stuck :-( Then I recalled the message that stated /etc/X11/xorg.conf was not re-created during virtualbox tool install since the installation script thought xorg.conf was originally created by virtualbox tool installer. Hmm. So I thought of editing /etc/X11/xorg.conf, but found it contained very few lines. No way to edit it in a meaningful way to placate the misbehaving tool, I thought. I got stuck again. Well, then I did something drastic. I simply removed xorg.conf. (Actually, I renamed it.) and decided to see how this would work out. I hit control+alt+backspace which will restart X server only in guest linux. I half expected the failure of X server. Instead, to my surprise, X started all right! Although the integration didn't work (because I removed the applicable *.ko), somehow X was usable anyway. [I wonder where X server picked up the default and looked at /var/log/Xorg.0.log, etc. It seemd that X server used default built into the binary, etc. and managed to come up and work!] After checking the behavior of shutting down and rebooting a few times, I decided to install toolkit again. This is because I sensed that the failure to replace xorg.conf during installation was possibly the cause of the failure This time, the installation produced xorg.conf since there was no xorg.conf under /etc/X11/ to speak of. (this was under 3.0.10. Funny, though, I could not find the ""old"" image of toolkit presumably installed for 3.0.10, but I only could install the later toolkit possibly installed by 3.1.2). After the tool installation, I shutdown X server only [C-ALT-BS] and saw that the integration now works and I could click on icons of Gnome desktop and invoke programs and type something into newly started terminal windows. So now, I shut down guest linux and decided to upgrade to 3.1.2 again. This time around, after a period of suspence, I saw that the mouse/desktop integration works correctly with virtualbox 3.1.2 EXCEPT for I can't type control-S to emacs window somehow!!! I have no idea why. This failure to pass contro-S to emacs is right now the only mouse/desktop integration problem that remains. There can be still a lurking problem with the toolkit distributed with 3.1.2. TIA ",defect,closed,other,VirtualBox 3.1.2,invalid,,,Linux,Windows