Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Keith Packard 
Adam Jackson  writes:

> What would this mean? If I point this picture at a depth-30 pixmap, is
> the intent really "draw into this as though it was x8r8g8b8"? Is there
> a world where that's useful?

I agree that it probably isn't useful, but we need to be careful with
the condition to not exclude *useful* formats, like r8g8b8 on depth 32,
or r5g5b5 on depth 16. Of course, the real fear is deleting a format
that an existing app is relying on...

> All the 16bpp formats say they have "depth 16", regardless of a/x.

I think that's because you don't have a depth 15 visual.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Keith Packard 
Michel Dänzer  writes:

> On 2018-02-22 10:53 PM, Adam Jackson wrote:
>> "depth" for a picture format is the sum of bits of a/r/g/b, and not x.
>> The default format list was creating an x8r8g8b8 format at depth 32,
>> which is wrong. Likewise, servers supporting depth 30 would get an
>> x8r8g8b8 format at depth 30, which is nonsense.
>
> Actually, the former isn't wrong, and the latter might not be either, I
> think. These are the constraints:
>
> * The sizes of a/x+r+g+b must equal bpp
> * The sizes of a+r+g+b must be <= depth (or == ?)

We could make it ==, but we currently make it <= so that you can have
r8g8b8 on depth 32, and r4g4b4 on depth 15 and 16.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Keith Packard 
Adam Jackson  writes:

> This is at the bottom of fbPictureInit. This is code that every driver
> already runs. The loop will find that a pixmap of depth 16 has 16 bits
> per pixel, and since that's larger than 12, it will add x4r4g4b4.

But, a pixmap of depth 15 or 16 cannot support r5g6b5 formats, and that's what
the tests do -- eliminate offering formats which require more bits than
the depth of the drawable.

> You might be right that we _should not_ expose formats not present in
> the hardware, though Render has kinda already lost that fight by making
> a1 and a4 mandatory. But the Render code today, and forever, is making
> the assertion that the code above it _will_ handle these formats.

We just need to make sure we don't promise to store bits beyond the
depth of the drawable.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/2] render: Store all 16bpc of precision for solid pictures

2018-02-23 Thread Keith Packard 
Adam Jackson  writes:

> Signed-off-by: Adam Jackson 

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/2] render: Simplify miCompositeRects

2018-02-23 Thread Keith Packard 
Adam Jackson  writes:

> Make a solid-fill picture for this instead of a 1x1 pixmap. In principle
> the backend can accelerate this directly, and we also get to preserve
> all the bits of the fill color.
>
> Signed-off-by: Adam Jackson 

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 2/2] render: Simplify miCompositeRects

2018-02-23 Thread Adam Jackson 
Make a solid-fill picture for this instead of a 1x1 pixmap. In principle
the backend can accelerate this directly, and we also get to preserve
all the bits of the fill color.

Signed-off-by: Adam Jackson 
---
 render/mirect.c | 63 +
 1 file changed, 9 insertions(+), 54 deletions(-)

