Detect Num Lock key press/up and other special keys in GLUT/FREEGLUT

I can't seem to find any documentation on how to detect other special keys like Num Lock, Scroll Lock, Pause, PrintScreen when they are hit/key up in Glut/FreeGlut

So far I know this glutSpecialFunc which only includes F1-10, arrow keys and the 6 keys above it (Insert to PageDown).

Btw, I'm using C specifically and not C++.
I haven't used glut, but does glutKeyboardFunc() return any value when you hit the buttons in question? If so, you may have to make your own constants for the special keys you wish to implement.
Last edited on
it only triggers on the glutKeyboardUpFunc to 144, not on glutKeyboardFunc

How do I detect if it is being held down?
Hey George P,

Other keys work with keydown and glutKeyboardFunc except for the NumLock key and other keys like Scroll lock, Print Screen etc.

I also already set to the key repeat to off.
Last edited on
what you want to do may not be supported at all, or partially. I don't know.
but if you can detect a key is hit, you can detect that a key is held:
you can use the <chrono> stuff for the times. Its easy to use, but I never remember all the types and such, so in pseudocode:

   static something last_time_here;
   if(the key down == the key you want)
       auto timediff = now - last_time_here;
       if(timediff < 0.1)
          held = true;
         //whatever you do when its held down!
            //anything special first time key is hit??
          last_time_here = now;

i don't know how this lib works so you may or may not need repeat on to make that workable.
you may also just need to look for another library to handle keyboard input. It looks like you want getch() like capability, where it reads the keyboard live without needing to press enter like cin would do? Windows has a bunch of ways to do that. I am sure unix has some useful way to do it too, but I don't know what it is.
Last edited on
It looks like certain special keyboard events are being given to other programs first, and since they take priority, and they tell the OS that the event has been correctly handled, it is unlikely that your program will ever be told about it. <- the suggested solution here is to remove the shortcut from your OS's shortcut-keys map. You wouldn't find all of the keys you're looking for, and I don't have to tell you why this is a bad idea if you plan to distribute your code.

It now makes sense why you only get a print_screen keyup event; the keydown event was eaten by the print screen program, but that same program doesn't care about the key being released. <- there is a Windows workaround mentioned here. You may find similar workarounds in X11 or Wayland for Linux systems. (Basically you create a Hook or System-Callback that gets called when the OS detects certain presses. I'm not sure if you're now stealing the event first, or if the other program will also be called, either way getting unexpected behavior may be just as frustrating for the end-user. Brightness up should just do what it says, I don't want it to make a funny boop and play an animation. It's sunny out and now I can't see the screen. ☹️)

There probably is a workaround for most individual OS's, unfortunately I am not aware of any cross-platform solutions to this problem... and it seems that the OS is trying to say that these keys are meant to be reserved, don't touch.

The best I can recommend is to not use those keys unless you are intending to replace them with similar functionality. <- of course this does not apply for personal use or hobby projects, it's your computer after all.
Last edited on
Thanks guys for the additional info.

The workaround you mentioned newbieg might also be useful and somehow similar to my issue. Thanks!
Registered users can post here. Sign in or register to post.