I'm a bit undecided about this bug.  The ARB_fbo spec says:

    "If the default framebuffer is bound to <target>, then
    <attachment> must be one of FRONT_LEFT, FRONT_RIGHT, BACK_LEFT,
    BACK_RIGHT, AUXi, DEPTH_BUFFER, or STENCIL_BUFFER, identifying a
    color buffer, the depth buffer, or the stencil buffer, and
    <pname> may be FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE or
    FRAMEBUFFER_ATTACHMENT_OBJECT_NAME."

This implies to me that FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE and FRAMEBUFFER_ATTACHMENT_OBJECT_NAME are the only valid queries.  This seems to be the conclusion of other vendors as well.

However, the OpenGL 3.0 spec says:

    "Upon successful return from GetFramebufferAttachmentParameteriv, if
    pname is FRAMEBUFFER ATTACHMENT OBJECT TYPE, then param will contain
    one of NONE, FRAMEBUFFER DEFAULT, TEXTURE, or RENDERBUFFER, identifying
    the type of object which contains the attached image. Other values accepted
    for pname depend on the type of object, as described below.

    If the value of FRAMEBUFFER ATTACHMENT OBJECT TYPE is NONE, no framebuffer
    is bound to target. In this case querying pname FRAMEBUFFER ATTACHMENT
    OBJECT NAME will return zero, and all other queries will generate an
    INVALID OPERATION error."

A little farther down on the same page, the spec says:

    "If pname is FRAMEBUFFER ATTACHMENT COLOR ENCODING, param will
    contain the encoding of components of the specified attachment, one of
    LINEAR or SRGB for linear or sRGB-encoded components, respectively.
    Only color buffer components may be sRGB-encoded; such components
    are treated as described in sections 4.1.8 and 4.1.9. For the default frame-
    buffer, color encoding is determined by the implementation. For framebuffer
    objects, components are sRGB-encoded if the internal format of a color
    attachment is one of the color-renderable SRGB formats described in sec-
    tion 3.9.15."

Here's my interpretation based on this and text in section 2.1 and the beginning of chapter 4 about the default framebuffer:

1. If there is a drawable (i.e., the default framebuffer exists and is complete), binding framebuffer object 0 should cause FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE to return FRAMEBUFFER_DEFAULT.

2. If there is no drawable (i.e., the default framebuffer does not exist), binding framebuffer object 0 should cause FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE to return NONE.

3. If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE to returns NONE, these queries should generate the error INVALID_OPERATION (0x502).  Returning INVALID_ENUM (0x500) is bogus no matter what.

My guess is that other implementations are incorrectly returning NONE unconditionally when FBO 0 is bound.  This causes them to correctly reject other queries.

Can we modify this test case to first query FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE?  If it returns anything other than FRAMEBUFFER_DEFAULT, the test should fail.

Unless there's some disagreement, I believe we should resolve this as NOTOURBUG.

Sounds good, Ian.  I'll try to fix Mesa and the piglit test unless you beat me to it.

Created attachment 40635 [details] [review]
Fix GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE query

Return GL_FRAMEBUFFER_DEFAULT for the default FBO.

Created attachment 40636 [details] [review]
add a GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE check to piglit fdo28551.c

Do additional checking in the piglit test.

I've committed the two attachments.

Vinson, do you want to re-run the piglit test with the other drivers and see what happens?  I think we'll just close this as NOTOURBUG as Ian said.

piglit: bf958cc359f00caad4c58608a8573b61f972ef66

fdo28551

Mesa - pass  
NVIDIA - fail (Default framebuffer's attachment type is not GL_FRAMEBUFFER_DEFAULT)
ATI - fail (Default framebuffer's attachment type is not GL_FRAMEBUFFER_DEFAULT)
Apple - fail (Default framebuffer's attachment type is not GL_FRAMEBUFFER_DEFAULT)
Intel - skip (Test requires GL_ARB_framebuffer_object)

btw: fdo28551 passes on NVIDIA 384.98