[PATCH] xfree86: Fix null pointer dereference

[Kyle Guinn]

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675

Signed-off-by: Kyle Guinn 
---
 hw/xfree86/i2c/xf86i2c.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/xfree86/i2c/xf86i2c.c b/hw/xfree86/i2c/xf86i2c.c
index 2a8b8df..62b647c 100644
--- a/hw/xfree86/i2c/xf86i2c.c
+++ b/hw/xfree86/i2c/xf86i2c.c
@@ -615,19 +615,21 @@ void
 xf86DestroyI2CDevRec(I2CDevPtr d, Bool unalloc)
 {
 if (d) {
-I2CDevPtr *p;
+if (d->pI2CBus) {
+I2CDevPtr *p;
 
-/* Remove this from the list of active I2C devices. */
+/* Remove this from the list of active I2C devices. */
 
-for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
-if (*p == d) {
-*p = (*p)->NextDev;
-break;
-}
+for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
+if (*p == d) {
+*p = (*p)->NextDev;
+break;
+}
 
-xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
-   "I2C device \"%s:%s\" removed.\n",
-   d->pI2CBus->BusName, d->DevName);
+xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
+   "I2C device \"%s:%s\" removed.\n",
+   d->pI2CBus->BusName, d->DevName);
+}
 
 if (unalloc)
 free(d);
-- 
1.8.4

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

[PATCH xf86-video-amdgpu] Initialize drmmode_crtc dpms_mode to DPMSModeOff

[Mykola Lysenko]

This disables query of disabled pipes for drmWaitVBlank on X start

Signed-off-by: Mykola Lysenko 
---
 src/drmmode_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index d3dc4b6..dadd8ad 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -975,6 +975,7 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, 
drmModeResPtr mode_res
drmmode_crtc->mode_crtc =
drmModeGetCrtc(pAMDGPUEnt->fd, mode_res->crtcs[num]);
drmmode_crtc->drmmode = drmmode;
+   drmmode_crtc->dpms_mode = DPMSModeOff;
crtc->driver_private = drmmode_crtc;
drmmode_crtc_hw_id(crtc);
 
-- 
1.9.1

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

problems with linux

[Yo-Yo More]

the crouton sent me here because the server was terminated. I have the link
here file:///tmp/Xorg.crouton.1.log can you please tell me what to do. I
have a newer asus chromebook. thank you.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] os: Treat ssh as a non-local client (v3)

[Adam Jackson]

On Thu, 2015-12-17 at 16:41 +0900, Michel Dänzer wrote:
> From: Adam Jackson 
> 
> By the time we get to ComputeLocalClient, we've already done
> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> we're built with #define CLIENTIDS), so we can look up the name of the
> client process and refuse to treat ssh's X forwarding as if it were
> local.
> 
> v2: (Michel Dänzer)
> * Only match "ssh" itself, not other executable names starting with
>   that prefix.
> * Ignore executable path for the match.
> v3: (Michel Dänzer)
> * Use GetClientCmdName (Mark Kettenis)
> * Perform check on Windows as well, but only ignore path on Cygwin
>   (Martin Peres, Emil Velikov, Jon Turney)

But this doesn't work reliably, which is why I used strncmp in the
first place. See my original test report:

http://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html

Note that cmdname is not always "ssh".  Are we honestly concerned that
some client's name is prefixed with "ssh" and _isn't_ ssh or something
acting like it?

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

Re: [PATCH xserver] os: Treat ssh as a non-local client (v3)

[Mark Kettenis]

> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= 
> 
> On 17.12.2015 16:41, Michel Dänzer wrote:
> > From: Adam Jackson 
> > 
> > By the time we get to ComputeLocalClient, we've already done
> > NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> > we're built with #define CLIENTIDS), so we can look up the name of the
> > client process and refuse to treat ssh's X forwarding as if it were
> > local.
> > 
> > v2: (Michel Dänzer)
> > * Only match "ssh" itself, not other executable names starting with
> >   that prefix.
> > * Ignore executable path for the match.
> > v3: (Michel Dänzer)
> > * Use GetClientCmdName (Mark Kettenis)
> > * Perform check on Windows as well, but only ignore path on Cygwin
> >   (Martin Peres, Emil Velikov, Jon Turney)
> > 
> > Signed-off-by: Adam Jackson 
> > Signed-off-by: Michel Dänzer 
> 
> Martin, Mark, Jon, any other objections? If not, can we get a Reviewed-by?

