Patch: simulated mouse events/duplicate touch events

(bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also sends a mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event. This
breaks existing applications which handle both types of events. Applications
cannot tell whether a mouse event was already handled as a touch event, is about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior has a
purpose. The following patch is a compromise. Instead of removing the duplicate
events, the attached patch adds a new hint, SDL_HINT_SIMULATE_INPUT_EVENTS,
leaving the above described behavior as the default, but permitting portable
apps to disable duplicate events. The hint API seemed to be the least intrusive
change. However, a note in the hint code raises concerns about whether it is
efficient enough to be checked in the event code, so I added a flag in the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a new API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2) call
SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable duplicate events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6

-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_HINT_SIMULATE_INPUT_EVENTS.patch
Type: text/x-patch
Size: 6662 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130207/aaeea085/attachment-0001.bin

I imagine the reason it has a warning about its performance is because
it’s handling strings (hint IDs are strings as well as hint values),
and string comparisons are definitely more expensive than, say,
checking the value of an integer. To what extent this hurts depends on
the situation.

2013/2/7, John :> (bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also sends a
mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event. This
breaks existing applications which handle both types of events.
Applications
cannot tell whether a mouse event was already handled as a touch event, is
about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior has a
purpose. The following patch is a compromise. Instead of removing the
duplicate
events, the attached patch adds a new hint, SDL_HINT_SIMULATE_INPUT_EVENTS,
leaving the above described behavior as the default, but permitting
portable
apps to disable duplicate events. The hint API seemed to be the least
intrusive
change. However, a note in the hint code raises concerns about whether it
is
efficient enough to be checked in the event code, so I added a flag in the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a new
API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2) call
SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable duplicate
events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6

Right. I wasn’t sure what approach the SDL development community would prefer.
The hints mechanism seems awkward for this (it’s a string table entry, yet we
only need 1 bit.) I’m happy to revisit other options.On 02/08/2013 02:40 AM, Sik the hedgehog wrote:

I imagine the reason it has a warning about its performance is because
it’s handling strings (hint IDs are strings as well as hint values),
and string comparisons are definitely more expensive than, say,
checking the value of an integer. To what extent this hurts depends on
the situation.

2013/2/7, John <@John6>:

(bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also sends a
mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event. This
breaks existing applications which handle both types of events.
Applications
cannot tell whether a mouse event was already handled as a touch event, is
about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior has a
purpose. The following patch is a compromise. Instead of removing the
duplicate
events, the attached patch adds a new hint, SDL_HINT_SIMULATE_INPUT_EVENTS,
leaving the above described behavior as the default, but permitting
portable
apps to disable duplicate events. The hint API seemed to be the least
intrusive
change. However, a note in the hint code raises concerns about whether it
is
efficient enough to be checked in the event code, so I added a flag in the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a new
API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2) call
SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable duplicate
events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This patch http://bugzilla.libsdl.org/attachment.cgi?id=999&action=diff
by Joseba
Garc?a Echebarria implements mouse movement for Android…I’d like to
incorporate it, but first my question to the community and our fearless
leaders Sam and Ryan is…do we really need/want SDL to inject fake mouse
events on a platform where an actual mouse can be plugged in (which is not
unlike desktop Linux for example)? Can’t we at least ifdef this behaviour
out by default and let anyone who likes/needs confusing duplicate events
enable it at configure time?

2013/2/8 John > Right. I wasn’t sure what approach the SDL development community would

prefer.
The hints mechanism seems awkward for this (it’s a string table entry, yet
we only need 1 bit.) I’m happy to revisit other options.

On 02/08/2013 02:40 AM, Sik the hedgehog wrote:

I imagine the reason it has a warning about its performance is because
it’s handling strings (hint IDs are strings as well as hint values),
and string comparisons are definitely more expensive than, say,
checking the value of an integer. To what extent this hurts depends on
the situation.

2013/2/7, John :

(bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also sends a
mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event.
This
breaks existing applications which handle both types of events.
Applications
cannot tell whether a mouse event was already handled as a touch event,
is
about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior has a
purpose. The following patch is a compromise. Instead of removing the
duplicate
events, the attached patch adds a new hint, SDL_HINT_SIMULATE_INPUT_**
EVENTS,
leaving the above described behavior as the default, but permitting
portable
apps to disable duplicate events. The hint API seemed to be the least
intrusive
change. However, a note in the hint code raises concerns about whether it
is
efficient enough to be checked in the event code, so I added a flag in
the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a
new
API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2)
call
SDL_SetHint(SDL_HINT_SIMULATE_**INPUT_EVENTS, “0”) to disable duplicate
events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bc**e6

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Gabriel.

