This guide introduces the input related functions of GLFW. For details on a specific function in this category, see the Input reference. There are also guides for the other areas of GLFW.
GLFW provides many kinds of input. While some can only be polled, like time, or only received via callbacks, like scrolling, there are those that provide both callbacks and polling. Where a callback is provided, that is the recommended way to receive that kind of input. The more you can use callbacks the less time your users' machines will need to spend polling.
All input callbacks receive a window handle. By using the window user pointer, you can access non-global structures or objects from your callbacks.
To get a better feel for how the various events callbacks behave, run the events test program. It register every callback supported by GLFW and prints out all arguments provided for every event, along with time and sequence information.
GLFW needs to communicate regularly with the window system both in order to receive events and to show that the application hasn't locked up. Event processing must be done regularly while you have any windows and is normally done each frame after buffer swapping. Even when you have no windows, event polling needs to be done in order to receive monitor connection events.
There are two functions for processing pending events. glfwPollEvents, processes only those events that have already been received and then returns immediately.
This is the best choice when rendering continually, like most games do.
If you only need to update the contents of the window when you receive new input, glfwWaitEvents is a better choice.
It puts the thread to sleep until at least one event has been received and then processes all received events. This saves a great deal of CPU cycles and is useful for, for example, editing tools. There must be at least one GLFW window for this function to sleep.
If you want to wait for events but have UI elements that need periodic updates, call glfwWaitEventsTimeout.
It puts the thread to sleep until at least one event has been received, or until the specified number of seconds have elapsed. It then processes any received events.
If the main thread is sleeping in glfwWaitEvents, you can wake it from another thread by posting an empty event to the event queue with glfwPostEmptyEvent.
Do not assume that callbacks will only be called through either of the above functions. While it is necessary to process events in the event queue, some window systems will send some events directly to the application, which in turn causes callbacks to be called outside of regular event processing.
GLFW divides keyboard input into two categories; key events and character events. Key events relate to actual physical keyboard keys, whereas character events relate to the Unicode code points generated by pressing some of them.
Keys and characters do not map 1:1. A single key press may produce several characters, and a single character may require several keys to produce. This may not be the case on your machine, but your users are likely not all using the same keyboard layout, input method or even operating system as you.
If you wish to be notified when a physical key is pressed or released or when it repeats, set a key callback.
The callback function receives the keyboard key, platform-specific scancode, key action and modifier bits.
The action is one of GLFW_PRESS, GLFW_REPEAT or GLFW_RELEASE. The key will be GLFW_KEY_UNKNOWN if GLFW lacks a key token for it, for example E-mail and Play keys.
The scancode is unique for every key, regardless of whether it has a key token. Scancodes are platform-specific but consistent over time, so keys will have different scancodes depending on the platform but they are safe to save to disk.
Key states for named keys are also saved in per-window state arrays that can be polled with glfwGetKey.
The returned state is one of GLFW_PRESS or GLFW_RELEASE.
This function only returns cached key event state. It does not poll the system for the current state of the key.
Whenever you poll state, you risk missing the state change you are looking for. If a pressed key is released again before you poll its state, you will have missed the key press. The recommended solution for this is to use a key callback, but there is also the GLFW_STICKY_KEYS input mode.
When sticky keys mode is enabled, the pollable state of a key will remain GLFW_PRESS until the state of that key is polled with glfwGetKey. Once it has been polled, if a key release event had been processed in the meantime, the state will reset to GLFW_RELEASE, otherwise it will remain GLFW_PRESS.
The GLFW_KEY_LAST constant holds the highest value of any named key.
GLFW supports text input in the form of a stream of Unicode code points, as produced by the operating system text input system. Unlike key input, text input obeys keyboard layouts and modifier keys and supports composing characters using dead keys. Once received, you can encode the code points into UTF-8 or any other encoding you prefer.
Because an unsigned int is 32 bits long on all platforms supported by GLFW, you can treat the code point argument as native endian UTF-32.
There are two callbacks for receiving Unicode code points. If you wish to offer regular text input, set a character callback.
The callback function receives Unicode code points for key events that would have led to regular text input and generally behaves as a standard text field on that platform.
If you wish to receive even those Unicode code points generated with modifier key combinations that a plain text field would ignore, or just want to know exactly what modifier keys were used, set a character with modifiers callback.
The callback function receives Unicode code points and modifier bits.
If you wish to refer to keys by name, you can query the keyboard layout dependent name of printable keys with glfwGetKeyName.
This function can handle both keys and scancodes. If the specified key is GLFW_KEY_UNKNOWN then the scancode is used, otherwise it is ignored. This matches the behavior of the key callback, meaning the callback arguments can always be passed unmodified to this function.
Mouse input comes in many forms, including cursor motion, button presses and scrolling offsets. The cursor appearance can also be changed, either to a custom image or a standard cursor shape from the system theme.
If you wish to be notified when the cursor moves over the window, set a cursor position callback.
The callback functions receives the cursor position, measured in screen coordinates but relative to the top-left corner of the window client area. On platforms that provide it, the full sub-pixel cursor position is passed on.
The cursor position is also saved per-window and can be polled with glfwGetCursorPos.
The GLFW_CURSOR input mode provides several cursor modes for special forms of mouse motion input. By default, the cursor mode is GLFW_CURSOR_NORMAL, meaning the regular arrow cursor (or another cursor set with glfwSetCursor) is used and cursor motion is not limited.
If you wish to implement mouse motion based camera controls or other input schemes that require unlimited mouse movement, set the cursor mode to GLFW_CURSOR_DISABLED.
This will hide the cursor and lock it to the specified window. GLFW will then take care of all the details of cursor re-centering and offset calculation and providing the application with a virtual cursor position. This virtual position is provided normally via both the cursor position callback and through polling.
GLFW_CURSOR_DISABLED.If you just wish the cursor to become hidden when it is over a window, set the cursor mode to GLFW_CURSOR_HIDDEN.
This mode puts no limit on the motion of the cursor.
To exit out of either of these special modes, restore the GLFW_CURSOR_NORMAL cursor mode.
GLFW supports creating both custom and system theme cursor images, encapsulated as GLFWcursor objects. They are created with glfwCreateCursor or glfwCreateStandardCursor and destroyed with glfwDestroyCursor, or glfwTerminate, if any remain.
A custom cursor is created with glfwCreateCursor, which returns a handle to the created cursor object. For example, this creates a 16x16 white square cursor with the hot-spot in the upper-left corner:
If cursor creation fails, NULL will be returned, so it is necessary to check the return value.
The image data is 32-bit, little-endian, non-premultiplied RGBA, i.e. eight bits per channel. The pixels are arranged canonically as sequential rows, starting from the top-left corner.
A cursor with a standard shape from the current system cursor theme can be can be created with glfwCreateStandardCursor.
These cursor objects behave in the exact same way as those created with glfwCreateCursor except that the system cursor theme provides the actual image.
When a cursor is no longer needed, destroy it with glfwDestroyCursor.
Cursor destruction always succeeds. All cursors remaining when glfwTerminate is called are destroyed as well.
A cursor can be set as current for a window with glfwSetCursor.
Once set, the cursor image will be used as long as the system cursor is over the client area of the window and the cursor mode is set to GLFW_CURSOR_NORMAL.
A single cursor may be set for any number of windows.
To remove a cursor from a window, set the cursor of that window to NULL.
When a cursor is destroyed, it is removed from any window where it is set. This does not affect the cursor modes of those windows.
If you wish to be notified when the cursor enters or leaves the client area of a window, set a cursor enter/leave callback.
The callback function receives the new classification of the cursor.
If you wish to be notified when a mouse button is pressed or released, set a mouse button callback.
The callback function receives the mouse button, button action and modifier bits.
The action is one of GLFW_PRESS or GLFW_RELEASE.
Mouse button states for named buttons are also saved in per-window state arrays that can be polled with glfwGetMouseButton.
The returned state is one of GLFW_PRESS or GLFW_RELEASE.
This function only returns cached mouse button event state. It does not poll the system for the current state of the mouse button.
Whenever you poll state, you risk missing the state change you are looking for. If a pressed mouse button is released again before you poll its state, you will have missed the button press. The recommended solution for this is to use a mouse button callback, but there is also the GLFW_STICKY_MOUSE_BUTTONS input mode.
When sticky mouse buttons mode is enabled, the pollable state of a mouse button will remain GLFW_PRESS until the state of that button is polled with glfwGetMouseButton. Once it has been polled, if a mouse button release event had been processed in the meantime, the state will reset to GLFW_RELEASE, otherwise it will remain GLFW_PRESS.
The GLFW_MOUSE_BUTTON_LAST constant holds the highest value of any named button.
If you wish to be notified when the user scrolls, whether with a mouse wheel or touchpad gesture, set a scroll callback.
The callback function receives two-dimensional scroll offsets.
A simple mouse wheel, being vertical, provides offsets along the Y-axis.
The joystick functions expose connected joysticks and controllers, with both referred to as joysticks. It supports up to sixteen joysticks, ranging from GLFW_JOYSTICK_1, GLFW_JOYSTICK_2 up to GLFW_JOYSTICK_LAST. You can test whether a joystick is present with glfwJoystickPresent.
When GLFW is initialized, detected joysticks are added to to the beginning of the array, starting with GLFW_JOYSTICK_1. Once a joystick is detected, it keeps its assigned index until it is disconnected, so as joysticks are connected and disconnected, they will become spread out.
Joystick state is updated as needed when a joystick function is called and does not require a window to be created or glfwPollEvents or glfwWaitEvents to be called.
The positions of all axes of a joystick are returned by glfwGetJoystickAxes. See the reference documentation for the lifetime of the returned array.
Each element in the returned array is a value between -1.0 and 1.0.
The states of all buttons of a joystick are returned by glfwGetJoystickButtons. See the reference documentation for the lifetime of the returned array.
Each element in the returned array is either GLFW_PRESS or GLFW_RELEASE.
The human-readable, UTF-8 encoded name of a joystick is returned by glfwGetJoystickName. See the reference documentation for the lifetime of the returned string.
Joystick names are not guaranteed to be unique. Two joysticks of the same model and make may have the same name. Only the joystick token is guaranteed to be unique, and only until that joystick is disconnected.
If you wish to be notified when a joystick is connected or disconnected, set a joystick callback.
The callback function receives the ID of the joystick that has been connected and disconnected and the event that occurred.
GLFW provides high-resolution time input, in seconds, with glfwGetTime.
It returns the number of seconds since the timer was started when the library was initialized with glfwInit. The platform-specific time sources used usually have micro- or nanosecond resolution.
You can modify the reference time with glfwSetTime.
This sets the timer to the specified time, in seconds.
You can also access the raw timer value, measured in 1 / frequency seconds, with glfwGetTimerValue.
The frequency of the raw timer varies depending on what time sources are available on the machine. You can query its frequency, in Hz, with glfwGetTimerFrequency.
If the system clipboard contains a UTF-8 encoded string or if it can be converted to one, you can retrieve it with glfwGetClipboardString. See the reference documentation for the lifetime of the returned string.
If the clipboard is empty or if its contents could not be converted, NULL is returned.
The contents of the system clipboard can be set to a UTF-8 encoded string with glfwSetClipboardString.
The clipboard functions take a window handle argument because some window systems require a window to communicate with the system clipboard. Any valid window may be used.
If you wish to receive the paths of files and/or directories dropped on a window, set a file drop callback.
The callback function receives an array of paths encoded as UTF-8.
The path array and its strings are only valid until the file drop callback returns, as they may have been generated specifically for that event. You need to make a deep copy of the array if you want to keep the paths.
Last update on Mon Nov 5 2018 for GLFW 3.2.1