glfw / glfw

A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input

GLFW

Introduction

GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platform-independent API for creating windows, contexts and surfaces, reading input, handling events, etc.

GLFW natively supports Windows, macOS and Linux and other Unix-like systems. On Linux both Wayland and X11 are supported.

GLFW is licensed under the zlib/libpng license.

You can download the latest stable release as source or Windows binaries. Each release starting with 3.0 also has a corresponding annotated tag with source and binary archives.

The documentation is available online and is included in all source and binary archives. See the release notes for new features, caveats and deprecations in the latest release. For more details see the version history.

The master branch is the stable integration branch and should always compile and run on all supported platforms, although details of newly added features may change until they have been included in a release. New features and many bug fixes live in other branches until they are stable enough to merge.

If you are new to GLFW, you may find the tutorial for GLFW 3 useful. If you have used GLFW 2 in the past, there is a transition guide for moving to the GLFW 3 API.

GLFW exists because of the contributions of many people around the world, whether by reporting bugs, providing community support, adding features, reviewing or testing code, debugging, proofreading docs, suggesting features or fixing bugs.

Compiling GLFW

GLFW is written primarily in C99, with parts of macOS support being written in Objective-C. GLFW itself requires only the headers and libraries for your OS and window system. It does not need any additional headers for context creation APIs (WGL, GLX, EGL, NSGL, OSMesa) or rendering APIs (OpenGL, OpenGL ES, Vulkan) to enable support for them.

GLFW supports compilation on Windows with Visual C++ 2013 and later, MinGW and MinGW-w64, on macOS with Clang and on Linux and other Unix-like systems with GCC and Clang. It will likely compile in other environments as well, but this is not regularly tested.

There are pre-compiled binaries available for all supported compilers on Windows and macOS.

See the compilation guide for more information about how to compile GLFW yourself.

Using GLFW

See the documentation for tutorials, guides and the API reference.

Contributing to GLFW

See the contribution guide for more information.

System requirements

GLFW supports Windows XP and later and macOS 10.11 and later. Linux and other Unix-like systems running the X Window System are supported even without a desktop environment or modern extensions, although some features require a running window or clipboard manager. The OSMesa backend requires Mesa 6.3.

See the compatibility guide in the documentation for more information.

Dependencies

GLFW itself needs only CMake 3.4 or later and the headers and libraries for your OS and window system.

The examples and test programs depend on a number of tiny libraries. These are located in the deps/ directory.

• getopt_port for examples with command-line options
• TinyCThread for threaded examples
• glad2 for loading OpenGL and Vulkan functions
• linmath.h for linear algebra in examples
• Nuklear for test and example UI
• stb_image_write for writing images to disk

The documentation is generated with Doxygen if CMake can find that tool.

Reporting bugs

Bugs are reported to our issue tracker. Please check the contribution guide for information on what to include when reporting a bug.

Changelog since 3.4

