This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS (SDL-1.2-directx-cursor-fixes.diff, text/plain, 2009-11-26 14:41:04 +0000, 2536 bytes)
• Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS (SDL-1.2-directx-cursor-fixes2.diff, text/plain, 2009-12-10 06:48:11 +0000, 3611 bytes)

Reported in version: 1.2.14
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2009-10-16 09:14:23 +0000, wrote:

The mouse cursor totally disappears when other applications get active and happen to move the mouse over the area of an SDL application!

Details:
When the SDL app releases the mouse grab and shows and redraws the cursors to allow the user to use other applications the standard Windows cursor appears when the mouse leaves the SDL app window. The SDL app cursor appears and moves again when the mouse enters the SDL window area - this is correct and unmodified to earlier releases.

But when the user once activates another application by clicking in another window and move then the cursor back to SDL app window the standard cursor disappears and no SDL cursor appears. The user has no idea where the mouse is! Just when activating the SDL app by clicking blindly anywhere within the SDL window the SDL cursor reappears. This behaviour has changed to earlier SDL releases and is certainly a serious bug.

I just tested this feature on Windows XP with the todays third prerelease of 1.2.14. The application is a MinGW compilation. Other operating systems still need to be tested.

On 2009-10-16 13:23:19 +0000, Adam Olsen wrote:

Sounds like the same bug I just reported against OpenTTD: http://bugs.openttd.org/task/3267

Using linux (gnome desktop), moving the mouse out and back in the window makes it disappear and reappear as expected. However, if I move it out, alt-tab so another window covers the libsdl window, move the mouse over it, then alt-tab to bring the libsdl window into focus, the cursor never reappears (although the game still reacts to it).

SDL 1.2.13-4ubuntu3 in Ubuntu 9.04. MX5000 bluetooth keyboard and mouse.

On 2009-10-17 04:48:39 +0000, wrote:

I checked meanwhile SDL 1.2.11,1.2.12,1.2.13 on Windows. All these versions show the cursor correctly. I just checked SDL 1.2.13, KDE on SUSE Linux - it shows the cursor correctly, too.

On 2009-10-17 08:46:27 +0000, wrote:

Narrowed down the source of this bug to svn commit # 4478 on fix of bug # 611.

On 2009-10-17 09:22:51 +0000, Sam Lantinga wrote:

Do you have an application I can use to test with this? I tried testing with testwm, and it appeared to work as I expected.

On 2009-10-17 09:32:12 +0000, Sam Lantinga wrote:

Nevermind, I can reproduce this with Enigma. I'm investigating this now.

On 2009-10-17 09:38:14 +0000, wrote:

(In reply to comment # 5)

Nevermind, I can reproduce this with Enigma. I'm investigating this now.

Exactly - this is my project. Ask for any help if you need info about this project.

On 2009-10-17 09:49:48 +0000, Sam Lantinga wrote:

This is fixed for release, thanks!

On 2009-10-17 12:57:19 +0000, Tim Angus wrote:

Oops!

On 2009-10-17 13:29:36 +0000, Sam Lantinga wrote:

laugh No worries. :)

On 2009-11-22 14:12:11 +0000, wrote:

The bug has been successfully fixed for the GDI driver. But revision 4478 breaks the DirectX driver with the same effects, too!

On 2009-11-26 14:41:04 +0000, Tim Angus wrote:

Created attachment 450
Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS

The problems with the directx driver are similar to the ones I introduced in the windib driver with r4478. Basically if the application did not have focus, the mouse position is not updated. It's not really that the mouse cursor was invisible, it's that it is stuck underneath another window where you can't see it. This behaviour predates my r4478 changes and is the reason I unwittingly broke the windib driver as I had been replicating the way the directx driver deals with focus. Prior to r4478 the directx driver could not be used in windowed mode, so the broken focusing would not have actually been observable.

Anyway, the attached patch makes the directx driver behaves like the windib driver in terms of focus.

Time for 1.2.15? ;)

On 2009-12-10 06:48:11 +0000, Tim Angus wrote:

Created attachment 460
Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS

I've added an additional change of moving the calls to WIN_GrabInput that are made on WM_ACTIVATE messages so that they only occur when the state is SDL_APPINPUTFOCUS. When a fullscreen application is minimised using alt-tab, it still receives WM_ACTIVATE messages when other applications are selected. If WIN_GrabInput is called when the SDL application doesn't have input focus, bad things happen; it shouldn't be being called at all.

