Under WIN32 numeric keypad keys don’t return
the same codes as under linux.
If you run the “checkkey” test program you can check that
return codes are not the same (in event.key.keysym.unicode).
I patched it in my program, but I really think
that it’s a little SDL’s bug (SDL must have the same
behaviour under different OSs). Isn’t it?
Thanks,
Enzo.
Hello, I’m reposting a mail that I’ve sent a few days ago,
cause I’ve got no answers.>Under WIN32 numeric keypad keys don’t return
the same codes as under linux.
If you run the “checkkey” test program you can check that
return codes are not the same (in event.key.keysym.unicode).I patched it in my program, but I really think
that it’s a little SDL’s bug (SDL must have the same
behaviour under different OSs). Isn’t it?Thanks,
Enzo.
“Enzo” wrote in message
news:20001030100853.A902 at tiscalinet.it…
Hello, I’m reposting a mail that I’ve sent a few days ago,
cause I’ve got no answers.Under WIN32 numeric keypad keys don’t return
the same codes as under linux.
If you run the “checkkey” test program you can check that
return codes are not the same (in event.key.keysym.unicode).I patched it in my program, but I really think
that it’s a little SDL’s bug (SDL must have the same
behaviour under different OSs). Isn’t it?
So, what results are you getting? AFAIK arrow keys don’t translate to
unicode at all. If num-lock is on, the keypad keys should translate to the
digit characters (0-9). Remember, event.key.keysym.sym contains the actual
key, while event.key.keysym.unicode contains the translation of the key (and
only if unicode translation is enabled).–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
So, what results are you getting? AFAIK arrow keys don’t translate to
unicode at all. If num-lock is on, the keypad keys should translate to the
digit characters (0-9). Remember, event.key.keysym.sym contains the actual
key, while event.key.keysym.unicode contains the translation of the key (and
only if unicode translation is enabled).
Under linux if I have numlock key enabled event.key.keysym.unicode
returns the code of the number I press, under Win32 it doesn’t.
I really think the correct one is that under linux,
and the SDL must do the same on each OS.
Thanks,
Enzo.–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.supereva.it
Under linux if I have numlock key enabled event.key.keysym.unicode
returns the code of the number I press, under Win32 it doesn’t.
I really think the correct one is that under linux,
and the SDL must do the same on each OS.
You still haven’t given us the exact codes (keysym, unicode, scancode) from
the two systems. The keypad doesn’t have that many keys, so the list should
be short.
Num lock is an anachronism anyway, from the time of the original IBM PC
keyboard which lacked separate arrow keys. It was made obsolete when the
PC AT arrived, about 1985
marted? 31 ottobre Mattias Engdeg?rd ha scritto:
You still haven’t given us the exact codes (keysym, unicode, scancode) from
the two systems. The keypad doesn’t have that many keys, so the list should
be short.
Ok, here it is:
This is output of checkkeys under linux:
With NUMLOCK ON
Unicode
|
V
Key pressed: 266-[.] (.) Key released: 266-[.] (.)
Key pressed: 256-[0] (0) Key released: 256-[0] (0)
Key pressed: 257-[1] (1) Key released: 257-[1] (1)
Key pressed: 258-[2] (2) Key released: 258-[2] (2)
Key pressed: 259-[3] (3) Key released: 259-[3] (3)
Key pressed: 260-[4] (4) Key released: 260-[4] (4)
Key pressed: 261-[5] (5) Key released: 261-[5] (5)
Key pressed: 262-[6] (6) Key released: 262-[6] (6)
Key pressed: 263-[7] (7) Key released: 263-[7] (7)
Key pressed: 264-[8] (8) Key released: 264-[8] (8)
Key pressed: 265-[9] (9) Key released: 265-[9] (9)
Key pressed: 267-[/] (/) Key released: 267-[/] (/)
Key pressed: 268-[] () Key released: 268-[] ()
Key pressed: 269-[-] (-) Key released: 269-[-] (-)
Key pressed: 270-[+] (+) Key released: 270-[+] (+)
Key pressed: 271-enter (^M) Key released: 271-enter (^M)
With NUMLOCK OFF
Unicode
|
V
Key pressed: 266-[.] Key released: 266-[.]
Key pressed: 256-[0] Key released: 256-[0]
Key pressed: 257-[1] Key released: 257-[1]
Key pressed: 258-[2] Key released: 258-[2]
Key pressed: 259-[3] Key released: 259-[3]
Key pressed: 260-[4] Key released: 260-[4]
Key pressed: 261-[5] Key released: 261-[5]
Key pressed: 262-[6] Key released: 262-[6]
Key pressed: 263-[7] Key released: 263-[7]
Key pressed: 264-[8] Key released: 264-[8]
Key pressed: 265-[9] Key released: 265-[9]
Key pressed: 267-[/] (/) Key released: 267-[/] (/)
Key pressed: 268-[] () Key released: 268-[] ()
Key pressed: 269-[-] (-) Key released: 269-[-] (-)
Key pressed: 270-[+] (+) Key released: 270-[+] (+)
Key pressed: 271-enter (^M) Key released: 271-enter (^M)
This is output of checkkeys under win32:
With NUMLOCK ON
Unicode
|
V
Key pressed: 266-[.] Key released: 266-[.]
Key pressed: 256-[0] Key released: 256-[0]
Key pressed: 257-[1] Key released: 257-[1]
Key pressed: 258-[2] Key released: 258-[2]
Key pressed: 259-[3] Key released: 259-[3]
Key pressed: 260-[4] Key released: 260-[4]
Key pressed: 261-[5] Key released: 261-[5]
Key pressed: 262-[6] Key released: 262-[6]
Key pressed: 263-[7] Key released: 263-[7]
Key pressed: 264-[8] Key released: 264-[8]
Key pressed: 265-[9] Key released: 265-[9]
Key pressed: 267-[/] (/) Key released: 267-[/] (/)
Key pressed: 268-[] () Key released: 268-[] ()
Key pressed: 269-[-] (-) Key released: 269-[-] (-)
Key pressed: 270-[+] (+) Key released: 270-[+] (+)
Key pressed: 271-enter (^M) Key released: 271-enter (^M)
With NUMLOCK OFF
Unicode
|
V
Key pressed: 266-[.] Key released: 266-[.]
Key pressed: 256-[0] Key released: 256-[0]
Key pressed: 257-[1] Key released: 257-[1]
Key pressed: 258-[2] Key released: 258-[2]
Key pressed: 259-[3] Key released: 259-[3]
Key pressed: 260-[4] Key released: 260-[4]
Key pressed: 261-[5] Key released: 261-[5]
Key pressed: 262-[6] Key released: 262-[6]
Key pressed: 263-[7] Key released: 263-[7]
Key pressed: 264-[8] Key released: 264-[8]
Key pressed: 265-[9] Key released: 265-[9]
Key pressed: 267-[/] (/) Key released: 267-[/] (/)
Key pressed: 268-[] () Key released: 268-[] ()
Key pressed: 269-[-] (-) Key released: 269-[-] (-)
Key pressed: 270-[+] (+) Key released: 270-[+] (+)
Key pressed: 271-enter (^M) Key released: 271-enter (^M)
Num lock is an anachronism anyway, from the time of the original IBM PC
keyboard which lacked separate arrow keys. It was made obsolete when the
PC AT arrived, about 1985
is not obsolete, I think, because everywhere in apps if you
have NUMLOCK OFF you can use keypad keys as arrows, but this
is not a problem (I filtered it in my program).
The matter is making different OSs return the same output.
Thanks,
Enzo.–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.supereva.it
This is output of checkkeys under win32:
With NUMLOCK ON
Unicode | VKey pressed: 266-[.] Key released: 266-[.]
Key pressed: 256-[0] Key released: 256-[0]
Key pressed: 257-[1] Key released: 257-[1]
Key pressed: 258-[2] Key released: 258-[2]
This is definitely a bug. Better have the keypad always generate the
unicode characters than not at all.
is not obsolete, I think, because everywhere in apps if you
have NUMLOCK OFF you can use keypad keys as arrows, but this
is not a problem (I filtered it in my program).
I know very well how it is supposed to work, and as I explained it has
been obsolete for the last 15 years. (Restricted keyboards such as
those found on laptops tend to have their own schemes for multiplexing
logical keys onto a smaller physical layout.)
Personally I xmodmap the entire keypad to its KP_* symbols regardless of
the numlock state, and it saves me a lot of grief. In general, adding
state to a keyboard is poor human factors design.
Ok, here it is:
I’ll take a look at it when I get a chance. I’m using the Windows API
calls to translate the key, so it’s likely that I’m not properly passing
the numlock state or something.
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Num lock is an anachronism anyway, from the time of the original IBM PC
keyboard which lacked separate arrow keys. It was made obsolete when the
PC AT arrived, about 1985
I’d personally agree, but I actually had a customer complain that those
keypad arrows didn’t work, so I added the translation myself. (we’re beta
testing the SDL version of our Hearts game)
Also, I wasn’t getting any unicode at all for the keypad, and had to add
that as well.
(Alas the additions were in two functions in my event handler, not SDL, so
there’s no patch)
Please note, too, that as Mattias says, having state in the keyboard is bad
design, but because of it, when a keypad key is pressed, the OS needs to be
queried at the time the press is received regarding the current state of
the numlock key to get accurate results. I found (as I mentioned earlier)
that the SDL internal numlock state gets out of sync with the OS (&
keyboard light) if the user does any task switching.
–Manny
So, what results are you getting? AFAIK arrow keys don’t translate to
unicode at all. If num-lock is on, the keypad keys should translate to the
digit characters (0-9). Remember, event.key.keysym.sym contains the actual
key, while event.key.keysym.unicode contains the translation of the key (and
only if unicode translation is enabled).
Under linux if I have numlock key enabled event.key.keysym.unicode
returns the code of the number I press, under Win32 it doesn’t.
I really think the correct one is that under linux,
and the SDL must do the same on each OS.
Thanks,
Enzo.–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.supereva.it
Under WIN32 numeric keypad keys don’t return
the same codes as under linux.
If you run the “checkkey” test program you can check that
return codes are not the same (in event.key.keysym.unicode).
I patched it in my program, but I really think
that it’s a little SDL’s bug (SDL must have the same
behaviour under different OSs). Isn’t it?
Thanks,
Enzo.
Tue, 31 Oct 2000 Manny wrote:
Num lock is an anachronism anyway, from the time of the original IBM PC
keyboard which lacked separate arrow keys. It was made obsolete when the
PC AT arrived, about 1985I’d personally agree, but I actually had a customer complain that those
keypad arrows didn’t work, so I added the translation myself. (we’re beta
testing the SDL version of our Hearts game)
There is a guy at work who always use the numpad for cursor control - rather
annoying to find the keypad doing “strange” things after he has been using a
machine…! hehe
(One should have a time-out that reverts to a default state after a while of
inactivity…)
Also, I wasn’t getting any unicode at all for the keypad, and had to add
that as well.(Alas the additions were in two functions in my event handler, not SDL, so
there’s no patch)Please note, too, that as Mattias says, having state in the keyboard is bad
design, but because of it, when a keypad key is pressed, the OS needs to be
queried at the time the press is received regarding the current state of
the numlock key to get accurate results.
And the reason why I’m posting; how do you get the keyboard state (caps,
numlock etc) from X in a reliable way?
(I’m using Cooledit for most of my code and text editing, but there is one bug
that I have to “fix” every time I build a new version; numlock never works -
with or w/o the “numlock interpretation” switch on. My quick hack is to simply
ignore the numlock state and translate the keycodes according to the standard
keypad layout - unicode doesn’t seem to work…)
I found (as I mentioned earlier)
that the SDL internal numlock state gets out of sync with the OS (&
keyboard light) if the user does any task switching.
Cooledit has the same problem; it tries to keep track of the numlock keypresses.
(And it seems that somehow, the chance of getting out-of-sync is about 90%…
grrr)
David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se
…- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
------------> http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y ------------------------. | Singer | | Rock Solid Low Latency Signal Processing | | Songwriter |—> http://www.angelfire.com/or/audiality -’ `-> david at linuxdj.com -’
And the reason why I’m posting; how do you get the keyboard state (caps,
numlock etc) from X in a reliable way?
Each X11 keyboard press/release event (as well as a lot of other events)
contains a state word representing the active modifiers and held mouse
buttons.
Another (better) way is to xmodmap away num lock, and you won’t have
to worry about it. Or ask the keypad not to care — my .xinitrc
contains:
xmodmap - <<END
keysym KP_0 = KP_0
keysym KP_1 = KP_1
keysym KP_2 = KP_2
keysym KP_3 = KP_3
keysym KP_4 = KP_4
keysym KP_5 = KP_5
keysym KP_6 = KP_6
keysym KP_7 = KP_7
keysym KP_8 = KP_8
keysym KP_9 = KP_9
END
Thu, 02 Nov 2000 Mattias Engdeg?rd wrote:
And the reason why I’m posting; how do you get the keyboard state (caps,
numlock etc) from X in a reliable way?Each X11 keyboard press/release event (as well as a lot of other events)
contains a state word representing the active modifiers and held mouse
buttons.
Yeah, I remember now that I’m doing this in some GGI applications, and it does
seem to work without problems.
Another (better) way is to xmodmap away num lock, and you won’t have
to worry about it. Or ask the keypad not to care — my .xinitrc
contains:xmodmap - <<END
keysym KP_0 = KP_0
keysym KP_1 = KP_1
keysym KP_2 = KP_2
keysym KP_3 = KP_3
keysym KP_4 = KP_4
keysym KP_5 = KP_5
keysym KP_6 = KP_6
keysym KP_7 = KP_7
keysym KP_8 = KP_8
keysym KP_9 = KP_9
END
Nice configuration trick for serious users, but it doesn’t help users without a
clue, or users who simply don’t want to do this for whatever reason.
Anyway, I think the fundamental point with this thread is whether or not SDL
should provide the same API on all platforms. Another, related question would
be “What should the applications be able to do?”
IMHO, it’s rather obvious that the API should behave the same way on all
platforms, as far as possible, and that applications should have total control,
while still being able to treat the keyboard according to the configuration.
(That is, reading only unicode should give you exactly what the keymap/layout
says. I’ve seen quite a few applications that try all kinds of other tricks
with the alpha keys, and most of them screw up if you have a Dvorak layout…)
David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se
…- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
------------> http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y ------------------------. | Singer | | Rock Solid Low Latency Signal Processing | | Songwriter |—> http://www.angelfire.com/or/audiality -’ `-> david at linuxdj.com -’
Under WIN32 numeric keypad keys don’t return
the same codes as under linux.
If you run the “checkkey” test program you can check that
return codes are not the same (in event.key.keysym.unicode).I patched it in my program, but I really think
that it’s a little SDL’s bug (SDL must have the same
behaviour under different OSs). Isn’t it?
It is indeed a bug to have different behavior under different operating
systems, although I just ran the checkkeys program under DirectX with
Windows 98, and it reported the same values as under Linux.
Can you tell me a little bit more about your system? Is it NT? '98?
Do you have an english keyboard?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Also, I wasn’t getting any unicode at all for the keypad, and had to add
that as well.
(Alas the additions were in two functions in my event handler, not SDL, so
there’s no patch)
Please note, too, that as Mattias says, having state in the keyboard is bad
design, but because of it, when a keypad key is pressed, the OS needs to be
queried at the time the press is received regarding the current state of
the numlock key to get accurate results. I found (as I mentioned earlier)
that the SDL internal numlock state gets out of sync with the OS (&
keyboard light) if the user does any task switching.
I would really appreciate a patch to fix this in SDL, if you get a chance.
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Anyway, I think the fundamental point with this thread is whether or not SDL
should provide the same API on all platforms.
Of course. I don’t know why people keep asking this. Yes, it’s a bug.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’ll try to look into it. I’m thinking maybe it’s enough to sync up on
App. Activate? I hope so anyway, otherwise SDL_GetModState would have to
be altered to be able to make an active query… Hafta try it and see.
This is kinda like the SDL for applications thread. I think maybe our game
must be very application like. But the chief trouble is multiplayer chat,
which is probably an increasingly common element.
–Manny>I would really appreciate a patch to fix this in SDL, if you get a chance.
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software