I'm not quite sure where the problem is here, but when I enable Kempston mouse support, it acts more like a random number generator.
My setup: Lenovo T450 (mouse is trackpad), Windows 7, running VirtualBox 5.0.26, running Solaris 12 (with VBox extensions installed).
I'm seeing this random behaviour with fuse 1.1.1 and 1.3.0. If I run fuse 1.3.0 for Windows on the same system, it works fine.
So I'm not sure which of the many layers the problem is in. Any tips on figuring it out?
Tomorrow I'll try bare-metal Solaris in case VirtualBox is causing a problem, but no other application under Vbox seems to suffer with mouse-related issues, and the "xev" program shows a smooth progression of mouse x/y values when moving the mouse slowly.
This happens with both the SDL ui and the gtk ui.
Adding a crude printf of "(int)event->x" (and y) to ui/gtk/gtkmouse.c shows we generally get a line of 128/128 interleaved with real mouse data when moving the pointer slowly in one direction (as best I can with a trackpad):
I think this is being caused by the implicit truncation / casting of the gdouble 'x' and 'y' into the int parameters for the call to ui_mouse_motion(). If I look at the values coming out there, I see values like this as I move the mouse around:
ui_mouse_motion: x 110 y 214
ui_mouse_motion: x 109 y 214
ui_mouse_motion: x 108 y 214
ui_mouse_motion: x 106 y 214
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 104 y 215
ui_mouse_motion: x 99 y 218
ui_mouse_motion: x 90 y 221
ui_mouse_motion: x 84 y 222
ui_mouse_motion: x 64 y 226
ui_mouse_motion: x 57 y 226
ui_mouse_motion: x 52 y 227
ui_mouse_motion: x 47 y 227
ui_mouse_motion: x 43 y 227
ui_mouse_motion: x 38 y 227
ui_mouse_motion: x 35 y 227
ui_mouse_motion: x 32 y 227
ui_mouse_motion: x 28 y 227
ui_mouse_motion: x 25 y 227
ui_mouse_motion: x 22 y 227
ui_mouse_motion: x 18 y 227
ui_mouse_motion: x 17 y 227
ui_mouse_motion: x 14 y 227
ui_mouse_motion: x 13 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 10 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 8 y 227
ui_mouse_motion: x 7 y 227
ui_mouse_motion: x 5 y 227
ui_mouse_motion: x 4 y 227
ui_mouse_motion: x 3 y 227
ui_mouse_motion: x 2 y 227
ui_mouse_motion: x 0 y 227
ui_mouse_motion: x -1 y 227
ui_mouse_motion: x -2 y 227
ui_mouse_motion: x -4 y 227
ui_mouse_motion: x -5 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -7 y 227
ui_mouse_motion: x -8 y 227
ui_mouse_motion: x -10 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -11 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -12 y 227
ui_mouse_motion: x -13 y 227
ui_mouse_motion: x -14 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -15 y 227
ui_mouse_motion: x -16 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -17 y 227
The recurring 0,0 seems somewhat strange, but we also get the values going negative. Furthermore, it seems from the above that ui_mouse_motion() is being called with some kind of relative position (relative to the top-left corner of fuse's window?), but kempmouse_update expects a delta value pair dx,dy. This presumably causes the calculations to go haywire, and thus the cursor jumps and is hard to move.
Thoughts welcome - it's been a while since I did any X programming, and then, that was nearly 20 years ago!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried on bare-metal Solaris, and it works fine. This is looking like a VBox interaction issue, or perhaps the X pointer is run in a different "mode" when under VBox?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That does seem to work around it, but makes everything else rather awkward to use until I turn it back on. I wonder if there is a way to detect and handle it within fuse, or perhaps a simpler and more general way to handle the mouse without using the XWarpPointer calls.
The accuracy of moving the mouse wasn't the problem - it's the values jumping all over the place which was the issue due to the relative / absolute mismatch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The XWarpPointer method is restrictive as we could use GTK+ UI with quartz, win32 or wayland backends (without x11). Fuse should accept different ways of mouse handling. The relative pointer and confinement on wayland and libinput is an interesting one.
I'm not quite sure where the problem is here, but when I enable Kempston mouse support, it acts more like a random number generator.
My setup: Lenovo T450 (mouse is trackpad), Windows 7, running VirtualBox 5.0.26, running Solaris 12 (with VBox extensions installed).
I'm seeing this random behaviour with fuse 1.1.1 and 1.3.0. If I run fuse 1.3.0 for Windows on the same system, it works fine.
So I'm not sure which of the many layers the problem is in. Any tips on figuring it out?
Tomorrow I'll try bare-metal Solaris in case VirtualBox is causing a problem, but no other application under Vbox seems to suffer with mouse-related issues, and the "xev" program shows a smooth progression of mouse x/y values when moving the mouse slowly.
This happens with both the SDL ui and the gtk ui.
Adding a crude printf of "(int)event->x" (and y) to ui/gtk/gtkmouse.c shows we generally get a line of 128/128 interleaved with real mouse data when moving the pointer slowly in one direction (as best I can with a trackpad):
mouseX = 128 mouseY = 128
mouseX = 593 mouseY = 339
mouseX = 595 mouseY = 339
mouseX = 128 mouseY = 128
mouseX = 596 mouseY = 339
mouseX = 597 mouseY = 339
mouseX = 128 mouseY = 128
mouseX = 600 mouseY = 339
mouseX = 128 mouseY = 128
mouseX = 601 mouseY = 339
mouseX = 128 mouseY = 128
mouseX = 602 mouseY = 339
mouseX = 128 mouseY = 128
mouseX = 603 mouseY = 339
I think this is being caused by the implicit truncation / casting of the gdouble 'x' and 'y' into the int parameters for the call to ui_mouse_motion(). If I look at the values coming out there, I see values like this as I move the mouse around:
ui_mouse_motion: x 110 y 214
ui_mouse_motion: x 109 y 214
ui_mouse_motion: x 108 y 214
ui_mouse_motion: x 106 y 214
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 104 y 215
ui_mouse_motion: x 99 y 218
ui_mouse_motion: x 90 y 221
ui_mouse_motion: x 84 y 222
ui_mouse_motion: x 64 y 226
ui_mouse_motion: x 57 y 226
ui_mouse_motion: x 52 y 227
ui_mouse_motion: x 47 y 227
ui_mouse_motion: x 43 y 227
ui_mouse_motion: x 38 y 227
ui_mouse_motion: x 35 y 227
ui_mouse_motion: x 32 y 227
ui_mouse_motion: x 28 y 227
ui_mouse_motion: x 25 y 227
ui_mouse_motion: x 22 y 227
ui_mouse_motion: x 18 y 227
ui_mouse_motion: x 17 y 227
ui_mouse_motion: x 14 y 227
ui_mouse_motion: x 13 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 10 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x 8 y 227
ui_mouse_motion: x 7 y 227
ui_mouse_motion: x 5 y 227
ui_mouse_motion: x 4 y 227
ui_mouse_motion: x 3 y 227
ui_mouse_motion: x 2 y 227
ui_mouse_motion: x 0 y 227
ui_mouse_motion: x -1 y 227
ui_mouse_motion: x -2 y 227
ui_mouse_motion: x -4 y 227
ui_mouse_motion: x -5 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -7 y 227
ui_mouse_motion: x -8 y 227
ui_mouse_motion: x -10 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -11 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -12 y 227
ui_mouse_motion: x -13 y 227
ui_mouse_motion: x -14 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -15 y 227
ui_mouse_motion: x -16 y 227
ui_mouse_motion: x 0 y 0
ui_mouse_motion: x -17 y 227
The recurring 0,0 seems somewhat strange, but we also get the values going negative. Furthermore, it seems from the above that ui_mouse_motion() is being called with some kind of relative position (relative to the top-left corner of fuse's window?), but kempmouse_update expects a delta value pair dx,dy. This presumably causes the calculations to go haywire, and thus the cursor jumps and is hard to move.
Thoughts welcome - it's been a while since I did any X programming, and then, that was nearly 20 years ago!
I've tried on bare-metal Solaris, and it works fine. This is looking like a VBox interaction issue, or perhaps the X pointer is run in a different "mode" when under VBox?
Hi Brian. I've seen that issue before. Try to disable the Input -> Mouse integration, so VirtualBox can grab the cursor.
I think the "PS/2 mouse" virtual pointing device and a real mouse (rather than a touchpad) could give extra accuracy.
That does seem to work around it, but makes everything else rather awkward to use until I turn it back on. I wonder if there is a way to detect and handle it within fuse, or perhaps a simpler and more general way to handle the mouse without using the XWarpPointer calls.
The accuracy of moving the mouse wasn't the problem - it's the values jumping all over the place which was the issue due to the relative / absolute mismatch.
The XWarpPointer method is restrictive as we could use GTK+ UI with quartz, win32 or wayland backends (without x11). Fuse should accept different ways of mouse handling. The relative pointer and confinement on wayland and libinput is an interesting one.
http://www.phoronix.com/scan.php?page=news_item&px=Relative-Pointer-Weston
http://www.phoronix.com/scan.php?page=news_item&px=MTg1MjY