From: Florian E. <fl...@bu...> - 2011-02-20 17:02:06
Attachments:
freeglut-svn-multitouch.patch
|
Hello everyone, it's been a while, but I've managed to update my multitouch patch to freeglut to also support Windows 7 touch events now as well as XInput 2 events on *nix. I'd like to ask two things: - Is there any interest to integrate this into freeglut as an optional feature (i.e., something enabled by an explicit configure switch)? - The additional public interface currently looks like this: #define GLUT_HAS_MPX 1 FGAPI void FGAPIENTRY glutXExtensionEntryFunc( void (* callback)( int, int ) ); FGAPI void FGAPIENTRY glutXExtensionButtonFunc( void (* callback)( int, int, int, int, int ) ); FGAPI void FGAPIENTRY glutXExtensionMotionFunc( void (* callback)( int, int, int ) ); FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( void (* callback)( int, int, int ) ); Obviously, the interface names is still influenced by the MPX origin (which has been superseded by XI2 anyway). The additional int parameter in every callback specifies the pointer or touchpoint ID which the data belongs to. Are there any suggestions from the side of the freeglut community as to how the API should look like w.r.t. naming etc.? (Particularly since the functions are now also supported in Windows 7). Thanks in advance for your suggestions! Florian |
From: Florian E. <fl...@bu...> - 2011-02-28 08:58:14
|
Sorry for bringing this up again, but... no opinions at all? Anyone? Florian On Sun, 2011-02-20 at 18:01 +0100, Florian Echtler wrote: > Hello everyone, > > it's been a while, but I've managed to update my multitouch patch to > freeglut to also support Windows 7 touch events now as well as XInput 2 > events on *nix. I'd like to ask two things: > > - Is there any interest to integrate this into freeglut as an optional > feature (i.e., something enabled by an explicit configure switch)? > > - The additional public interface currently looks like this: > > #define GLUT_HAS_MPX 1 > > FGAPI void FGAPIENTRY glutXExtensionEntryFunc( > void (* callback)( int, int ) ); > FGAPI void FGAPIENTRY glutXExtensionButtonFunc( > void (* callback)( int, int, int, int, int ) ); > FGAPI void FGAPIENTRY glutXExtensionMotionFunc( > void (* callback)( int, int, int ) ); > FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( > void (* callback)( int, int, int ) ); > > Obviously, the interface names is still influenced by the MPX origin > (which has been superseded by XI2 anyway). The additional int parameter > in every callback specifies the pointer or touchpoint ID which the data > belongs to. > > Are there any suggestions from the side of the freeglut community as to > how the API should look like w.r.t. naming etc.? > (Particularly since the functions are now also supported in Windows 7). > > Thanks in advance for your suggestions! > > Florian > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: John T. <nu...@me...> - 2011-02-28 15:15:23
|
On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: > Sorry for bringing this up again, but... no opinions at all? Anyone? > > > - Is there any interest to integrate this into freeglut as an optional > > feature (i.e., something enabled by an explicit configure switch)? I don't see why not > > FGAPI void FGAPIENTRY glutXExtensionEntryFunc( > > void (* callback)( int, int ) ); > > FGAPI void FGAPIENTRY glutXExtensionButtonFunc( > > void (* callback)( int, int, int, int, int ) ); > > FGAPI void FGAPIENTRY glutXExtensionMotionFunc( > > void (* callback)( int, int, int ) ); > > FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( > > void (* callback)( int, int, int ) ); > > > > Obviously, the interface names is still influenced by the MPX origin > > (which has been superseded by XI2 anyway). The additional int parameter > > in every callback specifies the pointer or touchpoint ID which the data > > belongs to. > > > > Are there any suggestions from the side of the freeglut community as to > > how the API should look like w.r.t. naming etc.? > > (Particularly since the functions are now also supported in Windows 7). I have no experience whatsoever about multitouch APIs, but it looks reasonable from a first glance. Care to explain a bit more what the entry function does? I think the rest are pretty obvious. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Evan F. <ka...@gm...> - 2011-02-28 18:14:16
|
Is there a reason not to just name them TouchEntryFunc, etc.. Naming them XExension seem to allude to a X lockin, but Touch is available many places now Evan On Mon, Feb 28, 2011 at 7:15 AM, John Tsiombikas <nu...@me...> wrote: > On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: >> Sorry for bringing this up again, but... no opinions at all? Anyone? >> >> > - Is there any interest to integrate this into freeglut as an optional >> > feature (i.e., something enabled by an explicit configure switch)? > > I don't see why not > >> > FGAPI void FGAPIENTRY glutXExtensionEntryFunc( >> > void (* callback)( int, int ) ); >> > FGAPI void FGAPIENTRY glutXExtensionButtonFunc( >> > void (* callback)( int, int, int, int, int ) ); >> > FGAPI void FGAPIENTRY glutXExtensionMotionFunc( >> > void (* callback)( int, int, int ) ); >> > FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( >> > void (* callback)( int, int, int ) ); >> > >> > Obviously, the interface names is still influenced by the MPX origin >> > (which has been superseded by XI2 anyway). The additional int parameter >> > in every callback specifies the pointer or touchpoint ID which the data >> > belongs to. >> > >> > Are there any suggestions from the side of the freeglut community as to >> > how the API should look like w.r.t. naming etc.? >> > (Particularly since the functions are now also supported in Windows 7). > > I have no experience whatsoever about multitouch APIs, but it looks > reasonable from a first glance. Care to explain a bit more what the > entry function does? I think the rest are pretty obvious. > > -- > John Tsiombikas > http://nuclear.mutantstargoat.com/ > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John T. <nu...@me...> - 2011-03-01 03:32:30
|
On Mon, Feb 28, 2011 at 10:13:56AM -0800, Evan Felix wrote: > > On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: >> >> FGAPI void FGAPIENTRY glutXExtensionEntryFunc( >> void (* callback)( int, int ) ); >> FGAPI void FGAPIENTRY glutXExtensionButtonFunc( >> void (* callback)( int, int, int, int, int ) ); >> FGAPI void FGAPIENTRY glutXExtensionMotionFunc( >> void (* callback)( int, int, int ) ); >> FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( >> void (* callback)( int, int, int ) ); > > Is there a reason not to just name them TouchEntryFunc, etc.. Naming > them XExension seem to allude to a X lockin, but Touch is available > many places now Oh indeed I didn't notice that, yes of course the XExtension bit has to be replaced. But I think "Touch" is not generic enough. I think something like MultiButtonFunc, MultiMotionFunc etc, would be ideal. It signifies that it's just the ButtonFunc and MotionFunc but with multiple pointers involved, wether those pointers are in fact touch or multiple mice, or whatever isn't really relevant. But that's pretty much a bikeshed discussion, most important is the API and its semantics. I'd still appreciate an explanation of what the EntryFunc does. And another thing that I think is more important is to discuss the interaction between multi-pointer and regular mouse events. Assuming that both sets of callbacks are registered by the application, it seems reasonable to expect in a multitouch input device, that the first "touch" will generate a regular mouse event AND a multi mouse event with id 0, while subsequent touches will generate only multi events with increasing IDs. Is that correct? What about the behaviour when the input comes from multiple attached mice, which I assume are easily identifiable, will the same semantics apply? My gut-feeling is that it's preferable if all the connected mice are capable of generating simple mouse events when they happened to be moved first regardless if it's mouse 0 or mouse 3 that moved, but through the multi interface the ID should remain fixed for each device. Your thoughts? How does this patch behave in those situations? As I said I have no experience with multitouch APIs whatsoever, I just think those are interesting questions regarding the semantics of such an interface and if there are many alternatives on how to behave in those situations we should consider them and pick the most intuitive. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. <joh...@cy...> - 2011-03-16 04:06:34
|
Florian, Rather than have me try going through your patch file and your conversation with John to divine the modifications to the patch file, would you be able simply to make a new patch file? It would make life much easier for me. Thanks, John On 3/1/2011 6:04 AM, Florian Echtler wrote: > John, many thanks for your feedback. > > On Tue, 2011-03-01 at 05:32 +0200, John Tsiombikas wrote: > >> On Mon, Feb 28, 2011 at 10:13:56AM -0800, Evan Felix wrote: >> >>> On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: >>> >>>> FGAPI void FGAPIENTRY glutXExtensionEntryFunc( >>>> void (* callback)( int, int ) ); >>>> FGAPI void FGAPIENTRY glutXExtensionButtonFunc( >>>> void (* callback)( int, int, int, int, int ) ); >>>> FGAPI void FGAPIENTRY glutXExtensionMotionFunc( >>>> void (* callback)( int, int, int ) ); >>>> FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( >>>> void (* callback)( int, int, int ) ); >>>> >>> Is there a reason not to just name them TouchEntryFunc, etc.. Naming >>> them XExension seem to allude to a X lockin, but Touch is available >>> many places now >>> >> Oh indeed I didn't notice that, yes of course the XExtension bit has to >> be replaced. But I think "Touch" is not generic enough. I think >> something like MultiButtonFunc, MultiMotionFunc etc, would be ideal. It >> signifies that it's just the ButtonFunc and MotionFunc but with multiple >> pointers involved, wether those pointers are in fact touch or multiple >> mice, or whatever isn't really relevant. >> > Absolutely right, I'll settle on glutMulti*. > > >> But that's pretty much a bikeshed discussion, most important is the API >> and its semantics. I'd still appreciate an explanation of what the >> EntryFunc does. >> > That one's just like the regular glutEntryFunc, it's triggered when the > respective mouse pointer enters the window. > > >> And another thing that I think is more important is to discuss the >> interaction between multi-pointer and regular mouse events. Assuming >> that both sets of callbacks are registered by the application, it seems >> reasonable to expect in a multitouch input device, that the first >> "touch" will generate a regular mouse event AND a multi mouse event with >> id 0, while subsequent touches will generate only multi events with >> increasing IDs. Is that correct? >> > Yes, if both types of callbacks are registered, both are triggered. On > Windows 7, the oldest contact point will control the mouse pointer. > > >> What about the behaviour when the input comes from multiple attached >> mice, which I assume are easily identifiable, will the same semantics >> apply? My gut-feeling is that it's preferable if all the connected mice >> are capable of generating simple mouse events when they happened to be >> moved first regardless if it's mouse 0 or mouse 3 that moved, but >> through the multi interface the ID should remain fixed for each device. >> > That's correct. Moving multiple mice simultaneously will result in > alternating positions for the regular callback. > > >> Your thoughts? How does this patch behave in those situations? As I said >> I have no experience with multitouch APIs whatsoever, I just think those >> are interesting questions regarding the semantics of such an interface >> and if there are many alternatives on how to behave in those situations >> we should consider them and pick the most intuitive. >> > There's probably need for a re-evaluation once XInput 2.1 becomes > available, but right now, I think it covers the two alternatives > reasonably well. > > Florian > |
From: Florian E. <fl...@bu...> - 2011-03-17 11:34:51
|
Hello John, was planning to do that anyway - will soon send a patch against current SVN, including results from the discussion and some additional minor fixes. Florian On Tue, 2011-03-15 at 23:06 -0500, John Fay wrote: > Florian, > > Rather than have me try going through your patch file and your > conversation with John to divine the modifications to the patch file, > would you be able simply to make a new patch file? It would make life > much easier for me. > > Thanks, > John > > > On 3/1/2011 6:04 AM, Florian Echtler wrote: > > John, many thanks for your feedback. > > > > On Tue, 2011-03-01 at 05:32 +0200, John Tsiombikas wrote: > > > >> On Mon, Feb 28, 2011 at 10:13:56AM -0800, Evan Felix wrote: > >> > >>> On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: > >>> > >>>> FGAPI void FGAPIENTRY glutXExtensionEntryFunc( > >>>> void (* callback)( int, int ) ); > >>>> FGAPI void FGAPIENTRY glutXExtensionButtonFunc( > >>>> void (* callback)( int, int, int, int, int ) ); > >>>> FGAPI void FGAPIENTRY glutXExtensionMotionFunc( > >>>> void (* callback)( int, int, int ) ); > >>>> FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( > >>>> void (* callback)( int, int, int ) ); > >>>> > >>> Is there a reason not to just name them TouchEntryFunc, etc.. Naming > >>> them XExension seem to allude to a X lockin, but Touch is available > >>> many places now > >>> > >> Oh indeed I didn't notice that, yes of course the XExtension bit has to > >> be replaced. But I think "Touch" is not generic enough. I think > >> something like MultiButtonFunc, MultiMotionFunc etc, would be ideal. It > >> signifies that it's just the ButtonFunc and MotionFunc but with multiple > >> pointers involved, wether those pointers are in fact touch or multiple > >> mice, or whatever isn't really relevant. > >> > > Absolutely right, I'll settle on glutMulti*. > > > > > >> But that's pretty much a bikeshed discussion, most important is the API > >> and its semantics. I'd still appreciate an explanation of what the > >> EntryFunc does. > >> > > That one's just like the regular glutEntryFunc, it's triggered when the > > respective mouse pointer enters the window. > > > > > >> And another thing that I think is more important is to discuss the > >> interaction between multi-pointer and regular mouse events. Assuming > >> that both sets of callbacks are registered by the application, it seems > >> reasonable to expect in a multitouch input device, that the first > >> "touch" will generate a regular mouse event AND a multi mouse event with > >> id 0, while subsequent touches will generate only multi events with > >> increasing IDs. Is that correct? > >> > > Yes, if both types of callbacks are registered, both are triggered. On > > Windows 7, the oldest contact point will control the mouse pointer. > > > > > >> What about the behaviour when the input comes from multiple attached > >> mice, which I assume are easily identifiable, will the same semantics > >> apply? My gut-feeling is that it's preferable if all the connected mice > >> are capable of generating simple mouse events when they happened to be > >> moved first regardless if it's mouse 0 or mouse 3 that moved, but > >> through the multi interface the ID should remain fixed for each device. > >> > > That's correct. Moving multiple mice simultaneously will result in > > alternating positions for the regular callback. > > > > > >> Your thoughts? How does this patch behave in those situations? As I said > >> I have no experience with multitouch APIs whatsoever, I just think those > >> are interesting questions regarding the semantics of such an interface > >> and if there are many alternatives on how to behave in those situations > >> we should consider them and pick the most intuitive. > >> > > There's probably need for a re-evaluation once XInput 2.1 becomes > > available, but right now, I think it covers the two alternatives > > reasonably well. > > > > Florian > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer -- SENT FROM MY DEC VT50 TERMINAL |
From: John T. <nu...@me...> - 2011-03-24 18:32:22
|
On Thu, Mar 24, 2011 at 08:04:11PM +0200, Eero Pajarre wrote: > Specifically my program which I compile with mostly static linking on > Windows 7 no longer works on Windows XP. (the Freeglut library is also > compiled on Win 7) > > This is because the multitouch functions are not available in > user32.dll in XP as they apparently are in later OS versions. So in that case they should be loaded at runtime with LoadLibrary/GetProcAddress. That should be a trivial fix. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Fay, J. F Dr C. U. A. AAC/X. <joh...@eg...> - 2011-03-24 19:36:00
|
Eero, Can you send a patch, please? John F. Fay Technical Fellow, Modeling and Simulation Jacobs Technology / TEAS Group P.O. Box 1935, Eglin AFB, FL 32542-5000 850-883-3496 -----Original Message----- From: Eero Pajarre [mailto:epa...@gm...] Sent: Thursday, March 24, 2011 1:04 PM To: FreeGLUT developers list Subject: Re: [Freeglut-developer] Multitouch patch v2, now with Win7 I just updated to latest (this morning local time) SVN version of Freeglut. I noticed an unfortunate side effect of the multitouch addition, it breaks binary compatibility between Microsoft operating systems. Specifically my program which I compile with mostly static linking on Windows 7 no longer works on Windows XP. (the Freeglut library is also compiled on Win 7) This is because the multitouch functions are not available in user32.dll in XP as they apparently are in later OS versions. I did fix this on my own system, but this might need some consideration. Eero ------------------------------------------------------------------------ ------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Eero P. <epa...@gm...> - 2011-03-25 05:15:36
|
On Thu, Mar 24, 2011 at 9:35 PM, Fay, John F Dr CTR USAF AFMC AAC/XRS <joh...@eg...> wrote: > Eero, > > Can you send a patch, please? > I will try, either today, or during the weekend.... (My first fix was to #if 0 the code out, but that was because I was doing an "onsite software installation") Eero |
From: John F. <joh...@cy...> - 2011-03-25 03:52:28
|
OK, we have a problem. Multitouch is supported by later Windows versions but not by Windows XP. Is it available on Posix/X11? I think we can live with a discrepancies between platforms as long as it's only Windows XP--and it needs still to build on that operating system and not crash when running--but something Windows-only with no X11 support is not good. - John On 3/24/2011 1:32 PM, John Tsiombikas wrote: > On Thu, Mar 24, 2011 at 08:04:11PM +0200, Eero Pajarre wrote: > >> Specifically my program which I compile with mostly static linking on >> Windows 7 no longer works on Windows XP. (the Freeglut library is also >> compiled on Win 7) >> >> This is because the multitouch functions are not available in >> user32.dll in XP as they apparently are in later OS versions. >> > So in that case they should be loaded at runtime with > LoadLibrary/GetProcAddress. That should be a trivial fix. > > |
From: John T. <nu...@me...> - 2011-03-25 05:38:55
|
On Thu, Mar 24, 2011 at 10:52:17PM -0500, John Fay wrote: > OK, we have a problem. Multitouch is supported by later Windows > versions but not by Windows XP. Is it available on Posix/X11? Yes, through the XInput extension. The multitouch patch you commited recently does implement the multitouch callbacks for X11, and if I remember correctly it even started life some time ago as a UNIX-only patch when it was first submitted to this list. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Florian E. <fl...@bu...> - 2011-03-25 08:36:09
|
Hello everyone, On Thu, 2011-03-24 at 19:32 +0100, John Tsiombikas wrote: > On Thu, Mar 24, 2011 at 08:04:11PM +0200, Eero Pajarre wrote: > > Specifically my program which I compile with mostly static linking on > > Windows 7 no longer works on Windows XP. (the Freeglut library is also > > compiled on Win 7) > > This is because the multitouch functions are not available in > > user32.dll in XP as they apparently are in later OS versions. Put that down as my mistake; I absolutely forgot about cross-compilation. > So in that case they should be loaded at runtime with > LoadLibrary/GetProcAddress. That should be a trivial fix. AFAICT the offending functions are: RegisterTouchWindow GetTouchInputInfo ScreenToClient CloseTouchInputHandle LoadLibrary probably isn't even necessary as user32.dll will always be loaded anyway. So this should be a matter of something like fghRegisterTouchWindow = GetProcAddress(GetModuleHandle("user32"),"RegisterTouchWindow"); I'll try to integrate this today and send a new patch. Florian -- SENT FROM MY DEC VT50 TERMINAL |
From: John F. F. <joh...@cy...> - 2011-05-27 20:18:05
|
Change set 919 - John On 5/3/2011 10:33 AM, Florian Echtler wrote: > Hello again, > > this took *a lot* longer than I hoped, but here's a patch that hopefully > fixes the cross-compilation issue by checking for the MT functions at > runtime. > > Florian > > On Fri, 2011-03-25 at 09:36 +0100, Florian Echtler wrote: > >> Hello everyone, >> >> On Thu, 2011-03-24 at 19:32 +0100, John Tsiombikas wrote: >> >>> On Thu, Mar 24, 2011 at 08:04:11PM +0200, Eero Pajarre wrote: >>> >>>> Specifically my program which I compile with mostly static linking on >>>> Windows 7 no longer works on Windows XP. (the Freeglut library is also >>>> compiled on Win 7) >>>> This is because the multitouch functions are not available in >>>> user32.dll in XP as they apparently are in later OS versions. >>>> >> Put that down as my mistake; I absolutely forgot about >> cross-compilation. >> >> >>> So in that case they should be loaded at runtime with >>> LoadLibrary/GetProcAddress. That should be a trivial fix. >>> >> AFAICT the offending functions are: >> >> RegisterTouchWindow >> GetTouchInputInfo >> ScreenToClient >> CloseTouchInputHandle >> >> LoadLibrary probably isn't even necessary as user32.dll will always be >> loaded anyway. So this should be a matter of something like >> >> fghRegisterTouchWindow = >> GetProcAddress(GetModuleHandle("user32"),"RegisterTouchWindow"); >> >> I'll try to integrate this today and send a new patch. >> >> Florian >> > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > > > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John F. F. <joh...@cy...> - 2011-06-08 02:09:05
|
OK, do I need to put something into SVN for this? - John On 6/5/2011 3:54 PM, Eero Pajarre wrote: > On Fri, May 27, 2011 at 11:17 PM, John F. Fay<joh...@cy...> wrote: > >> Change set 919 >> >> - John >> >> >> On 5/3/2011 10:33 AM, Florian Echtler wrote: >> >> Hello again, >> >> this took *a lot* longer than I hoped, but here's a patch that hopefully >> fixes the cross-compilation issue by checking for the MT functions at >> runtime. >> > > I now had time to updated to the latest freeglut. On my DebugStatic > build I compile with checking options, and while running (under visual > studio debugger) I get an error message which complains on some > register value being broken on function call, and claiming that > probable cause is using incorrect function call style. > > I fixed this by changing all the function related typedefs in this patch to > typedef BOOL (WINAPI *pRegisterTouchWindow)(HWND,ULONG); > > (two of these in freeglut_main and one in freeglut_window) > > Florian, could you check this (contact me if you need more info for > replicating the problem). > > Eero > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > |
From: Eero P. <epa...@gm...> - 2011-06-08 06:14:13
Attachments:
diff.api
|
(Added Florian as a direct recipient, as I am mangling his code....) On Wed, Jun 8, 2011 at 5:08 AM, John F. Fay <joh...@cy...> wrote: > OK, do I need to put something into SVN for this? > I am attaching the changes I did. (cleaned from svn diff, done in src directory) Eero |
From: Florian E. <fl...@bu...> - 2011-03-01 12:05:07
|
John, many thanks for your feedback. On Tue, 2011-03-01 at 05:32 +0200, John Tsiombikas wrote: > On Mon, Feb 28, 2011 at 10:13:56AM -0800, Evan Felix wrote: > > > > On Mon, Feb 28, 2011 at 09:58:05AM +0100, Florian Echtler wrote: > >> > >> FGAPI void FGAPIENTRY glutXExtensionEntryFunc( > >> void (* callback)( int, int ) ); > >> FGAPI void FGAPIENTRY glutXExtensionButtonFunc( > >> void (* callback)( int, int, int, int, int ) ); > >> FGAPI void FGAPIENTRY glutXExtensionMotionFunc( > >> void (* callback)( int, int, int ) ); > >> FGAPI void FGAPIENTRY glutXExtensionPassiveFunc( > >> void (* callback)( int, int, int ) ); > > > > Is there a reason not to just name them TouchEntryFunc, etc.. Naming > > them XExension seem to allude to a X lockin, but Touch is available > > many places now > > Oh indeed I didn't notice that, yes of course the XExtension bit has to > be replaced. But I think "Touch" is not generic enough. I think > something like MultiButtonFunc, MultiMotionFunc etc, would be ideal. It > signifies that it's just the ButtonFunc and MotionFunc but with multiple > pointers involved, wether those pointers are in fact touch or multiple > mice, or whatever isn't really relevant. Absolutely right, I'll settle on glutMulti*. > But that's pretty much a bikeshed discussion, most important is the API > and its semantics. I'd still appreciate an explanation of what the > EntryFunc does. That one's just like the regular glutEntryFunc, it's triggered when the respective mouse pointer enters the window. > And another thing that I think is more important is to discuss the > interaction between multi-pointer and regular mouse events. Assuming > that both sets of callbacks are registered by the application, it seems > reasonable to expect in a multitouch input device, that the first > "touch" will generate a regular mouse event AND a multi mouse event with > id 0, while subsequent touches will generate only multi events with > increasing IDs. Is that correct? Yes, if both types of callbacks are registered, both are triggered. On Windows 7, the oldest contact point will control the mouse pointer. > What about the behaviour when the input comes from multiple attached > mice, which I assume are easily identifiable, will the same semantics > apply? My gut-feeling is that it's preferable if all the connected mice > are capable of generating simple mouse events when they happened to be > moved first regardless if it's mouse 0 or mouse 3 that moved, but > through the multi interface the ID should remain fixed for each device. That's correct. Moving multiple mice simultaneously will result in alternating positions for the regular callback. > Your thoughts? How does this patch behave in those situations? As I said > I have no experience with multitouch APIs whatsoever, I just think those > are interesting questions regarding the semantics of such an interface > and if there are many alternatives on how to behave in those situations > we should consider them and pick the most intuitive. There's probably need for a re-evaluation once XInput 2.1 becomes available, but right now, I think it covers the two alternatives reasonably well. Florian -- SENT FROM MY DEC VT50 TERMINAL |
From: Eero P. <epa...@gm...> - 2011-03-24 18:04:18
|
I just updated to latest (this morning local time) SVN version of Freeglut. I noticed an unfortunate side effect of the multitouch addition, it breaks binary compatibility between Microsoft operating systems. Specifically my program which I compile with mostly static linking on Windows 7 no longer works on Windows XP. (the Freeglut library is also compiled on Win 7) This is because the multitouch functions are not available in user32.dll in XP as they apparently are in later OS versions. I did fix this on my own system, but this might need some consideration. Eero |
From: Florian E. <fl...@bu...> - 2011-05-03 15:53:21
Attachments:
freeglut_mt_fix.patch
|
Hello again, this took *a lot* longer than I hoped, but here's a patch that hopefully fixes the cross-compilation issue by checking for the MT functions at runtime. Florian On Fri, 2011-03-25 at 09:36 +0100, Florian Echtler wrote: > Hello everyone, > > On Thu, 2011-03-24 at 19:32 +0100, John Tsiombikas wrote: > > On Thu, Mar 24, 2011 at 08:04:11PM +0200, Eero Pajarre wrote: > > > Specifically my program which I compile with mostly static linking on > > > Windows 7 no longer works on Windows XP. (the Freeglut library is also > > > compiled on Win 7) > > > This is because the multitouch functions are not available in > > > user32.dll in XP as they apparently are in later OS versions. > Put that down as my mistake; I absolutely forgot about > cross-compilation. > > > So in that case they should be loaded at runtime with > > LoadLibrary/GetProcAddress. That should be a trivial fix. > AFAICT the offending functions are: > > RegisterTouchWindow > GetTouchInputInfo > ScreenToClient > CloseTouchInputHandle > > LoadLibrary probably isn't even necessary as user32.dll will always be > loaded anyway. So this should be a matter of something like > > fghRegisterTouchWindow = > GetProcAddress(GetModuleHandle("user32"),"RegisterTouchWindow"); > > I'll try to integrate this today and send a new patch. > > Florian -- SENT FROM MY DEC VT50 TERMINAL |
From: Eero P. <epa...@gm...> - 2011-06-05 20:54:54
|
On Fri, May 27, 2011 at 11:17 PM, John F. Fay <joh...@cy...> wrote: > Change set 919 > > - John > > > On 5/3/2011 10:33 AM, Florian Echtler wrote: > > Hello again, > > this took *a lot* longer than I hoped, but here's a patch that hopefully > fixes the cross-compilation issue by checking for the MT functions at > runtime. I now had time to updated to the latest freeglut. On my DebugStatic build I compile with checking options, and while running (under visual studio debugger) I get an error message which complains on some register value being broken on function call, and claiming that probable cause is using incorrect function call style. I fixed this by changing all the function related typedefs in this patch to typedef BOOL (WINAPI *pRegisterTouchWindow)(HWND,ULONG); (two of these in freeglut_main and one in freeglut_window) Florian, could you check this (contact me if you need more info for replicating the problem). Eero |
From: Florian E. <fl...@bu...> - 2011-06-08 07:37:35
|
Eero, many thanks for your fix. I'm assuming that my original patch worked for you and fixed the cross-compilation problem? John, I think this can be applied to SVN directly with no ill side effects. Yours, Florian On Wed, 2011-06-08 at 09:14 +0300, Eero Pajarre wrote: > (Added Florian as a direct recipient, as I am mangling his code....) > > On Wed, Jun 8, 2011 at 5:08 AM, John F. Fay <joh...@cy...> wrote: > > OK, do I need to put something into SVN for this? > > > > I am attaching the changes I did. (cleaned from svn diff, done in src directory) > > Eero -- SENT FROM MY DEC VT50 TERMINAL |
From: Eero P. <epa...@gm...> - 2011-06-08 09:43:42
|
On Wed, Jun 8, 2011 at 10:37 AM, Florian Echtler <fl...@bu...> wrote: > Eero, many thanks for your fix. I'm assuming that my original patch > worked for you and fixed the cross-compilation problem? I actually just now had the time to test this, but yes it Win7 -> WinXP cross compiled program seems to be good. Eero |
From: John F. F. <joh...@cy...> - 2011-06-10 03:51:03
|
It is done, in revision 925. - John On 6/8/2011 2:37 AM, Florian Echtler wrote: > Eero, many thanks for your fix. I'm assuming that my original patch > worked for you and fixed the cross-compilation problem? > > John, I think this can be applied to SVN directly with no ill side > effects. > > Yours, > Florian > > On Wed, 2011-06-08 at 09:14 +0300, Eero Pajarre wrote: > >> (Added Florian as a direct recipient, as I am mangling his code....) >> >> On Wed, Jun 8, 2011 at 5:08 AM, John F. Fay<joh...@cy...> wrote: >> >>> OK, do I need to put something into SVN for this? >>> >>> >> I am attaching the changes I did. (cleaned from svn diff, done in src directory) >> >> Eero >> > |