Must admit I'm not really thrilled by the diff.  SoI'll abstain.

> > ---
> >  os/access.c | 38 +++---
> >  1 file changed, 35 insertions(+), 3 deletions(-)
> > 
> > diff --git a/os/access.c b/os/access.c
> > index 10a48c3..3ea2e21 100644
> > --- a/os/access.c
> > +++ b/os/access.c
> > @@ -173,6 +173,10 @@ SOFTWARE.
> >  
> >  #endif  /* WIN32 */
> >  
> > +#if !defined(WIN32) || defined(__CYGWIN__)
> > +#include 
> > +#endif
> > +
> >  #define X_INCLUDE_NETDB_H
> >  #include 
> >  
> > @@ -1081,9 +1085,8 @@ ResetHosts(const char *display)
> >  }
> >  }
> >  
> > -/* Is client on the local host */
> > -Bool
> > -ComputeLocalClient(ClientPtr client)
> > +static Bool
> > +xtransLocalClient(ClientPtr client)
> >  {
> >  int alen, family, notused;
> >  Xtransaddr *from = NULL;
> > @@ -1116,6 +1119,35 @@ ComputeLocalClient(ClientPtr client)
> >  return FALSE;
> >  }
> >  
> > +/* Is client on the local host */
> > +Bool
> > +ComputeLocalClient(ClientPtr client)
> > +{
> > +const char *cmdname = GetClientCmdName(client);
> > +
> > +if (!xtransLocalClient(client))
> > +return FALSE;
> > +
> > +/* If the executable name is "ssh", assume that this client connection
> > + * is forwarded from another host via SSH
> > + */
> > +if (cmdname) {
> > +Bool ret;
> > +
> > +#if !defined(WIN32) || defined(__CYGWIN__)
> > +char *cmd = strdup(cmdname);
> > +ret = strcmp(basename(cmd), "ssh") != 0;
> > +free(cmd);
> > +#else
> > +ret = strcmp(cmdname, "ssh") != 0;
> > +#endif
> > +
> > +return ret;
> > +}
> > +
> > +return TRUE;
> > +}
> > +
> >  /*
> >   * Return the uid and all gids of a connected local client
> >   * Allocates a LocalClientCredRec - caller must call FreeLocalClientCreds
> > 
> 
> 
> -- 
> 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: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Intel NUC5C and X

[Jerry Geis]

>Skylake?
>Add this to the kernel parameters, but you'll likely require a more recent 
>kernel as well:

>i915.preliminary_hw_support=1

I added this to the grub config, reran the config and still nothing.

I donwloaded 4.4, compiled it and also did not seem to help.


Is there anything else to try?

Thanks,



Jerry
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH macros v2] Fix XORG_WITH_XMLTO to work with xmlto >= 0.0.27

[Andreas Boll]

Starting with xmlto version 0.0.27 the return code of
  xmlto --skip-validation txt conftest.xml
is non-zero if conftest.xml is an empty file.

As a consequence the macro XORG_WITH_XMLTO returns
  "xmlto cannot generate text format, this format skipped"
and therefore libraries like libxi, libxdmcp and others won't convert
docbook XML to text format.

This changed behavior was introduced with the following change in xmlto:
  xmlto.in: use correctly exit code from xsltproc
See also: https://fedorahosted.org/xmlto/changeset/77

This patch fixes this by additionally testing xmlto with a non-empty XML
file.

More details can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613674

Thanks to Peter Pearse, Helmut Grohne and Gaetan Nadon.

v2: To maintain compatibility with older xorg tarballs don't replace
the original test with the empty XML file but instead add a fallback
to additionally test with a non-empty XML file if the original test fails.
Use the alternate solution with  to skip compatibility issues
with different docbook versions.

Cc: Gaetan Nadon 
Signed-off-by: Andreas Boll 
---
I've successfully tested this patch to build libxi with xmlto 0.0.26, 0.0.27
and 0.0.28.

To test this patch on a platform with only docbook version 5 installed
I've replaced docbook-xml with docbook5-xml. On such a setup the macro
XORG_WITH_XMLTO detects xmlto correctly though it fails later in the build
with:

xmlto: /«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml does not validate
(status 3)
xmlto: Fix document syntax or use --skip-validation option
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml:2: warning: failed to
load external entity
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
D DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
   ^
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
validity error : Could not load the external subset
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
Document /«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml does not
validate

This build failure is expected since docbook version 5 is not backward
compatible to version 4 and XORG_WITH_XMLTO doesn't check for a specific
docbook version.

 xorg-macros.m4.in | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index 9b3c503..2ed7837 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -426,13 +426,24 @@ m4_ifval([$1],
 fi])
 
 # Test for the ability of xmlto to generate a text target
+#
+# NOTE: xmlto 0.0.27 or higher return a non-zero return code in the
+# following test for empty XML docbook files.
+# For compatibility reasons use the following empty XML docbook file and if
+# it fails try it again with a non-empty XML file.
 have_xmlto_text=no
 cat > conftest.xml << "EOF"
 EOF
 AS_IF([test "$have_xmlto" = yes],
   [AS_IF([$XMLTO --skip-validation txt conftest.xml >/dev/null 2>&1],
  [have_xmlto_text=yes],
- [AC_MSG_WARN([xmlto cannot generate text format, this format 
skipped])])])
+ [# Try it again with a non-empty XML file.
+  cat > conftest.xml << "EOF"
+
+EOF
+  AS_IF([$XMLTO --skip-validation txt conftest.xml >/dev/null 
2>&1],
+[have_xmlto_text=yes],
+[AC_MSG_WARN([xmlto cannot generate text format, this 
format skipped])])])])
 rm -f conftest.xml
 AM_CONDITIONAL([HAVE_XMLTO_TEXT], [test $have_xmlto_text = yes])
 AM_CONDITIONAL([HAVE_XMLTO], [test "$have_xmlto" = yes])
-- 
2.1.4

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

Re: [PATCH xserver] os: Treat ssh as a non-local client (v3)

[Martin Peres]

On 12/01/16 08:57, Michel Dänzer wrote:

On 17.12.2015 16:41, Michel Dänzer wrote:

From: Adam Jackson 

By the time we get to ComputeLocalClient, we've already done
NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
we're built with #define CLIENTIDS), so we can look up the name of the
client process and refuse to treat ssh's X forwarding as if it were
local.

v2: (Michel Dänzer)
 * Only match "ssh" itself, not other executable names starting with
   that prefix.
 * Ignore executable path for the match.
v3: (Michel Dänzer)
 * Use GetClientCmdName (Mark Kettenis)
 * Perform check on Windows as well, but only ignore path on Cygwin
   (Martin Peres, Emil Velikov, Jon Turney)

Signed-off-by: Adam Jackson 
Signed-off-by: Michel Dänzer 

Martin, Mark, Jon, any other objections? If not, can we get a Reviewed-by?


Oh, sorry, I already gave you my R-b and did not think you needed it 
again. In any case, thanks for the additional fixes!


Reviewed-by: Martin Peres 





---
  os/access.c | 38 +++---
  1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/os/access.c b/os/access.c
index 10a48c3..3ea2e21 100644
--- a/os/access.c
+++ b/os/access.c
@@ -173,6 +173,10 @@ SOFTWARE.
  
  #endif  /* WIN32 */
  
