Bug 38869 - Cannot create a valid pBuffer with height and/or width of zero
Summary: Cannot create a valid pBuffer with height and/or width of zero
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/X11 (show other bugs)
Version: 7.10
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-01 01:18 UTC by Jonathan Kirkham
Modified: 2015-10-22 22:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Kirkham 2011-07-01 01:18:21 UTC
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).

The MESA implmentation simply returns a surface handle of zero in Fake_glXCreatePbuffer (within fakeglx.c) when these values are used, without throwing an error. 

Because an error has not been thrown it appears than the buffer is valid when it is not. Subsequent calls to query or destroy the buffer will cause errors.

Other implementations throw a BAD_VALUE error in this case although this is not part of either specification.
Comment 1 Brian Paul 2011-07-20 07:25:36 UTC
"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?
Comment 2 Ian Romanick 2011-07-20 07:42:30 UTC
(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.
Comment 3 Brian Paul 2011-07-20 07:52:24 UTC
(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.
Comment 4 Jonathan Kirkham 2011-07-21 05:00:18 UTC
(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.
Comment 5 Corentin Wallez 2015-10-22 22:42:19 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.