SDL_GetError isn't like glGetError - it's only meant to be called after something actually errored - i.e. when an SDL function returns -1 or NULL etc. In any other case it can return whatever it wants, so you shouldn't assume there's an actual error if SDL_GetError returns something.

(In reply to Alex Szpakowski from comment #1)
> SDL_GetError isn't like glGetError - it's only meant to be called after
> something actually errored - i.e. when an SDL function returns -1 or NULL
> etc. In any other case it can return whatever it wants, so you shouldn't
> assume there's an actual error if SDL_GetError returns something.

I don't buy this. The Mac-specific gesture-handling code should clear the error before execution returns to the user's code. I'm going to try to find a MacBook later tonight to investigate this further, but I claim that this behavior is undesirable and should be easy to fix.

Perhaps, but the Wiki page for SDL_GetError does say this:
> You must check the return values of SDL function calls to determine when to appropriately call SDL_GetError().

If we're quoting the wiki, the previous sentence states that it should return "an empty string if there hasn't been an error."

I interpret the sentence you quoted to indicate that one should call SDL_GetError() in the event that a function in the SDL API indicated an error--not that it may return a non-empty string, violating the previously stated invariant, in the case that the SDL API indicated only success in the preceding calls.

It seems to me that either the code should be changed, or the documentation should be clarified. Something doesn't sit right.

I think that the error message "ERROR: NumPoints = 0" should be removed but for a different reason.

This error message is currently set if an applications uses touch events but no gestures. That is because touch events are always processed as gestures. The message is then set in an internal function but the return value of this function is not checked and not forwarded. Therefore it seems not even useful for debugging SDL itself unless SDL_GetError() is called unrelated to a functions return value. Additionally all applications which receive touch events get a tiny overhead of setting this message. (And it leads to Bugzilla entries like this one. :)

Originally the message was debug printf() but then changed to SDL_SetError(). [1] This may also be the reason for the different format because most of SDL's error messages do not have the prefix "Error: ".

[1] https://hg.libsdl.org/SDL/rev/d6adaafcfb10#l2.109

This bug still exists in SDL 2.0.3 and the current development version. 

As far as I can tell, the issue is because macs considers any "Apple Multitouch Trackpad" (built in or external) as an absolute pointing device, but SDL doesn't. When the mac gets the first touch event, it calls handleTouches:withEvent: in SDL_cocoawindow.m, which calls SDL_GetTouch, which causes the "Unknown touch device" error. The "ERROR: NumPoints = 0" error seems to be caused by the same sort of issue, as it occurs during the processing of touch events in SDL_PushEvent calling SDL_GestureProcessEvent.  This error should be able to be fixed by properly registering the trackpad as a touch device (though I may be wrong).

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

The "Unknown touch device" message appears because the initial touch device setup loop uses SDL_GetTouch() as a guard for calling SDL_AddTouch().  SDL_GetTouch() will always report "Unknown touch device" since the device hasn't been added yet.  The SDL_GetTouch() call is unnecessary since SDL_AddTouch() calls SDL_GetTouchIndex() to verify that the device hasn't been added yet, and SDL_GetTouchIndex() has the benefit of not reporting an error for a device it can't find.  Here is the necessary patch (ignore the 2.0.3, this is still present in the latest source):


*** SDL2-2.0.3.clean/src/video/x11/SDL_x11xinput2.c	2014-03-15 21:31:44.000000000 -0500
--- SDL2-2.0.3.mod/src/video/x11/SDL_x11xinput2.c	2015-04-09 16:45:11.800843629 -0500
***************
*** 197,205 ****
                  continue;
  
              touchId = t->sourceid;
!             if (!SDL_GetTouch(touchId)) {
!                 SDL_AddTouch(touchId, dev->name);
!             }
          }
      }
      X11_XIFreeDeviceInfo(info);
--- 197,203 ----
                  continue;
  
              touchId = t->sourceid;
!             SDL_AddTouch(touchId, dev->name);
          }
      }
      X11_XIFreeDeviceInfo(info);

Volumetric, your patch is in, and the same logic applied to almost every other touch initialization.
https://hg.libsdl.org/SDL/rev/7fc4a8be47a8

Thanks!