Re: [AD] XIM patch for Allegro 4.1.x

[Elias Pschernig <allefant@xxxxxxxxxx>]

> 
> Allegro.log attached. Here's what the top row of my keyboard looks like, if
> that helps:
> 
>   1   2     3     4     5     6     7     8     9     0
>   &   é ~   " #   ' {   ( [   - |   è `   _ \   ç ^   à @
> 
> As expected, the 4th and 6th keys get assigned KEY_QUOTE and KEY_MINUS, and
> the others get random constants. I'm not sure there is much you can do about
> that. KEY_0 and co. are just part of the constants that only make sense on a
> QWERTY keyboard.

Yes, just what I thought. It would still be nice to have a vers basic
set of keys to work with the KEY_* (even if a properly written program
shouldn't rely on it), including 0-9.
In this case, I can add a check for numbers in the second row, which
would have higher priority. It would be a hack, but so is
all the mapping to Allegro's KEY_* symbols. E.g. my keyboard has no
KEY_QUOTE, so it's detection is doomed to fail.

> 
> Sorry, I expressed myself poorly. Dead keys work exactly as you describe, but
> as a side effect, they set key[0]. Not really a problem, but I thought you
> might want to know.
> 

I think the problem is in keyboard.c:

      if (scancode >= 0) {
	 if ((!repeat_delay) && (_key[scancode]))
	    return;

	 _key[scancode] = -1;
      }

      if (keycode >= 0)
	 add_key(&_key_buffer, keycode, scancode);

If I change that last keycode >= 0 to keycode > 0, key[0] is not
reported anymore. Does anyone know why the 0 key was allowed at all?

> > > (4) Are you going to implement scancode_to_ascii() ? This is a very
> > > usefull function, for example to display meaningful key names in a
> > > controls-configuration screen. Even more so now that a lot of KEY_*
> > > constants have lost their meaning...
> >
> > I was going to add a scancode_to_ascii, which would just map e.g.
> > KEY_A to A. But it should be possible to create a reverse lookup
> > table, and provide the actual ascii - I'll add it.
> 
> That'd be wonderfull, thanks!
> 

Of course, for KEY_3, it would always return ". It would actually be
easy to report all the codes generated for the key, since X11 reports
that information (as can be seen in the logfile).

> > > (5) The changes made to the X port seem to have broken AllegroGL :-( Some
> > > of its examples work, but other crash. In my current project, if I call
> > > install_keyboard(), there are things that fails for no apparent
> > > reasons...
> >
> > Hm.. this sounds bad. Probably has to do with X locking. I'll try to
> > investigate, but NVidia's drivers are broken for my card.
> 
> I can help if you need. Also, can't you use OpenGL unaccelerated ? That might
> be enough to test. Or maybe this is a problem for Bob to fix ;-) Should I
> report on [AGL] ?
> 
> Anyway, here's what I could gather after a bit of investigation :
> 
> The AllegroGL examples that fail are dumbtest, exgui and exalleg. They have in
> common that they use rect() and rectfill() directly, or indirectly through
> gui objects. After commenting these use, they work fine. Does that help ?
> 

I think, you should report on the AGL list.. I just tried it here, and
it crashes with a 0 pointer reference in rect() it seems - can't see
how that is connected to XIM though.

> Also, in my program the problem was a locale problem: it seems the new
> install_keyboard somehow changes part or all of the program's locale to that
> of the keyboard layout. This is a problem with Lua, because it is known not
> to work in a locale where the decimal point is not a dot. If I put a
> setlocale(LC_ALL, "C") after install_keyboard, my program works again. Yay!
> (I don't use any allegro functions like rect).
> 

I'm confused. Does the rect problem have to do with the local problem,
or is it a different problem? I must admit, I have no idea why, but
XIM requires to set the locale:

setlocale(LC_ALL,"")

^ That's done in the initialization. When I remove it, XIM won't
initialize. But maybe it should be set back to the default locale
after XIM is initialized? Definitely need to investigate why XIM wants
a different locale..