It's already possible to trigger the initialization of the GL profiles manually by calling GLProfile.initSingleton(). It's already possible to know whether the rasterizer is hardware accelerated or not. However, "GDI Renderer" is not treated as a software rasterizer and jogamp.opengl.GLContextImpl.glRenderer isn't publicly exposed:
When there is no other available renderer than this "GDI Renderer" under Microsoft Windows, the creation of a pbuffer fails whereas the driver claims to support pbuffers if the depth bits bit of the capabilities isn't set to 32. The early detection of this renderer would allow to use the right depth bits bit and/or to query a capabilities object without pbuffer support.
Moreover, it would allow to implement a black list of unsupported drivers. The application wouldn't be launched when an unsuitable driver is installed.
Maybe modifying the implementation of isCurrentContextHardwareRasterizer() would be enough in my case but exposing the OpenGL renderer would be more useful on the long term and both can be done.
This is the information returned by a typical GDI renderer :
Constructeur de la carte (vendor) : Microsoft Corporation
Carte graphique (renderer) : GDI GENERIC
Version d'Open GL (version) : 1.1.0
The following exception is thrown when the pbuffer cannot be created:
javax.media.opengl.GLException: pbuffer creation error: Couldn't find a suitable pixel format
This is reproducible with the default driver and with those provided by the OEM on the Acer Veriton T661 under Microsoft Windows XP Pro with the Intel Q35 Express chip:
The GDI renderer is already correctly reported as a software renderer and there is no need to expose much more information about the renderer so early to work around some bugs. Maybe the fix of the bug 1077 improves a bit the current situation. I'll open another bug report for the problem with Intel Q35 Express.