#2763 closed defect
SDL: Mouse doesn't work right in full screen.
| Reported by: | SF/hatchetman1618 | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | Port: Linux |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
* ScummVM version: 0.10.0svn July 22 2006 * Bug details: When running scummvm on my pda with X11, the mouse cursor looses sync with the stylus often leaving the curse off to the side of where I touch. This only occurs when using the fullscreen option in options. If I leave fullscreen unchecked then the mouse works flawlessly. This happens in every game I've tried so far.
The cursor initially is correct, the problem begins to occur when the cursor touches any of the edges of the snree.
* Platform and Compiler: arm-linux-gcc (GCC) 3.4.4 I am running with SDL-1.2.7
xdpyinfo name of display: :0.0 version number: 11.0 vendor string: freedesktop.org vendor release number: 6710 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 4, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 254 focus: window 0x2400004, revert to PointerRoot number of extensions: 17 BIG-REQUESTS Composite DAMAGE MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SHAPE SYNC X-Resource XC-MISC XCALIBRATE XFIXES XTEST XVideo default screen number: 0 number of screens: 1
screen #0:
dimensions: 640x480 pixels (217x163 millimeters)
resolution: 75x75 dots per inch
depths (7): 1, 4, 8, 15, 16, 24, 32
root window id: 0x3b
depth of root window: 16 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 64
preallocated pixels: black 0, white 65535
options: backing-store NO, save-unders NO
largest cursor: 640x480
current input event mask: 0x5a0000
StructureNotifyMask SubstructureNotifyMask
SubstructureRedirectMask
PropertyChangeMask
number of visuals: 3
default visual id: 0x21
visual:
visual id: 0x21
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x38
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x39
class: TrueColor
depth: 32 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
Ticket imported from: #1529248. Ticket imported from: bugs/2763.
Change History (13)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
| Summary: | Mouse doesn't work right in full screen. → SDL: Mouse doesn't work right in full screen. |
|---|
comment:3 by , 18 years ago
I tried other SDL applications and tried to reproduce the effect without any luck. They also had full screen options, but did not mess up the cursor. I suspected it might be the mouse scaling in scummvm that gets confused for some reason when in fullscreen. Maybe that confusion comes from a bug in SDL. If you have any suggestions of how I could verify it one way or the other I would be happy to experiment.
My screen is 640x480, which is the size of the scummvm program window. When I switch to full screen, the size of the window doesn't get any bigger, just appears on top of my task bar. Could it be relevent that switching from windowed mode to full screen mode when not actually changing size causes a problem with the math?
Another thing I've noticed on my desktop is there is no apparent way to tell if the problem is actually occuring. You only see the scummvm cursor, and my eyes would never see an offset with the real mouse cursor. On my PDA the stylus touching in the same place, I expect the scummvm cursor in the same place and can tell when it's not.
comment:4 by , 18 years ago
I did some testing on my desktop machine using NX (I think VNC will accomplish the same thing) so that I could see the placement of the mouse as it reached the edges of the screen. The problem does become pretty apparent when you move the cursor in and out of the remote window.
comment:5 by , 18 years ago
| Priority: | normal → low |
|---|
comment:7 by , 17 years ago
When I was reading through the code trying to find a solution there was some code to adjust the mouse input scale to the scale of the game on screen. That's what I suspected. The problem ONLY occurs when I put ScummVM into full screen mode. Leaving it windowed and it works perfectly. Cntrl-m did not work on my PDA, however I don't recall if I tried it on the PC.
comment:8 by , 16 years ago
Actually, from what you describe, the problem is not at all due to mouse scaling. Rather, it sounds as if it's a problem with "relative" vs. "absolute" mouse coordinates. Still, it's odd that other SDL apps work fine...
So two questions: 1) Just to make sure, does it still happen with current SVN / daily builds? 2) Do you have "black borders" around the game graphics when using full screen?
comment:9 by , 16 years ago
| Status: | new → pending |
|---|
comment:10 by , 16 years ago
What is the status of this item? Is the issue still occurring with ScummVM 0.11.1 (or 0.12, which we'll release tomorrow) ? Does using a recent SDL version (1.2.13) have any effect?
Setting this item to pending.
comment:11 by , 16 years ago
| Status: | pending → closed |
|---|
comment:12 by , 16 years ago
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
comment:13 by , 5 years ago
| Component: | --Unset-- → Port: Linux |
|---|
This would be a bug in SDL, or maybe one in your system's drivers, but is quite unlikely to be caused by ScummVM itself.
Maybe updating to a newer version of SDL will help, though (1.2.11 is current, and 1.2.7 was released in Februrar 2004).