diff --git a/render/mirect.c b/render/mirect.c
index a36d1d6e3..65f8d5efd 100644
--- a/render/mirect.c
+++ b/render/mirect.c
@@ -91,8 +91,6 @@ miCompositeRects(CARD8 op,
  PicturePtr pDst,
  xRenderColor * color, int nRect, xRectangle *rects)
 {
-ScreenPtr pScreen = pDst->pDrawable->pScreen;
-
 if (color->alpha == 0x) {
 if (op == PictOpOver)
 op = PictOpSrc;
@@ -108,61 +106,18 @@ miCompositeRects(CARD8 op,
  pDst->alphaOrigin.x, pDst->alphaOrigin.y);
 }
 else {
-PictFormatPtr rgbaFormat;
-PixmapPtr pPixmap;
-PicturePtr pSrc;
-xRectangle one;
 int error;
-Pixel pixel;
-GCPtr pGC;
-ChangeGCVal gcvals[2];
-XID tmpval[1];
+PicturePtr pSrc = CreateSolidPicture(0, color, );
 
-rgbaFormat = PictureMatchFormat(pScreen, 32, PICT_a8r8g8b8);
-if (!rgbaFormat)
-goto bail1;
+if (pSrc) {
+while (nRect--) {
+CompositePicture(op, pSrc, 0, pDst, 0, 0, 0, 0,
+ rects->x, rects->y,
+ rects->width, rects->height);
+rects++;
+}
 
-pPixmap = (*pScreen->CreatePixmap) (pScreen, 1, 1, rgbaFormat->depth,
-CREATE_PIXMAP_USAGE_SCRATCH);
-if (!pPixmap)
-goto bail2;
-
-miRenderColorToPixel(rgbaFormat, color, );
-
-pGC = GetScratchGC(rgbaFormat->depth, pScreen);
-if (!pGC)
-goto bail3;
-gcvals[0].val = GXcopy;
-gcvals[1].val = pixel;
-
-ChangeGC(NullClient, pGC, GCFunction | GCForeground, gcvals);
-ValidateGC(>drawable, pGC);
-one.x = 0;
-one.y = 0;
-one.width = 1;
-one.height = 1;
-(*pGC->ops->PolyFillRect) (>drawable, pGC, 1, );
-
-tmpval[0] = xTrue;
-pSrc = CreatePicture(0, >drawable, rgbaFormat,
- CPRepeat, tmpval, serverClient, );
-
-if (!pSrc)
-goto bail4;
-
-while (nRect--) {
-CompositePicture(op, pSrc, 0, pDst, 0, 0, 0, 0,
- rects->x, rects->y, rects->width, rects->height);
-rects++;
+FreePicture((void *) pSrc, 0);
 }
-
-FreePicture((void *) pSrc, 0);
- bail4:
-FreeScratchGC(pGC);
- bail3:
-(*pScreen->DestroyPixmap) (pPixmap);
- bail2:
- bail1:
-;
 }
 }
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 0/2] Minor Render cleanups

2018-02-23 Thread Adam Jackson 
Some more little things found while testing the depth 30 series. Sadly
neither one fixes the rendercheck issues, but neither do they break
anything, and the result is definitely simpler.

 exa/exa_render.c|  4 +++-
 fb/fbpict.c | 16 +++--
 glamor/glamor_program.c |  7 +++---
 glamor/glamor_render.c  | 14 ---
 glamor/glamor_utils.h   |  9 +++
 render/mirect.c | 63 +++--
 render/picture.c| 10 +---
 render/picturestr.h |  2 +-
 8 files changed, 34 insertions(+), 91 deletions(-)

- ajax

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 1/2] render: Store all 16bpc of precision for solid pictures

2018-02-23 Thread Adam Jackson 
Signed-off-by: Adam Jackson 
---
 exa/exa_render.c|  4 +++-
 fb/fbpict.c | 16 +++-
 glamor/glamor_program.c |  7 ---
 glamor/glamor_render.c  | 14 --
 glamor/glamor_utils.h   |  9 +
 render/picture.c| 10 +-
 render/picturestr.h |  2 +-
 7 files changed, 25 insertions(+), 37 deletions(-)

diff --git a/exa/exa_render.c b/exa/exa_render.c
index b24bec052..2dad795f2 100644
--- a/exa/exa_render.c
+++ b/exa/exa_render.c
@@ -291,7 +291,9 @@ exaTryDriverSolidFill(PicturePtr pSrc,
 pixel = exaGetPixmapFirstPixel(pSrcPix);
 }
 else
