From mint-bounce@lists.fishpool.fi Thu Jul 7 15:04:46 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] [XAAES] Does not generate MU_TIMER events when asked From: Odd Skancke To: MiNT List In-Reply-To: <1120737364.5673.93.camel@linuxbox> References: <20050707132928.155c2829.mandin.patrice@wanadoo.fr> <1120737364.5673.93.camel@linuxbox> Content-Type: text/plain Date: Thu, 07 Jul 2005 15:00:53 +0200 Message-Id: <1120741253.5673.106.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.7 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: tor, 07,.07.2005 kl. 13.56 +0200, skrev Odd Skancke: > tor, 07,.07.2005 kl. 13.29 +0200, skrev Patrice Mandin: > > Hello, > > > > I have a big problem with Xaaes when running SDL programs: > > > > I use MU_TIMER to avoid waiting for AES events for too long, however > > Xaaes never generates MU_TIMER events when I ask him to do so. All my > > programs get stuck in the loop that calls AES event_multi(), waiting for > > a MU_TIMER event that never comes. > > Just ran the testprogram, and can confirm that this is a big problem > yes. I will see if I can figure it out as soon as possible. Ok, I know now what is 'wrong' .. In XaAES timer events are cancelled when any other AES events happens. The reason for this is that there is no mechanism to tell the AES that one wants to wait for a 'pending timeout', set by an earlier evnt_multi (). So, the problem seen with the test application is that MU_Mx events happens before the set timeout fires, and the timeout is cancelled upon delivering events to the client and reset again on the next evnt_multi (). I'm not sure how this is handled in other AES's, but I can imagine something like this; If a previous MU_TIMER has not yet timed out, do not use the value passed by evnt_multi(), but let the pending timeout continue. This means MU_TIMER requests are ignored by evnt_multi() (and perhaps evnt_timer()) if there is already a timeout pending. Summary; XaAES always resets a fresh timeout on every evnt_multi(), meaning that if one also MU_Mx to look for mousemovements, a timeout value of 10, for example, will never happen as long as the user moves the mouse. Other AES's ignores consecutive MU_TIMER settings until the first one actually has happened. I think this basically means one cannot change or cancel a timeout already set. I dont like the 'other AES' method, and am fishing for suggestions here. Best Regards Odd Skancke