| Summary: | Mouse cursor disappears on active application toggle | ||
|---|---|---|---|
| Product: | SDL | Reporter: | R.Lamprecht |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | rhamph+libsdl, tim |
| Version: | 1.2.14 | ||
| Hardware: | x86 | ||
| OS: | Windows (All) | ||
| Attachments: |
Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS
Fix to the cursor not being responsive when the app doesn't have SDL_APPINPUTFOCUS |
||
|
Description
R.Lamprecht
2009-10-16 09:14:23 UTC
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. 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. Narrowed down the source of this bug to svn commit #4478 on fix of bug #611. 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. Nevermind, I can reproduce this with Enigma. I'm investigating this now. (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. This is fixed for release, thanks! Oops! *laugh* No worries. :) The bug has been successfully fixed for the GDI driver. But revision 4478 breaks the DirectX driver with the same effects, too! Created attachment 450 [details]
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? ;)
Created attachment 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 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.
I've added your patch to subversion, thanks! Yes, it's getting pretty close to time for 1.2.15 :) (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. (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. I just want to double check... there's nothing still pending on this bug in subversion, right? (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 :-) (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). Okay, feel free to enter new bugs and potential patches for these other issues. Thanks! Actually, what would be even more helpful, is helping out on the 1.3 input grab implementation. :) |