+#if !defined(WIN32) || defined(__CYGWIN__)

+#include 
+#endif
+
  #define X_INCLUDE_NETDB_H
  #include 
  
@@ -1081,9 +1085,8 @@ ResetHosts(const char *display)

  }
  }
  
-/* Is client on the local host */

-Bool
-ComputeLocalClient(ClientPtr client)
+static Bool
+xtransLocalClient(ClientPtr client)
  {
  int alen, family, notused;
  Xtransaddr *from = NULL;
@@ -1116,6 +1119,35 @@ ComputeLocalClient(ClientPtr client)
  return FALSE;
  }
  
+/* Is client on the local host */

+Bool
+ComputeLocalClient(ClientPtr client)
+{
+const char *cmdname = GetClientCmdName(client);
+
+if (!xtransLocalClient(client))
+return FALSE;
+
+/* If the executable name is "ssh", assume that this client connection
+ * is forwarded from another host via SSH
+ */
+if (cmdname) {
+Bool ret;
+
+#if !defined(WIN32) || defined(__CYGWIN__)
+char *cmd = strdup(cmdname);
+ret = strcmp(basename(cmd), "ssh") != 0;
+free(cmd);
+#else
+ret = strcmp(cmdname, "ssh") != 0;
+#endif
+
+return ret;
+}
+
+return TRUE;
+}
+
  /*
   * Return the uid and all gids of a connected local client
   * Allocates a LocalClientCredRec - caller must call FreeLocalClientCreds





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

Re: [PATCH] glamor: fallback if font is too large for FBO size.

[Keith Packard]

Dave Airlie  writes:

> from glTexImage2D man page:
>GL_INVALID_VALUE is generated if width is less than 0 or greater than
>GL_MAX_TEXTURE_SIZE.
>
> Granted we should bail early since we know we are going to fail.

Ah, ok. Maybe we should check for that as well then, just in case the
driver has some other crazy error states.

Sorry for not adding my

Reviewed-by: Keith Packard 

before!

-- 
-keith


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

Re: [PATCH v2 3/8] randr: Add ability to turn PRIME sync off

[Adam Jackson]

On Tue, 2016-01-05 at 13:56 -0800, Alex Goins wrote:

> If the user wishes to enable or disable PRIME synchronization after PRIME
> has already been set up, they can run 'xrandr --output  --set
> "PRIME Synchronization" <0 or 1>' at any time, it will trigger a modeset,
> tear down and setup PRIME in the configuration they requested on CRTCs
> associated with that output.

I was confused trying to find where the modeset would be triggered; the
answer is xrandr re-sets the current mode after a property change, it's
not something xserver does internally.

> +static void
> +RRFiniPrimeSyncProps(ScreenPtr pScreen)
> +{
> +rrScrPrivPtr pScrPriv = rrGetScrPriv(pScreen);
> +int i;
> +
> +const char *syncStr = PRIME_SYNC_PROP;
> +Atom syncProp = MakeAtom(syncStr, strlen(syncStr), FALSE);
> +if (syncProp == None)
> +return;
> +
> +for (i = 0; i < pScrPriv->numOutputs; i++) {
> +RRDeleteOutputProperty(pScrPriv->outputs[i], syncProp);
> +}
> +}

This is sort of academic, but you're tearing down the output prop for
every output, which isn't really correct if we ever had different
sources for different outputs.  That's not really an issue since the
old per-crtc scanout pixmap work never landed [1], so we still have the
notion of _the_ screen pixmap.

But I suppose if we ever _did_ try to make that go, you could set the
property value to the XID of the source you wanted, and for
compatibility TRUE would mean "pick one".  And at that point we'd have
enough info to walk backwards to detach only the right properties at
provider destroy.

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

Re: Intel NUC5C and X

[Jerry Geis]

On Tue, Jan 12, 2016 at 2:30 PM, Jerry Geis  wrote:

> >Skylake?
> >Add this to the kernel parameters, but you'll likely require a more recent 
> >kernel as well:
>
> >i915.preliminary_hw_support=1
>
> I added this to the grub config, reran the config and still nothing.
>
> I donwloaded 4.4, compiled it and also did not seem to help.
>
>
> Is there anything else to try?
>
> Thanks,
>
>
>
> Jerry
>
>

I was mistaken... I incorrectly recomiled the Linux 4.4 kernel. I had to go
back and enable the preliminary support in the kernel also
not just the kernel option above... It is now infact working... Thanks for
the pointer.

Jerry
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH] glamor: initial attempt at component alpha in single pass

[Dave Airlie]

From: Dave Airlie 

It's been on the list to add dual source blending support to avoid
the two pass componentAlpha code, radeon has done this for a while
in EXA, so let's add support to bring glamor up to using it.

This adds dual blend to both render and composite glyphs paths.

Initial results show close to doubling of speed of x11perf -rgb10text.

Signed-off-by: Dave Airlie 
---
 glamor/glamor.c  |  2 ++
 glamor/glamor_composite_glyphs.c |  2 +-
 glamor/glamor_priv.h |  8 +
 glamor/glamor_program.c  | 28 ++--
 glamor/glamor_program.h  |  1 +
 glamor/glamor_render.c   | 71 ++--
 6 files changed, 98 insertions(+), 14 deletions(-)

diff --git a/glamor/glamor.c b/glamor/glamor.c
index 116d10c..523f0cb 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -571,6 +571,8 @@ glamor_init(ScreenPtr screen, unsigned int flags)
 glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP ||
 epoxy_gl_version() >= 30 ||
 epoxy_has_gl_extension("GL_NV_pack_subimage");
+glamor_priv->has_dual_blend =
+epoxy_has_gl_extension("GL_ARB_blend_func_extended");
 
 glamor_setup_debug_output(screen);
 
diff --git a/glamor/glamor_composite_glyphs.c b/glamor/glamor_composite_glyphs.c
index 8692904..fb31340 100644
--- a/glamor/glamor_composite_glyphs.c
+++ b/glamor/glamor_composite_glyphs.c
@@ -186,7 +186,7 @@ static const glamor_facet glamor_facet_composite_glyphs_130 
= {
 .vs_exec = ("   vec2 pos = primitive.zw * vec2(gl_VertexID&1, 
(gl_VertexID&2)>>1);\n"
 GLAMOR_POS(gl_Position, (primitive.xy + pos))
 "   glyph_pos = (source + pos) * ATLAS_DIM_INV;\n"),
-.fs_vars = ("varying vec2 glyph_pos;\n"),
+.fs_vars = ("varying vec2 glyph_pos;\nout vec4 color0;\nout vec4 
color1;\n"),
 .fs_exec = ("   vec4 mask = texture2D(atlas, glyph_pos);\n"),
 .source_name = "source",
 .locations = glamor_program_location_atlas,
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index a190e67..6a84548 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -86,6 +86,12 @@ typedef struct glamor_composite_shader {
 };
 } glamor_composite_shader;
 
+enum ca_state {
+CA_NONE,
+CA_TWO_PASS,
+CA_DUAL_BLEND,
+};
+
 enum shader_source {
 SHADER_SOURCE_SOLID,
 SHADER_SOURCE_TEXTURE,
@@ -106,6 +112,7 @@ enum shader_in {
 SHADER_IN_NORMAL,
 SHADER_IN_CA_SOURCE,
 SHADER_IN_CA_ALPHA,
+SHADER_IN_CA_DUAL_BLEND,
 SHADER_IN_COUNT,
 };
 
@@ -201,6 +208,7 @@ typedef struct glamor_screen_private {
 Bool has_unpack_subimage;
 Bool has_rw_pbo;
 Bool use_quads;
+Bool has_dual_blend;
 int max_fbo_size;
 
 struct xorg_list
diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
index 416c54a..f3e1202 100644
--- a/glamor/glamor_program.c
+++ b/glamor/glamor_program.c
@@ -344,6 +344,10 @@ glamor_build_program(ScreenPtr  screen,
 #endif
 glBindAttribLocation(prog->prog, GLAMOR_VERTEX_SOURCE, 
prim->source_name);
 }
+if (prog->alpha == glamor_program_alpha_dual_blend) {
+glBindFragDataLocationIndexed(prog->prog, 0, 0, "color0");
+glBindFragDataLocationIndexed(prog->prog, 0, 1, "color1");
+}
 
 glamor_link_glsl_prog(screen, prog->prog, "%s_%s", prim->name, fill->name);
 
@@ -438,6 +442,10 @@ static struct blendinfo composite_op_info[] = {
 [PictOpAdd] = {0, 0, GL_ONE, GL_ONE},
 };
 
+static struct blendinfo composite_op_db_info[] = {
+[PictOpOver] = {0, 1, GL_ONE, GL_ONE_MINUS_SRC1_ALPHA},
+};
+
 static void
 glamor_set_blend(CARD8 op, glamor_program_alpha alpha, PicturePtr dst)
 {
@@ -459,6 +467,8 @@ glamor_set_blend(CARD8 op, glamor_program_alpha alpha, 
PicturePtr dst)
 return;
 
 op_info = _op_info[op];
+if (alpha == glamor_program_alpha_dual_blend)
+op_info = _op_db_info[op];
 
 src_blend = op_info->source_blend;
 dst_blend = op_info->dest_blend;
@@ -479,6 +489,10 @@ glamor_set_blend(CARD8 op, glamor_program_alpha alpha, 
PicturePtr dst)
 dst_blend = GL_SRC_COLOR;
 else if (dst_blend == GL_ONE_MINUS_SRC_ALPHA)
 dst_blend = GL_ONE_MINUS_SRC_COLOR;
+else if (dst_blend == GL_SRC1_ALPHA)
+dst_blend = GL_SRC1_COLOR;
+else if (dst_blend == GL_ONE_MINUS_SRC1_ALPHA)
+dst_blend = GL_ONE_MINUS_SRC1_COLOR;
 }
 
 glEnable(GL_BLEND);
@@ -547,7 +561,9 @@ static const glamor_facet 
*glamor_facet_source[glamor_program_source_count] = {
 static const char *glamor_combine[] = {
 [glamor_program_alpha_normal]= "   gl_FragColor = source * 
mask.a;\n",
 [glamor_program_alpha_ca_first]  = "   gl_FragColor = source.a * 
mask;\n",
-[glamor_program_alpha_ca_second] = "   gl_FragColor = source * mask;\n"
+[glamor_program_alpha_ca_second] = "   gl_FragColor = source * 
mask;\n",

Re: [PATCH xserver] os: Treat ssh as a non-local client (v3)

[Michel Dänzer]

On 13.01.2016 03:43, Adam Jackson wrote:
> On Thu, 2015-12-17 at 16:41 +0900, Michel Dänzer wrote:
>> From: Adam Jackson 
>>
>> By the time we get to ComputeLocalClient, we've already done
>> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
>> we're built with #define CLIENTIDS), so we can look up the name of the
>> client process and refuse to treat ssh's X forwarding as if it were
>> local.
>>
>> v2: (Michel Dänzer)
>> * Only match "ssh" itself, not other executable names starting with
>>   that prefix.
>> * Ignore executable path for the match.
>> v3: (Michel Dänzer)
>> * Use GetClientCmdName (Mark Kettenis)
>> * Perform check on Windows as well, but only ignore path on Cygwin
>>   (Martin Peres, Emil Velikov, Jon Turney)
> 
> But this doesn't work reliably, which is why I used strncmp in the
> first place. See my original test report:
> 
> http://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html

I somehow missed that before, sorry.

Looks like this could be addressed by cutting of the colon and anything
after it using something like strtok(_r)?


> Note that cmdname is not always "ssh".

Indeed, that's one of the points which prompted my changes. E.g. it can
contain the executable path, which is stripped off with basename. That
might not work too well either with your example above without cutting
off at the colon.


> Are we honestly concerned that some client's name is prefixed with
> "ssh" and _isn't_ ssh or something acting like it?

That seems quite plausible. Debian is already shipping many more
executables starting with "ssh", that number will probably only increase
with time. Maybe none of them need DRI2/3 yet, but we shouldn't lightly
rely on that being the case for any future ones.


-- 
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: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg swapping: bug or expected?

[Adam Jackson]

On Mon, 2016-01-11 at 23:37 +0100, Francois wrote:

> My question is: is this normal? Do we expect Xorg to swap like any other
> program, or does Xorg (should) mlock some of the memory it uses to avoid
> swapping? Do you think there is anything else to investigate, or is this
> just working as designed?

Well it's working as written, whether that can be called "designed" is
perhaps arguable. The X server doesn't attempt to mlock itself, and
it's not even straightforward to figure out how much it would need to
lock to remain responsive, even assuming we could agree what
"responsive" was supposed to mean. If we wanted only that cursor
updates remain smooth that's still scattered across the server core and
whichever input driver is in use. If you want window updates to happen
promptly suddenly you're talking about potentially every pixmap held by
every application... (and also the compositor, or else every
application, since repaints will likely involve IPC).

That's not to say mlock couldn't help, but once you get into paging
like this, if X's pageins get scheduled behind other disk i/o we've
lost and there's nothing X can really do about that. We're ultimately
at the mercy of the kernel's block scheduler in any case.

That said, if dd is consuming so much memory that it's pushing X out of
the working set, I would tend to consider that a flaw in dd (or the
user's invocation of it) first. After all dd's working set size is
effectively bounded: there will be some optimal buffer size which gets
within epsilon of peak read throughput, and for all but the most exotic
hardware that's not going to be in the gigabyte range.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s