Hi,

Yep, I’d like to see that included, too :slight_smile:

I’d say both patches are complimentary in the sense that both make
sense if one wants to improve the input handling in Android. From a
SDL-user perspective I believe the SDL_HINT approach is the most
sensitive one, since behavior is very polarized in this regard.

If anybody is interested, I have improved the mouse handling code a
bit and it now can handle right mouse clicks and mouse hover movement
events in Android, too [1].
The problem with [1] is that it’s written for recent versions of
Android and it’s not really ready for being run in Android 2.3, which
I still consider a relevant version of Android.

After this thursday I’ll work on lowering the required version of
Android for my joystick and mouse input codes and will update the
patches accordingly. Hopefully this weekend will be highly productive
in this regard :slight_smile:

Kind regards,
Joseba

[1] http://code.google.com/p/bennugd-monolithic/source/browse/branches/my_monolithic/projects/android/src/org/libsdl/app/SDLActivity.java#717On Tue, Feb 12, 2013 at 6:12 PM, Gabriel Jacobo wrote:

This patch http://bugzilla.libsdl.org/attachment.cgi?id=999&action=diff by
Joseba Garc?a Echebarria implements mouse movement for Android…I’d like to
incorporate it, but first my question to the community and our fearless
leaders Sam and Ryan is…do we really need/want SDL to inject fake mouse
events on a platform where an actual mouse can be plugged in (which is not
unlike desktop Linux for example)? Can’t we at least ifdef this behaviour
out by default and let anyone who likes/needs confusing duplicate events
enable it at configure time?

2013/2/8 John

Right. I wasn’t sure what approach the SDL development community would
prefer.
The hints mechanism seems awkward for this (it’s a string table entry, yet
we only need 1 bit.) I’m happy to revisit other options.

On 02/08/2013 02:40 AM, Sik the hedgehog wrote:

I imagine the reason it has a warning about its performance is because
it’s handling strings (hint IDs are strings as well as hint values),
and string comparisons are definitely more expensive than, say,
checking the value of an integer. To what extent this hurts depends on
the situation.

2013/2/7, John :

(bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also sends
a
mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event.
This
breaks existing applications which handle both types of events.
Applications
cannot tell whether a mouse event was already handled as a touch event,
is
about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior has a
purpose. The following patch is a compromise. Instead of removing the
duplicate
events, the attached patch adds a new hint,
SDL_HINT_SIMULATE_INPUT_EVENTS,
leaving the above described behavior as the default, but permitting
portable
apps to disable duplicate events. The hint API seemed to be the least
intrusive
change. However, a note in the hint code raises concerns about whether
it
is
efficient enough to be checked in the event code, so I added a flag in
the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a
new
API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2)
call
SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable duplicate
events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

my question to the community…
do we really need/want SDL to inject fake mouse events?

I vote no. We don’t need fake mouse events. We should remove fake events from
the tip, and scrap my hint patch.

Some applications work much better with touch input being treated as mouse
input. SDL on iOS has always had this behavior, and I would rather keep
that the default to avoid breaking somebody unexpectedly.

The hint approach is a good compromise. Setting a bool in the mouse
structure is fine as an optimization.On Tue, Feb 12, 2013 at 11:56 AM, John wrote:

my question to the community…

do we really need/want SDL to inject fake mouse events?

I vote no. We don’t need fake mouse events. We should remove fake events
from the tip, and scrap my hint patch.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Joseba, I’m looking forward to your updates!

Thanks! :)On Tue, Feb 12, 2013 at 11:10 AM, Joseba Garc?a Etxebarria < josebagar at gmail.com> wrote:

Hi,

Yep, I’d like to see that included, too :slight_smile:

I’d say both patches are complimentary in the sense that both make
sense if one wants to improve the input handling in Android. From a
SDL-user perspective I believe the SDL_HINT approach is the most
sensitive one, since behavior is very polarized in this regard.

If anybody is interested, I have improved the mouse handling code a
bit and it now can handle right mouse clicks and mouse hover movement
events in Android, too [1].
The problem with [1] is that it’s written for recent versions of
Android and it’s not really ready for being run in Android 2.3, which
I still consider a relevant version of Android.

