We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1040

Summary: Tablets are unuseable in fullscreen mode with cursor hidden.
Product: SDL Reporter: PulkoMandy <pulkomandy>
Component: eventsAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED ENDOFLIFE QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: buratin.barabanus, Daniel-Knobe, support
Version: 1.2.14   
Hardware: All   
OS: Windows (XP)   

Description PulkoMandy 2010-08-06 06:58:30 UTC 
When in fullscreen mode and cursor is hidden with SDL_ShowCursor(0), the mouse coordinates from the OS seems to always be interpreted as relative, whereas when a tablet is plugged, they should be taken as absolute.

Everything works as expected in windowed mode or when you show the cursor, but as soon as you switch to fullscreen and hide the cursor, to keep the mouse position fixed you have to point right to the center of the tablet, else the cursor drifts as if the coordinate coming from the tablet were relative.

Our current fix in the GrafX2 project is to set the cursor to be visible, but use an 1x1 transparent bitmap as cursor, so it's not actually visible. This is also used by the game Barrage. Using the environment variable SDL_MOUSE_RELATIVE to 0, as suggested somewhere else on the internet, doesn't look like it's working for us.

References :
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg737265.html
http://code.google.com/p/grafx2/source/detail?r=1553
Comment 1 barabanus 2011-02-18 23:58:33 UTC 
I confirm this bug: http://www.adventuredevelopers.com/forum/index.php?topic=2952.0

It wasn't possible to play in adventure games using pen tablets in fullscreen mode.
Comment 2 Sam Lantinga 2011-02-19 11:20:32 UTC 
Is it possible to detect whether the mouse input is coming from a tablet or a mouse?
Comment 3 barabanus 2011-02-19 11:28:34 UTC 
I'm not sure, but what if SDL wouldn't actually hide the cursor, but rather set it transparent?

Who would use actual cursor hiding if it doesn't work properly?
Comment 4 Sam Lantinga 2011-12-30 02:42:59 UTC 
It's SDL that is setting relative mouse mode when the cursor is hidden by the application.  That's by design, but it's counterproductive when the input is coming from a tablet in absolute mode.  The trick is how do we detect this situation?
Comment 5 Sam Lantinga 2012-01-02 00:11:25 UTC 
*** Bug 1060 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Knobe 2013-11-21 16:04:37 UTC 
It works on all levels, this are the options:
<application android:hardwareAccelerated="true" ...>
or
<activity android:hardwareAccelerated="true" />
or
getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
in the onCreate() method.
Comment 7 Daniel Knobe 2013-11-21 16:05:09 UTC 
Sry wrong bug.
Comment 8 Ryan C. Gordon 2015-08-25 09:38:20 UTC 
Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we _will_ accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.