-pixel = pSrc->pSourcePict->solidFill.color;
+miRenderColorToPixel(pSrc->pFormat,
+ >pSourcePict->solidFill.color,
+ );
 
 if (!exaGetRGBAFromPixel(pixel, , , , ,
  pSrc->pFormat, pSrc->format) ||
diff --git a/fb/fbpict.c b/fb/fbpict.c
index 7ea0b668f..759f0d5db 100644
--- a/fb/fbpict.c
+++ b/fb/fbpict.c
@@ -220,20 +220,10 @@ static pixman_image_t *
 create_solid_fill_image(PicturePtr pict)
 {
 PictSolidFill *solid = >pSourcePict->solidFill;
-pixman_color_t color;
-CARD32 a, r, g, b;
+/* pixman_color_t and xRenderColor have the same layout */
+pixman_color_t *color = (pixman_color_t *)>color;
 
-a = (solid->color & 0xff00) >> 24;
-r = (solid->color & 0x00ff) >> 16;
-g = (solid->color & 0xff00) >> 8;
-b = (solid->color & 0x00ff) >> 0;
-
-color.alpha = (a << 8) | a;
-color.red = (r << 8) | r;
-color.green = (g << 8) | g;
-color.blue = (b << 8) | b;
-
-return pixman_image_create_solid_fill();
+return pixman_image_create_solid_fill(color);
 }
 
 static pixman_image_t *
diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
index 23c102bc3..29ffed05c 100644
--- a/glamor/glamor_program.c
+++ b/glamor/glamor_program.c
@@ -508,12 +508,13 @@ glamor_set_blend(CARD8 op, glamor_program_alpha alpha, 
PicturePtr dst)
 static Bool
 use_source_solid(CARD8 op, PicturePtr src, PicturePtr dst, glamor_program 
*prog)
 {
+PictSolidFill *solid = >pSourcePict->solidFill;
+float color[4];
 
+glamor_get_rgba_from_color(>color, color);
 glamor_set_blend(op, prog->alpha, dst);
+glUniform4fv(prog->fg_uniform, 1, color);
 
-glamor_set_color_depth(dst->pDrawable->pScreen, 32,
-   src->pSourcePict->solidFill.color,
-   prog->fg_uniform);
 return TRUE;
 }
 
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 7a96c82dd..75f4258d8 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -830,11 +830,8 @@ glamor_composite_choose_shader(CARD8 op,
 else if (!source->pDrawable) {
 if (source->pSourcePict->type == SourcePictTypeSolidFill) {
 key.source = SHADER_SOURCE_SOLID;
-glamor_get_rgba_from_pixel(source->pSourcePict->solidFill.color,
-   _solid_color[0],
-   _solid_color[1],
-   _solid_color[2],
-   _solid_color[3], PICT_a8r8g8b8);
+glamor_get_rgba_from_color(>pSourcePict->solidFill.color,
+   source_solid_color);
 }
 else
 goto fail;
@@ -850,11 +847,8 @@ glamor_composite_choose_shader(CARD8 op,
 if (!mask->pDrawable) {
 if (mask->pSourcePict->type == SourcePictTypeSolidFill) {
 key.mask = SHADER_MASK_SOLID;
-glamor_get_rgba_from_pixel
-(mask->pSourcePict->solidFill.color,
- _solid_color[0],
- _solid_color[1],
- _solid_color[2], _solid_color[3], 
PICT_a8r8g8b8);
+glamor_get_rgba_from_color(>pSourcePict->solidFill.color,
+   mask_solid_color);
 }
 else
 goto fail;
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 7597b92dc..d4f995ab9 100644
--- a/glamor/glamor_utils.h
+++ b/glamor/glamor_utils.h
@@ -710,6 +710,15 @@ glamor_get_rgba_from_pixel(CARD32 pixel,
 return TRUE;
 }
 
+static inline void
+glamor_get_rgba_from_color(const xRenderColor *color, float rgba[4])
+{
+rgba[0] = color->red   / (float)UINT16_MAX;
+rgba[1] = color->green / (float)UINT16_MAX;
+rgba[2] = color->blue  / (float)UINT16_MAX;
+rgba[3] = color->alpha / (float)UINT16_MAX;
+}
+
 inline static Bool
 glamor_is_large_pixmap(PixmapPtr pixmap)
 {
diff --git a/render/picture.c b/render/picture.c
index 9e4036e7d..9907e15d6 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -817,14 +817,6 @@ CreatePicture(Picture pid,
 return pPicture;
 }
 
-static CARD32
-xRenderColorToCard32(xRenderColor c)
-{
-return
-(c.alpha >> 8 << 24) |
-

Re: [PATCH xserver 7/7] modesetting: Allow a DRM fd to be passed through XF86_VIDEO_MODESETTING_FD

2018-02-23 Thread Keith Packard 
Eric Anholt  writes:

> Any security concerns with a suid xserver here?

Not that I know of, but it's probably only a matter of someone smarter
than me looking? I think what I want is a command line option that is
disabled when the server is setuid (or, frankly, run as root at
all?). This is purely a hack to show the xlease program working and test
KMS and X leases without needing Mesa changes.

I'll rewrite this as a command line option, which presumably involves
adding an option to the general xfree86 set.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] composite: Fix use-after-free in compReparentWindow

2018-02-23 Thread Adam Jackson 
On Thu, 2018-02-22 at 22:25 -0800, Keith Packard wrote:
> Peter Harris  writes:
> 
> > If an implicitly redirected window is unredirected by the reparent
> > operation, cw will be a stale pointer.
> > 
> > Signed-off-by: Peter Harris 
> 
> Reviewed-by: Keith Packard 

Merged, thanks:

remote: I: patch #206353 updated using rev 
efd84bff238f8e12bf652525990d36baada8785b.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   ac13d740bf..efd84bff23  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Adam Jackson 
On Thu, 2018-02-22 at 16:52 -0800, Keith Packard wrote:

> >  switch (bpp) {
> >  case 16:
> >  /* depth 12 formats */
> > -if (pDepth->depth >= 12) {
> > -addFormat(formats, , PICT_x4r4g4b4, 
> > pDepth->depth);
> > -addFormat(formats, , PICT_x4b4g4r4, 
> > pDepth->depth);
> > -}
> > +addFormat(formats, , PICT_x4r4g4b4, 12);
> > +addFormat(formats, , PICT_x4b4g4r4, 12);
> >  /* depth 15 formats */
> > -if (pDepth->depth >= 15) {
> > -addFormat(formats, , PICT_x1r5g5b5, 
> > pDepth->depth);
> > -addFormat(formats, , PICT_x1b5g5r5, 
> > pDepth->depth);
> > -}
> > +addFormat(formats, , PICT_x1r5g5b5, 15);
> > +addFormat(formats, , PICT_x1b5g5r5, 15);
> >  /* depth 16 formats */
> > -if (pDepth->depth >= 16) {
> > -addFormat(formats, , PICT_a1r5g5b5, 
> > pDepth->depth);
> > -addFormat(formats, , PICT_a1b5g5r5, 
> > pDepth->depth);
> > -addFormat(formats, , PICT_r5g6b5, pDepth->depth);
> > -addFormat(formats, , PICT_b5g6r5, pDepth->depth);
> > -addFormat(formats, , PICT_a4r4g4b4, 
> > pDepth->depth);
> > -addFormat(formats, , PICT_a4b4g4r4, 
> > pDepth->depth);
> > -}
> > +addFormat(formats, , PICT_a1r5g5b5, 16);
> > +addFormat(formats, , PICT_a1b5g5r5, 16);
> > +addFormat(formats, , PICT_r5g6b5, 16);
> > +addFormat(formats, , PICT_b5g6r5, 16);
> > +addFormat(formats, , PICT_a4r4g4b4, 16);
> > +addFormat(formats, , PICT_a4b4g4r4, 16);
> 
> You can't just blindly add formats that the driver might not
> support. Depth really means the bits supported by the driver; bits
> outside of depth may not be present in the hardware.

This is at the bottom of fbPictureInit. This is code that every driver
already runs. The loop will find that a pixmap of depth 16 has 16 bits
per pixel, and since that's larger than 12, it will add x4r4g4b4.

You might be right that we _should not_ expose formats not present in
the hardware, though Render has kinda already lost that fight by making
a1 and a4 mandatory. But the Render code today, and forever, is making
the assertion that the code above it _will_ handle these formats.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Adam Jackson 
On Fri, 2018-02-23 at 10:51 +0100, Michel Dänzer wrote:
> On 2018-02-22 10:53 PM, Adam Jackson wrote:
> > "depth" for a picture format is the sum of bits of a/r/g/b, and not x.
> > The default format list was creating an x8r8g8b8 format at depth 32,
> > which is wrong. Likewise, servers supporting depth 30 would get an
> > x8r8g8b8 format at depth 30, which is nonsense.
> 
> Actually, the former isn't wrong, and the latter might not be either, I
> think. These are the constraints:
> 
> * The sizes of a/x+r+g+b must equal bpp
> * The sizes of a+r+g+b must be <= depth (or == ?)

Okay, let's make this concrete. Xvfb at depth 30 gives me these
formats:

  pict format:
format id:0x2b
type: Direct
depth:30
alpha: 0 mask 0x0
red:  16 mask 0xff
green: 8 mask 0xff
blue:  0 mask 0xff
  pict format:
format id:0x2c
type: Direct
depth:30
alpha: 0 mask 0x0
red:   0 mask 0xff
green: 8 mask 0xff
blue: 16 mask 0xff

What would this mean? If I point this picture at a depth-30 pixmap, is
the intent really "draw into this as though it was x8r8g8b8"? Is there
a world where that's useful?

All the 16bpp formats say they have "depth 16", regardless of a/x.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 7/7] modesetting: Allow a DRM fd to be passed through XF86_VIDEO_MODESETTING_FD

2018-02-23 Thread Eric Anholt 
Keith Packard  writes:

> This lets an application open a suitable DRM device and pass the file
> descriptor to the mode setting driver through an environment variable.
>
> There's a companion application, xlease, which creates a DRM master by
> leasing an output from another X server. That is available at
>
>   git clone git://people.freedesktop.org/~keithp/xlease
>
> Signed-off-by: Keith Packard 
> ---
>  hw/xfree86/drivers/modesetting/driver.c | 29 -
>  hw/xfree86/drivers/modesetting/driver.h |  1 +
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> index 577559ea6..074872e97 100644
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -194,11 +194,28 @@ modesettingEntPtr ms_ent_priv(ScrnInfoPtr scrn)
>  return pPriv->ptr;
>  }
>  
> +static int
> +get_passed_fd(void)
> +{
> +char *fdstr = getenv("XF86_VIDEO_MODESETTING_FD");

Any security concerns with a suid xserver here?


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH util/modular] release.sh: Add support for mesa-demos

2018-02-23 Thread Andreas Boll 
2018-02-23 13:02 GMT+01:00 Emil Velikov :
> On 23 February 2018 at 09:40, Andreas Boll  wrote:
>> Signed-off-by: Andreas Boll 
>> ---
>>  release.sh | 34 ++
>>  1 file changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/release.sh b/release.sh
>> index ff89d2e..2045197 100755
>> --- a/release.sh
>> +++ b/release.sh
>> @@ -264,8 +264,10 @@ get_section() {
>> if [ $? -ne 0 ]; then
>> echo "Error: unable to extract section from $module_url second 
>> field."
>> return 1
>> -   elif [ x"$section" != xdrm ] && [ x"$section" != xmesa ]; then
>> -   echo "Error: section $section is not supported, only libdrm and 
>> mesa are."
>> +   elif [ x"$section" != xdrm ] &&
>> +[ x"$section" != xmesa ] &&
>> +[ x"$section" != xdemos ]; then
>> +   echo "Error: section $section is not supported, only libdrm, 
>> mesa and demos are."
>> return 1
>> fi
>>  fi
>> @@ -582,7 +584,8 @@ process_module() {
>>  section_path=libdrm
>>  srv_path="/srv/$host_current/www/$section_path"
>>  list_cc=$list_dri_devel
>> -elif [ x"$section" = xmesa ]; then
>> +elif [ x"$section" = xmesa ] ||
>> + [ x"$section" = xdemos ]; then
>>  host_current=$host_mesa
>>  mesa_version=`echo $pkg_version | sed 's:-rc.*::'`
>>  section_path=archive
>> @@ -590,16 +593,23 @@ process_module() {
>>  list_to=$list_mesa_announce
>>  list_cc=$list_mesa_devel
>>
>> -# Prior to 17.0.x Mesa uses separate folder for each release
>> -if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
>> -section_path=$section_path/$mesa_version
>> +if [ x"$section" = xdemos ]; then
>> +section_path=$section_path/$section
>>  srv_path="/srv/$host_current/www/$section_path"
> Let's keep demos as a separate if statement. As-is it gets a bit fiddly to 
> read.
Ack

>
>> -echo "Info: creating mesa directory on web server:"
>> -ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
>> -if [ $? -ne 0 ]; then
>> -echo "Error: cannot create the path \"$srv_path\" on the 
>> web server."
>> -cd $top_src
>> -return 1
>> +fi
>> +
>> +# Prior to 17.0.x Mesa uses separate folder for each release
>> +if [ x"$section" = xmesa ]; then
>> +if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
>> +section_path=$section_path/$mesa_version
>> +srv_path="/srv/$host_current/www/$section_path"
>> +echo "Info: creating mesa directory on web server:"
>> +ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
>> +if [ $? -ne 0 ]; then
>> +echo "Error: cannot create the path \"$srv_path\" on 
>> the web server."
>> +cd $top_src
>> +return 1
>> +fi
> Pretty sure this section can go now. I'll send a patch in a second.
Yep

>
> -Emil

Sent an even shorter v2 patch.

Thanks,
Andreas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH util-modular] release.sh: remove workaround for early Mesa versions

2018-02-23 Thread Andreas Boll 
Reviewed-by: Andreas Boll 

2018-02-23 13:56 GMT+01:00 Emil Velikov :
> From: Emil Velikov 
>
> Signed-off-by: Emil Velikov 
> ---
>  release.sh | 14 --
>  1 file changed, 14 deletions(-)
>
> diff --git a/release.sh b/release.sh
> index ff89d2e..99bd0c3 100755
> --- a/release.sh
> +++ b/release.sh
> @@ -584,24 +584,10 @@ process_module() {
>  list_cc=$list_dri_devel
>  elif [ x"$section" = xmesa ]; then
>  host_current=$host_mesa
> -mesa_version=`echo $pkg_version | sed 's:-rc.*::'`
>  section_path=archive
>  srv_path="/srv/$host_current/www/$section_path"
>  list_to=$list_mesa_announce
>  list_cc=$list_mesa_devel
> -
> -# Prior to 17.0.x Mesa uses separate folder for each release
> -if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
> -section_path=$section_path/$mesa_version
> -srv_path="/srv/$host_current/www/$section_path"
> -echo "Info: creating mesa directory on web server:"
> -ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
> -if [ $? -ne 0 ]; then
> -echo "Error: cannot create the path \"$srv_path\" on the web 
> server."
> -cd $top_src
> -return 1
> -fi
> -fi
>  fi
>
>  # Module xkeyboard-config goes in a subdir of the xorg "data" section
> --
> 2.16.0
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH util/modular v2] release.sh: Add support for mesa-demos

2018-02-23 Thread Andreas Boll 
v2: Rebase on Mesa cleanup.
Move demos into its own elif statement.

Signed-off-by: Andreas Boll 
---
Rebased on https://patchwork.freedesktop.org/patch/206466/

 release.sh | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/release.sh b/release.sh
index 99bd0c3..b2071b6 100755
--- a/release.sh
+++ b/release.sh
@@ -264,8 +264,10 @@ get_section() {
if [ $? -ne 0 ]; then
echo "Error: unable to extract section from $module_url second 
field."
return 1
-   elif [ x"$section" != xdrm ] && [ x"$section" != xmesa ]; then
-   echo "Error: section $section is not supported, only libdrm and 
mesa are."
+   elif [ x"$section" != xdrm ] &&
+[ x"$section" != xmesa ] &&
+[ x"$section" != xdemos ]; then
+   echo "Error: section $section is not supported, only libdrm, mesa 
and demos are."
return 1
fi
 fi
@@ -588,6 +590,12 @@ process_module() {
 srv_path="/srv/$host_current/www/$section_path"
 list_to=$list_mesa_announce
 list_cc=$list_mesa_devel
+elif [ x"$section" = xdemos ]; then
+host_current=$host_mesa
+section_path=archive/$section
+srv_path="/srv/$host_current/www/$section_path"
+list_to=$list_mesa_announce
+list_cc=$list_mesa_devel
 fi
 
 # Module xkeyboard-config goes in a subdir of the xorg "data" section
-- 
2.11.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH util-modular] release.sh: remove workaround for early Mesa versions

2018-02-23 Thread Emil Velikov 
From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 release.sh | 14 --
 1 file changed, 14 deletions(-)

diff --git a/release.sh b/release.sh
index ff89d2e..99bd0c3 100755
--- a/release.sh
+++ b/release.sh
@@ -584,24 +584,10 @@ process_module() {
 list_cc=$list_dri_devel
 elif [ x"$section" = xmesa ]; then
 host_current=$host_mesa
-mesa_version=`echo $pkg_version | sed 's:-rc.*::'`
 section_path=archive
 srv_path="/srv/$host_current/www/$section_path"
 list_to=$list_mesa_announce
 list_cc=$list_mesa_devel
-
-# Prior to 17.0.x Mesa uses separate folder for each release
-if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
-section_path=$section_path/$mesa_version
-srv_path="/srv/$host_current/www/$section_path"
-echo "Info: creating mesa directory on web server:"
-ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
-if [ $? -ne 0 ]; then
-echo "Error: cannot create the path \"$srv_path\" on the web 
server."
-cd $top_src
-return 1
-fi
-fi
 fi
 
 # Module xkeyboard-config goes in a subdir of the xorg "data" section
-- 
2.16.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH util/modular] release.sh: Add support for mesa-demos

2018-02-23 Thread Emil Velikov 
On 23 February 2018 at 09:40, Andreas Boll  wrote:
> Signed-off-by: Andreas Boll 
> ---
>  release.sh | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/release.sh b/release.sh
> index ff89d2e..2045197 100755
> --- a/release.sh
> +++ b/release.sh
> @@ -264,8 +264,10 @@ get_section() {
> if [ $? -ne 0 ]; then
> echo "Error: unable to extract section from $module_url second 
> field."
> return 1
> -   elif [ x"$section" != xdrm ] && [ x"$section" != xmesa ]; then
> -   echo "Error: section $section is not supported, only libdrm and 
> mesa are."
> +   elif [ x"$section" != xdrm ] &&
> +[ x"$section" != xmesa ] &&
> +[ x"$section" != xdemos ]; then
> +   echo "Error: section $section is not supported, only libdrm, mesa 
> and demos are."
> return 1
> fi
>  fi
> @@ -582,7 +584,8 @@ process_module() {
>  section_path=libdrm
>  srv_path="/srv/$host_current/www/$section_path"
>  list_cc=$list_dri_devel
> -elif [ x"$section" = xmesa ]; then
> +elif [ x"$section" = xmesa ] ||
> + [ x"$section" = xdemos ]; then
>  host_current=$host_mesa
>  mesa_version=`echo $pkg_version | sed 's:-rc.*::'`
>  section_path=archive
> @@ -590,16 +593,23 @@ process_module() {
>  list_to=$list_mesa_announce
>  list_cc=$list_mesa_devel
>
> -# Prior to 17.0.x Mesa uses separate folder for each release
> -if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
> -section_path=$section_path/$mesa_version
> +if [ x"$section" = xdemos ]; then
> +section_path=$section_path/$section
>  srv_path="/srv/$host_current/www/$section_path"
Let's keep demos as a separate if statement. As-is it gets a bit fiddly to read.

> -echo "Info: creating mesa directory on web server:"
> -ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
> -if [ $? -ne 0 ]; then
> -echo "Error: cannot create the path \"$srv_path\" on the web 
> server."
> -cd $top_src
> -return 1
> +fi
> +
> +# Prior to 17.0.x Mesa uses separate folder for each release
> +if [ x"$section" = xmesa ]; then
> +if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
> +section_path=$section_path/$mesa_version
> +srv_path="/srv/$host_current/www/$section_path"
> +echo "Info: creating mesa directory on web server:"
> +ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
> +if [ $? -ne 0 ]; then
> +echo "Error: cannot create the path \"$srv_path\" on the 
> web server."
> +cd $top_src
> +return 1
> +fi
Pretty sure this section can go now. I'll send a patch in a second.

-Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] render: Fix default picture format initialization

2018-02-23 Thread Michel Dänzer 
On 2018-02-22 10:53 PM, Adam Jackson wrote:
> "depth" for a picture format is the sum of bits of a/r/g/b, and not x.
> The default format list was creating an x8r8g8b8 format at depth 32,
> which is wrong. Likewise, servers supporting depth 30 would get an
> x8r8g8b8 format at depth 30, which is nonsense.

Actually, the former isn't wrong, and the latter might not be either, I
think. These are the constraints:

* The sizes of a/x+r+g+b must equal bpp
* The sizes of a+r+g+b must be <= depth (or == ?)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH util/modular] release.sh: Add support for mesa-demos

2018-02-23 Thread Andreas Boll 
Signed-off-by: Andreas Boll 
---
 release.sh | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/release.sh b/release.sh
index ff89d2e..2045197 100755
--- a/release.sh
+++ b/release.sh
@@ -264,8 +264,10 @@ get_section() {
if [ $? -ne 0 ]; then
echo "Error: unable to extract section from $module_url second 
field."
return 1
-   elif [ x"$section" != xdrm ] && [ x"$section" != xmesa ]; then
-   echo "Error: section $section is not supported, only libdrm and 
mesa are."
+   elif [ x"$section" != xdrm ] &&
+[ x"$section" != xmesa ] &&
+[ x"$section" != xdemos ]; then
+   echo "Error: section $section is not supported, only libdrm, mesa 
and demos are."
return 1
fi
 fi
@@ -582,7 +584,8 @@ process_module() {
 section_path=libdrm
 srv_path="/srv/$host_current/www/$section_path"
 list_cc=$list_dri_devel
-elif [ x"$section" = xmesa ]; then
+elif [ x"$section" = xmesa ] ||
+ [ x"$section" = xdemos ]; then
 host_current=$host_mesa
 mesa_version=`echo $pkg_version | sed 's:-rc.*::'`
 section_path=archive
@@ -590,16 +593,23 @@ process_module() {
 list_to=$list_mesa_announce
 list_cc=$list_mesa_devel
 
-# Prior to 17.0.x Mesa uses separate folder for each release
-if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
-section_path=$section_path/$mesa_version
+if [ x"$section" = xdemos ]; then
+section_path=$section_path/$section
 srv_path="/srv/$host_current/www/$section_path"
-echo "Info: creating mesa directory on web server:"
-ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
-if [ $? -ne 0 ]; then
-echo "Error: cannot create the path \"$srv_path\" on the web 
server."
-cd $top_src
-return 1
+fi
+
+# Prior to 17.0.x Mesa uses separate folder for each release
+if [ x"$section" = xmesa ]; then
+if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
+section_path=$section_path/$mesa_version
+srv_path="/srv/$host_current/www/$section_path"
+echo "Info: creating mesa directory on web server:"
+ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
+if [ $? -ne 0 ]; then
+echo "Error: cannot create the path \"$srv_path\" on the 
web server."
+cd $top_src
+return 1
+fi
 fi
 fi
 fi
-- 
2.16.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel