Yes, but if we add a function to return the primary monitor, should it be the one where the WM would run the app?

I think we should avoid the use of the name "primary". For one thing, if that's really what the user wants, he/she could just select the first screen (afterall, that's what "primary" means) and be done with it. This is already the current behaviour on OS X (since screen 0 is always the one with the Dock and the menu bar, which starts at 0,0) and, as I understand it, Linux.
What we would need then is a function that tells the user what the "active" or "default" display is where the OS will show a window, which is what [NSScreen mainScreen] returns on OS X.

For the sake of clarity I think we should maybe avoid the use of "primary" to refer to anything other than the first display (for which we don't need a function to tell us what it is, since it's the first one). It seems to me that this is mainly a Windows problem, where the first display is the one that is "on the left" rather than the one containing the taskbar (in other words, different operating systems mean different things by "primary display"). In which case, perhaps we need to have the following:

• A function to get the "active" (current, default, whatever) screen, which is where the window will appear unless we explicitly tell it to go elsewhere. Not sure how easy it is to get that on X11, but maybe this could just be a "magic" identifier of -1 to say "we don't care".

• A function to get the screen that has the taskbar (dock) on it. On OS X, this is just the first screen (index 0). No idea on how to get this information on X11 though.

With those two functions, I think we have all we need. I don't think we should force our own ordering on screens (for instance, force "0" to be the display containing the taskbar (dock) on every operating system, since I see that become messy and confusing in the future) beside that: whether screen "0" is "the one on the left" or "the one that contains the taskbar" depends on the platform.

No. It changes when the user changes the key window. In other words, it's the screen that the currently active window is on. The location of the mouse has nothing to do with it (obviously, OS X doesn't have focus-follows-mouse, which I still find annoying). But in the current context, that's irrelevant: what matters is that it's the screen that the display will appear on if we go with the default.

There is absolutely no way to ask where the window is going to show up if we don't specify anything?
In which case, we probably should go with a generic "-1" to indicate we don't care and "pick the default". We could still add a function that tells you what the "main" display is (the one with the taskbar on Windows, equivalent to the first one on OS X, probably equivalent to the first one on X11).

Sure. You probably understand what I meant though.

X doesn't though The closest thing to a primary monitor is the one at 0x0, and the closest thing to a default is the one that contains a window that has focus.

I think in the end thats what the "default" monitor has to be at any given time. The monitor with a window on it that has focus.

How about such results?

2 adapters found...
Main adapter is 0
Active adapter is 1
Adapter 0: (0, 0) - (1920, 1200)
   Available fullscreen display modes:
   Mode   0:  640 x  480, 60 Hz
   Mode   1:  720 x  480, 60 Hz
   ...
   Mode  25: 1920 x 1200, 60 Hz
Adapter 1: (1920, 0) - (3360, 900)
   Available fullscreen display modes:
   Mode   0: 1440 x  900, 60 Hz
   Mode   1: 1440 x  900, 75 Hz
   ...
   Mode  53: 1280 x 1024, 75 Hz

New functions:

int al_get_main_adapter(void);
int al_get_active_adapter(void);

First one return index of main adapter (one with task bar). Second one return active one. For example if you launch your application on second monitor then it will be considered as active. If active adapter couldn't be determined there is a fall back to main adapter.

During Allegro initialization active adapter is set as default adapter.

Edit:
I attached patch to this post. Please confirm me than Mac implementation is working and Linux version compile without problems. (Linux implementation isn't done, but I created stubs in mmon_interface).

No, the monitor at 0x0 can be listed at any point in the Xrandr output. I assume if you put a secondary to the left on OSX it might appear first in its output too.

I cannot speak for how Allegro works with the Windows API, but Windows treats the primary display as the one marked as "Use this device as the primary monitor." It doesn't matter which is to the left or right or up or down or has the task bar, etc.

I implemented OSX function according to this documentation.

The question is, what about NSApplicationDidChangeScreenParametersNotification? Maybe Allegro should notify user about changing display layout? There is also similar message generated by Windows.

OK. I added that magic "-1" value to my TODO list.

I will try to fix OSX version tomorrow.