On Mon, 15 Sep 2014 13:22:49 -0700 Jason Gerecke <killert...@gmail.com> wrote:
> It probably wouldn't be too hard to make this API work for reporting > joystick axes. I'm not familiar with how joysticks report their > position, but if it is in angles then TILT/ORIENTATION/TWIST already > have the basic axes covered. Additional joystick-specific axes (e.g. > THROTTLE, RUDDER, etc.) would have to be added, though I wonder how > more complex setups (e.g. throttle quadrants for dual-engine aircraft) > work and what demands it might place on an axis API... > > A the moment buttons aren't in-scope for this API (I wrote it assuming > buttons would be sent through another channel, e.g. mouse events) but > that might need to be discussed. Now that you mention it, there is also things like this (I have one) - http://www.3dconnexion.eu/products/spacemousepro.html I had recently added support to Imprudence Virtual World viewer for that, though thinking of switching to VRPN in future, for generic virtual world controller support - http://www.cs.unc.edu/Research/vrpn/ > On Wed, Sep 10, 2014 at 4:51 PM, Kim Shinwoo <kimcinoo....@gmail.com> > wrote: > > I love this thread. B-] > > I'd like to add newly defined events for the Joystick. It needs > > information such as Id, Index, Buttons, Axises, > > Connection(Disconnection) and so on. You could find such > > information from the W3C(http://www.w3.org/TR/gamepad/) also. > > This thread would be a good reference before adding the events. > > It have taken much of time to be here. So I'm sorry and frustrated > > already. Anyway, thank you. :-P > > > > Sincerely > > Shinwoo Kim. > > > > > > On Wed, Sep 10, 2014 at 3:50 AM, Jason Gerecke > > <killert...@gmail.com> wrote: > > > >> I've finished making the requested updates, but forgot to check to > >> see what your thoughts are about the coordinate system used in the > >> events. Right now data is being passed through pretty much as-is, > >> but this might not be appropriate if a window has been rotated. I > >> assume we want to adjust the reported AZIMUTH and TWIST values so > >> that the application doesn't have to worry about it, but where can > >> I find the necessary information? Also, is there any sense in > >> adjusting the other axes (e.g. X, Y, > >> {TOUCH,TOOL}_WIDTH_{MAJOR,MINOR}) to account for e.g. scaling? > >> > >> 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 Sat, Aug 30, 2014 at 7:32 PM, Carsten Haitzler > >> <ras...@rasterman.com> wrote: > >> > On Sat, 30 Aug 2014 18:37:13 -0700 Jason Gerecke > >> > <killert...@gmail.com> > >> said: > >> > > >> >> On Fri, Aug 29, 2014 at 7:25 PM, Carsten Haitzler > >> >> <ras...@rasterman.com > >> > > >> >> wrote: > >> >> > On Fri, 29 Aug 2014 13:18:37 -0700 Jason Gerecke < > >> killert...@gmail.com> > >> >> > said: > >> >> > > >> >> > review below. btw. it'd be really awesome if you could use > >> >> > arc to > >> land these > >> >> > patches for review. this is part of our "getting organized" > >> >> > and using > >> tools > >> >> > to make sure patches don't vanish in an inbox. :) there is a > >> >> > special limited sized review list for patches which allows > >> >> > inline code > >> comments > >> >> > etc. etc. see http://phab.enlightenment.org > >> >> > http://phab.enlightenment.org/w/arcanist/ > >> >> > > >> >> > 0001-Break-_ecore_x_input_handler-into-task-specific-sub-.patch: > >> >> > > >> >> > it'd be nice if it didn't have so many whitespace changes. > >> >> > it'd be > >> REALLY > >> >> > nice if you could "fix" the whitespace to match what was there > >> before. i'm > >> >> > sifting through it and almost all of this patch is whitespace > >> >> > changes > >> (that > >> >> > are not needed as no extra if, whole, for etc. clauses). > >> >> > > >> >> My editor seems to have gotten a little indent happy... I'll > >> >> work on cleaning up that mess up :) > >> >> > >> >> > 0002-Select-XI2-events-whenever-possible.patch: > >> >> > > >> >> > i am not sure here, but this may break multitouch support > >> >> > mpx-style > >> that > >> >> > checks for floating slaves vs slaves. (reading the diff is > >> >> > not fun :) > >> it is > >> >> > removing all the detection code and that is worrying, > >> >> > especially as > >> it's > >> >> > hard to test this support (but has been tested in the past > >> >> > when > >> written). > >> >> > > >> >> Basically this patch has the X server send Button, Motion, and > >> >> Touch events without regard to if the device is floating. A > >> >> driver with MPX multitouch that uses a floating device per > >> >> finger shouldn't be sending XI2 touch events, so I doubt adding > >> >> them to the mask would break anything. On the flip side, a > >> >> driver with XI2 multitouch devices *will* send button/motion > >> >> events (for the first finger) along with touch events, but the > >> >> '_ecore_x_input_multi_handler' function only responds to touch > >> >> events, so requesting more events from the server shouldn't > >> >> break anything in this case either. > >> > > >> > hmmm - for now, ok. > >> > > >> >> > 0003-Define-and-implement-new-Ecore_Event_Axis_Update-eve.patch: > >> >> > > >> >> > you have some ome todo's and fixme's... :)). one thing - the > >> >> > #include > >> of > >> >> > xserver-properties.h ... that literally is not an existing > >> >> > installed > >> file > >> >> > anywhere on my xorg installation. so this is going to be a > >> >> > problem... > >> it > >> >> > won't compile. and it likely isn't going to compile for > >> >> > anyone else. > >> what > >> >> > is this doing there and why? (oh .. and we don;'t use egyptian > >> brackets in > >> >> > count_bits ()) also @since 1.12 in the doxy comments so we > >> >> > know what version of efl this was introduced from :) oh and > >> >> > typedef enum _Ecore_Axis_Label like Ecore_Event_Axis_Update > >> >> > was. and in fact like > >> 0004 > >> >> > below - flatten out Ecore_Axis that isnt even typedeffed. :) > >> >> > > >> >> The xserver-properties.h file contains the names that drivers > >> >> are expected to use when naming their axes. It defines the > >> >> constants I use later in that file (e.g. > >> >> AXIS_LABEL_PROP_ABS_X). It looks like GTK at least just > >> >> hard-codes the strings instead of depending on the header > >> >> (which is part of the xorg server devel package). > >> > > >> > i'd recommend hardcoding them here ala gtk. :) there is nothing > >> > in these patches to check for this header, and since it's part > >> > of server devel 'd probably avoid relying on it. :) > >> > > >> >> I'll see what I can do about the todos and fixmes :D I expected > >> >> more critique on my design so only roughed out the > >> >> implementation and punted on the really hard parts in case they > >> >> needed to be changed anyway. > >> > > >> > design doesn't seem much of a problem :) > >> > > >> >> > 0004-Implement-EVAS_CALLBACK_AXIS_UPDATE-event-and-friend.patch: > >> >> > > >> >> > might i suggest not using struct _Evas_Axis * as a parameter > >> >> > but > >> actually > >> >> > passing in the enum lable and double. this makes it easier for > >> bindings to > >> >> > other languages. so pass them in as 2 params. that prbably > >> >> > means > >> removing > >> >> > this struct entirely (also being a raw struct is inconsistent > >> >> > with our typedeffing of all of these) so just break out enum > >> >> > (actually also > >> typedef > >> >> > the enum please) and double value into the event update > >> >> > struct :) > >> flatten > >> >> > the world! :) > >> >> > > >> >> The _Evas_Axis * is an array (whose length is given by > >> >> 'naxes'), not a single object. There'll be maybe a half-dozen > >> >> enum/double pairs depending on the device sending the event. > >> >> Would using some kind of EFL-specific list datatype work better > >> >> perhaps? > >> > > >> > oh. array. dang. then definitely typedef the axis struct. > >> > always. dont > >> leave it > >> > a raw struct (same with enum as above) > >> > > >> >> > 0005-Wire-the-Ecore-and-Evas-implementations-of-axis-upda.patch: > >> >> > > >> >> > fine EXCEPT i see no patch to expose > >> >> > ecore_event_evas_axis_update in > >> the > >> >> > header file :) it's EAPI (exposed api)... thus shoulld have > >> >> > something > >> in > >> >> > Ecore_Input.h :) don't forget @since 1.12 in a doxy comment :) > >> >> > > >> >> So _that's_ what EAPI means :D I should confess that pretty > >> >> much all of my code was mechanically written; grepping through > >> >> the tree for instances of e.g. "mouse_down" or "multi_down" and > >> >> then creating similar-looking blocks that said "axis_update". > >> >> I'm honestly surprised there aren't more little problems like > >> >> this... > >> > > >> > yup. EAPI is everywhere indicating it's exposed to external > >> > entities > >> (outside > >> > the lib/module.binary etc.). i though it would be obvious after > >> > reading a public header and seeing every single function > >> > prefixed with EAPI. > >> > > >> > it's actually important. it's a macro that sets attribute of > >> > visibility, > >> so if > >> > you strip -x the file these symbols remain. also on windows it > >> > does a > >> cdecl > >> > indicating to the linker to export this symbol. if you don't, on > >> windows, these > >> > functions have no symbols and are inaccessible. it isn't needed > >> > for > >> cross-file > >> > usage, or using any symbol within a single .so or single > >> > executable > >> binary, but > >> > it is needed for access from outside that destination file. > >> > > >> >> 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.... > >> >> > >> >> > 0006-DEBUG-Add-axis-update-logging-to-evas-multi-touch.c.patch: > >> >> > > >> >> > fine > >> >> > > >> >> > 0007-DEBUG-Make-evas-multi-touch-demo-be-pressure-sensiti.patch > >> >> > > >> >> > fine > >> >> > > >> >> >> Its been quite a while since my first patches were sent, so > >> >> >> unsurprisingly they no longer apply to the master branch. > >> >> >> I've attached an updated patchset which has been rebased and > >> >> >> should work once more. Hopefully it makes reviewing the code > >> >> >> a bit more > >> attractive > >> >> >> to those who've been standing on the sidelines... I'm not > >> >> >> terribly familiar with the EFL codebase so I'm *sure* > >> >> >> somebody out there could provide some feedback on the > >> >> >> design :) > >> >> >> > >> >> >> 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.... > >> >> > > >> >> > > >> >> > -- > >> >> > ------------- Codito, ergo sum - "I code, therefore I am" > >> -------------- > >> >> > The Rasterman (Carsten Haitzler) ras...@rasterman.com > >> >> > > >> >> > >> >> > >> ------------------------------------------------------------------------------ > >> >> Slashdot TV. > >> >> Video for Nerds. Stuff that matters. > >> >> http://tv.slashdot.org/ > >> >> _______________________________________________ > >> >> 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 > >> > > >> > >> > >> ------------------------------------------------------------------------------ > >> Want excitement? > >> Manually upgrade your production database. > >> When you want reliability, choose Perforce. > >> Perforce version control. Predictably reliable. > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > ------------------------------------------------------------------------------ > > Want excitement? > > Manually upgrade your production database. > > When you want reliability, choose Perforce > > Perforce version control. Predictably reliable. > > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