After this thursday I’ll work on lowering the required version of
Android for my joystick and mouse input codes and will update the
patches accordingly. Hopefully this weekend will be highly productive
in this regard :slight_smile:

Kind regards,
Joseba

[1]
http://code.google.com/p/bennugd-monolithic/source/browse/branches/my_monolithic/projects/android/src/org/libsdl/app/SDLActivity.java#717

On Tue, Feb 12, 2013 at 6:12 PM, Gabriel Jacobo wrote:

This patch http://bugzilla.libsdl.org/attachment.cgi?id=999&action=diffby
Joseba Garc?a Echebarria implements mouse movement for Android…I’d
like to
incorporate it, but first my question to the community and our fearless
leaders Sam and Ryan is…do we really need/want SDL to inject fake mouse
events on a platform where an actual mouse can be plugged in (which is
not
unlike desktop Linux for example)? Can’t we at least ifdef this behaviour
out by default and let anyone who likes/needs confusing duplicate events
enable it at configure time?

2013/2/8 John

Right. I wasn’t sure what approach the SDL development community would
prefer.
The hints mechanism seems awkward for this (it’s a string table entry,
yet

we only need 1 bit.) I’m happy to revisit other options.

On 02/08/2013 02:40 AM, Sik the hedgehog wrote:

I imagine the reason it has a warning about its performance is because
it’s handling strings (hint IDs are strings as well as hint values),
and string comparisons are definitely more expensive than, say,
checking the value of an integer. To what extent this hurts depends on
the situation.

2013/2/7, John :

(bugzilla kept crashing. Here is the report and patch.)

Description:
On Android and UIKit, when SDL sees a touch/finger event, it also
sends

a
mouse
motion or mouse button event. When the user touches their device, the
application will receive a touch event as well as a mouse down event.
This
breaks existing applications which handle both types of events.
Applications
cannot tell whether a mouse event was already handled as a touch
event,

is
about
to be handled as a touch event, or is a new event.

Solution:
Discussions on the SDL dev list were unclear whether this behavior
has a

purpose. The following patch is a compromise. Instead of removing the
duplicate
events, the attached patch adds a new hint,
SDL_HINT_SIMULATE_INPUT_EVENTS,
leaving the above described behavior as the default, but permitting
portable
apps to disable duplicate events. The hint API seemed to be the least
intrusive
change. However, a note in the hint code raises concerns about whether
it
is
efficient enough to be checked in the event code, so I added a flag in
the
SDL_Mouse struct to mirror the hint. A simpler patch might be to add a
new
API
call for this, or perhaps bit-level hints, rather than char* hints.

Advise:
Portable apps should either (1) not handle touch events at all, or (2)
call
SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable duplicate
events.

Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54
-0800.

Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/2/16 Sam Lantinga

Some applications work much better with touch input being treated as mouse
input. SDL on iOS has always had this behavior, and I would rather keep
that the default to avoid breaking somebody unexpectedly.

The hint approach is a good compromise. Setting a bool in the mouse
structure is fine as an optimization.

my question to the community…

do we really need/want SDL to inject fake mouse events?

I vote no. We don’t need fake mouse events. We should remove fake events
from the tip, and scrap my hint patch.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If I may ignore what you just said for a bit :), and keep the argument
alive, there’s two potential scenarios I’d like to add…

  1. With multitouch devices becoming more common every day, there is and
    there’s going to be desktop systems with no mouse present…should we
    extend that thinking to the desktop as well?
  2. Further, with devices such as the Steam box (wink wink), it may be
    possible that we have a desktop system with no mouse nor touch, but with a
    joystick attached…should we extend this mouse simulation to the joystick?

My point is that while emulating the mouse for iOS may have been a good
compromise back then, the lack of mouse on a system is not so uncommon as
it used to be, and apps should consider how to approach that on their own,
instead of SDL meddling in an inconsistent way.

Finally, as it’s been stated before, on Android there’s touch support and
there’s mouse support, and I’ve seen a few developers here asking about why
they are getting mouse events along with touch events.> On Tue, Feb 12, 2013 at 11:56 AM, John wrote:


Gabriel.

2013/2/16, Gabriel Jacobo :

  1. With multitouch devices becoming more common every day, there is and
    there’s going to be desktop systems with no mouse present…should we
    extend that thinking to the desktop as well?