I've also added a line to make sure that SDL_APPMOUSEFOCUS state is dropped when the application is minimised following an alt-tab.

On 2009-12-11 07:26:07 +0000, Sam Lantinga wrote:

I've added your patch to subversion, thanks!

Yes, it's getting pretty close to time for 1.2.15 :)

On 2009-12-11 08:26:26 +0000, wrote:

(In reply to comment # 12)

Created an attachment (id=460) [details]
Fix to the cursor not being responsive when the app doesn't have
SDL_APPINPUTFOCUS

I've added an additional change of moving the calls to WIN_GrabInput...
Great! We discussed this bug on the Enigma devel mailinglist a week ago. Besides your fix I noticed a troublesome code in WIN_GrabInput line 240f:

if ( mode == SDL_GRAB_OFF ) {
ClipCursor(NULL);

First this code has no error handling! It is fatal if an SDL app gets inactive without successful releasing its input grab.

Second it is critical behaviour if an SDL app resets the grab to the full screen area on grab release. It should reset the grab area to the rectangle that has been valid when it started grabbing the input.

On 2009-12-11 11:50:27 +0000, Tim Angus wrote:

(In reply to comment # 14)

    ClipCursor(NULL);

First this code has no error handling! It is fatal if an SDL app gets inactive
without successful releasing its input grab.

MSDN isn't clear, but I would be surprised if calling ClipCursor(NULL) /could/ fail. In fact the only failure mode I can really see happening is if you pass in a bad rectangle. You're right to point out the lack of error handling but there are loads of examples of this throughout SDL and virtually every other bit of software out there, so it's probably not worth focusing on it too much.

Second it is critical behaviour if an SDL app resets the grab to the full
screen area on grab release. It should reset the grab area to the rectangle
that has been valid when it started grabbing the input.

I think you're suggesting that before initially setting a cursor clip, SDL should call GetClipCursor and save the value it returns. Thereafter in places where ClipCursor(NULL) is currently called it should instead use the saved value? In other words if the SDL app has set its own cursor clip, SDL should restore to whatever that is?

Strictly speaking you probably have a point here, but I think the actual value of doing this is pretty limited. SDL is after all a platform abstraction library, so if you're SDL based application is also calling platform specific code (e.g. ClipCursor), is that not defeating the point of using SDL in the first place to some extent? In any case it's probably worth creating a new bug for it if you want to address it. CC me on it if you do please.

(In reply to comment # 13)

I've added your patch to subversion, thanks!

Yes, it's getting pretty close to time for 1.2.15 :)

Cheers, Sam. As luck would have it I fixed another bug last night in the directx driver (bug # 901). We made a beta release of Tremulous last week with an SVN copy of SDL, hence why we're getting a bunch of new bugs coming up. It would be great if we could get this new one in for a 1.2.15 release, if possible. Thanks again.

On 2009-12-15 00:53:38 +0000, Sam Lantinga wrote:

I just want to double check... there's nothing still pending on this bug in subversion, right?

On 2009-12-15 02:47:18 +0000, wrote:

(In reply to comment # 16)

I just want to double check... there's nothing still pending on this bug in
subversion, right?

Svn revision 5394 fixes the initial cursor disappearence as well as the active application toggle in fullscreen mode. Thanks!

The missing ClipCursor error handling and the resetting of the cursor clip as discussed in comment 14,15 are not essential (importance minor). Nevertheless 30 years of practical experience let me recommend fixing these points to stabilize SDL. E.g. without Tim's fix SDL did sometimes cause a complete system hang up, but with proper clip reset just an annoying misbehaviour. It is up to you Sam to rate the importance and to reinsert these remnants as another bug report.

(In reply to comment # 13)

Yes, it's getting pretty close to time for 1.2.15 :)
I would appreciate 1.2.15 :-)

On 2009-12-15 03:17:56 +0000, Tim Angus wrote:

(In reply to comment # 16)

I just want to double check... there's nothing still pending on this bug in
subversion, right?

From my point of view this bug is closed, yes. The other things being discussed should really be in a new bug(s).

On 2009-12-15 11:55:03 +0000, Sam Lantinga wrote:

Okay, feel free to enter new bugs and potential patches for these other issues.

Thanks!

On 2009-12-15 11:55:53 +0000, Sam Lantinga wrote:

Actually, what would be even more helpful, is helping out on the 1.3 input grab implementation. :)