Custom Query (16363 matches)
Results (1315 - 1317 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2302 | fixed | keys dead when remapped by xkb -> fixed in SVN | ||
| Description |
Xorg supports remapping keys via xkb. A typical way would be: Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbOptions" "therp:desktop"
Additionally we put the following line into /etc/X11/xkb/rules/base (or xorg in the same dir): therp:desktop = +therp(desktop) This teaches Xorg to treat the option string "therp:desktop" namely by resolving it to +therp(desktop). Further we need to add the line --p----- -m------ therp(desktop) to /etc/X11/xkb/symbols.dir And finally add a file called therp to /etc/X11/xkb/symbols with the following content: partial modifier_keys
xkb_symbols "desktop" {
key <AD11> { symbols[Group1]= [ parenleft, braceleft ] };
key <AD12> { symbols[Group1]= [ parenright, braceright ] };
key <AE09> { symbols[Group1]= [ 9, bracketleft ] };
key <AE10> { symbols[Group1]= [ 0, bracketright ] };
};
The effect of these lines is that the keys () and [] are swapped on the keyboard. I personally like that as I type round brackets more often and I like them to be accessible without the Shift modifier key. However, as soon as a key is touched by xkb, it goes dead for VirtualBox. Notice that 0 and 9 wasn't changed, however 0 and 9 don't work even unshifted. To make it work I have to adjust the layouts manually in the vbox source code and supply vbox with a keymap that resembles my remappings precisely. |
|||
| #2306 | fixed | where mouse is drawn on guest does not match mouse coordinates -> fixed in SVN | ||
| Description |
I've observed this on Debian Etch 64-bit guest running on Ubuntu 8.04 64-bit host; VirtualBox 2.0.2. With *some* guest screen resolutions (not all) the mouse seems to be drawn in the wrong location. Near the top of the screen, the mouse is OK. But as the mouse progresses through the Y axis towards the bottom of the screen, an offset appears between the drawn mouse and where X think the mouse is located. Near the bottom of the screen, I've seen a difference of maybe 100 pixels between the drawn mouse and where X thinks the mouse is located. This is very obvious when dragging a window towards the bottom of the screen, or trying to click on a button located near the bottom of the screen. End result is you must click anywhere between 50 to 100 pixels "higher" than where you actually want to click. Example resolution (/etc/X11/xorg.conf) where this problem does not happen: 1280x1024 Example resolutions where this problem occurs: 1400x940, 1152x864, 1200x950 Workaround: if I disable mouse integration then the mouse works fine. |
|||
| #2307 | fixed | Segfaults crashing GuestOS when starting VBox on other virtual desktop | ||
| Description |
I am running ArchLinux as the host OS. I'm using the Awesome window manager. And I have it set to always start my VBox WindowsXP guest on a certain virtual desktop. The crashes only seem to occur when I start it in a desktop other than the active one. These are the messages that get written to the system wide log for the crashes. You can see that it's not always to same message: Sep 23 00:11:16 localhost VirtualBox[18860]: segfault at 6000000c8 ip 6000000c8 sp 7fff5b91b8a8 error 14 Sep 23 00:11:59 localhost VirtualBox[18990]: segfault at 3000000c0 ip 7ffaf8617804 sp 7fff0343a3f8 error 4 in libQtGui.so.4.4.2[7ffaf842b000+820000] Sep 23 00:14:58 localhost VirtualBox[19293] general protection ip:7f76d863ae81 sp:7fffe2aa2a50 error:0 in libQtCore.so.4.4.2[7f76d84fc000+1f8000] Sep 23 00:17:27 localhost VirtualBox[19533]: segfault at 7f680467df80 ip 7f680467df80 sp 7fff0cfc4fd8 error 15 Sep 23 00:21:13 localhost VirtualBox[19757] general protection ip:7fd22dc84e81 sp:7fff380ec110 error:0 in libQtCore.so.4.4.2[7fd22db46000+1f8000] I did do core dump for it as well. But the file is 80MB compressed, so I'm not sure how that should be handled. |
|||

