Re: Weird problems with keyboard

[Federico Mena <federico nuclecu unam mx>]

>  Try making the following change to gdk.c and see if it helps:
>  
>    static gint
>    gdk_event_translate (GdkEvent *event,
>  	  	       XEvent   *xevent)
>    {
>  
>      GdkWindow *window;
>      GdkWindowPrivate *window_private;
>  -   XComposeStatus compose;
>  +   static XComposeStatus compose;
>      int charcount;
>    #ifdef USE_XIM
>      static gchar* buf = NULL;
>      static gint buf_len= 0;

This didn't do it; it keeps crashing.

>  (GDK was passing a pointer to unitialized stack data to an argument
>   that according to X specs should be ignored, but isn't always)
>  
>  If that doesn't help, try changing
>  
>  	charcount = XLookupString (&xevent->xkey, buf, buf_len,
>  				   (KeySym*) &event->key.keyval,
>  -				   &compose);
>  +				   NULL);
>  
>  (There are two of those)

I replaced all such occurrences by NULL, and it keeps crashing.  Argh
:-(

Actually, passing NULL seems to be the right thing to do.  At least it
says so in the Xlib manual; it seems that whatever is returned in the
status_in_out parameter is not portable.  It says:

       If present (non-NULL), the XComposeStatus structure records the
       state, which is private to Xlib, that needs preservation across
       calls to XLookupString to implement compose processing.  The
       creation of XComposeStatus structures is implementation-
       dependent; a portable program must pass NULL for this argument.

>  If neither helps, I'm on the wrong track.

Do you have any idea why it would work fine when I run the program on
an Intel box but keep the display on the Linux/Sparc?  Or when I keep
running it on the alpha but with display on a Solaris box?  This looks
pretty weird to me.

As soon as the Solaris machine is free, I'll get xev to tell me what
kind of stuff X thinks the keyboard is sending.  Would that be useful
at all?

  Quartic