On Mon, 16 Dec 2013 15:56:56 -0800 Jason Gerecke <killert...@gmail.com> said:
finally coming back to this. christmas/new years etc. has kept me busy along
with other things and this mail has been on my todo. it's one of 3 last
outstanding ones to e-devel.
> Hello again! Had some other priorities come up, and then vacation, but
> I've recently gotten back to scratching my head and poking around the
> code.
as with everyone. :)
> My idea at the moment is to create a new "axis updated"
> event/callback. Applications that register for it would be notified
> whenever a device axis changed and have access to a snapshot of the
> current state. This has a number of advantages over modifying the
> existing 'mouse' or 'multi' events:
>
> * The change should be ABI compatible
> * Multi events are not abused to mean "any kind of extended pointer"
> * Cleaner API that keeps mouse and multi APIs focused on their
> "usual" use-cases
> * "Unusual" axes are only sent to apps that are actually interested
> * The event can be reasonably sent for many kinds of input devices
> (mouse, touch, stylus, 6DOF "spaceball", knob controller, etc.)
ok - while this means you don't get instant emulation support in existing apps,
it does mean it's cleaner when you REALLY want a pen.
> This approach does wind up duplicating some data that's already
> available through the "standard" events (e.g. stylus X/Y or
> touchscreen tilt). I don't think that's really an issue though: the
> axis event should be viewed as /supplemental/ to any data delivered by
> the standard events. You should be able to interchangeably use either
> source for the duplicated data without too much trouble.
>
> I've scratched out the following definitions with the aim of making
> something that will be easy to keep forward-compatible, and flexible
> enough to handle many kinds of input devices:
>
> ~~~~~~~~~~~~~~~~
> enum _Ecore_Axis_Name {
> UNKNOWN,
> X, /* Position along physical X axis; ????? units. */
> Y, /* Position along physical Y axis; ????? units. */
> PRESSURE, /* Normalized force applied to tool tip; Range: [0.0, 1.0] */
> DISTANCE, /* Normalized distance along physical Z axis; Range:
> [0.0, 1.0] */
> AZIMUTH, /* Angle of tool about the Z axis from positive X axis;
> Range: [-PI, PI] radians */
> TILT, /* Angle of tool about plane of sensor from positive Z
> axis; Range: [0.0, PI] radians */
> TWIST, /* Angle of tool about tool's major axis from tool's
> "natural" position; Range: [-PI, PI] radians */
> TOUCH_WIDTH_MAJOR, /* Length of contact ellipse along AZIMUTH */
> TOUCH_WIDTH_MINOR, /* Length of contact ellipse perpendicular to AZIMUTH
> */ TOOL_WIDTH_MAJOR, /* Length of tool ellipse along AZIMUTH */
> TOOL_WIDTH_MINOR /* Length of tool ellipse perpendicular to AZIMUTH */
> };
ok - i get the idea. naming needs of course to be namespaced. fyi - i much
prefer degrees to radians. i know. its not what sin/cos and math.h like... but
its what most programmers understand FIRST and otherwise end up converting
to/from degrees. :) also i'm not so sure bout "axis_name" if anything it'd be
axis_type... :)
> enum _Ecore_Tool_Name {
> UNKNOWN,
> MOUSE, /* Mouse or "puck" digitizer */
> FINGER, /* Touchscreen, touchpad, etc. */
> STYLUS, /* Pen writing tip */
> ERASER, /* Pen erasing tip */
> AIRBRUSH, /* ... is this a useful hint? */
> MARKER /* ... is this a useful hint? */
> }
the last 3 - can you explain these? i am familiar with some wacom tablets and
pens, but the only ting that may make a stylus become an eraser is simply
turning it aroun and using the other end. is this the same for airbrush and
marker? or something similar? hold down a button on the stylus to switch to
airbrush mode? (my wacom pen has such a togle button on it).? if so shouldn't
these last 3 just become modifiers of the stylus?
> struct _Ecore_Axis {
> enum _Ecore_Axis_Name name;
> double value;
> };
ok.
> struct _Ecore_Event_Axis_Update
> {
> unsigned int timestamp;
> unsigned int modifiers; /* Is this necessary? */
as above... eraser, marker, airbrush... ? maybe?
> int device; /* Unique device identifier */
> int toolid; /* Unique tool identifier (e.g. tool serial number,
> touchscreen contact number, etc.) */
> enum _Ecore_Tool_Name tooltype; /* Type of tool in use (e.g. "puck", ) */
>
> int nvalues;
> struct _Ecore_Axis *values;
> };
> ~~~~~~~~~~~~~~~~
hmm. you want to put an evas_device * handle in there... this allows the event
receiver to figure out much more about the input device by tracking this back
and doing queries.
> These are still in pretty heavy flux though. The basic event structure
> contains identifiers about where the event came from (device and
> toolid), what kind of tool created it (tooltype), and what the current
> axis values are (values). The axis values are stored with a
> dynamically allocated array so that we aren't limited to 'N' axes, and
agree. this sounds fine. since the event is allocated anyway this is easy -
just expand the allocation size to allow the values to be appended at the end
and set the pointer to there. maybe just use an array anyway like:
struct _Ecore_Axis values[1];
and then simply over-allocate the memory yo allow the array to grow to [2] and
[3] and however many are needed for nvalues. :)
> each axis is given an label to make it clear to clients how it should
> be interpreted. The tooltype field might be an unnecessary hint, or
> might belong somewhere else (e.g. evas_device); hard to say. I'm also
> not sure how I want to send X/Y information; none of the options are
> particularly savory.
i think that evas_device here might be where these belong. the stylus, eraser,
mouse/whatever awould be classes/types of evas_device. a quick query of the
evas_Device handle and its type/class will tell you where it comes from. :)
> Would anyone mind giving some feedback on this? I'm hacking up a
> quick-and-dirty implementation to get a feel for the complexities
> involved, and the first half (posting events to the queue) went easy
> enough. Now to work on implementing the labyrinth of functions that
> the event follows on its way from the queue to an application.
as above... and i notice you've sent some code. lt me look at that, but this
mail i had marked. :)
>
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one /
> (That is to say, eight) to the two, /
> But you can’t take seven from three, /
> So you look at the sixty-fours....
>
>
>
> On Thu, Oct 3, 2013 at 5:19 AM, Rafael Antognolli <antogno...@gmail.com>
> wrote:
> > On Thu, Oct 3, 2013 at 7:58 AM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> >> On Wed, 2 Oct 2013 22:28:54 -0700 Jason Gerecke <killert...@gmail.com>
> >> said:
> >>
> >>> On Wed, Oct 2, 2013 at 8:21 PM, Carsten Haitzler <ras...@rasterman.com>
> >>> wrote:
> >>> > On Wed, 2 Oct 2013 13:59:47 -0700 Jason Gerecke <killert...@gmail.com>
> >>> > said:
> >>> >
> >>> > 3 things here.
> >>> >
> >>> > 1. for general device queries (get name, description, device classes
> >>> > etc.) there is already an evas_device api. right now though nothng
> >>> > populates the evas device information from lower levels (xi/xi2, etc.
> >>> > etc.), so it's unused. but it's there.
> >>> Would clients be expected to call this just once prior to receiving
> >>> input, or is there some way to notify them that a change has occured?
> >>
> >> the query of the devices and building of their nodes and tree should be in
> >> ecore-evas. EVAS_CALLBACK_DEVICE_CHANGED is already there for this - u can
> >> set a callback on the evas itself to listen for this. the idea is that if
> >> you get this callback - re-query the device tree and see. :)
> >>
> >>> I ask because the type information (e.g. pen tip vs. eraser or
> >>> airbrush vs. inking pen) is likely to change fairly regularly. We
> >>> would want to be sure that clients can get their hands on that,
> >>> whether it means notifying that they need to refresh their
> >>> understanding or sending the type information in each event.
> >>
> >> well the device add/del is really more about plug and unplug. here i'd
> >> expect there to be a single device representing the pen and pen vs eraser
> >> vs brush i'd expect as a mode field on the pen (like i mention below about
> >> eraser)
> >>
> >>> > 2. i've talked with some people about this and the general take was
> >>> > that we need to add new pen events (ala multi) because they need to
> >>> > handle more than multi: e.g.:
> >>> >
> >>> > * button number on pen pressed/released SEPARATELY from pen touching.
> >>> > * pen touch vs eraser touch (ie indicate which "end" of N ends a pen
> >>> > presses down).
> >>> > * some pens support a hover ability - so that means motion events
> >>> > without down/up begin/end points like multi, BUT we would ned/want to
> >>> > report distance as a value during this hover
> >>> > * possibly other custom inputs on the pens themselves that are not
> >>> > accounted for.
> >>> >
> >>> > we COULD extend multi events and add fields, but i think you are
> >>> > mistaking habitual over-engineering in efl for intent for these to be
> >>> > pen events. a lot of stuff gets extended beyond its initial scope "in
> >>> > case". eg in case out touch surface can report size, pressure and angle
> >>> > of your finger... :) also it'd cause issues with existing multi event
> >>> > usage.
> >>> >
> >>> As I said, the multi event is interesting for its extra fields, but
> >>> might not be a good semantic match. A pen isn't anything more than
> >>> fancy mouse: it has motion without a touch event and a set of buttons
> >>> to worry about. The only thing that makes it special are all those
> >>> extra axes, and most of those could be imagined on a
> >>> sufficiently-advanced mouse. Wacom actually makes such a "mouse" for
> >>> their Intuos tablets which reports things like height above the pad,
> >>> rotation about the z-axis, and absolute position of a spring-loaded
> >>> fingerwheel.
> >>>
> >>> The way most APIs handle pen input is to just pass the data alongside
> >>> the X/Y position you'd expect for a mouse. Throw in an enum or
> >>> function to let clients distinguish pen tip from eraser and you're
> >>> set.
> >>
> >> i'm thinking similarly - have down/up and move events, with a bunch of
> >> extra fields. only q is.. what set of fileds pretty much covers every
> >> aspect of a possible pen.... :)
> >>
> >>> > 3. if you want to tal about the extra buttons and what not that you
> >>> > find on pen tablets (i have a bamboo sitting on my desk at home - i
> >>> > know cheapo little pen tablet, but its indicative at a small scale of a
> >>> > lot of them), i believe these should just be "keys" like any keyboard.
> >>> > i don't think these belong in any specialized event system. as with #1
> >>> > we CAN attach a special device handle to them though so you can
> >>> > differentiate where the key comes from... :)
> >>> >
> >>> Most implementations send these as "buttons" rather than "keys". In
> >>> the case of evdev, the Intuos and Cintiq tablets will send the
> >>> "meaningless" BTN_{0,1,2,3,...} buttons. For a Bamboo though, you'll
> >>> find the mouse buttons BTN_{LEFT,RIGHT,FORWARD,BACK} instead. In the X
> >>> driver these are all mapped to mouse buttons that clients can easily
> >>> understand. The first few mouse buttons usually have attached
> >>> semantics (e.g. button 1 => left click => primary action) which makes
> >>> them non-ideal, but "keys" don't fare much better since you'd need
> >>> clients to properly understand a non-standard keyboard layout. These
> >>> buttons are always a tricky issue.
> >>
> >> sure, but i see keys as better as they have keysyms at least that have
> >> enumerations... if the intent is to emulate a mouse - then buttons sounds
> >> right... anyway... if buttons then its kind of weirs to expose a button
> >> pres from the tablet base as this press event carries x/y info but
> >> actually has nothing to do with location... :)
> >>
> >>> > adding new event type isn't too hard in evas - you add the structures,
> >>> > enums (at the end of the current list of callbacks), add the feed api's
> >>> > to feed the event in, add the appropriate routing (the same we do for
> >>> > multi and mouse), and then that's done.
> >>> >
> >>> > then there is edje - likely you want to expose the pen events as signals
> >>> > like mouse. maybe not? optional really.
> >>> >
> >>> > and the important bit then ecore-evas + ecore-input + ecore-input-evas
> >>> > needs to gather the events from the next layer down and call the feed
> >>> > calls. the layer below could be evdev/console input devices (fb) x11
> >>> > (xi/xi2 etc.), or wl.. or win32.. or anything... and then for these
> >>> > ecore-x, ecore-fb, ecore-wl etc. needs to gather the appropriate events
> >>> > from the display system/event input system below that. one thing
> >>> > missign in ecore-evas is what i describe in #1 - querying all available
> >>> > devices, monitoring for new devices being plugged/unplugged and
> >>> > appropriately populating/managing the evas_device tree per canvas. :)
> >>> > it's something we need to get around to ding some time... :)
> >>> >
> >>> Sounds like there'll be a bit of code spelunking in my future. I'll be
> >>> happy once I wrap my head around how each of these components (edje,
> >>> ecore, evas, etc.) fit together.
> >>
> >> indeed. i hope this helped a bit. keep this dialog going and ask questions,
> >> swap initial struct definitions or ideas etc. :)
> >
> > Put a backtrace on _mouse_down_cb, on that evas_multi_touch example,
> > and you will find that it is delivered by the
> > ecore_event_evas_mouse_button_down function, which is a handler for an
> > Ecore event called ECORE_EVENT_MOUSE_BUTTON_DOWN. That one is
> > delivered by the underlying input system for that engine. Find out
> > which part of the code delivers that event and then you can trace
> > where it started by simple gdb backtrace.
> >
> > I suggest using eo_backtrace for debugging, to keep you sane from the
> > lots of eo_internal stuff that goes in the middle of the backtraces.
> >
> > I hope that helps,
> > Rafael
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from the latest Intel processors and coprocessors. See abstracts and
> > register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________ enlightenment-devel mailing
> > list enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
