[Bug 94820] Nearest neighbor scaling?

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94820

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Michel Dänzer  ---
Looks like everything necessary for this is already available to clients via
the RandR extension.

*** This bug has been marked as a duplicate of bug 94816 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94815] Nearest neighbor scaling?

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94815

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Michel Dänzer  ---
Looks like everything necessary for this is already available to clients via
the RandR extension.

*** This bug has been marked as a duplicate of bug 94816 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: ARMSOC X11 plugin issues

2016-04-04 Thread Daniel Stone 
Hi,

On 4 April 2016 at 11:45, Siarhei Siamashka  wrote:
> This really must be something new, because I don't remember anything
> like this when skimming through the EULA back in 2013. Making the EULA
> even more restrictive seems to contradict with the promise of Jem
> Davies to provide legally redistributable mali binary drivers that
> we had in 2014:
>
> 
> http://anandtech.com/comments/8226/ask-the-experts-arm-fellow-jem-davies-answers-your-gpu-questions/409101
>
> Can anyone from ARM provide an update on this?

Getting fairly off-topic now, but the Midgard (6xx/7xx/8xx) drivers
are now redistributable.

Cheers,
Daniel
___
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: [xrandr v2] Select NearestNeighbour filtering for pixel exact scaling

2016-04-04 Thread Alex Deucher 
On Mon, Apr 4, 2016 at 4:34 PM, Chris Wilson  wrote:
> When using pixel-exact scaling from for example running a 3840x2160 monitor
> at 1920x1080 half-resolution upscaling using a bilinear filter
> introduces blur where none is expected.
>
> v2: Allow the user to specify what filter they want using --filter, but
> default to automatic selection.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=94816

Also:
https://bugs.freedesktop.org/show_bug.cgi?id=94820

Reviewed-by: Alex Deucher 

