I tried your patch to handle the crash with MergedFB mode... There still is a problem:
$ spectro/dispwin -d 2
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 136 (XFree86-VidModeExtension)
Minor opcode of failed request: 19 (XF86VidModeGetGammaRampSize)
Value in failed request: 0x0
Serial number of failed request: 67
Current serial number in output stream: 67
It crashes when trying to load the LUT... It doesn't if I do not use the '-d 2' param, but I need it, or I'm unable to put the patches on the right screen...
This is what I would expect, the VideoLUTs aren't accessible, so you can't use them. I'm presuming from the above sequence that the colored squares were displayed correctly, and I gather from what you've said that it is able to run all the way through on the first display if you don't use -d2, or you use -d1.
The fact that it stops running after the X error might be more of an issues. I might have to protect all the VideoLUT accesses so that the MerfedFB/TwinView problem doesn't stop them continuing execution in the same way they do if the VidModeExtension is not present.
I think when you detect the MergedFB/TwinView mode, you also need to force the LUT to be loaded to the first screen, even if '-d 2' param is used.
I know of no way of detecting MergedFB/TwinView mode, and I'm worried about misleading people into thinking calibration works, when in fact it doesn't. In this sort of situation I think it will be up to the end user to manage things (ie. to set the calibration they want on the display they are able, and then take care of what affect this has on other displays, etc.)
Without a very complete test rig (ATI and NVidia cards with twin outputs, testing all combinations of muli-output from single cards and multi-output from multiple cards), I can't second guess the actual effects of setting the VideoLUTs on the screens which are accessible, on other screens where it's not accessible. The end user will have to figure this out using dispwin.
Another solution could be to handle the screen as one big screen (number 1), and let the user use coordinates modifier to put the patches at the correct location.
If I fix it so that VideoLUT access failure due to MergedFB/TwinView is detected rather than stopping program execution, then there is nothing to stop dispread being run on the second screen. It already does so if the VidModeExtension is not present.
If you have the system configured as one big screen (ie. Xinerama emulation is off), then the dispwin window should appear in the middle of the big screen, and the usual -p option will work.
I've updated the source patch to patch 3, to address this problem. See how you go, and if it works as expected, I'll update the binaries later.