Honestly I’m not that sure touch screens will do that well on desktop,
it’s just too tiresome to use for long periods of time compared to a
mouse (especially given the monitor is placed vertically, the least
ideal situation for the hand).

On laptops the story may be different though, since using a mouse with
those is indeed cumbersome (either you use the touchpad or have to
carry a separate mouse around). I wonder if some day laptop
manufacturers will drop the touchpad (the simulated mouse) and stick
to only touch screens altogether (hey, they don’t seem to be shameful
when removing keys from the keyboard after all).

  1. Further, with devices such as the Steam box (wink wink), it may be
    possible that we have a desktop system with no mouse nor touch, but with a
    joystick attached…should we extend this mouse simulation to the joystick?

Take that even further: it’s likely the joystick would be the only
device: no mouse, no touch screen, no keyboard even. It’s pretty
much like a console in that sense. That last bit may be even more
troublesome than lack of mouse, keyboard emulation isn’t even remotely
common. I wonder if Steam will end up providing its own keyboard
emulation given how many games could have broken features without it.

56% of android devices on Google Play run version 2.3 (platform 10) or lower.
(http://developer.android.com/about/dashboards/index.html)

If you add something to SDL that bumps android OS requirements, please add a way
to disable it. A simple #ifdef would be great.On 02/16/2013 04:40 AM, Sam Lantinga wrote:

Joseba, I’m looking forward to your updates!

Thanks! :slight_smile:

On Tue, Feb 12, 2013 at 11:10 AM, Joseba Garc?a Etxebarria <josebagar at gmail.com <mailto:josebagar at gmail.com>> wrote:

Hi,

Yep, I'd like to see that included, too :)

I'd say both patches are complimentary in the sense that both make
sense if one wants to improve the input handling in Android. From a
SDL-user perspective I believe the SDL_HINT approach is the most
sensitive one, since behavior is very polarized in this regard.

If anybody is interested, I have improved the mouse handling code a
bit and it now can handle right mouse clicks and mouse hover movement
events in Android, too [1].
The problem with [1] is that it's written for recent versions of
Android and it's not really ready for being run in Android 2.3, which
I still consider a relevant version of Android.

After this thursday I'll work on lowering the required version of
Android for my joystick and mouse input codes and will update the
patches accordingly. Hopefully this weekend will be highly productive
in this regard :)

Kind regards,
Joseba

[1]
http://code.google.com/p/bennugd-monolithic/source/browse/branches/my_monolithic/projects/android/src/org/libsdl/app/SDLActivity.java#717

On Tue, Feb 12, 2013 at 6:12 PM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
 > This patch http://bugzilla.libsdl.org/attachment.cgi?id=999&action=diff by
 > Joseba Garc?a Echebarria implements mouse movement for Android...I'd like to
 > incorporate it, but first my question to the community and our fearless
 > leaders Sam and Ryan is...do we really need/want SDL to inject fake mouse
 > events on a platform where an actual mouse can be plugged in (which is not
 > unlike desktop Linux for example)? Can't we at least ifdef this behaviour
 > out by default and let anyone who likes/needs confusing duplicate events
 > enable it at configure time?
 >
 >
 > 2013/2/8 John <@John6 <mailto:@John6>>
 >>
 >> Right. I wasn't sure what approach the SDL development community would
 >> prefer.
 >> The hints mechanism seems awkward for this (it's a string table entry, yet
 >> we only need 1 bit.) I'm happy to revisit other options.
 >>
 >>
 >> On 02/08/2013 02:40 AM, Sik the hedgehog wrote:
 >>>
 >>> I imagine the reason it has a warning about its performance is because
 >>> it's handling strings (hint IDs are strings as well as hint values),
 >>> and string comparisons are definitely more expensive than, say,
 >>> checking the value of an integer. To what extent this hurts depends on
 >>> the situation.
 >>>
 >>> 2013/2/7, John <@John6