> Signed-off-by: Chris Wilson 
> ---
>  configure.ac |   2 +-
>  xrandr.c | 275 
> +--
>  2 files changed, 192 insertions(+), 85 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index dcf7c10..95cc1f6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -39,7 +39,7 @@ XORG_DEFAULT_OPTIONS
>  AC_CHECK_LIB(m,floor)
>
>  # Checks for pkg-config packages
> -PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17)
> +PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17 
> pixman-1)
>
>  AC_CONFIG_FILES([
> Makefile
> diff --git a/xrandr.c b/xrandr.c
> index dcfdde0..5c3a326 100644
> --- a/xrandr.c
> +++ b/xrandr.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef HAVE_CONFIG_H
>  #include "config.h"
> @@ -135,6 +136,7 @@ usage(void)
> "  --scale x\n"
> "  --scale-from x\n"
> "  --transform \n"
> +   "  --filter auto,bilinear,nearest\n"
> "  --off\n"
> "  --crtc \n"
> "  --panning 
> x[++[/x++[]]]\n"
> @@ -285,6 +287,7 @@ typedef enum _changes {
>  changes_panning = (1 << 10),
>  changes_gamma = (1 << 11),
>  changes_primary = (1 << 12),
> +changes_filter = (1 << 13),
>  } changes_t;
>
>  typedef enum _name_kind {
> @@ -305,19 +308,24 @@ typedef struct {
>  typedef struct _crtc crtc_t;
>  typedef struct _output output_t;
>  typedef struct _transform transform_t;
> +typedef struct _filter filter_t;
>  typedef struct _umode  umode_t;
>  typedef struct _output_prop output_prop_t;
>  typedef struct _provider provider_t;
>  typedef struct _monitors monitors_t;
>  typedef struct _umonitor umonitor_t;
>
> -struct _transform {
> -XTransform transform;
> +struct _filter {
>  const char *filter;
>  intnparams;
>  XFixed *params;
>  };
>
> +
> +struct _transform {
> +XTransform transform;
> +};
> +
>  struct _crtc {
>  name_t crtc;
>  Bool   changing;
> @@ -331,6 +339,7 @@ struct _crtc {
>  output_t   **outputs;
>  intnoutput;
>  transform_tcurrent_transform, pending_transform;
> +filter_tcurrent_filter, pending_filter;
>  };
>
>  struct _output_prop {
> @@ -370,6 +379,7 @@ struct _output {
>  Bool   automatic;
>  intscale_from_w, scale_from_h;
>  transform_ttransform;
> +filter_tfilter;
>
>  struct {
> float red;
> @@ -707,19 +717,29 @@ init_transform (transform_t *transform)
>  memset (>transform, '\0', sizeof (transform->transform));
>  for (x = 0; x < 3; x++)
> transform->transform.matrix[x][x] = XDoubleToFixed (1.0);
> -transform->filter = "";
> -transform->nparams = 0;
> -transform->params = NULL;
> +}
> +
> +static void
> +init_filter (filter_t *filter)
> +{
> +filter->filter = "";
> +filter->nparams = 0;
> +filter->params = NULL;
>  }
>
>  static void
>  set_transform (transform_t  *dest,
> -  XTransform   *transform,
> -  const char   *filter,
> -  XFixed   *params,
> -  int  nparams)
> +  XTransform   *transform)
>  {
>  dest->transform = *transform;
> +}
> +
> +static void
> +set_filter (filter_t*dest,
> +   const char  *filter,
> +   XFixed  *params,
> +   int  nparams)
> +{
>  /* note: this string is leaked */
>  dest->filter = strdup (filter);
>  dest->nparams = nparams;
> @@ -728,10 +748,25 @@ set_transform (transform_t  *dest,
>  }
>
>  static void
> +auto_filter (output_t *output)
> +{
> +if ((output->changes & changes_filter) == 0) {
> +init_filter (>filter);
> +output->filter.filter = "auto";
> +output->changes |= changes_filter;
> +}
> +}
> +
> +static void
>  copy_transform (transform_t *dest, transform_t *src)
>  {
> -set_transform (dest, >transform,
> -  src->filter, src->params, src->nparams);
> +set_transform (dest, >transform);
> +}
> +
> +static void
> +copy_filter (filter_t *dest, filter_t *src)
> +{
> +set_filter(dest, src->filter, src->params, src->nparams);
>  }
>
>  static Bool
> @@ -739,6 +774,12 @@ equal_transform

[xrandr v2] Select NearestNeighbour filtering for pixel exact scaling

2016-04-04 Thread Chris Wilson 
When using pixel-exact scaling from for example running a 3840x2160 monitor
at 1920x1080 half-resolution upscaling using a bilinear filter
introduces blur where none is expected.

v2: Allow the user to specify what filter they want using --filter, but
default to automatic selection.

References: https://bugs.freedesktop.org/show_bug.cgi?id=94816
Signed-off-by: Chris Wilson 
---
 configure.ac |   2 +-
 xrandr.c | 275 +--
 2 files changed, 192 insertions(+), 85 deletions(-)

diff --git a/configure.ac b/configure.ac
index dcf7c10..95cc1f6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,7 +39,7 @@ XORG_DEFAULT_OPTIONS
 AC_CHECK_LIB(m,floor)
 
 # Checks for pkg-config packages
-PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17)
+PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17 pixman-1)
 
 AC_CONFIG_FILES([
Makefile
diff --git a/xrandr.c b/xrandr.c
index dcfdde0..5c3a326 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
@@ -135,6 +136,7 @@ usage(void)
"  --scale x\n"
"  --scale-from x\n"
"  --transform \n"
+   "  --filter auto,bilinear,nearest\n"
"  --off\n"
"  --crtc \n"
"  --panning 
x[++[/x++[]]]\n"
@@ -285,6 +287,7 @@ typedef enum _changes {
 changes_panning = (1 << 10),
 changes_gamma = (1 << 11),
 changes_primary = (1 << 12),
+changes_filter = (1 << 13),
 } changes_t;
 
 typedef enum _name_kind {
@@ -305,19 +308,24 @@ typedef struct {
 typedef struct _crtc crtc_t;
 typedef struct _output output_t;
 typedef struct _transform transform_t;
+typedef struct _filter filter_t;
 typedef struct _umode  umode_t;
 typedef struct _output_prop output_prop_t;
 typedef struct _provider provider_t;
 typedef struct _monitors monitors_t;
 typedef struct _umonitor umonitor_t;
 
-struct _transform {
-XTransform transform;
+struct _filter {
 const char *filter;
 intnparams;
 XFixed *params;
 };
 
+
+struct _transform {
+XTransform transform;
+};
+
 struct _crtc {
 name_t crtc;
 Bool   changing;
@@ -331,6 +339,7 @@ struct _crtc {
 output_t   **outputs;
 intnoutput;
 transform_tcurrent_transform, pending_transform;
+filter_tcurrent_filter, pending_filter;
 };
 
 struct _output_prop {
@@ -370,6 +379,7 @@ struct _output {
 Bool   automatic;
 intscale_from_w, scale_from_h;
 transform_ttransform;
+filter_tfilter;
 
 struct {
float red;
@@ -707,19 +717,29 @@ init_transform (transform_t *transform)
 memset (>transform, '\0', sizeof (transform->transform));
 for (x = 0; x < 3; x++)
transform->transform.matrix[x][x] = XDoubleToFixed (1.0);
-transform->filter = "";
-transform->nparams = 0;
-transform->params = NULL;
+}
+
+static void
+init_filter (filter_t *filter)
+{
+filter->filter = "";
+filter->nparams = 0;
+filter->params = NULL;
 }
 
 static void
 set_transform (transform_t  *dest,
-  XTransform   *transform,
-  const char   *filter,
-  XFixed   *params,
-  int  nparams)
+  XTransform   *transform)
 {
 dest->transform = *transform;
+}
+
+static void
+set_filter (filter_t*dest,
+   const char  *filter,
+   XFixed  *params,
+   int  nparams)
+{
 /* note: this string is leaked */
 dest->filter = strdup (filter);
 dest->nparams = nparams;
@@ -728,10 +748,25 @@ set_transform (transform_t  *dest,
 }
 
 static void
+auto_filter (output_t *output)
+{
+if ((output->changes & changes_filter) == 0) {
+init_filter (>filter);
+output->filter.filter = "auto";
+output->changes |= changes_filter;
+}
+}
+
+static void
 copy_transform (transform_t *dest, transform_t *src)
 {
-set_transform (dest, >transform,
-  src->filter, src->params, src->nparams);
+set_transform (dest, >transform);
+}
+
+static void
+copy_filter (filter_t *dest, filter_t *src)
+{
+set_filter(dest, src->filter, src->params, src->nparams);
 }
 
 static Bool
@@ -739,6 +774,12 @@ equal_transform (transform_t *a, transform_t *b)
 {
 if (memcmp (>transform, >transform, sizeof (XTransform)) != 0)
return False;
+return True;
+}
+
+static Bool
+equal_filter (filter_t *a, filter_t *b)
+{
 if (strcmp (a->filter, b->filter) != 0)
return False;
 if (a->nparams != b->nparams)
@@ -1157,6 +1198,40 @@ set_gamma_info(output_t *output)
 XRRFreeGamma(crtc_gamma);
 }
 
+static Bool
+pixel_exact(const XTransform *t)
+{
+struct pixman_transform inv;
+
+if

Re: [PATCH xserver v2] xfree86: Immediately handle failure to set HW cursor

2016-04-04 Thread Michael Thayer 

Hello,

Please excuse the top posting.  Tested this in a dual-head non-mirrored 
virtual machine and hit the following problem: xf86CursorSetCursor() in 
hw/xfree86/ramdac/xf86Cursor.c calls xf86SetCursor() which fails because 
the cursor is not visible on one of the two screens, and falls back to 
software cursor rendering as a result.  Perhaps xf86_crtc_show_cursor() 
should return TRUE if crtc->cursor_shown is FALSE?


I'm afraid I will be away from the computer again for a few weeks, so it 
will be a while before I can test again.


Regards,

Michael

On 30.03.2016 08:41, Alexandre Courbot wrote:

There is currently no reliable way to report failure to set a HW
cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
ioctl fails (which currently happens at least with modesetting on Tegra
for format incompatibility reasons).

As failures are currently handled by setting the HW cursor size to
(0,0), the fallback to SW cursor will not happen until the next time the
cursor changes and xf86CursorSetCursor() is called again. In the
meantime, the cursor will be invisible to the user.

This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
_xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
This allows to propagate errors up to xf86CursorSetCursor(), which can
then fall back to using the SW cursor immediately.

Signed-off-by: Alexandre Courbot 
---
Changes since v1:
- Keep the old hooks unchanged to preserve compatibility

  hw/xfree86/drivers/modesetting/drmmode_display.c | 15 +++-
  hw/xfree86/modes/xf86Crtc.h  |  4 
  hw/xfree86/modes/xf86Cursors.c   | 30 +---
  hw/xfree86/ramdac/xf86Cursor.h   |  1 +
  hw/xfree86/ramdac/xf86HWCurs.c   | 18 ++
  5 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index f573a27f4985..28d663c3d22e 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -532,7 +532,7 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int x, int y)
  drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x, y);
  }

-static void
+static Bool
  drmmode_set_cursor(xf86CrtcPtr crtc)
  {
  drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
@@ -551,7 +551,7 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
handle, ms->cursor_width, ms->cursor_height,
cursor->bits->xhot, cursor->bits->yhot);
  if (!ret)
-return;
+return TRUE;
  if (ret == -EINVAL)
  use_set_cursor2 = FALSE;
  }
@@ -566,7 +566,10 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
  cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
  drmmode_crtc->drmmode->sw_cursor = TRUE;
  /* fallback to swcursor */
+   return FALSE;
  }
+
+return TRUE;
  }

  static void
@@ -599,12 +602,12 @@ drmmode_hide_cursor(xf86CrtcPtr crtc)
   ms->cursor_width, ms->cursor_height);
  }

-static void
-drmmode_show_cursor(xf86CrtcPtr crtc)
+static Bool
+drmmode_show_cursor_check(xf86CrtcPtr crtc)
  {
  drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
  drmmode_crtc->cursor_up = TRUE;
-drmmode_set_cursor(crtc);
+return drmmode_set_cursor(crtc);
  }

  static void
@@ -844,7 +847,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
  .set_mode_major = drmmode_set_mode_major,
  .set_cursor_colors = drmmode_set_cursor_colors,
  .set_cursor_position = drmmode_set_cursor_position,
-.show_cursor = drmmode_show_cursor,
+.show_cursor_check = drmmode_show_cursor_check,
  .hide_cursor = drmmode_hide_cursor,
  .load_cursor_argb = drmmode_load_cursor_argb,

diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 8b0160845a02..4bc4d6fc78fd 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -187,6 +187,8 @@ typedef struct _xf86CrtcFuncs {
   */
  void
   (*show_cursor) (xf86CrtcPtr crtc);
+Bool
+ (*show_cursor_check) (xf86CrtcPtr crtc);

  /**
   * Hide cursor
@@ -982,6 +984,8 @@ extern _X_EXPORT void
   */
  extern _X_EXPORT void
   xf86_show_cursors(ScrnInfoPtr scrn);
+extern _X_EXPORT Bool
+ xf86_show_cursors_check(ScrnInfoPtr scrn);

  /**
   * Called by the driver to turn cursors off
diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 5df1ab73a37e..ae581001c222 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -333,17 +333,23 @@ xf86_hide_cursors(ScrnInfoPtr scrn)
  }
  }

-static void
+static Bool
  xf86_crtc_show_cursor(xf86CrtcPtr crtc)
  {
  if (!crtc->cursor_shown && crtc->cursor_in_range) {
-

Re: [PATCH glx] glx: avoid memory leak when using indirect rendering

2016-04-04 Thread Guilherme Melo 
Updated patch with some other places with a potential leak.


On Thu, Mar 24, 2016 at 3:52 AM Guilherme Melo  wrote:

> I've finally got some time to rewrite this patch and now the solution
> makes more sense.
> I'm sending as an attachment.
> I also have some tests on a github repository to check this bug. I don't
> know if it is ok to post the link here though.
>
>
> Guilherme
>
> On Tue, Dec 8, 2015 at 4:48 PM Guilherme Melo  wrote:
>
>>
>> This should be lastGLContext->loseCurrent(lastGLContext) I think. cx
>>
>>
>> Yes, you are right. It seems the right thing to do, but actually this
>> should be done every place where lastGLContext is set, right?
>> It seems to me that every place where lastGLContext is set is a potential
>> leak.
>>
>> While you're at it, it'd be nice to move that big block comment into the
>>> commit message
>>
>>
>> I'll do that, thanks.
>>
>>
>> Guilherme
>>
>>
>>
>> 2015-12-08 14:44 GMT-02:00 Adam Jackson :
>>
>>> On Fri, 2015-12-04 at 14:16 -0200, Guilherme Quentel Melo wrote:
>>>
>>> > diff --git a/glx/glxext.c b/glx/glxext.c
>>> > index e41b881..16b8039 100644
>>> > --- a/glx/glxext.c
>>> > +++ b/glx/glxext.c
>>> > @@ -469,6 +469,24 @@ __glXForceCurrent(__GLXclientState * cl,
>>> GLXContextTag tag, int *error)
>>> >
>>> >  /* Make this context the current one for the GL. */
>>> >  if (!cx->isDirect) {
>>> > +/*
>>> > + ** If we are forcing the context it means someone already
>>> called makeCurrent before. If
>>> > + ** we just call makeCurrent again, the drawable of this
>>> context will be left with one
>>> > + ** refcount more forever and will never be freed.
>>> > + **
>>> > + ** This situation happens when there are many X clients
>>> using GL:
>>> > + **
>>> > + ** 1 - client1: calls glXMakeCurrent
>>> > + **
>>> > + ** 2 - client2: calls glXMakeCurrent
>>> > + ** This is the first context switch for this client. So
>>> old_context_tag=0
>>> > + **
>>> > + ** 3 - client1: calls glXRender
>>> > + ** For the client, its context is already current.
>>> > + ** For the server side lastGLContext points to client2's
>>> context. So the execution path
>>> > + ** will get here.
>>> > + */
>>> > +(*cx->loseCurrent) (cx);
>>>
>>> This should be lastGLContext->loseCurrent(lastGLContext) I think. cx
>>> here is the current context from client2's perspective, you want to
>>> release client1's context.
>>>
>>> While you're at it, it'd be nice to move that big block comment into
>>> the commit message and just note /* drop previous client's context */
>>> or similar in the code.
>>>
>>> - ajax
>>
>>
>>
From 3dc360e2998392d62af7c8272819e2c91350d183 Mon Sep 17 00:00:00 2001
From: Guilherme Quentel Melo 
Date: Thu, 24 Mar 2016 03:13:30 -0300
Subject: [PATCH] glx: avoid memory leak when using indirect rendering

When multiple processes are using GL with indirect rendering a race
condition can make drawables refcount never drop to zero.

This situation could happen when there are many X clients using indirect
GLX:

1 - client1: calls glXMakeCurrent

2 - client2: calls glXMakeCurrent
This is the first context switch for this client. So old_context_tag=0

3 - client1: calls glXRender
For the client, its context is already current.
For the server side lastGLContext points to client2's context.

Signed-off-by: Guilherme Quentel Melo 
---
 glx/glxcmds.c | 20 ++--
 glx/glxext.c  | 18 +++---
 2 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 561faeb..ffc6e9b 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -188,6 +188,11 @@ validGlxDrawable(ClientPtr client, XID id, int type, int access_mode,
 void
 __glXContextDestroy(__GLXcontext * context)
 {
+__GLXcontext *lastglxc;
+if (lastGLContext != NULL && lastGLContext != context) {
+lastglxc = (__GLXcontext*)lastGLContext;
+(*lastglxc->loseCurrent) (lastglxc);
+}
 lastGLContext = NULL;
 }
 
@@ -563,7 +568,7 @@ DoMakeCurrent(__GLXclientState * cl,
 {
 ClientPtr client = cl->client;
 xGLXMakeCurrentReply reply;
-__GLXcontext *glxc, *prevglxc;
+__GLXcontext *glxc, *prevglxc, *lastglxc = NULL;
 __GLXdrawable *drawPriv = NULL;
 __GLXdrawable *readPriv = NULL;
 int error;
@@ -659,13 +664,24 @@ DoMakeCurrent(__GLXclientState * cl,
 if (!(*prevglxc->loseCurrent) (prevglxc)) {
 return __glXError(GLXBadContext);
 }
-lastGLContext = NULL;
 if (!prevglxc->isDirect) {
 prevglxc->drawPriv = NULL;
 prevglxc->readPriv = NULL;
 }
 }
 
+/*
+ ** lastGLContext may be different than prevglxc, so we need lose it to
+ ** avoid a memory leak
+ */
+if (lastGLContext != NULL) {
+

[ANNOUNCE] xorg-server 1.18.3

2016-04-04 Thread Adam Jackson 
A few fixes relative to 1.18.2, including one fairly important
performance fix to the Present extension. Thanks to all for fixes and
testing.

Adam Jackson (2):
  vfb: Re-add LD_EXPORT_SYMBOLS_FLAG to LDFLAGS
  xserver 1.18.3

Chris Wilson (1):
  Xext/vidmode: Reduce verbosity of GetModeLine debug messages

Dave Airlie (1):
  glamor: swizzle RED to 0 for alpha textures

Michel Dänzer (2):
  present: Only requeue for next MSC after flip failure
  xfree86/modes: Make sure the HW cursor is hidden when it should be

Olivier Fourdan (2):
  xwayland: do not include frequency in mode name
  xwayland: Pretend we support viewport in vidmode

Sonny Jiang (1):
  DRI2: add Polaris PCI IDs

git tag: xorg-server-1.18.3

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2
MD5:  043d720bf2472a65bb8f0daa97f83dfa  xorg-server-1.18.3.tar.bz2
SHA1: b3d8818bb3e1deeeb8f02d741c1223a72182e63c  xorg-server-1.18.3.tar.bz2
SHA256: ea739c22517cdbe2b5f7c0a5fd05fe8a10ac0629003e71c0c7862f4bb60142cd  
xorg-server-1.18.3.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz
MD5:  f077e27a91bc9c37e3b78958454c9dd2  xorg-server-1.18.3.tar.gz
SHA1: 21fdf20305d01bf0123ed0a4f1a30d079134  xorg-server-1.18.3.tar.gz
SHA256: 9b872f946b912f11a0ffc911d936764fce604ee4ac65ee1f131b78b3e89ede26  
xorg-server-1.18.3.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz.sig

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xorg-server 1.18.3

2016-04-04 Thread Adam Jackson 
A few fixes relative to 1.18.2, including one fairly important
performance fix to the Present extension. Thanks to all for fixes and
testing.

Adam Jackson (2):
  vfb: Re-add LD_EXPORT_SYMBOLS_FLAG to LDFLAGS
  xserver 1.18.3

Chris Wilson (1):
  Xext/vidmode: Reduce verbosity of GetModeLine debug messages

Dave Airlie (1):
  glamor: swizzle RED to 0 for alpha textures

Michel Dänzer (2):
  present: Only requeue for next MSC after flip failure
  xfree86/modes: Make sure the HW cursor is hidden when it should be

Olivier Fourdan (2):
  xwayland: do not include frequency in mode name
  xwayland: Pretend we support viewport in vidmode

Sonny Jiang (1):
  DRI2: add Polaris PCI IDs

git tag: xorg-server-1.18.3

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2
MD5:  043d720bf2472a65bb8f0daa97f83dfa  xorg-server-1.18.3.tar.bz2
SHA1: b3d8818bb3e1deeeb8f02d741c1223a72182e63c  xorg-server-1.18.3.tar.bz2
SHA256: ea739c22517cdbe2b5f7c0a5fd05fe8a10ac0629003e71c0c7862f4bb60142cd  
xorg-server-1.18.3.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz
MD5:  f077e27a91bc9c37e3b78958454c9dd2  xorg-server-1.18.3.tar.gz
SHA1: 21fdf20305d01bf0123ed0a4f1a30d079134  xorg-server-1.18.3.tar.gz
SHA256: 9b872f946b912f11a0ffc911d936764fce604ee4ac65ee1f131b78b3e89ede26  
xorg-server-1.18.3.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz.sig

- ajax


signature.asc
Description: This is a digitally signed message part
___
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

[ANNOUNCE] xorg-server 1.18.3

2016-04-04 Thread Adam Jackson 
A few fixes relative to 1.18.2, including one fairly important
performance fix to the Present extension. Thanks to all for fixes and
testing.

Adam Jackson (2):
  vfb: Re-add LD_EXPORT_SYMBOLS_FLAG to LDFLAGS
  xserver 1.18.3

Chris Wilson (1):
  Xext/vidmode: Reduce verbosity of GetModeLine debug messages

Dave Airlie (1):
  glamor: swizzle RED to 0 for alpha textures

Michel Dänzer (2):
  present: Only requeue for next MSC after flip failure
  xfree86/modes: Make sure the HW cursor is hidden when it should be

Olivier Fourdan (2):
  xwayland: do not include frequency in mode name
  xwayland: Pretend we support viewport in vidmode

Sonny Jiang (1):
  DRI2: add Polaris PCI IDs

git tag: xorg-server-1.18.3

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2
MD5:  043d720bf2472a65bb8f0daa97f83dfa  xorg-server-1.18.3.tar.bz2
SHA1: b3d8818bb3e1deeeb8f02d741c1223a72182e63c  xorg-server-1.18.3.tar.bz2
SHA256: ea739c22517cdbe2b5f7c0a5fd05fe8a10ac0629003e71c0c7862f4bb60142cd  
xorg-server-1.18.3.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz
MD5:  f077e27a91bc9c37e3b78958454c9dd2  xorg-server-1.18.3.tar.gz
SHA1: 21fdf20305d01bf0123ed0a4f1a30d079134  xorg-server-1.18.3.tar.gz
SHA256: 9b872f946b912f11a0ffc911d936764fce604ee4ac65ee1f131b78b3e89ede26  
xorg-server-1.18.3.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz.sig

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH xserver 0/7] --disable-iglx

2016-04-04 Thread Guilherme Melo 
> I don't intend to delete the IGLX code. My primary motivation for this
> series is to more clearly define the boundary between the code that
> enables direct contexts and the indirect renderer

Right then, it would be nice to have a clearer separation.

> If that need is because the customers of this app need it to work on
RHEL5, then by
> using indirect GLX to the host you're not actually testing that it
> works with a RHEL5 X stack.

Yes, that is our case. We are aware that it is not a complete RHEL5 test
(different linux kernel, X server, graphics drivers), but OpenGL is only a
small
part of these tests. And using a chroot we can have a uniform development
environment regardless of the host distribution or if it is a physical or
virtual machine.
So it still worth for us using IGLX, even though it does not really mimics
a real RHEL5

Anyway my concern was more about IGLX being completed removed in the near
future.
If that is not the case I would be glad to continue contributing patches to
fix the issues
we found.


Guilherme

On Mon, Apr 4, 2016 at 3:33 PM Adam Jackson  wrote:

> On Fri, 2016-04-01 at 17:53 +, Guilherme Melo wrote:
> > Hi Adam,
> >
> > So it seems that the direction that is being taken is to eventually
> > drop indirect GLX.
> > In my company we make heavy usage of indirect contexts for running
> > GUI application tests.
> >
> > The reason why we use IGLX is that we run inside a CentOS/RedHat5
> > chroot. We need to support this distro but don't want to have it as
> > the host because it is too painful to work with it.
> >
> > With that setup I found two bugs with IGLX. One fix I submitted on ht
> > tps://patchwork.freedesktop.org/patch/78162/ and the other I did not
> > tested enough but can be found at https://github.com/gqmelo/xserver-
> > xorg/tree/gqmelo-1.17.2-custom
> >
> > So if this is really the direction that it is being taken, this
> > feature will be probably be much harder to use in the future. Then
> > would you have any other suggestion how to to run OpenGL applications
> > inside an old chroot?
> >
> > Also, is it worth that I continue submitting these patches?
>
> Yes, it is worthwhile. I'll take a look at integrating your patches,
> thanks for the reminder.
>
> I don't intend to delete the IGLX code. My primary motivation for this
> series is to more clearly define the boundary between the code that
> enables direct contexts and the indirect renderer, and the reason I
> want that is, ideally, to wire up glamor as the GLX provider and
> (potentially) be independent of Mesa internals.
>
> I'm a little confused about your question about RHEL5 chroots though,
> particularly the "need to support this distro" part. If that need is
> because the customers of this app need it to work on RHEL5, then by
> using indirect GLX to the host you're not actually testing that it
> works with a RHEL5 X stack. If that need is because you are the
> customer of the app and it's only certified on RHEL5, my instinct would
> be to ignore the certification, install it on a RHEL6 or RHEL7 host,
> resolve any functionality issues that happen to arise [1]. Which should
> be few, to the extent that it's an X11 app and not sensitive to, say,
> the init system in use.
>
> [1] - And maybe ask my vendor to certify on an OS that's less than nine
> years old.
>
> - 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 0/7] --disable-iglx

2016-04-04 Thread Adam Jackson 
On Fri, 2016-04-01 at 17:53 +, Guilherme Melo wrote:
> Hi Adam,
> 
> So it seems that the direction that is being taken is to eventually
> drop indirect GLX.
> In my company we make heavy usage of indirect contexts for running
> GUI application tests.
> 
> The reason why we use IGLX is that we run inside a CentOS/RedHat5
> chroot. We need to support this distro but don't want to have it as
> the host because it is too painful to work with it.
> 
> With that setup I found two bugs with IGLX. One fix I submitted on ht
> tps://patchwork.freedesktop.org/patch/78162/ and the other I did not
> tested enough but can be found at https://github.com/gqmelo/xserver-
> xorg/tree/gqmelo-1.17.2-custom
> 
> So if this is really the direction that it is being taken, this
> feature will be probably be much harder to use in the future. Then
> would you have any other suggestion how to to run OpenGL applications
> inside an old chroot?
> 
> Also, is it worth that I continue submitting these patches?

Yes, it is worthwhile. I'll take a look at integrating your patches,
thanks for the reminder.

I don't intend to delete the IGLX code. My primary motivation for this
series is to more clearly define the boundary between the code that
enables direct contexts and the indirect renderer, and the reason I
want that is, ideally, to wire up glamor as the GLX provider and
(potentially) be independent of Mesa internals.

I'm a little confused about your question about RHEL5 chroots though,
particularly the "need to support this distro" part. If that need is
because the customers of this app need it to work on RHEL5, then by
using indirect GLX to the host you're not actually testing that it
works with a RHEL5 X stack. If that need is because you are the
customer of the app and it's only certified on RHEL5, my instinct would
be to ignore the certification, install it on a RHEL6 or RHEL7 host,
resolve any functionality issues that happen to arise [1]. Which should
be few, to the extent that it's an X11 app and not sensitive to, say,
the init system in use.

[1] - And maybe ask my vendor to certify on an OS that's less than nine
years old.

- 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: [xrandr] Select NearestNeighbour filtering for pixel exact scaling

2016-04-04 Thread Chris Wilson 
On Mon, Apr 04, 2016 at 05:11:11PM +0100, Chris Wilson wrote:
> When using pixel-exact scaling from for example running a 3840x2160 monitor
> at 1920x1080 half-resolution upscaling using a bilinear filter
> introduces blur where none is expected.

Missed --scale, this only changes --scale-from.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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

[xrandr] Select NearestNeighbour filtering for pixel exact scaling

2016-04-04 Thread Chris Wilson 
When using pixel-exact scaling from for example running a 3840x2160 monitor
at 1920x1080 half-resolution upscaling using a bilinear filter
introduces blur where none is expected.

References: https://bugs.freedesktop.org/show_bug.cgi?id=94816
Signed-off-by: Chris Wilson 
---
 xrandr.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xrandr.c b/xrandr.c
index dcfdde0..b6b208c 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -1292,6 +1292,7 @@ set_output_info (output_t *output, RROutput xid, 
XRROutputInfo *output_info)
/* for --scale-from, figure out the mode size and compute the transform
 * for the target framebuffer area */
if (output->scale_from_w > 0 && output->mode_info) {
+   XTransform *t = >transform.transform;
double sx = (double)output->scale_from_w /
output->mode_info->width;
double sy = (double)output->scale_from_h /
@@ -1300,10 +1301,10 @@ set_output_info (output_t *output, RROutput xid, 
XRROutputInfo *output_info)
printf("scaling %s by %lfx%lf\n", output->output.string, sx,
   sy);
init_transform (>transform);
-   output->transform.transform.matrix[0][0] = XDoubleToFixed (sx);
-   output->transform.transform.matrix[1][1] = XDoubleToFixed (sy);
-   output->transform.transform.matrix[2][2] = XDoubleToFixed (1.0);
-   if (sx != 1 || sy != 1)
+   t->matrix[0][0] = XDoubleToFixed (sx);
+   t->matrix[1][1] = XDoubleToFixed (sy);
+   t->matrix[2][2] = XDoubleToFixed (1.0);
+   if ((t->matrix[0][0] | t->matrix[1][1]) & 0x)
output->transform.filter = "bilinear";
else
output->transform.filter = "nearest";
-- 
2.8.0.rc3

___
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

[Bug 94820] New: Nearest neighbor scaling?

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94820

Bug ID: 94820
   Summary: Nearest neighbor scaling?
   Product: xorg
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: Driver/Radeon
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: nw9165-3...@yahoo.com
QA Contact: xorg-t...@lists.x.org

Hello,

would it be possible that you add a nearest-neighbor scaling mode to the
driver, so that one could display 1920x1080 natively on a 3840x2160 monitor or
1280x720 natively on a 2560x1440 monitor and so on (one pixel becomes four
pixels)?

There is some information on this topic over there:

https://forums.geforce.com/default/topic/844905/geforce-drivers/integer-scaling-mode/

Regards

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94815] New: Nearest neighbor scaling?

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94815

Bug ID: 94815
   Summary: Nearest neighbor scaling?
   Product: xorg
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: Driver/AMDgpu
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: nw9165-3...@yahoo.com
QA Contact: xorg-t...@lists.x.org

Hello,

would it be possible that you add a nearest-neighbor scaling mode to the
driver, so that one could display 1920x1080 natively on a 3840x2160 monitor or
1280x720 natively on a 2560x1440 monitor and so on (one pixel becomes four
pixels)?

There is some information on this topic over there:

https://forums.geforce.com/default/topic/844905/geforce-drivers/integer-scaling-mode/

Regards

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xf86-video-amdgpu] glamor: Force GPU rendering to/from pixmaps created via DRI3

2016-04-04 Thread Alex Deucher 
On Mon, Apr 4, 2016 at 5:30 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Fixes crash when running DRI3 clients with ShadowPrimary enabled.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94799
> Signed-off-by: Michel Dänzer 


Revewied-by: Alex Deucher 

> ---
>  src/amdgpu_dri3.c|  6 +-
>  src/amdgpu_glamor_wrappers.c | 11 ++-
>  2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/src/amdgpu_dri3.c b/src/amdgpu_dri3.c
> index c3042e7..0686599 100644
> --- a/src/amdgpu_dri3.c
> +++ b/src/amdgpu_dri3.c
> @@ -135,8 +135,12 @@ static PixmapPtr amdgpu_dri3_pixmap_from_fd(ScreenPtr 
> screen,
> if (AMDGPUPTR(xf86ScreenToScrn(screen))->use_glamor) {
> pixmap = glamor_pixmap_from_fd(screen, fd, width, height,
>stride, depth, bpp);
> -   if (pixmap)
> +   if (pixmap) {
> +   struct amdgpu_pixmap *priv = calloc(1, sizeof(*priv));
> +
> +   amdgpu_set_pixmap_private(pixmap, priv);
> return pixmap;
> +   }
> }
>  #endif
>
> diff --git a/src/amdgpu_glamor_wrappers.c b/src/amdgpu_glamor_wrappers.c
> index 6700851..35b6d7e 100644
> --- a/src/amdgpu_glamor_wrappers.c
> +++ b/src/amdgpu_glamor_wrappers.c
> @@ -148,10 +148,11 @@ amdgpu_glamor_finish_access_cpu(PixmapPtr pixmap)
>   */
>
>  static Bool
> -amdgpu_glamor_use_gpu(PixmapPtr pixmap)
> +amdgpu_glamor_use_gpu(PixmapPtr pixmap, struct amdgpu_pixmap *priv)
>  {
> return (pixmap->usage_hint &
> -   (AMDGPU_CREATE_PIXMAP_SCANOUT | AMDGPU_CREATE_PIXMAP_DRI2)) 
> != 0;
> +   (AMDGPU_CREATE_PIXMAP_SCANOUT | AMDGPU_CREATE_PIXMAP_DRI2)) 
> != 0 ||
> +   (priv && !priv->bo);
>  }
>
>  static Bool
> @@ -432,7 +433,7 @@ amdgpu_glamor_poly_fill_rect(DrawablePtr pDrawable, GCPtr 
> pGC,
> PixmapPtr pixmap = get_drawable_pixmap(pDrawable);
> struct amdgpu_pixmap *priv = amdgpu_get_pixmap_private(pixmap);
>
> -   if ((info->force_accel || amdgpu_glamor_use_gpu(pixmap)) &&
> +   if ((info->force_accel || amdgpu_glamor_use_gpu(pixmap, priv)) &&
> amdgpu_glamor_prepare_access_gpu(priv)) {
> info->glamor.SavedPolyFillRect(pDrawable, pGC, nrect, prect);
> amdgpu_glamor_finish_access_gpu_rw(info, priv);
> @@ -536,8 +537,8 @@ amdgpu_glamor_copy_area(DrawablePtr pSrcDrawable, 
> DrawablePtr pDstDrawable,
> struct amdgpu_pixmap *dst_priv = 
> amdgpu_get_pixmap_private(dst_pixmap);
> RegionPtr ret = NULL;
>
> -   if (amdgpu_glamor_use_gpu(dst_pixmap) ||
> -   amdgpu_glamor_use_gpu(src_pixmap)) {
> +   if (amdgpu_glamor_use_gpu(dst_pixmap, dst_priv) ||
> +   amdgpu_glamor_use_gpu(src_pixmap, src_priv)) {
> if (!amdgpu_glamor_prepare_access_gpu(dst_priv))
> goto fallback;
> if (src_priv != dst_priv &&
> --
> 2.8.0.rc3
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: ARMSOC X11 plugin issues

2016-04-04 Thread Daniel Drake 
On Mon, Apr 4, 2016 at 4:45 AM, Siarhei Siamashka
 wrote:
>> In our case, we don't really have any restrictions on the memory
>> resource locations, and I'm not aware of any particular weird
>> alignment constraints either.
>
> Yes, this problem can be solved by using malloc for all pixmaps, and
> only migrating them to CMA or any other special allocation method
> when needed. We encountered this back in 2013, when xf86-video-mali
> had exactly the same design issues as you see now with
> xf86-video-armsoc:
>
> http://ssvb.github.io/2013/02/01/new-xf86-video-sunxifb-ddx-driver.html
>
> As far as I know, Daniel Drake had some fixes for xf86-video-armsoc,
> but I have no idea which of the armsoc forks is the most up to date
> right now.

Yes, I have another approach:
https://github.com/endlessm/xf86-video-armsoc/commit/d7855656a82513d2e81d05bb690ecddabb2db1ca
(and then several follow up commits for corner cases)

Unfortunately it's all part of a significant fork based on an old
version of armsoc. Newer versions have some more fundamental problems.
I did send some patches and tried to start corresponding discussions
almost 2 years ago, but those emails are still unanswered.

Daniel
___
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: ARMSOC X11 plugin issues

2016-04-04 Thread Siarhei Siamashka 
Hello Maxime,

On Sat, 2 Apr 2016 15:58:37 +0200
Maxime Ripard  wrote:

> Hello David,
> 
> Thanks for your answer.
> 
> On Fri, Apr 01, 2016 at 06:57:07AM +, David Garbett wrote:
> > The main difference between modesetting and armsoc is that armsoc
> > supports DRI2, and modesetting doesn't. This is what allows the GLES
> > driver to render to X buffers.  
> 
> Yes, that's what I figured.
> 
> > DRI2 enables any application to pass any X pixmap into the GLES/EGL
> > driver, so all buffers need to be allocated from shareable memory.
> > That's not the case with modesetting - other than the main framebuffer,
> > other allocations (for pixmaps and windows) can just be local to the X
> > server, so don't allocate from the DRM driver.
> > 
> > I've not looked at your DRM driver proposal so I can't really say why it
> > can't cope with the additional allocations. Though I do notice in your
> > armsoc patch that you don't handle scanout buffers any differently. In
> > many systems scanout buffers are a more scarce resource (perhaps they
> > need to be contiguous, or meet certain alignment restrictions).  
> 
> We do agree on that. However, it looks like the arm soc driver does
> way much more allocations, and usually smaller ones, than modesetting
> that basically just allocates a buffer for its framebuffers and that's
> it.
> 
> If I was to guess, I'd say that it allocates buffers for applications
> (and possibly part of the applications window), that eventually
> depletes the CMA pool, even though the GPU is not used.
> 
> I'd expect the DRI buffers to be allocated from this pool, because of
> the reasons you pointed out, but I would also expect that the
> applications do not hit that pool, precisely because it's a scarce
> resource.
> 
> I'm possibly missing something though, or have broken expectations :)
> 
> In our case, we don't really have any restrictions on the memory
> resource locations, and I'm not aware of any particular weird
> alignment constraints either.

Yes, this problem can be solved by using malloc for all pixmaps, and
only migrating them to CMA or any other special allocation method
when needed. We encountered this back in 2013, when xf86-video-mali
had exactly the same design issues as you see now with
xf86-video-armsoc:

http://ssvb.github.io/2013/02/01/new-xf86-video-sunxifb-ddx-driver.html

As far as I know, Daniel Drake had some fixes for xf86-video-armsoc,
but I have no idea which of the armsoc forks is the most up to date
right now.

There are also a few tricks to ensure that the 2D performance
is not regressed in Xorg by integrating the mali drivers, and
also to get zero-copy tear-free OpenGL ES rendering in windows.
This all is now available in the xf86-video-fbturbo DDX (renamed
from xf86-video-sunxifb) if anyone is interested.

And I'm happy to know that you are working on the kernel side and
doing the conversion of the Allwinner's custom fbdev based kernel
interface into a more standard DRM/KMS interface. This had to be
done by somebody and it is better late than never.

> > > > Then, we noticed (using xfce4, on debian jessie) that the systray
> > > > icons were not displayed for some reason. There's also some game
> > > > (alex4 [4]), that starts, runs, but the window content remains black
> > > > (but it remains interactive, audio plays and if we take a screenshot,
> > > > the content is on the image, but the screen remains black).  
> 
> That's what concerns me the most though. We can always work around the
> memory allocations by playing cat and mouse and allocating a bigger
> pool (even though I'd really like to avoid that).
> 
> However, those glitches are kind of weird, and not really convenient :/

Well, the mali drivers EULA kind of warns that a problem-free experience
is not to be expected. And they deliver what is promised :-)

The EULA now has an extra clause in the "RESTRICTIONS ON USE OF THE
SOFTWARE" paragraph, which basically says that any benchmark results
or reports about quality issues are not allowed to be disclosed without
an explicit permission from ARM:


http://malideveloper.arm.com/resources/drivers/arm-mali-utgard-gpu-user-space-drivers/

This really must be something new, because I don't remember anything
like this when skimming through the EULA back in 2013. Making the EULA
even more restrictive seems to contradict with the promise of Jem
Davies to provide legally redistributable mali binary drivers that
we had in 2014:


http://anandtech.com/comments/8226/ask-the-experts-arm-fellow-jem-davies-answers-your-gpu-questions/409101

Can anyone from ARM provide an update on this?

-- 
Best regards,
Siarhei Siamashka
___
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

[Bug 94811] ATI radeon driver displays nothing or a client refused to switch message on hybrid graphics

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94811

--- Comment #3 from Saurav  ---
I have experienced this with version 7.6.1-3.20160215gitd41fccc of
xorg-x11-drv-ati on Fedora 23 and version 7.5.0+git20150819-0ubuntu1 of
xserver-xorg-video-ati on Ubuntu 15.10. I am unsure which generic version is
applicable to this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94811] ATI radeon driver displays nothing or a client refused to switch message on hybrid graphics

2016-04-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94811

Saurav  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |xorg-driver-ati@lists.x.org
   |.org|
 QA Contact||xorg-t...@lists.x.org
Product|DRI |xorg
  Component|DRM/Radeon  |Driver/Radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: Xorg software excellence recognized

2016-04-04 Thread Martin Peres 

On 02/04/16 02:53, Jamenson Ferreira Espindula de Almeida Melo wrote:

Jaboatão dos Guararapes, Pernambuco, Brazil, April 01, 2016.

Xorg software excellence recognized


I would like to congratulate the Xorg Software Development Team for the
excellent software.

I am using the twm and I am really satisfied.  You point the mouse to
focus a window, without select it.  You click the window to select it.
You can roll up and roll down the Firefox text region without select the
window, but just focusing it.   I think this is the correct approach.

Congratulations and go on!


Good one :D
___
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 xf86-video-amdgpu] glamor: Force GPU rendering to/from pixmaps created via DRI3

2016-04-04 Thread Michel Dänzer 
From: Michel Dänzer 

Fixes crash when running DRI3 clients with ShadowPrimary enabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94799
Signed-off-by: Michel Dänzer 
---
 src/amdgpu_dri3.c|  6 +-
 src/amdgpu_glamor_wrappers.c | 11 ++-
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/amdgpu_dri3.c b/src/amdgpu_dri3.c
index c3042e7..0686599 100644
--- a/src/amdgpu_dri3.c
+++ b/src/amdgpu_dri3.c
@@ -135,8 +135,12 @@ static PixmapPtr amdgpu_dri3_pixmap_from_fd(ScreenPtr 
screen,
if (AMDGPUPTR(xf86ScreenToScrn(screen))->use_glamor) {
pixmap = glamor_pixmap_from_fd(screen, fd, width, height,
   stride, depth, bpp);
-   if (pixmap)
+   if (pixmap) {
+   struct amdgpu_pixmap *priv = calloc(1, sizeof(*priv));
+
+   amdgpu_set_pixmap_private(pixmap, priv);
return pixmap;
+   }
}
 #endif
 
diff --git a/src/amdgpu_glamor_wrappers.c b/src/amdgpu_glamor_wrappers.c
index 6700851..35b6d7e 100644
--- a/src/amdgpu_glamor_wrappers.c
+++ b/src/amdgpu_glamor_wrappers.c
@@ -148,10 +148,11 @@ amdgpu_glamor_finish_access_cpu(PixmapPtr pixmap)
  */
 
 static Bool
-amdgpu_glamor_use_gpu(PixmapPtr pixmap)
+amdgpu_glamor_use_gpu(PixmapPtr pixmap, struct amdgpu_pixmap *priv)
 {
return (pixmap->usage_hint &
-   (AMDGPU_CREATE_PIXMAP_SCANOUT | AMDGPU_CREATE_PIXMAP_DRI2)) != 
0;
+   (AMDGPU_CREATE_PIXMAP_SCANOUT | AMDGPU_CREATE_PIXMAP_DRI2)) != 
0 ||
+   (priv && !priv->bo);
 }
 
 static Bool
@@ -432,7 +433,7 @@ amdgpu_glamor_poly_fill_rect(DrawablePtr pDrawable, GCPtr 
pGC,
PixmapPtr pixmap = get_drawable_pixmap(pDrawable);
struct amdgpu_pixmap *priv = amdgpu_get_pixmap_private(pixmap);
 
-   if ((info->force_accel || amdgpu_glamor_use_gpu(pixmap)) &&
+   if ((info->force_accel || amdgpu_glamor_use_gpu(pixmap, priv)) &&
amdgpu_glamor_prepare_access_gpu(priv)) {
info->glamor.SavedPolyFillRect(pDrawable, pGC, nrect, prect);
amdgpu_glamor_finish_access_gpu_rw(info, priv);
@@ -536,8 +537,8 @@ amdgpu_glamor_copy_area(DrawablePtr pSrcDrawable, 
DrawablePtr pDstDrawable,
struct amdgpu_pixmap *dst_priv = amdgpu_get_pixmap_private(dst_pixmap);
RegionPtr ret = NULL;
 
-   if (amdgpu_glamor_use_gpu(dst_pixmap) ||
-   amdgpu_glamor_use_gpu(src_pixmap)) {
+   if (amdgpu_glamor_use_gpu(dst_pixmap, dst_priv) ||
+   amdgpu_glamor_use_gpu(src_pixmap, src_priv)) {
if (!amdgpu_glamor_prepare_access_gpu(dst_priv))
goto fallback;
if (src_priv != dst_priv &&
-- 
2.8.0.rc3

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver 0/7] --disable-iglx

2016-04-04 Thread Evgeny Zubok 
Guilherme Melo  writes:

> So if this is really the direction that it is being taken, this
> feature will be probably be much harder to use in the future. Then
> would you have any other suggestion how to to run OpenGL applications
> inside an old chroot?

Second this. Please, don't drop indirect GLX. It's better to make it a
loadable module as Keith suggested. I'm aware of the tactics that was
mentioned many times by Keith: (i) drop some feature; (ii) wait for some
time until someone says, "Hey, where's that feature that I was using for
a long time?". "Sorry, but it's too late. Where were you all of these
three years?"  :)

___
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 rendercheck 3/5] Use ELF sections to make test setup easier.

2016-04-04 Thread Pekka Paalanen 
On Sun, 03 Apr 2016 01:20:41 -0700
Jeremy Huddleston Sequoia  wrote:

> The use of __attribute(section()), __start_test_section, and
> __stop_test_section is not portable.  Could you please follow this up
> with a change that allows rendercheck to continue to function on
> non-ELF platforms as well? Preferably by just having alternate
> implementations of the DECLARE_RENDERCHECK_ARG_TEST and for_each_test
> macros.

FWIW, I'd also be interested to see how you can write an anternative
implementation without causing more "duplicate" code to have to be
written by hand for each test. Apart from a parser script collecting
entries from C file and generating the table, I haven't come up with
anything.

The reason I'm interested is that I've heard -flto breaking
Wayland/Weston test suites, which use the same section trick. Maybe
that could be fixed otherwise, but learning about portable solutions is
interesting.


Thanks,
pq

> > On Feb 1, 2016, at 13:48, Eric Anholt  wrote:
> > 
> > Managing the group logic was really error-prone (forget to edit
> > success_mask when copy and pasting?  Forget to printf a description
> > of the group?).  Most new tests being written can be described as a
> > single call that does a couple subtests.
> > 
> > This doesn't convert all of the tests.  Some of the remaining ones
> > use "win" for presenting results (which we may want to just put in a
> > global?), and the rest use the pre-created pictures, which would
> > need some much bigger refactoring if we want to move their test
> > logic into their test files.
> > 
> > Signed-off-by: Eric Anholt 
> > ---
> > main.c   | 47
> > ++-
> > rendercheck.h| 51
> > ---
> > t_gtk_argb_xbgr.c| 17 - t_libreoffice_xrgb.c |
> > 18 -- tests.c  | 37
> > ++--- 5 files changed, 120
> > insertions(+), 50 deletions(-)
> > 

> > diff --git a/rendercheck.h b/rendercheck.h
> > index 2195cb4..f0fa7b7 100644
> > --- a/rendercheck.h
> > +++ b/rendercheck.h
> > @@ -64,6 +64,19 @@ struct op_info {
> > bool disabled;
> > };
> > 
> > +struct rendercheck_test_result {
> > +   int tests;
> > +   int passed;
> > +};
> > +
> > +static inline void
> > +record_result(struct rendercheck_test_result *result, bool success)
> > +{
> > +   result->tests++;
> > +   if (success)
> > +   result->passed++;
> > +}
> > +
> > #define TEST_FILL   0x0001
> > #define TEST_DSTCOORDS  0x0002
> > #define TEST_SRCCOORDS  0x0004
> > @@ -77,8 +90,27 @@ struct op_info {
> > #define TEST_REPEAT 0x0400
> > #define TEST_TRIANGLES  0x0800
> > #define TEST_BUG73660x1000
> > -#define TEST_GTK_ARGB_XBGR 0x2000
> > -#define TEST_LIBREOFFICE_XRGB  0x4000
> > +#define TEST_gtk_argb_xbgr 0x2000
> > +#define TEST_libreoffice_xrgb  0x4000
> > +
> > +struct rendercheck_test {
> > +   int bit;
> > +   const char *arg_name;
> > +   const char *long_name;
> > +   struct rendercheck_test_result (*func)(Display *dpy);
> > +};
> > +
> > +#define DECLARE_RENDERCHECK_TEST(name)   \
> > +   const struct rendercheck_test test_desc_##name \
> > +   __attribute__ ((section ("test_section")))
> > +
> > +#define DECLARE_RENDERCHECK_ARG_TEST(arg_name_, long_name_,
> > func_)  \
> > +   DECLARE_RENDERCHECK_TEST(arg_name_) =
> > {   \
> > +   .bit =
> > TEST_##arg_name_,   \
> > +   .arg_name =
> > #arg_name_, \
> > +   .long_name =
> > long_name_, \
> > +   .func =
> > func_,  \
> > +   }
> > 
> > struct render_format {
> > XRenderPictFormat *format;
> > @@ -88,6 +120,12 @@ struct render_format {
> > extern struct render_format *formats;
> > extern int nformats;
> > 
> > +/* Storage that will point at the start and end of the ELF section
> > for test
> > + * structs.  These are automatically set up by the linker when
> > placing things
> > + * in their sections.
> > + */
> > +extern struct rendercheck_test __start_test_section,
> > __stop_test_section; +
> > extern int pixmap_move_iter;
> > extern int win_width, win_height;
> > extern struct op_info ops[];
> > @@ -226,8 +264,7 @@ trifan_test(Display *dpy, picture_info *win,
> > picture_info *dst, int op, bool
> > bug7366_test(Display *dpy);
> > 
> > -bool
> > -gtk_argb_xbgr_test(Display *dpy);
> > -
> > -bool
> > -libreoffice_xrgb_test(Display *dpy, bool invert);
> > +#define
> > for_each_test(test) \
> > +   for (struct rendercheck_test *test =
> > &__start_test_section;  \
> > +test <
> > &__stop_test_section;   \
> > +test++)



pgptvY1uLTDlA.pgp

[PATCH xf86-video-ati] Update manpage entry for Option "TearFree"

2016-04-04 Thread Michel Dänzer 
From: Michel Dänzer 

It's now effective for rotation as well.

(Ported from amdgpu commit faf9d720b7d650f5f1ea657a874d08eac3972e60)

Signed-off-by: Michel Dänzer 
---
 man/radeon.man | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man/radeon.man b/man/radeon.man
index fa55c6d..1acdc63 100644
--- a/man/radeon.man
+++ b/man/radeon.man
@@ -279,9 +279,10 @@ Pageflipping is supported on all radeon hardware.
 .TP
 .BI "Option \*qTearFree\*q \*q" boolean \*q
 Enable tearing prevention using the hardware page flipping mechanism. This
-option currently doesn't have any effect for rotated CRTCs. It requires
-allocating two separate scanout buffers for each non-rotated CRTC. Enabling
-this option currently disables Option \*qEnablePageFlip\*q. The default is
+option currently doesn't have any effect for CRTCs using transforms other than
+rotation or reflection. It requires allocating two separate scanout buffers for
+each supported CRTC. Enabling this option currently disables Option
+\*qEnablePageFlip\*q. The default is
 .B off.
 .TP
 .BI "Option \*qAccelMethod\*q \*q" "string" \*q
-- 
2.8.0.rc3

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati