The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi,

The patch in the SDL trunk (listed below) breaks apps that correctly handle
mouse and touch events. Apps will receive mouse events AND touch events. Also,
the precision of the mouse events will be incredibly lossy due to integer
truncation when compared with the touch events, which have double precision.

Recommend removing this patch altogether.

The patch in question is http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file "src/video/android/SDL_androidtouch.c"


-John


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is a required feature for games that use gesture support as well as mouse interaction.  If you prefer to use only touch events, can you ignore the mouse events?

On Thu, Nov 29, 2012 at 3:31 PM, John wrote:

How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It generates
fake mouse events whenever it sees touch events, then delivers BOTH events to
the app. From the perspective of an app's event loop, sometimes SDL_MouseEvent
is really a mouse event, and sometimes it is a duplicate of a touch event or a
finger event.

I guess this is really a question of what an app event loop should look like
now. Say an app's event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
...etc.

How would you recommend app developers revise their event handlers to work after
the mouse emulation patch?



On 12/01/2012 05:17 PM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I'm understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes, sort of. It's not important to me whether the events were truly triggered
by such-and-such device, although I can see why an app might need that. I'd like
to know how a "well behaved" app event loop should interpret the new SDL events.
Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button graphic.
The player can "press" the on-screen button with a mouse down event. They may
also press the on-screen button with a finger event. The app handles both
events, and it handles the "up" events as well in order to alter the button
appearance. Just your typical "onmousedown/onmouseup" sort of stuff. The code
compiles nicely on all platforms that SDL supports. Now, with the mouse
emulation patch applied, on Android, when the user touches the screen, the app
recieves a flurry of mouse events AND touch events. The mousemotion is even
weirder, because the mouse emulation patch generates very sudden, fast motion
when there is no motion at all. On finger-down, SDL moves the "fake" mouse
location from it's previously fake location to the new finger location by
generating a mouse motion event. Kinda like the old WarpMouse call.

Here's the event sequence on Android before the patch, when the user touches the
screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION... dozens of these.
FINGERUP

Here's the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
MOUSEBUTTONUP
FINGERUP




On 12/01/2012 10:08 PM, Sik the hedgehog wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, I assume the idea behind the patch is so that programs that
weren't designed for touch in the first place can act accordingly when
a touch screen is used (since again, those are really cursor events,
not mouse events - the name is a misnomer).

Dunno what you're asking about? If you mean about handling the cursor
as-is, unless you're handling specific gestures you should probably
use only the cursor events - though cursor events are quite barebones,
I had suggested a double click event some time ago (which could be
mapped to whatever is the touch equivalent).

I guess it depends on whether you just want a barebones generic cursor
or want to handle touch gestures specifically.

2012/12/2 John:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Android apps that worked on both desktops and droids before this patch no longer
work because they will receive fake events in addition to actual events. I'd
like to know what the new event model is so I can fix my apps.



Yes, I would assume the same judging by the commit message, and it's a perfectly
reasonable thing to do for a portability layer. I defer to the patch author to
explain what the goal is. I am happy to revise my apps to fit the new SDL event
model, whatever that may be.



I think what you are suggesting is that SDL_Mouse*Event now represents a
generic, higher level "input" event, and existing apps should be revised to only
handle mouse events, but ignore all the touch/finger events. If so, I'm ok with
that. I actually don't care about barebones v. logical/virtual v. legacy
emulation layers. Barebones is fine by me. Logical events are fine by me.
Emulation is fine by me, too. Pick one and I can code to it! :)


On 12/02/2012 01:08 AM, Sik the hedgehog wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/12/2 John:

Can you be more specific about what breaks? Or better said, what kind
of problems it causes. Otherwise it's going to be hard to tell what
could be a good solution, since as usual it depends on the situation.


Mouse events were always cursor events, calling them mouse events was
always a misnomer, it's probably from when pretty much the only way
you would be likely to control the cursor was with a mouse. I know
Allegro has this same naming issue.