<mailto:@John6>>:
 >>>>
 >>>> (bugzilla kept crashing. Here is the report and patch.)
 >>>>
 >>>> Description:
 >>>> On Android and UIKit, when SDL sees a touch/finger event, it also sends
 >>>> a
 >>>> mouse
 >>>> motion or mouse button event. When the user touches their device, the
 >>>> application will receive a touch event as well as a mouse down event.
 >>>> This
 >>>> breaks existing applications which handle both types of events.
 >>>> Applications
 >>>> cannot tell whether a mouse event was already handled as a touch event,
 >>>> is
 >>>> about
 >>>> to be handled as a touch event, or is a new event.
 >>>>
 >>>> Solution:
 >>>> Discussions on the SDL dev list were unclear whether this behavior has a
 >>>> purpose. The following patch is a compromise. Instead of removing the
 >>>> duplicate
 >>>> events, the attached patch adds a new hint,
 >>>> SDL_HINT_SIMULATE_INPUT_EVENTS,
 >>>> leaving the above described behavior as the default, but permitting
 >>>> portable
 >>>> apps to disable duplicate events. The hint API seemed to be the least
 >>>> intrusive
 >>>> change. However, a note in the hint code raises concerns about whether
 >>>> it
 >>>> is
 >>>> efficient enough to be checked in the event code, so I added a flag in
 >>>> the
 >>>> SDL_Mouse struct to mirror the hint. A simpler patch might be to add a
 >>>> new
 >>>> API
 >>>> call for this, or perhaps bit-level hints, rather than char* hints.
 >>>>
 >>>> Advise:
 >>>> Portable apps should either (1) not handle touch events at all, or (2)
 >>>> call
 >>>> SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, "0") to disable duplicate
 >>>> events.
 >>>>
 >>>>
 >>>> Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54 -0800.
 >>>> Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6
 >>>>
 >>>>
 >>> _______________________________________________
 >>> SDL mailing list
 >>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
 >>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >>>
 >> _______________________________________________
 >> SDL mailing list
 >> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
 >> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >
 >
 >
 >
 > --
 > Gabriel.
 >
 > _______________________________________________
 > SDL mailing list
 > SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
 > http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Yeah, but only ~10% are running Android < 2.3. I’m testing the code to
be compatible with Android 2.3 (android-9) or higher.
That said, I should be able to update the mouse, sensor and joystick
patches tomorrow, as I’ve been working on all this and it’s looking
fine.

Regards and thanks for taking the time to look at my code,
JosebaOn Sat, Feb 16, 2013 at 7:33 PM, John wrote:

56% of android devices on Google Play run version 2.3 (platform 10) or
lower.
(http://developer.android.com/about/dashboards/index.html)

If you add something to SDL that bumps android OS requirements, please add a
way to disable it. A simple #ifdef would be great.

On 02/16/2013 04:40 AM, Sam Lantinga wrote:

Joseba, I’m looking forward to your updates!

Thanks! :slight_smile:

On Tue, Feb 12, 2013 at 11:10 AM, Joseba Garc?a Etxebarria <@Joseba_Garcia_Etxeba mailto:Joseba_Garcia_Etxeba> wrote:

Hi,

Yep, I'd like to see that included, too :)

I'd say both patches are complimentary in the sense that both make
sense if one wants to improve the input handling in Android. From a
SDL-user perspective I believe the SDL_HINT approach is the most
sensitive one, since behavior is very polarized in this regard.

If anybody is interested, I have improved the mouse handling code a
bit and it now can handle right mouse clicks and mouse hover movement
events in Android, too [1].
The problem with [1] is that it's written for recent versions of
Android and it's not really ready for being run in Android 2.3, which
I still consider a relevant version of Android.

After this thursday I'll work on lowering the required version of
Android for my joystick and mouse input codes and will update the
patches accordingly. Hopefully this weekend will be highly productive
in this regard :)

Kind regards,
Joseba

[1]

http://code.google.com/p/bennugd-monolithic/source/browse/branches/my_monolithic/projects/android/src/org/libsdl/app/SDLActivity.java#717

On Tue, Feb 12, 2013 at 6:12 PM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:
 > This patch

http://bugzilla.libsdl.org/attachment.cgi?id=999&action=diff by
> Joseba Garc?a Echebarria implements mouse movement for
Android…I’d like to
> incorporate it, but first my question to the community and our
fearless
> leaders Sam and Ryan is…do we really need/want SDL to inject fake
mouse
> events on a platform where an actual mouse can be plugged in (which
is not
> unlike desktop Linux for example)? Can’t we at least ifdef this
behaviour
> out by default and let anyone who likes/needs confusing duplicate
events
> enable it at configure time?
>
>
> 2013/2/8 John <john at leafygreengames.com
<mailto:john at leafygreengames.com>>

 >>
 >> Right. I wasn't sure what approach the SDL development community

