Why is mouse capture needed to be able to emulate the mouse? Why can't you just send mouse movement packets while the cursor is moving over/inside the bochs window?
I hope the Bochs developers don't mind me replying, I'm interested in not having to capture the mouse when in USB tablet mode.
Capture is necessary when emulating a mouse
Bochs emulates a mouse by default, and mice provide relative motion - left, right, etc. - rather than absolute, and this requires capture.
Imagine that the guest's mouse cursor is at the right edge of the guest's screen, and you want to move it to the left edge of the screen. If capture wasn't used and you moved the mouse over the Bochs window from the right edge of the window and then moved it all the way to the left edge of the Bochs window, thereby delivering the maximum amount of leftward motion possible, this might not actually move the guest's cursor all the way to the left edge of the guest's screen if the guest's mouse cursor movement speed is slower relative to the host's. Then you would need to move your mouse back to the right hand edge of the Bochs window by going around the outside of the window without crossing it and deliver some more leftward motion. If you accidentally cross the corner of the Bochs window while moving around the outside of it, you might accidentally move the cursor right a bit. This is not very nice!
Capture means that all your mouse movements are delivered to the guest - they don't stop when your mouse happens to leave the bounds of the Bochs window - so it's easier to move the guest cursor around.
Capture can be avoided with a tablet, but isn't yet
Bochs can also emulate a USB tablet pointing device. This is an absolute pointing device, so the cursor position over the Bochs window can be directly passed to the guest via the emulated pointing device, and hence it isn't necessary for the mouse to be captured to enable the mouse cursor in the guest to be controlled properly.
Other software like Qemu doesn't require the mouse to be captured to allow you to control the emulated USB tablet, but Bochs does. I found this thread where a similar request was made some time ago, and at that time Bochs was updated to add some support to enable the USB tablet to be used without mouse capture - a post in that thread indicated that at least some of the GUIs (X11 and SDL) are able to send absolute mouse position to the emulated device - but capture is still required. It seems that more work is required to remove the requirement for mouse capture in order to make it more "friendly".
Investigation
I'm not a Bochs developer, but I was interested in how much work it would be to address this and took a quick look at the Bochs 2.7 code.
I found that in iodev/devices.cc, mouse_motion() ignores mouse motion if the mouse isn't captured. Presumably it would be easy to change this to never ignore the motion when using a USB tablet.
However, I also found that in the SDL driver sdl.cc, mouse motion is ignored unless the sdl_grab flag is set. This presumably means that all the drivers would need some work to remove the capture requirement.
Making those two little changes did give me the ability to move the mouse around without capture and also left click, but I can't right click for some reason. Some work would also be required to hide the host cursor so that when the guest's cursor hasn't caught up yet there aren't two cursors shown.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Correction: capture can be avoided with a tablet, and essentially is with either of these settings:
display_library:wxdisplay_library:x
but is not with:
display_library:sdl
Specifically when I test on CentOS 7 built against wxGTK3 and the standard X libraries, with either of the first two settings listed above, "mouse capture" is more like a "mouse enabled" state when using a USB tablet (at least with Windows 98 SE): when the mouse is "captured", the mouse can still leave the guest part of the window, so the only effect of "mouse capture" is that when it's turned on mouse movements are not sent to the guest.
SDL (which is all I tested previously) is the odd one out of these three in that mouse capture really does capture the mouse in the guest area of the window.
Mouse capture can be enabled by default using:
mouse: enabled=1
Even though the mouse setting is for configuring a non-USB mouse, the enabled part of the setting applies to the USB tablet too, so with a combination of display_library: x or wx, a USB tablet and mouse: enabled=1, you can get nice behaviour.
I don't know what the status of other display libraries is with regards to mouse capture when using a USB tablet, e.g. win32 or carbon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hope the Bochs developers don't mind me replying, I'm interested in not having to capture the mouse when in USB tablet mode.
Capture is necessary when emulating a mouse
Bochs emulates a mouse by default, and mice provide relative motion - left, right, etc. - rather than absolute, and this requires capture.
Imagine that the guest's mouse cursor is at the right edge of the guest's screen, and you want to move it to the left edge of the screen. If capture wasn't used and you moved the mouse over the Bochs window from the right edge of the window and then moved it all the way to the left edge of the Bochs window, thereby delivering the maximum amount of leftward motion possible, this might not actually move the guest's cursor all the way to the left edge of the guest's screen if the guest's mouse cursor movement speed is slower relative to the host's. Then you would need to move your mouse back to the right hand edge of the Bochs window by going around the outside of the window without crossing it and deliver some more leftward motion. If you accidentally cross the corner of the Bochs window while moving around the outside of it, you might accidentally move the cursor right a bit. This is not very nice!
Capture means that all your mouse movements are delivered to the guest - they don't stop when your mouse happens to leave the bounds of the Bochs window - so it's easier to move the guest cursor around.
Capture can be avoided with a tablet, but isn't yet
Bochs can also emulate a USB tablet pointing device. This is an absolute pointing device, so the cursor position over the Bochs window can be directly passed to the guest via the emulated pointing device, and hence it isn't necessary for the mouse to be captured to enable the mouse cursor in the guest to be controlled properly.
Other software like Qemu doesn't require the mouse to be captured to allow you to control the emulated USB tablet, but Bochs does. I found this thread where a similar request was made some time ago, and at that time Bochs was updated to add some support to enable the USB tablet to be used without mouse capture - a post in that thread indicated that at least some of the GUIs (X11 and SDL) are able to send absolute mouse position to the emulated device - but capture is still required. It seems that more work is required to remove the requirement for mouse capture in order to make it more "friendly".
Investigation
I'm not a Bochs developer, but I was interested in how much work it would be to address this and took a quick look at the Bochs 2.7 code.
I found that in
iodev/devices.cc,mouse_motion()ignores mouse motion if the mouse isn't captured. Presumably it would be easy to change this to never ignore the motion when using a USB tablet.However, I also found that in the SDL driver
sdl.cc, mouse motion is ignored unless thesdl_grabflag is set. This presumably means that all the drivers would need some work to remove the capture requirement.Making those two little changes did give me the ability to move the mouse around without capture and also left click, but I can't right click for some reason. Some work would also be required to hide the host cursor so that when the guest's cursor hasn't caught up yet there aren't two cursors shown.
Correction: capture can be avoided with a tablet, and essentially is with either of these settings:
but is not with:
Specifically when I test on CentOS 7 built against wxGTK3 and the standard X libraries, with either of the first two settings listed above, "mouse capture" is more like a "mouse enabled" state when using a USB tablet (at least with Windows 98 SE): when the mouse is "captured", the mouse can still leave the guest part of the window, so the only effect of "mouse capture" is that when it's turned on mouse movements are not sent to the guest.
SDL (which is all I tested previously) is the odd one out of these three in that mouse capture really does capture the mouse in the guest area of the window.
Mouse capture can be enabled by default using:
Even though the
mousesetting is for configuring a non-USB mouse, theenabledpart of the setting applies to the USB tablet too, so with a combination ofdisplay_library: xorwx, a USB tablet andmouse: enabled=1, you can get nice behaviour.I don't know what the status of other display libraries is with regards to mouse capture when using a USB tablet, e.g.
win32orcarbon.