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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-11-22 at 18:20 +0100, Julien Cugnière wrote:
> Elias Pschernig a écrit :
> 
> > - pckeys isn't linked into the X11 version anymore
> 
> Hmm, this generates lots of "undefined reference" errors during the 
> compilation of setup/keyconf.c. This utility relies on _key_ascii_table and 
> co., which are all defined in pckeys.c.
> 

Ah, yes, sorry. I'll remove keyconf from the programs that are built on
unix, since it makes no sense - X11/linux_console/OSX all don't use
keyboard.dat. Only the platforms using the evil pckeys.c actually should
build keyconf. I also updated xkeymap, which had the same problem.

> > More serious changes:
> > - new function: char const *scancode_to_name(int scancode);
> 
> Personnaly, I'm all for it. But there is a small typo in the patch, in 
> _keyboard_common_name[]: "KEy106". 
> 

Fixed, thanks.


> The only problem with KeysymToString is with modifiers keys: KEY_LWIN and 
> KEY_RWIN are named "Super_L" and "Super_R", and KEY_ALTGR is named 
> "ISO_Level3_Shift" (!). It might be better to use our names where possible, 
> and use KeysymToString for the rest.
> 

Yes, I was wondering about that as well.. probably makes sense to use
the Allegro names for all the modifier keys (not thinking about the poor
Sunos or Darwin users).

> > - updated exkeys to demonstrate keyboard_lowlevel_callback and
> > scancode_to_name
> 
> Here are a couple things I noticed in the example:
> 
> (1) Unfortunately, drawing from a callback doesn't work, not even in X :-(. 
> The program sometimes aborts when I press keys, or hold them down. Doesn't 
> always happen, though...

Um. I guess this isn't such a good idea then. But I wonder why it aborts
- it seems to work here. All X11 drawing should use a pthread lock, so
even when drawing from the input thread, it should work in this case,
where nothing else (e.g. the mouse) is drawn. I guess it will work once
we clarify that _xwin_in_gfx_call issue. But for now, I'll not do any
changes to exkeys.

> (2a) During the "press a combination of numbers" part, keys (not just numbers) 
> sometime get "stuck". They appear pressed even after you've released them. 
> This doesn't happen anymore if I put a "rest(0)" inside the loop, or remove 
> the keypress_handler.

A rest(0) or better rest(1) there is a good idea in any case, since
exkeys jumps to 100% CPU usage in the numbers test for me, otherwise.

> 
> (2b) Also, with or without the keypress_handler, this part of the example is a 
> bit "unresponsive": when pressing a number key, there is sometimes a small 
> delay before the appearance / disappearance of the number on the screen. 
> Again, this doesn't happen anymore if I put a rest(0) in the loop. But IIRC, 
> unresponsive input when drawing in a tigh loop is a long standing issue, no ?
> 

Only with the signals version, not with the pthread version. But depends
on the kernel settings I guess.. mine seems to schedule the input thread
as responsive despite the spinlocking main thread - I can't notice any
responsiveness loss in the numbers test - just the fans start noising
loud. Are you using a 2.4.x kernel maybe? That did a context switch
every time a pthread lock was encountered.. 

> (3) The example will crash if scancode_to_name() returns NULL. This happens 
> for me for the "Power", "Sleep" and "Wake" keys. They get assigned the 
> KEY_YEN, KEY_KANA and KEY_CONVERT constants, but scancoded_toname() returns 
> NULL, and the keypress_handler crashes, presumably in ustrzncpy().
> 

Oops. Yeah, scancode_to_name shouldn't return NULL for valid scancodes,
and the return value should be checked for NULL in any case. Fixed it.

To not produce a complete mess here, I applied all the mentioned stuff
which just fixes things related to the XIM patch to CVS now.

A patch against the updated cvs containing only the scancode_to_name
addition and modified exkeys (just to test the new function) is
attached.

-- 
Elias Pschernig

Attachment: keys3.diff.gz
Description: GNU Zip compressed data