would
>> prefer.
>> The hints mechanism seems awkward for this (it’s a string table
entry, yet
>> we only need 1 bit.) I’m happy to revisit other options.
>>
>>
>> On 02/08/2013 02:40 AM, Sik the hedgehog wrote:
>>>
>>> I imagine the reason it has a warning about its performance is
because
>>> it’s handling strings (hint IDs are strings as well as hint
values),
>>> and string comparisons are definitely more expensive than, say,
>>> checking the value of an integer. To what extent this hurts
depends on
>>> the situation.
>>>
>>> 2013/2/7, John <john at leafygreengames.com
<mailto:john at leafygreengames.com>>:

 >>>>
 >>>> (bugzilla kept crashing. Here is the report and patch.)
 >>>>
 >>>> Description:
 >>>> On Android and UIKit, when SDL sees a touch/finger event, it

also sends
>>>> a
>>>> mouse
>>>> motion or mouse button event. When the user touches their
device, the
>>>> application will receive a touch event as well as a mouse down
event.
>>>> This
>>>> breaks existing applications which handle both types of events.
>>>> Applications
>>>> cannot tell whether a mouse event was already handled as a touch
event,
>>>> is
>>>> about
>>>> to be handled as a touch event, or is a new event.
>>>>
>>>> Solution:
>>>> Discussions on the SDL dev list were unclear whether this
behavior has a
>>>> purpose. The following patch is a compromise. Instead of
removing the
>>>> duplicate
>>>> events, the attached patch adds a new hint,
>>>> SDL_HINT_SIMULATE_INPUT_EVENTS,
>>>> leaving the above described behavior as the default, but
permitting
>>>> portable
>>>> apps to disable duplicate events. The hint API seemed to be the
least
>>>> intrusive
>>>> change. However, a note in the hint code raises concerns about
whether
>>>> it
>>>> is
>>>> efficient enough to be checked in the event code, so I added a
flag in
>>>> the
>>>> SDL_Mouse struct to mirror the hint. A simpler patch might be to
add a
>>>> new
>>>> API
>>>> call for this, or perhaps bit-level hints, rather than char*
hints.
>>>>
>>>> Advise:
>>>> Portable apps should either (1) not handle touch events at all,
or (2)
>>>> call
>>>> SDL_SetHint(SDL_HINT_SIMULATE_INPUT_EVENTS, “0”) to disable
duplicate
>>>> events.
>>>>
>>>>
>>>> Patch is based on HG tip: c259f0817583 Tue, 05 Feb 2013 12:10:54
-0800.
>>>> Patch checksum (MD5): 06d9ef060a0cad24c9a8d71ef701bce6
>>>>
>>>>
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

 >>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >>>
 >> _______________________________________________
 >> SDL mailing list
 >> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

 >> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >
 >
 >
 >
 > --
 > Gabriel.
 >
 > _______________________________________________
 > SDL mailing list
 > SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

 > http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
 >
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

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

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

events
Message-ID:
<CAKDfes=ezDN5W1Gg=XuaY1i1LD786-jE8aZP1FozY9dbca0LJA at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

2013/2/16 Sam Lantinga

Some applications work much better with touch input being treated as
mouse
input. SDL on iOS has always had this behavior, and I would rather keep
that the default to avoid breaking somebody unexpectedly.

The hint approach is a good compromise. Setting a bool in the mouse
structure is fine as an optimization.

> Date: Sat, 16 Feb 2013 11:16:18 -0300

From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] patch: simulated mouse events/duplicate touch

If I may ignore what you just said for a bit :), and keep the argument
alive, there’s two potential scenarios I’d like to add…

  1. With multitouch devices becoming more common every day, there is and
    there’s going to be desktop systems with no mouse present…should we
    extend that thinking to the desktop as well?
  2. Further, with devices such as the Steam box (wink wink), it may be
    possible that we have a desktop system with no mouse nor touch, but with a
    joystick attached…should we extend this mouse simulation to the joystick?

Date: Sat, 16 Feb 2013 14:09:48 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] patch: simulated mouse events/duplicate touch
events
Message-ID:
<CAEyBR+V8ZsE=_TawHwCzVod+TqvW9eHutDahcsVTx9xxDu9pRA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2013/2/16, Gabriel Jacobo :

  1. With multitouch devices becoming more common every day, there is and
    there’s going to be desktop systems with no mouse present…should we
    extend that thinking to the desktop as well?