• Added GLFW_UNLIMITED_MOUSE_BUTTONS input mode that allows mouse buttons beyond the limit of the mouse button tokens to be reported (#2423)
• [Cocoa] Added QuartzCore framework as link-time dependency
• [Cocoa] Removed support for OS X 10.10 Yosemite and earlier (#2506)
• [Wayland] Bugfix: The fractional scaling related objects were not destroyed
• [Wayland] Bugfix: glfwInit would segfault on compositor with no seat (#2517)
• [Wayland] Bugfix: A drag entering a non-GLFW surface could cause a segfault
• [Null] Added Vulkan 'window' surface creation via VK_EXT_headless_surface
• [Null] Added EGL context creation on Mesa via EGL_MESA_platform_surfaceless
• [EGL] Allowed native access on Wayland with GLFW_CONTEXT_CREATION_API set to GLFW_NATIVE_CONTEXT_API (#2518)

Contact

On glfw.org you can find the latest version of GLFW, as well as news, documentation and other information about the project.

If you have questions related to the use of GLFW, we have a forum.

If you have a bug to report, a patch to submit or a feature you'd like to request, please file it in the issue tracker on GitHub.

Finally, if you're interested in helping out with the development of GLFW or porting it to your favorite platform, join us on the forum or GitHub.

glfw's Issues

Documentation for GLFW_*_LAST tokens

This issue has been moved from SourceForge.

GLFW_JOYSTICK_LAST, GLFW_MOUSE_BUTTON_LAST, and GLFW_KEY_LAST are not mentioned in the docs. These are very useful for things like static arrays of key states.

Segfault in glXQueryVersion

I got some trouble in glfwInit():

Signal
Event Properties
Reason
SIGSEGV
Address
000000000000000000
Details
Invalid memory reference.

_glfwInitContextAPI - libglfw.so.3
_glfwPlatformInit - libglfw.so.3
glfwInit - libglfw.so.3
InitGLClass::InitGLClass - engInit.cpp, line 28
__static_initialization_and_destruction_0 - main.cpp, line 5
_GLOBAL__sub_I_initgl - main.cpp, line 33
__libc_csu_init -
__libc_start_main - libc.so.6
_start -

in _glfwInitContextAPI:
Call Stack
Function Name
_glfwInitContextAPI
File Path
N/A
Line Number
N/A
Module Name
/usr/local/lib/libglfw.so.3
Instruction Counter Address
0x00007ffff7603429
Function address
N/A

Bug is here:

if (!glXQueryVersion(_glfw.x11.display,
&_glfw.glx.versionMajor,
&_glfw.glx.versionMinor))
{
_glfwInputError(GLFW_API_UNAVAILABLE,
"GLX: Failed to query GLX version");
return GL_FALSE;
} (in if)

Seems that he can't find _glfw.x11.display

http://devgurus.amd.com/message/1296934 - CodeXL topic

Retrieval of self-owned clipboard selection may not work

More detailed CMake build instructions

This issue has been moved from SourceForge.

Previous build system was self explanatory, when you typed 'make' it would tell you what you needed to type to install for your platform with specifics like dynamic or static installed libs.

The new cmake build system, while more advanced and smarter, is not as easy to use and the readme file included with GLFW 3.0 does not explain what I need to type in order to generate the build files or install the library itself.

Extremely pedantic instructions are required for users to easily install the library.

Default window created with 16-bit color with OS X / AMD Radeon HD 6750M

Using GLFW3, the default pixel format for the window is 16-bit color on OS X 10.8.4 with an AMD Radeon HD 6750M. If I force use of integrated graphics (Intel HD Graphics 3000) I get 32-bit color. I used the code found here for testing:

http://www.glfw.org/docs/3.0/quick.html

This issue does not occur with GLFW 2.7. I was able to fix the problem by adding
glfwWindowHint(GLFW_ALPHA_BITS, 8) before window creation. Without this, kCGLPFAAlphaSize shows as 1 instead of 8 which is stated as the default value.

Iconification of full screen windows not implemented

Split code into enterFullscreenMode and leaveFullscreenMode.

Cannot build on Ubuntu 12.04 LTS - The Xf86VidMode library and headers were not found

Cannot build even though the xf86vidmode library and headers are installed.

Debug context flag always set

NVIDIA Geforce GT 430 (Driver 320.18 - Win7-64)

The hint GLFW_OPENGL_DEBUG_CONTEXT does not trigger a normal context, why?
Is it a bug?

I'm using the binary version of glfw3.0 donwloaded from the site.

int main(void) {

GLFWwindow* window;
if (!glfwInit())
    return -1;



glfwWindowHint( GLFW_CONTEXT_VERSION_MAJOR, 3 );
glfwWindowHint( GLFW_CONTEXT_VERSION_MINOR, 3 );
glfwWindowHint( GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE );


glfwWindowHint( GLFW_OPENGL_DEBUG_CONTEXT, false);


window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
if (!window) {
    glfwTerminate();
    return -1;
}
glfwMakeContextCurrent(window);


// the result is always true
bool isDebugContext  = glfwGetWindowAttrib(window, GLFW_OPENGL_DEBUG_CONTEXT);

printf("debug context: %s\n", (isDebugContext)? "true" : "false");


while (!glfwWindowShouldClose(window)) {
    glfwSwapBuffers(window);
    glfwPollEvents();
}

glfwTerminate();
return 0;

}

Remove INSTALL target from CMakeLists.txt if needed

When you use GLFW in a project using CMake, a natural way of doing this would be to use the add_subdirectory() command and add GLFW that way. However, this will create an INSTALL project that will contain stuff from GLFW. However, if I want to use something like CPack to generate packages for an application including GLFW this way, it will also contain stuff from GLFW.

It would be nice to have a CMake configure option (something like GLFW_NO_INSTALL) to give CMake so that GLFW doesn't add anything to INSTALL when this is set...

I could probably come up with a patch.

Window mode switching

Moving a window triggers window size callback

I observed the following under Ubuntu Linux 12.10. On windows it works as expected.

As the title says, moving a window around (dragging it with the mouse, not resizing it) triggers the window-size callback (set with glfwSetWindowSizeCallback). The reported new window dimensions are the current window dimensions.

Character callback not triggered when Ctrl, Alt or Super is held down

No character callbacks are produced when typing with alt held down. This worked in 2.x but doesn't in 3.0. Probably the easiest way to implement it is to handle WM_SYSCHAR in addition to WM_CHAR.

Framebuffer resize proposition

Hi !
When you minimize window, resize callback sets wind and height to 0x0 . Same thing using framebuffer resize callback. I think glfw shouldn't call both ( or just new framebuffer ) callbacks when window is minimizing.

I have some FBO's attached to screen that has to be realloced when window is minimized and restored - thats not nesesery needed. Especialy, that new callbacks allow to get iconify events.

Its just a sugestion ;)

X11 window creation only on defaultscreen.

In some X11 setups, a second monitor is represented as a second X11 screen. In these cases, GLFW can only create window on the defaultscreen. See x11_init.c:
_glfw.x11.screen = DefaultScreen(_glfw.x11.display);
_glfw.x11.root = RootWindow(_glfw.x11.display, _glfw.x11.screen);
_glfw.x11.context = XUniqueContext();
It would be nice if GLFW could collect output candidates from all available X11 screens.

Letterboxed rendering for full screen windows on Retina MBP

Mac OS: 10.8.4
Mac: Macbook Pro w/ Retina 15" (MC950LL) (2880x1800) ran at 1440*900
RAM: 16GB
Video Card: Switchable Intel HD 4000 / nVidia 650 GT

Commit: "7423cfa5bf3324c0526a92d9d7a5aa36bf0c7604"

Whenever I choose to put GLFW into Full Screen on my Retina using glfwGetPrimaryMonitor() it is not matching my appropriate resolution, at least it appears that way.

What happens is everything inside of the OpenGL View is fuzzy, it almost looks like when it went full screen that it didn't go to my computers resolution. I can assure you that this is not due to the fact that I'm seeing it pixely because I'm on a retina... Its actually fuzzy, like the aspect ratio is off. Also on the top and bottom of my screen there is a black bar. Both black bars are about 100 Pixels in height and the width of the black bar is the width of my monitor. I set the glColor to blue so thats how I see the black bar.
Its also not an issue with GLFWvidmode because its reporting the proper resolution for my display.

CODE IM USING TO GO INTO FULL SCREEN:

GLFWvidmode mainMonVidMode = glfwGetVideoMode(glfwGetPrimaryMonitor());
GLFWwindow* window = glfwCreateWindow(mainMonVidMode.width, mainMonVidMode.height, "Welcome to My Game", glfwGetPrimaryMonitor(), NULL);
if (!window)
{
glfwTerminate();
exit(EXIT_FAILURE);
}
glfwMakeContextCurrent(window);

I also cannot figure out why this is happening in the source code of GLFW 3.0 either. In cocoa_window.m the following code is the proper code to enter full screen. However once it goes into full screen like I said everything is blurry like it didn't go into fullscreen at the proper resolution.

if (wndconfig->monitor)
{
if (!_glfwSetVideoMode(window->monitor, &window->videoMode))
return GL_FALSE;
_glfwPlatformShowWindow(window);
[[window->ns.object contentView] enterFullScreenMode:wndconfig->monitor->ns.screen
withOptions:nil];
}

Soft window hints interpreted as hard minimum values

Manual pixel format matching may need to be brought back to fix this.

Clipboard data not pushed to clipboard manager on window destruction

The client side of the clipboard manager protocol needs to be implemented.

Failed to open window when using Windows remote desktop

Hi, I get Win32: Failed to retrieve PFD for selected pixel format when I use Windows remotely.
It seems that pixelFormat (wgl_context.c line 331) value is 0 before the call to DescribePixelFormat, which cause an ERROR_INVALID_PARAMETER
I tried to set it to 1 (just for test) and it worked, creating a window with an OpenGL 1.1 context. (The default Windows generic gdi)

Using Windows 8 as host and Windows 7 as client

GLFW cannot use C++ lambdas as it is written in C

I would like to see the glfwSet...Callback functions to accept lambda-expressions with captures (from c++11).
Example:

glfwSetWindowSizeCallback(window,
    [&](int w, int h){
        width = w; height = h;
    });

glfwMakeCurrent not working after initial call

This issue has been moved from SourceForge.

glfwMakeCurrent seems to only work once. I was testing a multithreaded app and if I called glfwMakeCurrent from the initializing thread (which i did to init GLEW) the rendering thread never became current. I looked at the source and it appeared to be checking to see if the window was the same, so I tried making current with a NULL window first but it still didn't work. I've modified my app to load GLEW in the rendering thread so all is well, but I thought the whole point of 'makecurrent' was to be able to switch around which thread can make OpenGL calls.

Add --devel option to Homebrew recipe?

It seems like a good idea to provide a way to install the latest development release of glfw via Homebrew. They have an option for this already (--devel) and it just takes a few lines of code to get it in there.

This will allow installing the 3.0 branch with Homebrew on OS X.

$ brew install glfw --devel

If you agree that this is a good idea, read on.

I put together a patch (see the link below) for this to build master from the 3.0 repository. I didn't know if you would want this out there or not, so I'm posting it here in case you want to recommend it to Homebrew. If you would like me to submit to Homebrew, just let me know or you can do it yourself if you prefer.

https://github.com/tee3/homebrew/commit/dc9fbd95fc434384ff1b892a02ffa1367f0deb1a

Hidden and captured cursor modes not working

Mac OS: 10.8.4
Mac: Macbook Pro w/ Retina 15" (MC950LL) (2880x1800) ran at 1440*900
RAM: 16GB
Video Card: Switchable Intel HD 4000 / nVidia 650 GT

I just pulled the latest 7423cfa commit and I cannot get either to work.
glfwSetInputMode(window, GLFW_CURSOR_MODE, GLFW_CURSOR_CAPTURED);
nor
glfwSetInputMode(window, GLFW_CURSOR_MODE, GLFW_CURSOR_HIDDEN);

If I try HIDDEN nothing happens, which is what the documentation says is expected however in a recent commit I thought it was fixed.
If I try CAPTURED and click on the window my cursor shoots to the center of the window, then I can move the cursor freely as I choose, the moment I click the window title bar however my cursor will shoot back to the center but is still visible.

NOTE: This is my first time pulling GLFW Master.

X11 input extensions library headers not checked in cmake

When trying to compile for the first time on Linux (ubuntu 13.04), I get the error that X11/extensions/XInput2.h could not be found. It would be useful to get an error message when the x11 input extensions library (libxi-dev) or this header specifically.

Crash with no monitor callback set, MBP retina

Running on a Macbook Pro retina, applications start by giving a GLFW_DISCONNECTED followed by a GLFW_CONNECTED event. This behavior does not occur on my Macbook Air, or Mac mini. If no monitor callback function is set, this will result in a crash, which it does in most examples. Guarding the call to the monitor callback in monitor.c with a check if the callback function != NULL will solve this.

Full resolution rendering on Retina displays not supported

glfwGetMonitors lists deactivated monitors

On my machine (Ubuntu Linux 12.10) this function also lists monitors that were deactivated (via the Displays system tool).

This is problematic, as using these monitor handles in glfw queries causes errors. For example calling glfwGetMonitorPos(), I get:

X Error of failed request:  BadRRCrtc (invalid Crtc parameter)
  Major opcode of failed request:  157 (RANDR)
  Minor opcode of failed request:  20 (RRGetCrtcInfo)
  Crtc id in failed request: 0x0
  Serial number of failed request:  103
  Current serial number in output stream:  103

pkg-config settings missing libs

I'm using pkg-config back ticked in a makefile, however I find I also have to do something like this...

opengl compiled glfw

#EXTRAGLFWLIBS=-lGL -lXrandr -lXi

GLESv2 compiled glfw

EXTRAGLFWLIBS=-lXxf86vm -lXrandr -lXi

LIBS= pkg-config --libs glfw3 $(EXTRAGLFWLIBS)

regardless how glfw's compile has been setup the pkg-config settings should reflect this

Cross-platform sleep function

usleep on Linux, Sleep on Windows, maybe usleep on mac ?

at any rate this is the only none cross platform aspect that glfw doesn't address

We don't always want to be running the cpu/gpu 100%

While there might be some cross platform way to do this in c++2014 it would be nice if there was a way to do this from C...

Only lower-left quadrant is rendering on Retina MBP.

(Possibly related to #4?)

I'm running GLFW on a Retina MBP with OSX 10.8.4.

When I ported my code to GLFW 3.0.1, I found that it was rendering everything to the bottom-left quadrant of the viewport. If tried a couple of the samples and found the same problem shows up there too.

When wave.c first starts up, everything renders in the bottom-left quadrant:

Bizarrely, when I drag the Wave Simulation window to a new position on the desktop, it suddenly starts rendering correctly:

None of the callbacks seem to be getting called and updating the projection matrix however. boing.c, gears.c both exhibit the same symptoms.

simple.c also renders to the lower-left quadrant, but isn't fixed by repositioning the window. The same is true for my code.

Weird OSX behaviour without _GLFW_USE_MENUBAR

Hi, I've ported my code from GLFW 2.7.x to 3.0.1 (current head) today and I noticed that the callback I registered with glfwSetKeyCallback was never being called, along with some other weird effects.

I discovered it was because I wasn't defining _GLFW_USE_MENUBAR. (I should point out that I'm building GLFW using a custom GYP file rather than the provided CMake configs, but I don't think this is relevant in this case).

This problem reproduces with the various sample projects - boing.c, wave.c, simple.c if I build them without _GLFW_USE_MENUBAR. FWIW, I'm running OSX 10.8.4 with a Retina MBP.

The side-effects I saw:

1. When I run the compiled samples from the command line, the GLFW window is created in the background (i.e, it appears behind the terminal).
2. When I move focus to the GLFW window and type, my keyboard input appears in the terminal window and my key callback (glfwSetKeyCallback) is never called.
3. If I use my .gyp file to generate an XCode project, launching the samples again results in the windows appearing in the background. Furthermore, if I use Expose to switch to the GLFW window, it almost immediately pops behind the XCode window. I.e. it won't retain focus.

Quickly scanning the code for cocoa_window.m, I see this chunk of code that's ifdef-ed out by _GLFW_USE_MENUBAR:

// If we get here, the application is unbundled
ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType(&psn, kProcessTransformToForegroundApplication);

// Having the app in front of the terminal window is also generally
// handy.  There is an NSApplication API to do this, but...
SetFrontProcess(&psn);

If I call these directly from initializeAppKit, all 3 issues listed above are fixed.

(edit: spelling)

Window resizing causes event processing to block

This can be seen on the demos as well.

Full screen windows always using primary monitor

Problem occurs on Ubuntu 13.04 with Unity desktop, dual monitor setup.

GLFWmonitor** monitors;
int count = 0;
monitors = glfwGetMonitors(&count);

GLFWmonitor* monitor = monitors[1];
GLFWvidmode vidmode = glfwGetVideoMode(monitor);

window = glfwCreateWindow(vidmode.width, vidmode.height, " ", monitor, NULL);

Screensaver status not properly handled when switching between full screen windows

Error C2275 at line 85 in “monitor.c” when using msvc compiler

It's a compiler incompatibility bug !

//Just modify line 85:
GLFWvidmode* modes = _glfwPlatformGetVideoModes(monitor, &modeCount);
//to:
modes = _glfwPlatformGetVideoModes(monitor, &modeCount);

//and add this declaration to the line 81:
GLFWvidmode* modes;

//then compiler works!

IME input

Nothing being rendered in window with GLES2 context

I have compiled and installed glfw 3.0 with

• OpenGL ES 2.0 (GLFW_CLIENT_LIBRARY = glesv2)
• egl for context creation (GLFW_USE_EGL = True).
  on Ubuntu 12.04 LTS 64bit.

Everything works fine, except if I use

glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_ES_API);

Then the screen stays black and nothing renders.

glfwSetCursorPos after unhide.

Hello !

I've just ported my engine from 2.7.x to 3.0 branch. Everything went smooth, and you guys made a great work with new version of glfw !

One thing I noticed :

When you hide cursor using
glfwSetInputMode( glfw_window , GLFW_CURSOR_MODE , GLFW_CURSOR_CAPTURED );
and then unhide it
glfwSetInputMode( glfw_window , GLFW_CURSOR_MODE , GLFW_CURSOR_NORMAL );

Cursors jump to the position before its have been hide. It make sense unless after unhide i do
glfwSetCursorPos( glfw_window , mouse_pos_x , mouse_pos_y );
what have no efect.

Example :

So after operation, cursor comes back to green dot.
Btw, I've submit same issue in website subproject here on git for mistake.

No workaround for broken vsync on Aero

Under Windows, glfwSwapInterval() doesn't do anything if composition is enabled (see _glfwPlatformSwapInterval() in wgl_context.c) because it can cause some from jitter when sync is actually enabled.

It would be nice if it was possible to force use of VSync, even if composition is enabled.

failed to retrieve context version string

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 6670
OpenGL version string: 4.2.12217 Compatibility Profile Context 12.104
OpenGL shading language version string: 4.20

Linux lynne-Desktop 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

using code that works fine on an intel HD4000

this is not my machine so I cannot get to in immediately to test things so please be patient!

I see this warning
libEGL warning: DRI2: failed to authenticate

which I don't for example see with glxgears

when stepping through the code it appears to get context (passes EGL_NO_CONTEXT ok)

creates window ok

makes a surface ok when making context current

_glfwRefreshContextParams() fails when parse version gets zero from glGetString(GL_VERSION);

Object sharing between windowed and full screen windows fails on context creation

Originally reported by @NathanSweet.

Gamma ramps of sizes other than 256 are not supported

This can be fixed by changing the GLFWgammaramp struct to

typedef struct
{
    unsigned short* red;
    unsigned short* green;
    unsigned short* blue;
    unsigned int size;
} GLFWgammaramp;

However, this puts the responsibility of freeing the arrays returned by glfwGetGammaRamp on the client, forcing the choice between adding glfwFreeGammaRamp or endless complaints of memory leaks and (when beginners mix debug and release MS libcs) crashes.

Creating GLFW window objects with existing native handles

It's really great that we can access native data from the OpenGL context such as glfwGetWin32Window() and glfwGetWGLContext().

It would be nice if that part of the API would be extended to wrap a window that has been created outside of GLFW into GLFW structures for OpenGL context creation, or wrap a context that was created outside of GLFW into GLFW strucutres so that we can use GLFW functions on that context (such as glfwSwapInterval()) for instance.

An example of where this would useful is for screensaver development. Let's say an OpenGL cross-platform screensaver is to be developed. On Windows and Linux for instance, writing a screensaver starts by the OS giving you a window in a platform-specific way. It would be nice to be able to give that OS-specific window handle to GLFW so that from then on, we can use platform-independent GLFW calls to create the context, swap buffers, etc.

Touch input

Always-on-top window hint

Just was wondering if it might be possible to get a window hint flag to allow for this?

Currently creating a non-decorated window the size of the desktop keeps the menu bar displayed on Mac.

I've worked around this issue by using the native window functions and just doing:

NSWindow * macwindow = glfwGetCocoaWindow(window);
[NSMenu setMenuBarVisible:NO];
NSPoint p = NSMakePoint(0, 0);
[macwindow setFrameOrigin:p];

However, it would be lovely if GLFW could support this behavior out of the box. I haven't tested how this works on Windows or Linux for instance.

Monitor callback only triggered by physical device events

This issue has been moved from SourceForge.

Tested under Windows 8, but probably exists for prior versions, _glfw.monitorCallback is only being called on physical device connects/disconnects. The cause of this is that it relies on the WM_DEVICECHANGE/DBT_DEVNODES_CHANGED message which is, of course, only sent when a physical device is connected or disconnected from the system. This means that enabling or disabling displays (e.g., turning extended display settings on/off) does not trigger a callback and cannot be re-enumerated without restarting the program.

By using Spy++ to watch notifications sent when displays were enabled/disabled I was able to identify a few notifications that are triggered through this action, of which WM_DISPLAYCHANGE is the most promising (the others tended to get sent multiple times). As a proof of concept, I modified windowProc in win32_window.c, but I have concerns about it's suitability as a permanent solution. Off the top of my head, though, I see two reasons why this solution might not be a good one:

• it means that display connects/disconnects will result in _glfwInputMonitorChange being called twice as a result of handling both 'WM_DEVICECHANGEandWM_DISPLAYCHANGE`.
• it means that initiating a video mode change will result in _glfwInputMonitorChange being called unnecessarily.

There is probably a better way of handling this scenario, but Windows isn't my thing and I don't really know how else to integrate support for handling display enabling/disabling with the existing methods for handling notifications.

Regardless, as enabling/disabling monitors without disconnecting them is a common usage scenario this is something that probably should be supported.

Joysticks connected after glfwInit not detected

Joysticks connected after `glfwInit' has completed are not detected and hence cannot be used from GLFW. Resolving this involves using inotify or libudev on Linux and the IOKit on OS X. The proper solution on Linux is libudev, while the easy solution is inotify.

Joystick axes inverted compared to values reported by SDL

Captured cursor mode causes jitter with non-trivial rendering and non-zero swap interval

Monitor and window positions use different coordinate systems

Title bar drag, close, minimize, maximize not working

Am using Windows 7 and glfw 3.0.
By setting mode to GLFW_CURSOR_NORMAL, i can see my cursor over the glfw window to be "circle"(as if some task is going on) but no mouse events are getting processed like drag, minimize, close from title bar