Again: those events are pretty barebones. No idea exactly how they're
mapped (given I don't have touch screens), but I assume the only two
things that really map are left click (start touching for click press,
stop touching for click release) and dragging (move the finger around
as you're touching). It can't handle multiple touches, let alone
gestures.

I suppose that what we really need is better cursor support in
general. Again, maybe it would be better if you could tell us exactly
what problems are caused to work around them meanwhile.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In general, I think you only want to handle the mouse events, unless you're doing something that's specifically touch sensitive, e.g. handling gestures.  The intent is that you can assume that any touch input will also generate simulated mouse events if no mouse is present, so any non-touch-specific UI elements will work consistently on platforms with only mice as well as platforms with only touch input.

If you have a UI element that works better with touch input for some reason, then as soon as you get touch input events you should reset your state and start ignoring mouse input.


Looking at the event sequence it may make sense to send the touch events first so you know the mouse events are coming. e.g.

FINGERDOWN
MOUSEMOTION
MOUSEBUTTONDOWN
FINGERMOTION ,MOUSEMOTION,... dozens of these pairs.
FINGERUP
MOUSEBUTTONUP


Cheers!

On Sat, Dec 1, 2012 at 8:47 PM, John wrote:

Is the order of the events guaranteed to come in that order, though?

2012/12/2 Sam Lantinga:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I've seen this same behaviour myself (mouse and touch events sent for the same actual touch in Android). To be fair it wouldn't mind much if it wasn't because the mouse event's reported position was, in fact, many pixels aways from the actual touch location (and from the touch event's reported location).

As a quick thought, isn't this wrong? Shouldn't both touch and mouse events report the same position?

The patch appears to always generate mouse events whether or not the user has
connected a mouse to their android device.


Here's one solution: SDL could expose an API so that apps could query SDL to
find out whether or not SDL is generating artificial events. A similar solution
would be for SDL to set a bit in the SDL_MouseEvent and SDL_MouseMotion event
structs to inform the app the given event is artificial.



I think it's safe to assume that modern game developers wish to support gestures
and multiple touch points, rather than the single-mouse/cursor input model.




On 12/02/2012 02:52 AM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sure. For example, imagine code which handles SDL_MOUSEMOTION and
SDL_FINGERMOTION. Say it detects a traditional "mouse drag" or a contemporary
"fling" of an on-screen object.

case SDL_MOUSEMOTION:
if (is_inside(obj, evt) && is_pressed (evt)){
vx = evt.motion.xrel/dt;
vy = evt.motion.yrel/dt;
accelerate_fling (obj, vx, vy);
}
break;

case SDL_FINGERMOTION:
if (is_inside(obj, evt) && is_pressed (evt)){
SDL_Touch* tch = SDL_GetTouch(evt.tfinger.touchId);
vx = (evt.tfinger.dx * window.w/tch->xres)/dt;
vy = (evt.tfinger.dy * window.h/tch->yres)/dt;
accelerate_fling (obj, vx, vy);
}
break;

Before the patch, the player can drag the object with a mouse or with a finger.
It doesn't matter which. It works on all platforms. After the patch, the app
will sometimes receive duplicate (but not identical) events, first the
artificial mouse event, followed by the fingermotion event. The app sees an
artificial mousemotion with a vector whose x-component has magnitude `xrel` in
the direction of SIGN(xrel). Then it sees a finger motion with a similar vector.
The app doesn't know whether the mouse event is artificial, so it must handle
both if it wishes to support touch devices at all. The result here is that the
app will over-accelerate the object.



On 12/02/2012 03:50 AM, Sik the hedgehog wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Oh interesting, is there any way to tell if a mouse is connected?  I don't think we have any way of generating real mouse events on Android right now... ?

On Sun, Dec 2, 2012 at 1:08 PM, John wrote:

Even better, indicate which device generated the event. This could
also become useful if SDL decides to support multiple mouses using the
same API, or even better, if new devices appear that aren't mouses or
touch screens but also generate cursor events - a single bit can't let
you know what kind of device generated it, just distinguish between
two of them.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It looks like one can actually guess what kind of device is associated with each input device.
Please have a look at this:
http://developer.android.com/reference/android/view/InputDevice.html

So it might be possible to only send SDL mouse events when an actual mouse is sending those events. To me this is a good conceptual approach as the user can still implement a compatibility layer to equivalence all the kind of pointers in case they need it.

Regards