If it's coming from the X, can't you switch off autorepeat in the X ?
Granted, I cannot find the correct documentaiton as to how to do it at
the shell level, but the XkeyboardControl structure contains a flag to
set it off or on... So there must be a way... Like xset -r ?


...............

            int auto_repeat_mode;/* AutoRepeatModeOff, AutoRepeatModeOn,
                                   AutoRepeatModeDefault */
       } XKeyboardControl;


Just a thought...

 It does not work on the computer where I am sitting but that may be
because I am logged in over the network using SSH on a PuTTy terminal
from a Windows machien, so nobody can figure out who's responsible for
the key repeats.



> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> On Behalf Of ugur guney
> Sent: 29 May 2007 12:28
> To: Claude Heiland-Allen
> Cc: pd-list
> Subject: Re: [PD] Behavoir of [keyup] in Linux
> 
> # Adding a delay worked well. But something is surprising. 
> The [delay] have to be longer than 0.1 to block this 
> oscillating behavior. I'm attaching a patch (delaykey.pd) 
> which shows the implementation. I think X11 gives the "key 
> pressed" message in every 40 msec's or something. So 0.1 
> delay is not enough to block these messages.
> # and I'm attaching the abstracion I was using in Windows 
> too. (keybin.pd, keybin-help.pd)
> -ugur-
> 
> 
> On 5/29/07, Claude Heiland-Allen <[EMAIL PROTECTED]> wrote:
> 
>       ugur guney wrote:
>       > # When I press and hold a key, after a short time 
> [keyup] starts to output
>       > the number of that key repeatedly (before releasing 
> it). In Windows it only
>       > outputs the key no when a key is released. 
> 
> 
>       It's just the way X11 works, as far as I understand it. 
>  I did a test
>       with GridFlow, and the same thing happens (console log 
> from attached patch):
>       
>       Here the first number is the elapsed time since the 
> previous event
>       (measured in Pd logical time).  It would be possible to patch up
>       something that would discard any "keyrelease 
> immediately-followed-by
>       keypress for the same key" pairs that occur with an 
> elapsed time of 0
>       (hint: it would use [delay 0.1] or so, maybe even 
> [delay 0] would work). 
>         The last keyrelease would be delayed a little, but it 
> would either be
>       unnoticeable with [delay 0.1] or at exactly the same 
> logical time with
>       [delay 0]
>       
>       
> 
> 

_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to