Bug 38869

"Both the EGL and GLX specifications allow pbuffers to be created with a height
and/or width of zero (and these are the default values)."
[...]
"Other implementations throw a BAD_VALUE error in this case although this is not
part of either specification."

I'm not clear on what you're saying.  According to the GLX spec, it looks like a size 0 x 0 pbuffer is legal.  But are you saying other implementations throw BadValue if you try that?

In Mesa, have you tried removing the width==0 || height==0 check?  If so, what happens when you create a 0x0 pbuffer?

Also, off-hand, I don't know of a way to directly generate an X error with Xlib calls.  Remember, the fake GLX layer we're talking about here has no internal hooks into X so we can't do everything that the real GLX library does.  I suppose we could set up an unrelated protocol request that purposely has bad arguments to generate the error.  If you need this, could you try to implement it?

(In reply to comment #0)
> Both the EGL and GLX specifications allow pbuffers to be created with a height
> and/or width of zero (and these are the default values).

Is there any language in the specs that specifically allow this?  If there is, we should add a test case.

(In reply to comment #2)
> (In reply to comment #0)
> > Both the EGL and GLX specifications allow pbuffers to be created with a height
> > and/or width of zero (and these are the default values).
> 
> Is there any language in the specs that specifically allow this?  If there is,
> we should add a test case.

The spec says the default values for the width/height attribs are zero.  That's all I found after a quick skim.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > Both the EGL and GLX specifications allow pbuffers to be created with a height
> > > and/or width of zero (and these are the default values).
> > 
> > Is there any language in the specs that specifically allow this?  If there is,
> > we should add a test case.
> 
> The spec says the default values for the width/height attribs are zero.  That's
> all I found after a quick skim.

(In reply to comment #1)
> "Both the EGL and GLX specifications allow pbuffers to be created with a height
> and/or width of zero (and these are the default values)."
> [...]
> "Other implementations throw a BAD_VALUE error in this case although this is
> not
> part of either specification."
> 
> I'm not clear on what you're saying.  According to the GLX spec, it looks like
> a size 0 x 0 pbuffer is legal.  But are you saying other implementations throw
> BadValue if you try that?
> 
> In Mesa, have you tried removing the width==0 || height==0 check?  If so, what
> happens when you create a 0x0 pbuffer?
> 
> Also, off-hand, I don't know of a way to directly generate an X error with Xlib
> calls.  Remember, the fake GLX layer we're talking about here has no internal
> hooks into X so we can't do everything that the real GLX library does.  I
> suppose we could set up an unrelated protocol request that purposely has bad
> arguments to generate the error.  If you need this, could you try to implement
> it?


I meant that other implementations that DO NOT support heights and widths of zero (although they should be doing so) throw a BAD_VALUE error to indicate that they cannot create the pbuffer.

Implementations that do support it (e.g. the Nvidia driver) return a valid pbuffer handle that can be queryied etc.

Bumping this as I've run into this bug (feature?) while porting ANGLE to run on GLX. When ANGLE is initialized we make the context current on a dummy PBuffer created with {None} as attributes, which makes it a (0, 0)-sized Pbuffer.

Doing so on Mesa 10.5.9 on a HD Graphics 5500 causes the following to be thrown:
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  53 (X_CreatePixmap)

It seems that the driver might be trying to back the PBuffer using a Pixmap of the same size. The documentation of XCreatePixmap says that the width and height should be non-zero or BadValue is generated.

Let me know if you need more information.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/77.