On Wed, Mar 19, 2014 at 5:44 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Wed, 19 Mar 2014 17:19:39 -0700 Jason Gerecke <killert...@gmail.com> said:
>
>> On Tue, Feb 25, 2014 at 5:24 PM, Jason Gerecke <killert...@gmail.com> wrote:
>> > On Thu, Jan 30, 2014 at 12:16 AM, Carsten Haitzler <ras...@rasterman.com>
>> > wrote:
>> >> 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... :)
>> >>
>> > All sound good. As you point out, radians are nicer for dealing with
>> > the math libraries, but I won't begrudge degrees :)
>> >
>> >>> 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?
>> >>
>> > ERASER, AIRBRUSH, and MARKER are really just hints to the application
>> > that the tool is "expected" to be used in a particular way. Erasers
>> > don't necessarily have to erase, but by default an application should
>> > probably treat it as one. Similarly, the accessory "Airbrush" and "Art
>> > Pen" tools that you can buy for the professional tablets [1] don't
>> > necessarily have to simulate an airbrush or marker by default, but
>> > given the form-factor (the button on the Airbrush is more likely to be
>> > used to lay paint than to right-click) and features (only the Art Pen
>> > has the sensors necessary to accurately simulate a chisel-tip marker
>> > or fountain pen) it's a handy hint to the app about how the user may
>> > expect the tool to be used.
>> >
>> > There are a number of degrees of refinement in the information you can
>> > potentially provide. The USB HID spec allows a *ton* of descriptive
>> > information to be provided by the device. You could potentially
>> > provide information like:
>> >
>> > Source device: mouse, touchscreen, touchpad, tablet, spaceball,
>> > control board, etc.
>> > Device tool: hand, finger, stylus, knob, fader, etc.
>> > Tool type: eraser, airbrush, marker, rotary encoder (infinite; think
>> > mousewheel), potentiometer (finite; think volume knob or fader), etc.
>> > Tool: Intuos4 Art Pen, Intuos4 Airbrush, etc.
>> > Tool serial number: varies
>> >
>> > Ideally an app would have access to full richness of this kind of
>> > information. Realistically though, its a lot of work to encode in a
>> > way for applications to easily make sense of what they care about. My
>> > solution here was to just provide type information and hope that
>> > developers would treat STYLUS, ERASER, AIRBRUSH, and MARKER
>> > identically if they don't care about the distinction, rather than
>> > providing an explicit hierarchy of hints.
>> >
>> > [1]: https://store.wacom.com/us/accessories/pens
>> >
>> >>> 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?
>> >>
>> > I wasn't sure what the modifiers field was for. I've been working
>> > under the assumption it contains keyboard modifiers like SHIFT, CTRL,
>> > and ALT so that applications can alter how they treat events. Though
>> > it'd be a bit duplicative for pen events (since the mouse events will
>> > also have modifiers), other devices that update their axes might not
>> > be so lucky and could benefit. Am I right in assuming this used
>> > elsewhere for keyboard modifiers?
>> >
>> >>> 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.
>> >>
>> > Yeah, that would be kinda handy, wouldn't it... Can't believe I left it
>> > out! :D
>> >
>> >>> 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. :)
>> >>
>> > That's a nifty pointer trick, but it sounds a bit too clever for its
>> > own good. I'm having horrifying visions of somebody wondering why
>> > free(values) is never called, and "fixing" it without realizing its a
>> > pointer to somewhere *inside* a block of memory. Declaring an array is
>> > almost as bad: while nobody should go free()-happy on it, I know I'd
>> > be scratching my head something fierce at the sight of an array of
>> > size one for an event that's supposedly transferring several axis
>> > values.
>> >
>> > Unless memory fragmentation is a big issue or this kind of trick is a
>> > common idiom, I'd much rather be boringly obvious and just malloc/free
>> > a chunk of memory to hold the axis values.
>> >
>> >>> 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. :)
>> >>
>> > Thanks for the feedback -- its nice to know that I'm stumbling in the
>> > right general direction :)
>> >
>> > On Thu, Jan 30, 2014 at 2:08 AM, Carsten Haitzler <ras...@rasterman.com>
>> > wrote:
>> >> 0001 - ok
>> >> 0002 - i smell problems maybe... i'd have to test - but that code
>> >> specifically was written to detect and mpx-style setup as well as xi2.2
>> >> etc. an this may break it.
>> > I should probably break this patch into two pieces. It contains 90%
>> > cleanup and 10% functionality change. It looks like the original code
>> > was written with a bit of misunderstanding of XI2 leading to
>> > nonsensical statements (the `if (((atdev) && (atdev->use !=
>> > XIMasterPointer)) || (!atdev))` statement will *never* evaluate to
>> > `true`!) and code duplication. The remaining 10% non-cleanup change
>> > causes us to request XI_{Button{Press,Release},Motion} events from
>> > *all* slave devices (not just floating slaves, as in the original).
>> >
>> > I haven't tested MPX specifically, but this shouldn't cause any
>> > problems with that. MPX is a matter of creating multiple master
>> > pointers; the only change this patch does is cause their underlying
>> > non-floating slaves to start reporting XI2 events. The master pointers
>> > will continue to send core X events for translation into standard
>> > mouse events.
>> >
>> > For reference, the XI2.0 and 2.2 protocols are documented at [2] and [3].
>> >
>> > [2]:
>> > http://www.opensource.apple.com/source/X11proto/X11proto-57.2/inputproto/inputproto-2.0.1/XI2proto.txt
>> > [3]: http://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt
>> >
>> >> 0003 - as per my mail erply to your previous mail :)
>> >> 0004 - as per previous mail - Evas_Device *dev pointer in struct, also
>> >> missing void *data field (general field in all events), event_src object
>> >> ptr, ... maybe modifiers... event_flags... and then we need to consider
>> >> canvs vs output
>> > Could you quickly explain what those various variables are for? I'll
>> > add them in, but I'm just curious since I'm poking my nose around the
>> > event system anyway :)
>> >
>> >> values/coords. remember that evas will transform coordinates if an object
>> >> is rotated or tiled in 3d etc. but then canvas coords will be the properly
>> >> calculated/translated coords and output will be pre-transform (raw
>> >> on-canvas/screen coords).
>> > As far as coordinate system goes, I'm not sure what would be best. The
>> > most obvious answer would be to use the same coordinate system as
>> > mouse events, to make using the subpixel-precise axis data as easy as
>> > possible. The problem is that figuring out the window coordinates that
>> > correspond to the current device coordinates isn't trivial. The tablet
>> > can be mapped to an arbitrary region of the desktop by the driver,
>> > which means that the window manager can't simply assume there is a 1:1
>> > mapping between device space and desktop space. You could look at the
>> > coordinates of the mouse to get a good idea, but that gets tricky with
>> > MPX and impossible if the device has been detached from all master
>> > pointers. An X11 property describes the device-to-desktop
>> > transformation, but that can change at any point in time. You can
>> > listen for the changes, but _wow_ that's taken quite a bit of code to
>> > make the axes report data in a nice way.
>> >
>> > An alternative could be to state that the coordinates are in device
>> > space, and wish the best of luck to anyone who wants to use them for
>> > subpixel positioning. Its not a terribly satisfying answer though,
>> > since subpixel positioning is one of the key features of using a
>> > tablet over a mouse.
>> >
>> >> 0005 - ok
>> >> 0006 - ok
>> >> 0007 - ok
>> >>
>> >> :)
>> >
>> > 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....
>>
>> Poking the list since its been a few weeks without a reply...
>
> sorry - your'e one of about 30 mails on this list i have marked to get back
> to,
> but right now i'm busy trying to trawl through our patch submission queue on
> phab and not dealing with my e-devel backlog. :(
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
With work starting on defining a tablet API in libinput, I thought
this might be a good time to try bumping the topic again and seeing if
anyone has input.
Hopefully that backlog of patches and mail hasn't grown too huge in
the meantime :)
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....
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
