If you do a Try-Catch block around the SetGraphicsDriver() call, and if it throws an exception, it may indicate that OpenGL is not supported in some way.
I don't think there is anything in particular you can do to checks that kind of thing. If you just have a normal level of cautiousness about each step you take to open a display, ie using lots of Try/Catch and `If =Null` type of stuff, then you should be able to detect when something is misbehaving.
One thing I can tell you is that once you have established what should be a display, either using Graphics(), GLGraphics(), SetGraphics() or CanvasGraphics(), if and only if the display opened correctly will OpenGL return valid and useful information, e.g. glGetIntegerv(GL_RED_BITS,Varptr(a)). If for some reason the display did not open right, which will happen if you ask for some buffers that the mode you requested does not support, then anything OpenGL says is useless as it will give you default values back.
What I do is try opening the display then try drawing something to the backbuffer then do a Flip() to make sure it is visible, then set glReadBuffer(GL_FRONT) and use GLReadPixels() to read the area that you drew to to make sure there is some pixel data there, and if there is you know for sure everything opened right and the display is working and the user can see results. When the context did not open and is not working, it won't render or flip the data. One thing to bear in mind is that on some systems 0,0 is topleft, on others it is bottom left, so draw something to both corners and test both corners to be sure. If you get proper pixel data back rather than black (use cls before drawing), then you know OpenGL context is valid and will report correct data, then use glGetIntegerv() to read state from OpenGL - it will be reliable. And you will find that you get some buffers you didn't ask for and you may not get some that you did ask for. You should check all of them to be sure.
Also note that some systems (mac at least) do not support OpenGL in fullscreen mode, due to not enough video ram and other matters. To trap this use a Try/Catch block around the line that opens the display (e.g. CreateGraphics(), Graphics() etc). If it makes an exception the display did not open at all. This may indicate GL is not supported or just that GL can't run in fullscreen. On the Mac you apparently need 16mb videoram to run GL in fullscreen. CreateGraphics() will set the display to fullscreen but will show nothing, and then SetGraphics will make an exception.
Note you also cannot ever be sure that using glDrawBuffer(GL_BACK) will actually draw to the back. On some systems the identification of which buffer is which is totally blind. You also probably cannot draw to the front buffer on some systems, they just wont allow it. Just assume you're on the backbuffer, draw stuff and flip.
Note also that when you open a GL context, it will probably only open in at least 15-bit depth. If your desktop is 8-bit, the GL context may still be 15-bit internally and calls to read the bit depths will tell you so. It is automatically dithered down to 256-colors by the o/s or GL driver when you flip. If you don't have at least 15-bits total for the RGB components, I would close it down and request more bit depth because if you get an index buffer instead of RGBA it'll give you very unpredictable results.
Note also that some systems return 0 as the hertz rate of the display, even within the o/s. You'll have to use a guesstimated software rate in that case.
I don't think there is anything in particular you can do to checks that kind of thing. If you just have a normal level of cautiousness about each step you take to open a display, ie using lots of Try/Catch and `If =Null` type of stuff, then you should be able to detect when something is misbehaving.
One thing I can tell you is that once you have established what should be a display, either using Graphics(), GLGraphics(), SetGraphics() or CanvasGraphics(), if and only if the display opened correctly will OpenGL return valid and useful information, e.g. glGetIntegerv(GL_RED_BITS,Varptr(a)). If for some reason the display did not open right, which will happen if you ask for some buffers that the mode you requested does not support, then anything OpenGL says is useless as it will give you default values back.
What I do is try opening the display then try drawing something to the backbuffer then do a Flip() to make sure it is visible, then set glReadBuffer(GL_FRONT) and use GLReadPixels() to read the area that you drew to to make sure there is some pixel data there, and if there is you know for sure everything opened right and the display is working and the user can see results. When the context did not open and is not working, it won't render or flip the data. One thing to bear in mind is that on some systems 0,0 is topleft, on others it is bottom left, so draw something to both corners and test both corners to be sure. If you get proper pixel data back rather than black (use cls before drawing), then you know OpenGL context is valid and will report correct data, then use glGetIntegerv() to read state from OpenGL - it will be reliable. And you will find that you get some buffers you didn't ask for and you may not get some that you did ask for. You should check all of them to be sure.
Also note that some systems (mac at least) do not support OpenGL in fullscreen mode, due to not enough video ram and other matters. To trap this use a Try/Catch block around the line that opens the display (e.g. CreateGraphics(), Graphics() etc). If it makes an exception the display did not open at all. This may indicate GL is not supported or just that GL can't run in fullscreen. On the Mac you apparently need 16mb videoram to run GL in fullscreen. CreateGraphics() will set the display to fullscreen but will show nothing, and then SetGraphics will make an exception.
Note you also cannot ever be sure that using glDrawBuffer(GL_BACK) will actually draw to the back. On some systems the identification of which buffer is which is totally blind. You also probably cannot draw to the front buffer on some systems, they just wont allow it. Just assume you're on the backbuffer, draw stuff and flip.
Note also that when you open a GL context, it will probably only open in at least 15-bit depth. If your desktop is 8-bit, the GL context may still be 15-bit internally and calls to read the bit depths will tell you so. It is automatically dithered down to 256-colors by the o/s or GL driver when you flip. If you don't have at least 15-bits total for the RGB components, I would close it down and request more bit depth because if you get an index buffer instead of RGBA it'll give you very unpredictable results.
Note also that some systems return 0 as the hertz rate of the display, even within the o/s. You'll have to use a guesstimated software rate in that case.