Honestly I’m not that sure touch screens will do that well on desktop,
it’s just too tiresome to use for long periods of time compared to a
mouse (especially given the monitor is placed vertically, the least
ideal situation for the hand).

On laptops the story may be different though, since using a mouse with
those is indeed cumbersome (either you use the touchpad or have to
carry a separate mouse around). I wonder if some day laptop
manufacturers will drop the touchpad (the simulated mouse) and stick
to only touch screens altogether (hey, they don’t seem to be shameful
when removing keys from the keyboard after all).

  1. Further, with devices such as the Steam box (wink wink), it may be
    possible that we have a desktop system with no mouse nor touch, but with
    a
    joystick attached…should we extend this mouse simulation to the
    joystick?

Take that even further: it’s likely the joystick would be the only
device: no mouse, no touch screen, no keyboard even. It’s pretty
much like a console in that sense. That last bit may be even more
troublesome than lack of mouse, keyboard emulation isn’t even remotely
common. I wonder if Steam will end up providing its own keyboard
emulation given how many games could have broken features without it.

When the time comes, it might be a good idea to add a "generic input"
interface to SDL 2.1. All inputs that I know of (except for images,
and streaming stuff like audio and video) can reasonably be expressed
with a grouped combination of buttons, relative axes, and absolute
axes (and for that matter, you can express buttons as absolute axes,
so just absolute and relative axes). Therefor, if in the future
interfaces become reliably unreliable, we can rebase SDL on a “generic
interface” foundation, and switch the current interfacing methods to
be compatibility layers.

Not something to do right now, but worth looking at in a year or three.

This is something I have been wondering myself some time ago,
especially since now there are analog buttons which indeed could be
expressed like an axis (0.0 = fully released, 1.0 = fully pressed),
and there are (supposedly) a few keyboards that have analog keys.

Of course there’s more to it that you need to take into account.
Joystick axes go both ways - so they range from -1 to 1. Analog
buttons only would go one way, so they range from 0 to 1. Relative
axes (mouse movement, etc.) have a range of -infinity to infinity
(i.e. no limit), and with these ones we have the extra issue of
determining from where is the value relative (I guess it’d be since
the last event?).

That really isn’t much of an issue API-wise (you can see how quickly I
solved the axis range issue), besides having to provide information
about the properties for each axis, but this will require making
programs in a different way. I guess that isn’t what concerns us,
though.

2013/2/18, Jared Maddox :> When the time comes, it might be a good idea to add a “generic input”

interface to SDL 2.1. All inputs that I know of (except for images,
and streaming stuff like audio and video) can reasonably be expressed
with a grouped combination of buttons, relative axes, and absolute
axes (and for that matter, you can express buttons as absolute axes,
so just absolute and relative axes). Therefor, if in the future
interfaces become reliably unreliable, we can rebase SDL on a “generic
interface” foundation, and switch the current interfacing methods to
be compatibility layers.

Not something to do right now, but worth looking at in a year or three.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

events
Message-ID:
<CAEyBR+WrwhyKr=w2gBgE4aqor25gG7MLnB50OSp3LgSDUsMURg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Of course there’s more to it that you need to take into account.
Joystick axes go both ways - so they range from -1 to 1. Analog
buttons only would go one way, so they range from 0 to 1.

-1 to 1 is certainly a way to express the range of a joystick axis,
but who knows what kind of weird hardware users have hooked up (or how
it might have degraded over time!), so 0 is not necessarily what you
think it is: the (or “a”, in the case of dials with multiple “points
of stability”) self-centering point. For that, what you really want is
another function. I’ve used some CAD software before, so I’ll suggest
SDL_AbsoluteAxisSnaps and SDL_AbsoluteAxisSnap. That way, it would
even support multiple unevenly-spaced points of stability.

That really isn’t much of an issue API-wise (you can see how quickly I
solved the axis range issue), besides having to provide information
about the properties for each axis, but this will require making
programs in a different way. I guess that isn’t what concerns us,
though.

Yeah, as I said before, I don’t think it would be reasonable to try to
put such a thing in until the work begins on SDL 2.1 .> Date: Mon, 18 Feb 2013 18:48:24 -0300

From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] patch: simulated mouse events/duplicate touch