Re: [AD] More Unix patches

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Jason Wilkins <fenix@xxxxxxxxxx> writes:
> What I have not done i figured out how to map KB_ACCENT* and KB_INALTSEQ* 

You don't need to. KB_ACCENT is only relevant when you are entering accented 
characters from different locales, and KB_INALTSEQ when you use the 
alt+numpad sequence to type a character in directly as a numeric value. 
Since you are using the OS for all the character codes conversion, this 
stuff doesn't apply.

> Shawn, could you explain how these work?

In allegro.cfg, set keyboard=es. Fire up the grabber, put the cursor over a 
text entry box, and press [+e. The [ escape key adds an accent to whatever 
you press. During this interval after you pressed [ but before you hit the 
e, a KB_ACCENT flag will be set.

btw. don't try this test in exkeys or the test.exe keyboard test: I just 
tried this and found that it didn't work :-) To fix it, you need to edit 
those files and change the sprintf() calls to usprintf().

> I think that BeOS uses something called 'dead keys' to handle accenting 
> characters, which is probably the same thing as the allegro accent shifts. 
> To give allegro access to these, I may need to set a KB_ACCENT shift flag 
> when a person uses a dead key combination.

Just don't bother setting the accent flags at all. They are state 
information for the keyboard handler rather than something that user 
programs ever need to know about, and as long as you produce sensible 
end-level input, it doesn't matter if the intermediate steps are a bit 
different.

> There is also a lot of other functionality in pckeys.c which I don't want
> to duplicate, but may want to use.  It really depends on if BeOS already
> has keymapping that does everything Allegro creates for DOS.

As long as you are reading your character codes from the OS, I think that 
should be total. If the OS lacks some feature, that feature should stay 
missing: it would get too complicated if you started using the OS to do most 
of the conversions, but then trying to add other bits of information 
yourself. None of the code in pckeys does anything other than to convert 
scancodes into character codes, and to set the modifier flags, so as long as 
you have some other source of the character code data, it is irrelevant.

The only really useful feature you might want to put in is ctrl+alt+end to 
kill off the program. But that has to be done in the hardware driver, 
because the method is wildly different from one platform to another (I still 
haven't figured out how to do it in Watcom without rebooting the machine).

> Another keyboard driver related question.  Right now, capslock, numlock,
> and scroll-lock all stay down when you press them, and are only released
> when you hit them again.  I am thinking that this behavior is in software,
> not hardware, and should be disabled when the allegro keyboard driver is
> installed.  Am I right, or do these key need to continue to lock when
> pressed?

ctrl, alt, and shift are realtime toggles, but the locks are sticky. The 
flags in the key array should respond straight away (on when the key is 
down, off when it is up), but the flags in _key_shifts only change state 
when you press the key.

> PrintScr/SysRq has a strange habit of creating a screen shot in my home
> directory when I press it.   I hope I can disable this.

If that is a BeOS standard, you might as well leave it. Windows does the 
same thing, but to the clipboard.

> Pause is a really strange key, I'm not sure at all what its doing, but its
> not like the other keys.

In hardware terms, it only sends make codes, so pressing it once makes it be 
set, and then pressing it again makes it be released. You don't get any 
interrupt from releasing it at all. Very odd.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."