Caps lock / num lock behaviour request

I posted a while ago about how caps lock and num lock having different (and
undocumentedly so), and was told this had to be so since it is the best that
can be done on X in general. However, this is the one thing that means I
cannot support the already developed SDL target of my program, even where
having those keys generate exactly the same behaviour as all the other keys
is an option.

What I would really like is a function, something like
’SDL_SetLocksNonSpecial()’ which returns 0 on success, -1 on failure and of
course always fails on targets which do not support the mode.

Would such a function be necessarily unwanted in the main distribution? What
I really mean is - should I attempt to add this myself and contribute the
difference? And in doing so, are there any code nuances I should watch out
for?

-Thomas

I posted a while ago about how caps lock and num lock having different (and
undocumentedly so), and was told this had to be so since it is the best that
can be done on X in general.

If it was my reply you refer to then you misunderstood. It is true
that it cannot be done in a good way in general but that should not
prevent us from making {caps, num} lock behave sensible where it is
possible. And no special call should be necessary; it should be an
unchangeable default

If it was my reply you refer to then you misunderstood. It is true
that it cannot be done in a good way in general but that should not
prevent us from making {caps, num} lock behave sensible where it is
possible. And no special call should be necessary; it should be an
unchangeable default

No, my thinking comes from that, as was revealed the last time I brought
this topic up, making those keys act just like all the rest requires, on all
platforms where this is possible, just a single line of source removed.
Therefore I assumed it had been decided upon high that the feature was not a
good idea if it couldn’t be implemented across all targets invisbly. I
wasn’t making a snide swipe at you or anything.

My approach would have been on targets where key up/key down is not
detectible to have the key being pressed the first or second time generate
both signals, the up immediately after the down in the event queue . . .

-Thomas