Re: [PATCH xserver v2] glamor: add support for NV12 in Xv

[Alex Deucher]

On Tue, Sep 11, 2018 at 1:30 PM Julien Isorce  wrote:
>
> Useful when video decoders only output NV12. Currently
> glamor Xv only supports I420 and YV12.
>
> Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
>
> Test: xvinfo | grep NV12
> Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
>
> v2: Combine the two texture2Ds on u_sampler.
>
> Signed-off-by: Julien Isorce 

Reviewed-by: Alex Deucher 

> ---
>  glamor/glamor_xv.c | 180 
> +
>  1 file changed, 155 insertions(+), 25 deletions(-)
>
> diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
> index 62fc4ff..6fef6ed 100644
> --- a/glamor/glamor_xv.c
> +++ b/glamor/glamor_xv.c
> @@ -59,8 +59,40 @@ typedef struct tagREF_TRANSFORM {
>  #define RTFContrast(a)   (1.0 + ((a)*1.0)/1000.0)
>  #define RTFHue(a)   (((a)*3.1416)/1000.0)
>
> -static const glamor_facet glamor_facet_xv_planar = {
> -.name = "xv_planar",
> +static const glamor_facet glamor_facet_xv_planar_2 = {
> +.name = "xv_planar_2",
> +
> +.version = 120,
> +
> +.source_name = "v_texcoord0",
> +.vs_vars = ("attribute vec2 position;\n"
> +"attribute vec2 v_texcoord0;\n"
> +"varying vec2 tcs;\n"),
> +.vs_exec = (GLAMOR_POS(gl_Position, position)
> +"tcs = v_texcoord0;\n"),
> +
> +.fs_vars = ("uniform sampler2D y_sampler;\n"
> +"uniform sampler2D u_sampler;\n"
> +"uniform vec4 offsetyco;\n"
> +"uniform vec4 ucogamma;\n"
> +"uniform vec4 vco;\n"
> +"varying vec2 tcs;\n"),
> +.fs_exec = (
> +"float sample;\n"
> +"vec2 sample_uv;\n"
> +"vec4 temp1;\n"
> +"sample = texture2D(y_sampler, tcs).w;\n"
> +"temp1.xyz = offsetyco.www * vec3(sample) + 
> offsetyco.xyz;\n"
> +"sample_uv = texture2D(u_sampler, tcs).xy;\n"
> +"temp1.xyz = ucogamma.xyz * vec3(sample_uv.x) + 
> temp1.xyz;\n"
> +"temp1.xyz = clamp(vco.xyz * vec3(sample_uv.y) + 
> temp1.xyz, 0.0, 1.0);\n"
> +"temp1.w = 1.0;\n"
> +"gl_FragColor = temp1;\n"
> +),
> +};
> +
> +static const glamor_facet glamor_facet_xv_planar_3 = {
> +.name = "xv_planar_3",
>
>  .version = 120,
>
> @@ -110,26 +142,50 @@ Atom glamorBrightness, glamorContrast, 
> glamorSaturation, glamorHue,
>  XvImageRec glamor_xv_images[] = {
>  XVIMAGE_YV12,
>  XVIMAGE_I420,
> +XVIMAGE_NV12
>  };
>  int glamor_xv_num_images = ARRAY_SIZE(glamor_xv_images);
>
>  static void
> -glamor_init_xv_shader(ScreenPtr screen)
> +glamor_init_xv_shader(ScreenPtr screen, int id)
>  {
>  glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
>  GLint sampler_loc;
> +const glamor_facet *glamor_facet_xv_planar = NULL;
> +
> +switch (id) {
> +case FOURCC_YV12:
> +case FOURCC_I420:
> +glamor_facet_xv_planar = _facet_xv_planar_3;
> +break;
> +case FOURCC_NV12:
> +glamor_facet_xv_planar = _facet_xv_planar_2;
> +break;
> +default:
> +break;
> +}
>
>  glamor_build_program(screen,
>   _priv->xv_prog,
> - _facet_xv_planar, NULL, NULL, NULL);
> + glamor_facet_xv_planar, NULL, NULL, NULL);
>
>  glUseProgram(glamor_priv->xv_prog.prog);
>  sampler_loc = glGetUniformLocation(glamor_priv->xv_prog.prog, 
> "y_sampler");
>  glUniform1i(sampler_loc, 0);
>  sampler_loc = glGetUniformLocation(glamor_priv->xv_prog.prog, 
> "u_sampler");
>  glUniform1i(sampler_loc, 1);
> -sampler_loc = glGetUniformLocation(glamor_priv->xv_prog.prog, 
> "v_sampler");
> -glUniform1i(sampler_loc, 2);
> +
> +switch (id) {
> +case FOURCC_YV12:
> +case FOURCC_I420:
> +sampler_loc = glGetUniformLocation(glamor_priv->xv_prog.prog, 
> "v_sampler");
> +glUniform1i(sampler_loc, 2);
> +break;
> +case FOURCC_NV12:
> +break;
> +default:
> +break;
> +}
>
>  }
>
> @@ -227,6 +283,21 @@ glamor_xv_query_image

Re: [PATCH xserver 0/3] Xv: add NV12 support in glamor

[Alex Deucher]

On Thu, Sep 6, 2018 at 6:40 PM Julien Isorce  wrote:
>
> Some video decoders can only output NV12 and currently glamor Xv only
> supports I420 and YV12.
>
> Tested with xf86-video-ati, xf86-video-amdgpu and xf86-video-modesetting
> on AMD graphics but should work on any setup that can use glamor.
>
> Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
>
> Julien Isorce (3):
>   xfree86: define FOURCC_NV12 and XVIMAGE_NV12
>   glamor: add support for GL_RG
>   glamor: add support for NV12 in Xv

Series is:
Reviewed-by: Alex Deucher 

>
>  glamor/glamor.c|   2 +
>  glamor/glamor.h|   1 +
>  glamor/glamor_priv.h   |   4 +-
>  glamor/glamor_transfer.c   |  10 ++-
>  glamor/glamor_utils.h  |   4 +
>  glamor/glamor_xv.c | 180 
> ++---
>  hw/xfree86/common/fourcc.h |  20 +
>  7 files changed, 193 insertions(+), 28 deletions(-)
>
> --
> 2.7.4
>
> ___
> 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

Re: [V2] modesetting: Fix X crash in ms_dirty_update()

[Alex Deucher]

On Sun, Aug 5, 2018 at 10:40 PM, Jim Qu  wrote:
> On some Intel iGPU + AMD dGPU platform, when connect extern display
> from dGPU, X will crash, show the log like:
>
> randr: falling back to unsynchronized pixmap sharing
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
> (EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
> (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
> (EE)
> (EE) Segmentation fault at address 0x0
> (EE)
>
> There is NULL pointer accessing on ent->slave_dst->drawable.pScreen->
> SharedPixmapNotifyDamage.
>
> On the platform, since the dGPU is GPU device, so that the iGPU is
> output master device. SharedPixmapNotifyDamage() should be called when
> current device is output master.
>
> Change-Id: I8fa6922a4f75b5e068970fc4d362f778052379f2
> Signed-off-by: Jim Qu 

Reviewed-by: Alex Deucher 


> ---
>  hw/xfree86/drivers/modesetting/driver.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> index 9362370..37fafb1 100644
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -640,19 +640,21 @@ ms_dirty_update(ScreenPtr screen, int *timeout)
>  xorg_list_for_each_entry(ent, >pixmap_dirty_list, ent) {
>  region = DamageRegion(ent->damage);
>  if (RegionNotEmpty(region)) {
> -msPixmapPrivPtr ppriv =
> -msGetPixmapPriv(>drmmode, ent->slave_dst);
> +if (!screen->isGPU) {
> +msPixmapPrivPtr ppriv =
> +msGetPixmapPriv(>drmmode, 
> ent->slave_dst->master_pixmap);
>
> -if (ppriv->notify_on_damage) {
> -ppriv->notify_on_damage = FALSE;
> +if (ppriv->notify_on_damage) {
> +ppriv->notify_on_damage = FALSE;
>
> -ent->slave_dst->drawable.pScreen->
> -SharedPixmapNotifyDamage(ent->slave_dst);
> -}
> +ent->slave_dst->drawable.pScreen->
> +SharedPixmapNotifyDamage(ent->slave_dst);
> +}
>
> -/* Requested manual updating */
> -if (ppriv->defer_dirty_update)
> -continue;
> +/* Requested manual updating */
> +if (ppriv->defer_dirty_update)
> +continue;
> +}
>
>  redisplay_dirty(screen, ent, timeout);
>  DamageEmpty(ent->damage);
> --
> 2.7.4
>
> ___
> 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

Re: [PATCH] DRI2: Sync radeonsi_pci_ids.h from Mesa

[Alex Deucher]

On Sun, May 13, 2018 at 9:31 AM, Bas Nieuwenhuizen
<b...@basnieuwenhuizen.nl> wrote:
> Fixes DRI2 client driver name mapping for newer AMD GPUs with the
> modesetting driver, allowing the DRI2 extension to initialize.
>
> Fixes using GL with the modesetting driver for me.
>
> Seems we were way behind on this one, time to look into something
> more scalable?
>
> Signed-off-by: Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index 20c15837a..2ec8a1e24 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -205,3 +205,33 @@ CHIPSET(0x67CF, POLARIS10_, POLARIS10)
>  CHIPSET(0x67DF, POLARIS10_, POLARIS10)
>
>  CHIPSET(0x98E4, STONEY_, STONEY)
> +
> +CHIPSET(0x6980, POLARIS12_, POLARIS12)
> +CHIPSET(0x6981, POLARIS12_, POLARIS12)
> +CHIPSET(0x6985, POLARIS12_, POLARIS12)
> +CHIPSET(0x6986, POLARIS12_, POLARIS12)
> +CHIPSET(0x6987, POLARIS12_, POLARIS12)
> +CHIPSET(0x6995, POLARIS12_, POLARIS12)
> +CHIPSET(0x6997, POLARIS12_, POLARIS12)
> +CHIPSET(0x699F, POLARIS12_, POLARIS12)
> +
> +CHIPSET(0x694C, VEGAM_, VEGAM)
> +CHIPSET(0x694E, VEGAM_, VEGAM)
> +
> +CHIPSET(0x6860, VEGA10_, VEGA10)
> +CHIPSET(0x6861, VEGA10_, VEGA10)
> +CHIPSET(0x6862, VEGA10_, VEGA10)
> +CHIPSET(0x6863, VEGA10_, VEGA10)
> +CHIPSET(0x6864, VEGA10_, VEGA10)
> +CHIPSET(0x6867, VEGA10_, VEGA10)
> +CHIPSET(0x6868, VEGA10_, VEGA10)
> +CHIPSET(0x687F, VEGA10_, VEGA10)
> +CHIPSET(0x686C, VEGA10_, VEGA10)
> +
> +CHIPSET(0x69A0, VEGA12_, VEGA12)
> +CHIPSET(0x69A1, VEGA12_, VEGA12)
> +CHIPSET(0x69A2, VEGA12_, VEGA12)
> +CHIPSET(0x69A3, VEGA12_, VEGA12)
> +CHIPSET(0x69AF, VEGA12_, VEGA12)
> +
> +CHIPSET(0x15DD, RAVEN_, RAVEN)
> --
> 2.17.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

Re: [PATCH xrandr v5 0/6] xrandr: improve option parsing and documentation

[Alex Deucher]

On Tue, Feb 27, 2018 at 6:20 AM, Giuseppe Bilotta
<giuseppe.bilo...@gmail.com> wrote:
> Miscellaneous patches to improve option parsing and documentation for
> xrandr.
>
> Allow single values to be given to --scale and --gamma, rejecting the
> option if valid values are followed by extra junk (e.g. 2x3a isn't
> accepted as a valid value for --scale), or if they are not positive.
>
> Minor improvements to the documentation are also introduced, the largest
> of which is the documentation of the xrandr monitor options.
>
> v2: rebased on current head.
> v3: fix code indentation, add grammar fix patch
> v4: single value accepted for --gamma too, monitor options documented
> v5: additional patch to check for positive values
>
> The patchset is also available from:
>
>   git://git.oblomov.eu/xorg/xrandr parse-doc-fixes
>
> up to c9755465412cbcf533d3c512397773949a26e55f.

For the series:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>
> Giuseppe Bilotta (6):
>   xrandr: allow a single value for --scale
>   xrandr: stricter --scale argument parsing
>   xrandr.man: grammar tuning
>   xrandr: allow single value for --gamma
>   xrandr.man: document the monitor manipulation options
>   xrandr: gamma and scaling factors must be positive
>
>  man/xrandr.man | 46 +-
>  xrandr.c   | 31 ---
>  2 files changed, 61 insertions(+), 16 deletions(-)
>
> --
> 2.14.1.439.g647b9b4702
>
> ___
> 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

Re: [PATCH xserver] glamor: unifdef XORG_VERSION_CURRENT

[Alex Deucher]

On Mon, Feb 26, 2018 at 3:26 PM, Adam Jackson <a...@redhat.com> wrote:
> This is always true now that glamor is in-tree.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_utils.h | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
> index 7597b92dc..84371f769 100644
> --- a/glamor/glamor_utils.h
> +++ b/glamor/glamor_utils.h
> @@ -601,10 +601,8 @@ format_for_depth(int depth)
>  default:
>  case 24:
>  return PICT_x8r8g8b8;
> -#if XORG_VERSION_CURRENT >= 10699900
>  case 30:
>  return PICT_x2r10g10b10;
> -#endif
>  case 32:
>  return PICT_a8r8g8b8;
>  }
> @@ -669,7 +667,6 @@ glamor_get_rgba_from_pixel(CARD32 pixel,
>  gshift = rbits;
>  bshift = gshift + gbits;
>  ashift = bshift + bbits;
> -#if XORG_VERSION_CURRENT >= 10699900
>  }
>  else if (PICT_FORMAT_TYPE(format) == PICT_TYPE_BGRA) {
>  ashift = 0;
> @@ -678,7 +675,6 @@ glamor_get_rgba_from_pixel(CARD32 pixel,
>  rshift = PICT_FORMAT_BPP(format) - (rbits + gbits + bbits);
>  gshift = rshift + rbits;
>  bshift = gshift + gbits;
> -#endif
>  }
>  else {
>  return FALSE;
> --
> 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
___
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] glamor: Add 30bit RGB color format support

[Alex Deucher]

On Thu, Jan 25, 2018 at 12:03 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Hawking Zhang <hawking.zh...@amd.com>
>
> Signed-off-by: Hawking Zhang <hawking.zh...@amd.com>
>
> [ Michel Dänzer: Adapt to glamor changes since 1.19 ]
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Acked-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_egl.c  | 7 +--
>  glamor/glamor_fbo.c  | 5 -
>  glamor/glamor_transfer.c | 4 
>  glamor/glamor_utils.h| 3 +++
>  4 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
> index 53a74b8da..202b83efd 100644
> --- a/glamor/glamor_egl.c
> +++ b/glamor/glamor_egl.c
> @@ -376,14 +376,17 @@ glamor_back_pixmap_from_fd(PixmapPtr pixmap,
>
>  glamor_egl = glamor_egl_get_screen_private(scrn);
>
> -if (bpp != 32 || !(depth == 24 || depth == 32) || width == 0 || height 
> == 0)
> +if (bpp != 32 || !(depth == 24 || depth == 32 || depth == 30) || width 
> == 0 || height == 0)
>  return FALSE;
>
>  import_data.fd = fd;
>  import_data.width = width;
>  import_data.height = height;
>  import_data.stride = stride;
> -import_data.format = GBM_FORMAT_ARGB;
> +if (depth == 30)
> +import_data.format = GBM_FORMAT_ARGB2101010;
> +else
> +import_data.format = GBM_FORMAT_ARGB;
>  bo = gbm_bo_import(glamor_egl->gbm, GBM_BO_IMPORT_FD, _data, 0);
>  if (!bo)
>  return FALSE;
> diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
> index 9f1288c60..e8c4330b3 100644
> --- a/glamor/glamor_fbo.c
> +++ b/glamor/glamor_fbo.c
> @@ -123,7 +123,10 @@ _glamor_create_tex(glamor_screen_private *glamor_priv,
> int w, int h, GLenum format)
>  {
>  unsigned int tex;
> +GLenum iformat = format;
>
> +if (format == GL_RGB10_A2)
> +format = GL_RGBA;
>  glamor_make_current(glamor_priv);
>  glGenTextures(1, );
>  glBindTexture(GL_TEXTURE_2D, tex);
> @@ -132,7 +135,7 @@ _glamor_create_tex(glamor_screen_private *glamor_priv,
>  if (format == glamor_priv->one_channel_format && format == GL_RED)
>  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_A, GL_RED);
>  glamor_priv->suppress_gl_out_of_memory_logging = true;
> -glTexImage2D(GL_TEXTURE_2D, 0, format, w, h, 0,
> +glTexImage2D(GL_TEXTURE_2D, 0, iformat, w, h, 0,
>   format, GL_UNSIGNED_BYTE, NULL);
>  glamor_priv->suppress_gl_out_of_memory_logging = false;
>
> diff --git a/glamor/glamor_transfer.c b/glamor/glamor_transfer.c
> index d788d06f4..ebb5101d1 100644
> --- a/glamor/glamor_transfer.c
> +++ b/glamor/glamor_transfer.c
> @@ -33,6 +33,10 @@ glamor_format_for_pixmap(PixmapPtr pixmap, GLenum *format, 
> GLenum *type)
>  *format = GL_BGRA;
>  *type = GL_UNSIGNED_INT_8_8_8_8_REV;
>  break;
> +case 30:
> +*format = GL_BGRA;
> +*type = GL_UNSIGNED_INT_2_10_10_10_REV;
> +break;
>  case 16:
>  *format = GL_RGB;
>  *type = GL_UNSIGNED_SHORT_5_6_5;
> diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
> index 090b0e18a..7597b92dc 100644
> --- a/glamor/glamor_utils.h
> +++ b/glamor/glamor_utils.h
> @@ -619,6 +619,9 @@ gl_iformat_for_pixmap(PixmapPtr pixmap)
>  if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP &&
>  ((pixmap)->drawable.depth == 1 || (pixmap)->drawable.depth == 8)) {
>  return glamor_priv->one_channel_format;
> +} else if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP &&
> +   (pixmap)->drawable.depth == 30) {
> +return GL_RGB10_A2;
>  } else {
>  return GL_RGBA;
>  }
> --
> 2.15.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
___
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 00/27] edid-decode: fixes and new features and checks

[Alex Deucher]

On Thu, Aug 31, 2017 at 7:40 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> From: Hans Verkuil <hans.verk...@cisco.com>
>
> This edid-decode patch series has been sitting in my git repo for
> way too long, so it is time to upstream this.
>
> We (that is Cisco Systems Norway) have been using this to verify
> both our own and others EDIDs. So besides adding support for new
> data blocks and correcting little bugs all over it also improves
> compliance checks. Especially making sure that the reported
> timings are not out of range of the reported monitor frequency
> range.

I didn't double check the specs, but I did a quick review of the
patches and they look good to me.  Series is:
Acked-by: Alex Deucher <alexander.deuc...@amd.com>


>
> Regards,
>
> Hans Verkuil
>
> Hans Verkuil (27):
>   edid-decode: add HDMI Forum VSDB support
>   edid-decode: print the chromaticities
>   edid-decode: report picture aspect ratio
>   edid-decode: add check for both serial number and string
>   edid-decode: verify 640x480p60 is defined for CEA-861
>   edid-decode: bit 0, byte 0x18 has been renamed for EDID 1.4
>   edid-decode: fix CVT version
>   edid-decode: fix "Supports CVT standard blanking"
>   edid-decode: add support for the "More standard timings" block
>   edid-decode: add Display Color Management support
>   edid-decode: add support for the Color Point
>   edid-decode: add support for Established Timings III
>   edid-decode: add horizontal freq and pixelclock
>   edid-decode: check monitor min/max range against supported timings
>   edid-decode: SVDs in the 4:2:0 Data Block have half the pixclk
>   edid-decode: YCbCr 4:2:0 Capability Map support
>   edid-decode: fix has_preferred_timing handling for 1.4
>   edid-decode: fix week/year interpretation.
>   edid-decode: fix 1.3/1.4 differences in Model Year and Feature Support
>   edid-decode: return 1 if no edid was found
>   edid-decode: improve the hex dump parser to be more generic
>   edid-decode: allow for comma separated hex values
>   edid-decode: allow the year to be one year in the future
>   edid-decode: check Max TMDS Rates
>   edid-decode: check if HDMI VICs are also in the VSB
>   edid-decode: calculate hfreq and clock from CVT
>   edid-decode: show correct EDID version in string
>
>  edid-decode.c | 1080 
> -
>  1 file changed, 833 insertions(+), 247 deletions(-)
>
> --
> 2.14.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
___
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 0/5] Improve Present support in Xwayland with per window flips

[Alex Deucher]

On Wed, Aug 30, 2017 at 5:15 AM, Roman Gilg  wrote:
> On Wed, Aug 30, 2017 at 4:42 AM, Michel Dänzer  wrote:
>>
>>
>> Hi Roman,
>>
>>
>> On 30/08/17 12:24 AM, Roman Gilg wrote:
>> >
>> > Originating from the bug report
>> >
>> > https://bugs.freedesktop.org/show_bug.cgi?id=99702
>> >
>> > and my own observations with Xwayland misbehaving when outscanning on
>> > overlay planes, this patch series aims at improving Present support in
>> > Xwayland.
>> >
>> > For that it introduces an internal flip mode API to Present, with that
>> > it's possible to try other Pixmap flips than just for a whole screen like
>> > before. For Xwayland we add a flip mode per window, but for example in the
>> > future we could also try to add a mode for flips per CRTC. Anyway the idea
>> > is to clearly separate different flip modes with their own code paths.
>> >
>> > In Xwayland we flip per window, and also with the last patch in the
>> > series use sub-surfaces for that in order to flip on child windows. In my
>> > tests this was still somewhat fragile.
>>
>> I made some high level comments based on commit logs. I haven't reviewed
>> the patches in detail yet, because it seems difficult unless at least
>> some of them are split up:
>>
>> * Moving code without any functional changes should be in its own patch,
>>   not intermixed with functional changes.
>
>
> What do you mean exactly? I put the code moving of present.c to
> present_execute.c and present_vblank.c in the separate patch 2. Or should it
> not be part of this patch set at all? Or do you mean the moving of code in
> patch 1 to present_scrmode.c?
>
>> * Only one logical change per patch.
>
>
> Can you give an example? What do you mean by a logical change. I partitioned
> my changes such that they form functional units and such that every patch is
> self-contained, i.e. such that the Xserver can work even if the later ones
> won't get pushed.

I haven't looked closely at the patches, but if you are moving code
around with no functional change (e.g., breaking some common code out
into a new shared function or moving code to avoid an extra function
declaration or moving code to a new file), those should be separate
from functional changes (e.g. changing the code to do A rather than
B).  Each one is a separate logical change.  Mixing them together
makes it harder to review each change.

Alex

>
>> > * Mutter: Neverball framerate capped to 120 (probably Mutter doesn't
>> > release buffers faster)
>>
>> Was that with PresentOptionAsync (e.g. via "V-Sync" disabled in the game
>> settings, or e.g. vblank_mode=0)? Without PresentOptionAsync, the
>> intention is for the presentation frame rate to match the scanout
>> refresh rate.
>
>
> PresentOptionAsync is always on in Xwayland. And I disabled V-Sync in game
> (set vblank_mode=0). Although that in game setting makes with my current
> patches no difference, since V-Sync regressed for now with this patch series
> and only works again when later some mechanism for queuing vblanks, for
> example by using the Presentation Time protocol, is added.
>
> ___
> 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

Re: [PATCH xserver] glx: Fix error generation for non-reply vendor private requests

[Alex Deucher]

On Tue, Aug 22, 2017 at 12:19 PM, Adam Jackson <a...@redhat.com> wrote:
> Discarding the return value here is just wrong.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glx/glxcmds.c | 3 +--
>  glx/glxcmdsswap.c | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index 6a763970da..241abc6a58 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -2376,8 +2376,7 @@ __glXDisp_VendorPrivate(__GLXclientState * cl, GLbyte * 
> pc)
>  __glXGetProtocolDecodeFunction(_dispatch_info,
> vendorcode, 0);
>  if (proc != NULL) {
> -(*proc) (cl, (GLbyte *) req);
> -return Success;
> +return (*proc) (cl, (GLbyte *) req);
>  }
>
>  cl->client->errorValue = req->vendorCode;
> diff --git a/glx/glxcmdsswap.c b/glx/glxcmdsswap.c
> index 44a09e61cb..10d84062ed 100644
> --- a/glx/glxcmdsswap.c
> +++ b/glx/glxcmdsswap.c
> @@ -873,8 +873,7 @@ __glXDispSwap_VendorPrivate(__GLXclientState * cl, GLbyte 
> * pc)
>  __glXGetProtocolDecodeFunction(_dispatch_info,
> vendorcode, 1);
>  if (proc != NULL) {
> -(*proc) (cl, (GLbyte *) req);
> -return Success;
> +return (*proc) (cl, (GLbyte *) req);
>  }
>
>  cl->client->errorValue = req->vendorCode;
> --
> 2.13.5
>
> ___
> 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

Re: [PATCH xserver 1/3] glx: Remove True/False defines

[Alex Deucher]

On Wed, Aug 16, 2017 at 2:49 PM, Adam Jackson <a...@redhat.com> wrote:
> Those are xlib spellings, we say TRUE/FALSE pretty consistently
> elsewhere in the server.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glx/createcontext.c| 16 
>  glx/glxdri2.c  | 16 
>  glx/glxext.c   | 16 
>  glx/glxserver.h|  7 ---
>  glx/indirect_program.c |  4 ++--
>  hw/xwin/glx/indirect.c |  2 +-
>  6 files changed, 27 insertions(+), 34 deletions(-)
>
> diff --git a/glx/createcontext.c b/glx/createcontext.c
> index 068b35fa7..1216f9412 100644
> --- a/glx/createcontext.c
> +++ b/glx/createcontext.c
> @@ -37,29 +37,29 @@ static Bool
>  validate_GL_version(int major_version, int minor_version)
>  {
>  if (major_version <= 0 || minor_version < 0)
> -return False;
> +return FALSE;
>
>  switch (major_version) {
>  case 1:
>  if (minor_version > 5)
> -return False;
> +return FALSE;
>  break;
>
>  case 2:
>  if (minor_version > 1)
> -return False;
> +return FALSE;
>  break;
>
>  case 3:
>  if (minor_version > 3)
> -return False;
> +return FALSE;
>  break;
>
>  default:
>  break;
>  }
>
> -return True;
> +return TRUE;
>  }
>
>  static Bool
> @@ -70,9 +70,9 @@ validate_render_type(uint32_t render_type)
>  case GLX_COLOR_INDEX_TYPE:
>  case GLX_RGBA_FLOAT_TYPE_ARB:
>  case GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT:
> -return True;
> +return TRUE;
>  default:
> -return False;
> +return FALSE;
>  }
>  }
>
> @@ -316,7 +316,7 @@ __glXDisp_CreateContextAttribsARB(__GLXclientState * cl, 
> GLbyte * pc)
>  ctx->config = config;
>  ctx->id = req->context;
>  ctx->share_id = req->shareList;
> -ctx->idExists = True;
> +ctx->idExists = TRUE;
>  ctx->isDirect = req->isDirect;
>  ctx->renderMode = GL_RENDER;
>  ctx->resetNotificationStrategy = reset;
> diff --git a/glx/glxdri2.c b/glx/glxdri2.c
> index 701944283..9961c1bfb 100644
> --- a/glx/glxdri2.c
> +++ b/glx/glxdri2.c
> @@ -344,11 +344,11 @@ dri2_convert_glx_attribs(__GLXDRIscreen *screen, 
> unsigned num_attribs,
>  unsigned i;
>
>  if (num_attribs == 0)
> -return True;
> +return TRUE;
>
>  if (attribs == NULL) {
>  *error = BadImplementation;
> -return False;
> +return FALSE;
>  }
>
>  *major_ver = 1;
> @@ -381,13 +381,13 @@ dri2_convert_glx_attribs(__GLXDRIscreen *screen, 
> unsigned num_attribs,
>  break;
>  default:
>  *error = __glXError(GLXBadProfileARB);
> -return False;
> +return FALSE;
>  }
>  break;
>  case GLX_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB:
>  if (screen->dri2->base.version >= 4) {
>  *error = BadValue;
> -return False;
> +return FALSE;
>  }
>
>  switch (attribs[i * 2 + 1]) {
> @@ -399,14 +399,14 @@ dri2_convert_glx_attribs(__GLXDRIscreen *screen, 
> unsigned num_attribs,
>  break;
>  default:
>  *error = BadValue;
> -return False;
> +return FALSE;
>  }
>  break;
>  default:
>  /* If an unknown attribute is received, fail.
>   */
>  *error = BadValue;
> -return False;
> +return FALSE;
>  }
>  }
>
> @@ -414,7 +414,7 @@ dri2_convert_glx_attribs(__GLXDRIscreen *screen, unsigned 
> num_attribs,
>   */
>  if ((*flags & ~ALL_DRI_CTX_FLAGS) != 0) {
>  *error = BadValue;
> -return False;
> +return FALSE;
>  }
>
>  /* If the core profile is requested for a GL version is less than 3.2,
> @@ -428,7 +428,7 @@ dri2_convert_glx_attribs(__GLXDRIscreen *screen, unsigned 
> num_attribs,
>  }
>
>  *error = Success;
> -return True;
> +return TRUE;
>  }
>
>  static void
> diff --git a/glx/glxext.c b/glx/glxext.c
> index e88bbd107..9b4d81641 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -97,7 +97,7 @@ ContextGone(__GLXcontext * cx, XID id)
>  __glXFr

Re: [PATCH xserver] dri2: sort DRI2InfoPtr::version checking in ascending order

[Alex Deucher]

On Thu, Aug 3, 2017 at 2:43 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Makes it easer to follow if 8 is between 7 and 9 ;-)

Agreed :)
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
>  hw/xfree86/dri2/dri2.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
> index f9f9859e1..75abc18ac 100644
> --- a/hw/xfree86/dri2/dri2.c
> +++ b/hw/xfree86/dri2/dri2.c
> @@ -1538,6 +1538,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
>  ds->CreateBuffer = info->CreateBuffer;
>  ds->DestroyBuffer = info->DestroyBuffer;
>  ds->CopyRegion = info->CopyRegion;
> +cur_minor = 1;
>
>  if (info->version >= 4) {
>  ds->ScheduleSwap = info->ScheduleSwap;
> @@ -1545,13 +1546,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
>  ds->GetMSC = info->GetMSC;
>  cur_minor = 3;
>  }
> -else {
> -cur_minor = 1;
> -}
>
> -if (info->version >= 8) {
> -ds->AuthMagic = info->AuthMagic2;
> -}
>  if (info->version >= 5) {
>  ds->LegacyAuthMagic = info->AuthMagic;
>  }
> @@ -1566,6 +1561,10 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
>  cur_minor = 4;
>  }
>
> +if (info->version >= 8) {
> +ds->AuthMagic = info->AuthMagic2;
> +}
> +
>  if (info->version >= 9) {
>  ds->CreateBuffer2 = info->CreateBuffer2;
>  if (info->CreateBuffer2 && pScreen->isGPU) {
> --
> 2.13.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
___
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/3] modesetting: Hide cursor during DPMS

[Alex Deucher]

On Thu, Aug 3, 2017 at 12:19 AM, Keith Packard <kei...@keithp.com> wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Shouldn't this be done at a higher level instead?
>
> Thanks for a really good question.
>
> The X server doesn't touch cursors when turning off crtcs that aren't in
> use any more. That's because xf86DisableUnusedFunctions doesn't touch
> the cursor for disabled crtcs, it only sets the cursor for enabled ones.
>
> I think a better patch is to just disable the cursor whenever we're
> turning the crtc off during mode setting. After the mode setting is
> finished, xf86DisableUnusedFunctions will get called and that will call
> xf86CursorResetCursor to make sure the cursor is enabled everywhere it
> should be.
>
> Here's a replacement for the modesetting patch which does this up in
> xfree86/modes:

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>
>
> --
> -keith
>
> ___
> 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

Re: [PATCH xserver 0/1] Good bye GlxSetVisualConfigs

[Alex Deucher]

On Mon, Jul 31, 2017 at 9:13 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> Hi all,
>
> While skimming though, I've noticed that GlxSetVisualConfigs has not
> been used since 2008, at the very least.
>
> At the same time, a handful of driver were still using it, assuming
> that it works. So here it is - update all the drivers (about 200+ lines
> dropped in each) and finally remove the symbol from Xserver.
>
> All the drivers are built tested, unless stated otherwise.

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
> Thanks
> 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
___
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] glx: don't export __glXDRISWRastProvider

[Alex Deucher]

On Mon, Jul 31, 2017 at 9:06 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> The symbol is used only internally and is not part of the API/ABI.
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glx/glxdriswrast.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
> index 396b68911..251bdd2dd 100644
> --- a/glx/glxdriswrast.c
> +++ b/glx/glxdriswrast.c
> @@ -477,7 +477,7 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
>  return NULL;
>  }
>
> -_X_EXPORT __GLXprovider __glXDRISWRastProvider = {
> +__GLXprovider __glXDRISWRastProvider = {
>  __glXDRIscreenProbe,
>  "DRISWRAST",
>  NULL
> --
> 2.13.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
___
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] glx: fix typo becuase -> because

[Alex Deucher]

On Mon, Jul 31, 2017 at 9:06 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glx/glxcmds.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index ac21136b1..9ad90eec2 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -224,7 +224,7 @@ __glXdirectContextCreate(__GLXscreen * screen,
>  /**
>   * Create a GL context with the given properties.  This routine is used
>   * to implement \c glXCreateContext, \c glXCreateNewContext, and
> - * \c glXCreateContextWithConfigSGIX.  This works becuase of the hack way
> + * \c glXCreateContextWithConfigSGIX.  This works because of the hack way
>   * that GLXFBConfigs are implemented.  Basically, the FBConfigID is the
>   * same as the VisualID.
>   */
> --
> 2.13.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
___
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: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Alex Deucher]

On Wed, Jul 26, 2017 at 8:15 AM, Nicolai Hähnle  wrote:
> On 26.07.2017 08:29, Michel Dänzer wrote:
>>
>> On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
>>>
>>> On 22.07.2017 14:00, Daniel Stone wrote:


 I don't have any great solution off the top of my head, but I'd be
 inclined to bundle stride in with placement. TTBOMK (from having
 looked at radv), buffers shared cross-GPU also need to be allocated
 from a separate externally-visible memory heap. And at the moment,
 lacking placement information at allocation time (at least for EGL
 allocations, via DRIImage), that happens via transparent migration at
 import time I think. Placement restrictions would probably also
 involve communicating base address alignment requirements.
>>>
>>>
>>> Stride isn't really in the same category as placement and base address
>>> alignment, though.
>>>
>>> Placement and base address alignment requirements can apply to all
>>> possible texture layouts, while the concept of stride is specific to
>>> linear layouts.
>>
>>
>> Also, the starting address of shareable buffers is generally aligned to
>> at least the CPU page size anyway. Do we know of any cases requiring
>> higher alignment than that, and if so, which address space does the
>> requirement apply to?
>
>
> Only tiling modes, as Marek mentioned. We don't do tiling shares across
> different GPUs right now.
>
> Maybe we can do it in the future with gfx9 GPUs. But then the alignment
> requirements should be known on both sides based on the tiling mode anyway
> -- if they even apply for non-VRAM textures.

We should be able to do some 1D tiling modes.  That doesn't have any
per sku alignment dependencies.

Alex

>
>
 Given that, I'm fairly inclined to punt those until we have the grand
 glorious allocator, rather than trying to add it to EGL/GBM
 separately. The modifiers stuff was a fairly obvious augmentation -
 EGL already had no-modifier format import but no query as to which
 formats it would accept, and modifiers are a logical extension of
 format - but adding the other restrictions is a bigger step forward.
>>>
>>>
>>> Perhaps a third option would be to encode the required pitch_in_bytes
>>> alignment as part of the modifier?
>>>
>>> So DRI3GetSupportedModifiers would return DRM_FORMAT_MOD_LINEAR_256B
>>> when the display GPU is a Raven Ridge.
>>>
>>> More generally, we could say that fourcc_mod_code(NONE, k) means that
>>> the pitch_in_bytes has to be a multiple of 2**k for e.g. k <= 31. Or if
>>> you prefer, we could have a stride requirement in elements or pixels
>>> instead of bytes.
>>
>>
>> Interesting idea. FWIW, I suspect we'd need to support specifying the
>> requirement in both bytes or pixels, since one or the other alone may
>> not be sufficient to describe the constraints of all hardware.
>
>
> From what I've seen, modifiers are always specified together with one
> specific format, so the bytes-per-pixel are always known, so I don't think
> we need both. Specifying it in bytes is a bit more natural for our hardware,
> that's all.
>
> Cheers,
> Nicolai
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
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: Multi gpu display

[Alex Deucher]

On Fri, Jul 14, 2017 at 4:27 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
> On Fri, Jul 14, 2017 at 4:36 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>
>>
>> On 2017年07月06日 10:30, zhoucm1 wrote:
>>>
>>>
>>>
>>> On 2017年07月06日 00:15, Alex Deucher wrote:
>>>>
>>>> On Tue, Jul 4, 2017 at 6:26 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>
>>>>>
>>>>> On 2017年07月04日 13:43, zhoucm1 wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017年07月04日 13:34, Alex Deucher wrote:
>>>>>>>
>>>>>>> On Tue, Jul 4, 2017 at 1:22 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2017年07月04日 11:41, Alex Deucher wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Jul 3, 2017 at 4:32 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi xorg-devel guys,
>>>>>>>>>>
>>>>>>>>>> Anyone can help me?
>>>>>>>>>>
>>>>>>>>>> I tried two gpu card with four monitors on Unbuntu 16.04, each gpu
>>>>>>>>>> has
>>>>>>>>>> two
>>>>>>>>>> monitors.
>>>>>>>>>> By default config, I can see four monitors all are lighting with
>>>>>>>>>> its
>>>>>>>>>> separate desktop instance, and the running application with small
>>>>>>>>>> window
>>>>>>>>>> can
>>>>>>>>>> be spanning all monitors, but if application only can be run on one
>>>>>>>>>> of
>>>>>>>>>> monitros with fullscreen setting. I attached Xorg log and xrandr
>>>>>>>>>> output
>>>>>>>>>> info.
>>>>>>>>>>
>>>>>>>>>> How should I configure if I want to all monitors as a big desktop
>>>>>>>>>> or
>>>>>>>>>> the
>>>>>>>>>> full screen application can run on all monitors? or How should I
>>>>>>>>>> do/change?
>>>>>>>>>
>>>>>>>>> You'd need to configure it in the window manager. Most window
>>>>>>>>> managers use the geometry info advertised via randr to define what
>>>>>>>>> is
>>>>>>>>> considered full screen.  You need to tell it to ignore that and just
>>>>>>>>> use the full surface size.  How to do that varies from window
>>>>>>>>> manager
>>>>>>>>> to window manager.
>>>>>>>>
>>>>>>>> Thanks Alex for input.
>>>>>>>> I'm using ubuntu16.04, which window manager should be compiz, how to
>>>>>>>> tell it
>>>>>>>> to ignore that and just use the full surface size.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://askubuntu.com/questions/73573/how-to-maximise-a-window-across-two-monitors
>>>>>
>>>>> Could you also tell me how to set it for Redhat7.3?
>>>>
>>>> I'm not sure.  Probably some setting in gnome shell.  wmctrl -e might
>>>> do what you want.
>>>
>>> Unfortunately, it doesn't combine all desktop to one big desktop.
>>>
>>> -e option is to resize the window on one desktop, no effect for desktop.
>>>
>>> I also tried to specify application with it:  wmctrl -r "glxgears" -e
>>> 0,0,0,115200,2160, it has no effect as well.
>>
>> Hi Alex,
>>
>> From wmctrl -m, I can see Redhat7.3 is using 'gnome shell' as its window
>> manager, I searched from google and realize many people are asking the same
>> question, but all no right answer for Redhat.
>>
>> Do you know any guys from Redhat company can help this question?
>
> mutter/gnomeshell doesn't provide a similar knob like compiz does.
> We'd need to either patch mutter/gnomeshell or provide some sort of
> general override via randr.


I guess you could also manually specify the geometry on the command
line when starting the app, although, I guess that would probably not
properly inhibit the compositor.

Alex

>
> Alex
>
>>
>> Thanks,
>> David Zhou
>>
>>>
>>> Thanks anyway,
>>> David Zhou
>>>>
>>>>
>>>> Alex
>>>>
>>>>> Thanks,
>>>>> David Zhou
>>>>>
>>>>>> That's great, it solves my problem, otherwise I'm going to add an
>>>>>> extention for xinerama.
>>>>>>
>>>>>> Thanks a lot.
>>>>>> David Zhou
>>>>>>>
>>>>>>> Also, looks like wmctrl works as well.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> David Zhou
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>
>>
___
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: Multi gpu display

[Alex Deucher]

On Fri, Jul 14, 2017 at 4:36 AM, zhoucm1 <david1.z...@amd.com> wrote:
>
>
> On 2017年07月06日 10:30, zhoucm1 wrote:
>>
>>
>>
>> On 2017年07月06日 00:15, Alex Deucher wrote:
>>>
>>> On Tue, Jul 4, 2017 at 6:26 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>
>>>>
>>>> On 2017年07月04日 13:43, zhoucm1 wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 2017年07月04日 13:34, Alex Deucher wrote:
>>>>>>
>>>>>> On Tue, Jul 4, 2017 at 1:22 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2017年07月04日 11:41, Alex Deucher wrote:
>>>>>>>>
>>>>>>>> On Mon, Jul 3, 2017 at 4:32 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi xorg-devel guys,
>>>>>>>>>
>>>>>>>>> Anyone can help me?
>>>>>>>>>
>>>>>>>>> I tried two gpu card with four monitors on Unbuntu 16.04, each gpu
>>>>>>>>> has
>>>>>>>>> two
>>>>>>>>> monitors.
>>>>>>>>> By default config, I can see four monitors all are lighting with
>>>>>>>>> its
>>>>>>>>> separate desktop instance, and the running application with small
>>>>>>>>> window
>>>>>>>>> can
>>>>>>>>> be spanning all monitors, but if application only can be run on one
>>>>>>>>> of
>>>>>>>>> monitros with fullscreen setting. I attached Xorg log and xrandr
>>>>>>>>> output
>>>>>>>>> info.
>>>>>>>>>
>>>>>>>>> How should I configure if I want to all monitors as a big desktop
>>>>>>>>> or
>>>>>>>>> the
>>>>>>>>> full screen application can run on all monitors? or How should I
>>>>>>>>> do/change?
>>>>>>>>
>>>>>>>> You'd need to configure it in the window manager. Most window
>>>>>>>> managers use the geometry info advertised via randr to define what
>>>>>>>> is
>>>>>>>> considered full screen.  You need to tell it to ignore that and just
>>>>>>>> use the full surface size.  How to do that varies from window
>>>>>>>> manager
>>>>>>>> to window manager.
>>>>>>>
>>>>>>> Thanks Alex for input.
>>>>>>> I'm using ubuntu16.04, which window manager should be compiz, how to
>>>>>>> tell it
>>>>>>> to ignore that and just use the full surface size.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://askubuntu.com/questions/73573/how-to-maximise-a-window-across-two-monitors
>>>>
>>>> Could you also tell me how to set it for Redhat7.3?
>>>
>>> I'm not sure.  Probably some setting in gnome shell.  wmctrl -e might
>>> do what you want.
>>
>> Unfortunately, it doesn't combine all desktop to one big desktop.
>>
>> -e option is to resize the window on one desktop, no effect for desktop.
>>
>> I also tried to specify application with it:  wmctrl -r "glxgears" -e
>> 0,0,0,115200,2160, it has no effect as well.
>
> Hi Alex,
>
> From wmctrl -m, I can see Redhat7.3 is using 'gnome shell' as its window
> manager, I searched from google and realize many people are asking the same
> question, but all no right answer for Redhat.
>
> Do you know any guys from Redhat company can help this question?

mutter/gnomeshell doesn't provide a similar knob like compiz does.
We'd need to either patch mutter/gnomeshell or provide some sort of
general override via randr.

Alex

>
> Thanks,
> David Zhou
>
>>
>> Thanks anyway,
>> David Zhou
>>>
>>>
>>> Alex
>>>
>>>> Thanks,
>>>> David Zhou
>>>>
>>>>> That's great, it solves my problem, otherwise I'm going to add an
>>>>> extention for xinerama.
>>>>>
>>>>> Thanks a lot.
>>>>> David Zhou
>>>>>>
>>>>>> Also, looks like wmctrl works as well.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> Regards,
>>>>>>> David Zhou
>>>>>>>>
>>>>>>>>
>>>>>>>> Alex
>>>>>>>
>>>>>>>
>>
>
___
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: Multi gpu display

[Alex Deucher]

On Tue, Jul 4, 2017 at 6:26 AM, zhoucm1 <david1.z...@amd.com> wrote:
>
>
> On 2017年07月04日 13:43, zhoucm1 wrote:
>>
>>
>>
>> On 2017年07月04日 13:34, Alex Deucher wrote:
>>>
>>> On Tue, Jul 4, 2017 at 1:22 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>
>>>>
>>>> On 2017年07月04日 11:41, Alex Deucher wrote:
>>>>>
>>>>> On Mon, Jul 3, 2017 at 4:32 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>>>>
>>>>>> Hi xorg-devel guys,
>>>>>>
>>>>>> Anyone can help me?
>>>>>>
>>>>>> I tried two gpu card with four monitors on Unbuntu 16.04, each gpu has
>>>>>> two
>>>>>> monitors.
>>>>>> By default config, I can see four monitors all are lighting with its
>>>>>> separate desktop instance, and the running application with small
>>>>>> window
>>>>>> can
>>>>>> be spanning all monitors, but if application only can be run on one of
>>>>>> monitros with fullscreen setting. I attached Xorg log and xrandr
>>>>>> output
>>>>>> info.
>>>>>>
>>>>>> How should I configure if I want to all monitors as a big desktop or
>>>>>> the
>>>>>> full screen application can run on all monitors? or How should I
>>>>>> do/change?
>>>>>
>>>>> You'd need to configure it in the window manager.  Most window
>>>>> managers use the geometry info advertised via randr to define what is
>>>>> considered full screen.  You need to tell it to ignore that and just
>>>>> use the full surface size.  How to do that varies from window manager
>>>>> to window manager.
>>>>
>>>> Thanks Alex for input.
>>>> I'm using ubuntu16.04, which window manager should be compiz, how to
>>>> tell it
>>>> to ignore that and just use the full surface size.
>>>
>>>
>>> https://askubuntu.com/questions/73573/how-to-maximise-a-window-across-two-monitors
>
> Could you also tell me how to set it for Redhat7.3?

I'm not sure.  Probably some setting in gnome shell.  wmctrl -e might
do what you want.

Alex

>
> Thanks,
> David Zhou
>
>> That's great, it solves my problem, otherwise I'm going to add an
>> extention for xinerama.
>>
>> Thanks a lot.
>> David Zhou
>>>
>>> Also, looks like wmctrl works as well.
>>>
>>> Alex
>>>
>>>> Regards,
>>>> David Zhou
>>>>>
>>>>>
>>>>> Alex
>>>>
>>>>
>>
>
___
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: Multi gpu display

[Alex Deucher]

On Tue, Jul 4, 2017 at 1:22 AM, zhoucm1 <david1.z...@amd.com> wrote:
>
>
> On 2017年07月04日 11:41, Alex Deucher wrote:
>>
>> On Mon, Jul 3, 2017 at 4:32 AM, zhoucm1 <david1.z...@amd.com> wrote:
>>>
>>> Hi xorg-devel guys,
>>>
>>> Anyone can help me?
>>>
>>> I tried two gpu card with four monitors on Unbuntu 16.04, each gpu has
>>> two
>>> monitors.
>>> By default config, I can see four monitors all are lighting with its
>>> separate desktop instance, and the running application with small window
>>> can
>>> be spanning all monitors, but if application only can be run on one of
>>> monitros with fullscreen setting. I attached Xorg log and xrandr output
>>> info.
>>>
>>> How should I configure if I want to all monitors as a big desktop or the
>>> full screen application can run on all monitors? or How should I
>>> do/change?
>>
>> You'd need to configure it in the window manager.  Most window
>> managers use the geometry info advertised via randr to define what is
>> considered full screen.  You need to tell it to ignore that and just
>> use the full surface size.  How to do that varies from window manager
>> to window manager.
>
> Thanks Alex for input.
> I'm using ubuntu16.04, which window manager should be compiz, how to tell it
> to ignore that and just use the full surface size.

https://askubuntu.com/questions/73573/how-to-maximise-a-window-across-two-monitors
Also, looks like wmctrl works as well.

Alex

>
> Regards,
> David Zhou
>>
>>
>> Alex
>
>
___
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: Multi gpu display

[Alex Deucher]

On Mon, Jul 3, 2017 at 4:32 AM, zhoucm1  wrote:
> Hi xorg-devel guys,
>
> Anyone can help me?
>
> I tried two gpu card with four monitors on Unbuntu 16.04, each gpu has two
> monitors.
> By default config, I can see four monitors all are lighting with its
> separate desktop instance, and the running application with small window can
> be spanning all monitors, but if application only can be run on one of
> monitros with fullscreen setting. I attached Xorg log and xrandr output
> info.
>
> How should I configure if I want to all monitors as a big desktop or the
> full screen application can run on all monitors? or How should I do/change?

You'd need to configure it in the window manager.  Most window
managers use the geometry info advertised via randr to define what is
considered full screen.  You need to tell it to ignore that and just
use the full surface size.  How to do that varies from window manager
to window manager.

Alex
___
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/4] xfree86: Miscellaneous fixes for PCI domain in BusID

[Alex Deucher]

On Mon, Jun 19, 2017 at 6:05 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> For https://bugs.freedesktop.org/101446 , I had to spend a significant
> amount of time grepping and reading code to figure out how a non-0 PCI
> domain can be specified in the BusID stanza.
>
> The first two patches fix issues I noticed while doing so.
>
> The last two patches add documentation of how this works.
>
> Michel Dänzer (4):
>   xfree86: Print BusID stanza compatible bus IDs for found devices
>   xfree86: Fix printing of PCI domain/bus in xf86MatchPciInstances
>   xfree86: Document BusID PCI domain format in xorg.conf manpage
>   xfree86: Document BusID PCI domain format in ddxDesign.xml

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  hw/xfree86/common/xf86pciBus.c | 6 +++---
>  hw/xfree86/doc/ddxDesign.xml   | 3 ++-
>  hw/xfree86/man/xorg.conf.man   | 8 
>  3 files changed, 9 insertions(+), 8 deletions(-)
>
> --
> 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
___
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] xfree86: Add Option "PreferCloneMode"

[Alex Deucher]

On Thu, May 25, 2017 at 3:21 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> When the default behaviour was changed from clone mode to horizontal
> extended layout, a boolean ScrnInfoRec member preferClone was introduced
> to choose the old default behaviour. Option "PreferCloneMode" allows
> setting this preferClone member.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/man/xorg.conf.man | 5 +
>  hw/xfree86/modes/xf86Crtc.c  | 4 
>  2 files changed, 9 insertions(+)
>
> diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man
> index 0c39062e6..ec8d07c65 100644
> --- a/hw/xfree86/man/xorg.conf.man
> +++ b/hw/xfree86/man/xorg.conf.man
> @@ -1495,6 +1495,11 @@ option.
>  .BI "Option \*qModeDebug\*q \*q" boolean \*q
>  Enable printing of additional debugging information about modesetting to
>  the server log.
> +.TP 7
> +.BI "Option \*qPreferCloneMode\*q \*q" boolean \*q
> +If enabled, bring up monitors of a screen in clone mode instead of horizontal
> +extended layout by default. (Defaults to off; the video driver can change the
> +default value, but this option can always override it)
>  .ig
>  .TP 7
>  This optional entry allows an IRQ number to be specified.
> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
> index 3f9857b4a..fa404d9d4 100644
> --- a/hw/xfree86/modes/xf86Crtc.c
> +++ b/hw/xfree86/modes/xf86Crtc.c
> @@ -469,10 +469,12 @@ static OptionInfoRec xf86OutputOptions[] = {
>
>  enum {
>  OPTION_MODEDEBUG,
> +OPTION_PREFER_CLONEMODE,
>  };
>
>  static OptionInfoRec xf86DeviceOptions[] = {
>  {OPTION_MODEDEBUG, "ModeDebug", OPTV_BOOLEAN, {0}, FALSE},
> +{OPTION_PREFER_CLONEMODE, "PreferCloneMode", OPTV_BOOLEAN, {0}, FALSE},
>  {-1, NULL, OPTV_NONE, {0}, FALSE},
>  };
>
> @@ -2134,6 +2136,8 @@ xf86TargetRightOf(ScrnInfoPtr scrn, xf86CrtcConfigPtr 
> config,
>  Bool has_tile = FALSE;
>  uint32_t configured_outputs;
>
> +xf86GetOptValBool(config->options, OPTION_PREFER_CLONEMODE,
> +  >preferClone);
>  if (scrn->preferClone)
>  return FALSE;
>
> --
> 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
___
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] modesetting: Add the "DPI" connector type.

[Alex Deucher]

On Tue, Apr 25, 2017 at 2:36 PM, Eric Anholt <e...@anholt.net> wrote:
> The number for it was merged to drm_mode.h in kernel 4.7, and the
> output_names[] array just requires that we slot in new strings in
> order.
>
> Signed-off-by: Eric Anholt <e...@anholt.net>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 516eb7691507..bbca8ca704a5 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -1621,6 +1621,7 @@ static const char *const output_names[] = {
>  "eDP",
>  "Virtual",
>  "DSI",
> +"DPI",
>  };
>
>  static xf86OutputPtr find_output(ScrnInfoPtr pScrn, int id)
> --
> 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
___
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] xfree86/modes: Make colormap/gamma glue code work with RandR disabled

[Alex Deucher]

On Wed, Apr 12, 2017 at 5:34 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> E.g. because Xinerama is enabled.
>
> Fixes crash on startup and wrong colours in that case.
>
> Bugzilla: https://bugs.freedesktop.org/100293
> Bugzilla: https://bugs.freedesktop.org/100294
> Fixes: 62f44052573b ("xfree86/modes: Move gamma initialization to
>   xf86RandR12Init12 v2")
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/modes/xf86RandR12.c | 136 
> +++--
>  1 file changed, 91 insertions(+), 45 deletions(-)
>
> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
> index 900048df9..55d88e331 100644
> --- a/hw/xfree86/modes/xf86RandR12.c
> +++ b/hw/xfree86/modes/xf86RandR12.c
> @@ -1246,33 +1246,50 @@ xf86RandR12CrtcSet(ScreenPtr pScreen,
>  }
>
>  static void
> -xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, RRCrtcPtr randr_crtc)
> +xf86RandR12CrtcComputeGamma(xf86CrtcPtr crtc, LOCO *palette,
> +int palette_red_size, int palette_green_size,
> +int palette_blue_size, CARD16 *gamma_red,
> +CARD16 *gamma_green, CARD16 *gamma_blue,
> +int gamma_size)
>  {
> -XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
> -xf86CrtcPtr crtc = randr_crtc->devPrivate;
>  int gamma_slots;
> -CARD16 value;
> +unsigned shift;
> +CARD32 value;
>  int i, j;
>
> -gamma_slots = crtc->gamma_size / randrp->palette_red_size;
> -for (i = 0; i < randrp->palette_red_size; i++) {
> -value = randr_crtc->gammaRed[randrp->palette[i].red];
> +for (shift = 0; (gamma_size << shift) < (1 << 16); shift++);
> +
> +gamma_slots = crtc->gamma_size / palette_red_size;
> +for (i = 0; i < palette_red_size; i++) {
> +value = palette[i].red;
> +if (gamma_red)
> +value = gamma_red[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_red[i * gamma_slots + j] = value;
>  }
>
> -gamma_slots = crtc->gamma_size / randrp->palette_green_size;
> -for (i = 0; i < randrp->palette_green_size; i++) {
> -value = randr_crtc->gammaGreen[randrp->palette[i].green];
> +gamma_slots = crtc->gamma_size / palette_green_size;
> +for (i = 0; i < palette_green_size; i++) {
> +value = palette[i].green;
> +if (gamma_green)
> +value = gamma_green[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_green[i * gamma_slots + j] = value;
>  }
>
> -gamma_slots = crtc->gamma_size / randrp->palette_blue_size;
> -for (i = 0; i < randrp->palette_blue_size; i++) {
> -value = randr_crtc->gammaBlue[randrp->palette[i].blue];
> +gamma_slots = crtc->gamma_size / palette_blue_size;
> +for (i = 0; i < palette_blue_size; i++) {
> +value = palette[i].blue;
> +if (gamma_blue)
> +value = gamma_blue[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_blue[i * gamma_slots + j] = value;
> @@ -1280,10 +1297,8 @@ xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, 
> RRCrtcPtr randr_crtc)
>  }
>
>  static void
> -xf86RandR12CrtcReloadGamma(RRCrtcPtr randr_crtc)
> +xf86RandR12CrtcReloadGamma(xf86CrtcPtr crtc)
>  {
> -xf86CrtcPtr crtc = randr_crtc->devPrivate;
> -
>  if (!crtc->scrn->vtSema || !crtc->funcs->gamma_set)
>  return;
>
> @@ -1305,7 +1320,14 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
> randr_crtc)
>  return FALSE;
>
>  if (randrp->palette_size) {
> -xf86RandR12CrtcComputeGamma(pScreen, randr_crtc);
> +xf86RandR12CrtcComputeGamma(crtc, randrp->palette,
> +randrp->palette_red_size,
> +randrp->palette_green_size,
> +randrp->palette_blue_size,
> +randr_crtc->gammaRed,
> +randr_crtc->gammaGreen,
> +randr_crtc->gammaBlue,
> +randr_crtc-&

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Alex Deucher]

On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter  wrote:
> On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
>> Daniel Vetter  writes:
>>
>> > Also if this confuses VR, then another reason why we want to make leases
>> > invariant and only allow pure revoke, not changing the list.
>>
>> I'm not sure why you want this to be asymmetrical, nor why you would
>> expect lessees to be any more competent at dealing with hotplug than the
>> lessor.
>>
>> One use case already proposed for this API was to allow for multi-seat,
>> where the lessee would be an existing window system, which we already
>> accept as being incompetent at dealing with resource hotplug. I imagine
>> that in this case, a newly plugged monitor would be detected by the
>> multi-seat manager (logind?) and added to one of the existing leases,
>> along with a suitable CRTC resource. For this to work, the lessee will
>> need to already know about those resources and only have their
>> connectivity status hidden.
>
> The multi-seat thing sounds like vapourware, I think we should care about
> the vr use-case for now, and only that one. And for that restricting stuff
> is perfectly fine. Of course we can design the entire thing in a way that
> doesn't draw us into a corner in the future right away, but that's mostly
> on the implementation side. For VR itself I'd go as far as saying that
> probably our "create lease" ioctl should have only the semantics we need
> to pass one crtc+primary plane for pageflipping in a VR compositor,
> expressed in a flag. All the details about additional corner cases are
> just so unclear to me (and there's not even a clear use case that will
> materialize) that I don't think having the uapi is worth it. Too close to
> the "I'll regret this immediately" bucket :-)
>

I don't know about vaprware.  There were a number of attempts to
provide static allocation if display resources over the years to solve
things like custom zaphod configs and users wanting to use multiple
heads for separate users (which currently ends up in various zephyr
hacks IRC).  Lots of patches were proposed, none landed.  I think
there is a definite use case there.  Why do we need to make X aware of
the lease stuff?  What about having some pre-X configuration that
decides how to split up the display resources.  It could be user
defined static or dynamic based on what is attached.  You can just
start X on the device nodes with whatever resources they are assigned.
In the multi-user case, you can statically assign resources to each
node; in the VR case, you can detect the HMD and automatically assign
it's resources to a separate node or override if necessary.

Alex
___
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: voting confirmation

[Alex Deucher]

On Thu, Apr 6, 2017 at 10:39 AM, Antoine Martin  wrote:
> Hi,
>
> Apologies for sending an image link to this list, but I can't think of a
> better way to explain the somewhat confusing page that showed up after I
> cast my ballot:
> http://imgur.com/r8nSblg
> Did it take my vote into account? Did I actually vote? And not for "".
> I had agreed to the changed membership agreement, but again it shows "".

Yes, the votes were cast properly.

Alex
___
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] xf86_crtc_supports_gamma: Return FALSE if RandR is disabled

[Alex Deucher]

On Wed, Apr 5, 2017 at 11:23 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> E.g. becuase Xinerama is enabled.
>
> Fixes crash on server startup when RandR is disabled and all other
> conditions in xf86_crtc_supports_gamma are satisfied.
>
> Bugzilla: https://bugs.freedesktop.org/100293
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/modes/xf86Crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
> index 3f9857b4a..9ce303de7 100644
> --- a/hw/xfree86/modes/xf86Crtc.c
> +++ b/hw/xfree86/modes/xf86Crtc.c
> @@ -3405,7 +3405,8 @@ xf86_crtc_notify(ScreenPtr screen)
>  Bool
>  xf86_crtc_supports_gamma(ScrnInfoPtr pScrn)
>  {
> -if (xf86CrtcConfigPrivateIndex != -1) {
> +if (dixPrivateKeyRegistered(rrPrivKey) &&
> +xf86CrtcConfigPrivateIndex != -1) {
>  xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
>  xf86CrtcPtr crtc;
>
> --
> 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
___
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] Xephyr: Handle source-only pictures in ephyrPrepare/DoneComposite

[Alex Deucher]

On Wed, Mar 22, 2017 at 11:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> There is no pixmap associated with source-only pictures.
>
> Fixes Xephyr -fakexa crashing on startup.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/kdrive/ephyr/ephyr_draw.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/kdrive/ephyr/ephyr_draw.c b/hw/kdrive/ephyr/ephyr_draw.c
> index 5b8a1d504..66371334a 100644
> --- a/hw/kdrive/ephyr/ephyr_draw.c
> +++ b/hw/kdrive/ephyr/ephyr_draw.c
> @@ -254,7 +254,8 @@ ephyrPrepareComposite(int op, PicturePtr pSrcPicture, 
> PicturePtr pMaskPicture,
>  EphyrFakexaPriv *fakexa = scrpriv->fakexa;
>
>  ephyrPreparePipelinedAccess(pDst, EXA_PREPARE_DEST);
> -ephyrPreparePipelinedAccess(pSrc, EXA_PREPARE_SRC);
> +if (pSrc != NULL)
> +ephyrPreparePipelinedAccess(pSrc, EXA_PREPARE_SRC);
>  if (pMask != NULL)
>  ephyrPreparePipelinedAccess(pMask, EXA_PREPARE_MASK);
>
> @@ -298,7 +299,8 @@ ephyrDoneComposite(PixmapPtr pDst)
>
>  if (fakexa->pMask != NULL)
>  ephyrFinishPipelinedAccess(fakexa->pMask, EXA_PREPARE_MASK);
> -ephyrFinishPipelinedAccess(fakexa->pSrc, EXA_PREPARE_SRC);
> +if (fakexa->pSrc != NULL)
> +ephyrFinishPipelinedAccess(fakexa->pSrc, EXA_PREPARE_SRC);
>  ephyrFinishPipelinedAccess(fakexa->pDst, EXA_PREPARE_DEST);
>  }
>
> --
> 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
___
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] glamor: Always purge the FBO cache in BlockHandler

[Alex Deucher]

On Fri, Mar 3, 2017 at 3:46 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Or if the cache watermark is reached, whichever comes earlier.
>
> This slightly simplifies the FBO cache management, and prevents it from
> potentially holding entries for a long time, while preserving the main
> benefit of the cache for bursts of drawing operations.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor.c  |  6 ++
>  glamor/glamor_fbo.c  | 24 
>  glamor/glamor_priv.h |  6 --
>  3 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/glamor/glamor.c b/glamor/glamor.c
> index feae7a21f..1a0fc4318 100644
> --- a/glamor/glamor.c
> +++ b/glamor/glamor.c
> @@ -254,9 +254,7 @@ glamor_block_handler(ScreenPtr screen)
>  glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
>
>  glamor_make_current(glamor_priv);
> -glamor_priv->tick++;
>  glFlush();
> -glamor_fbo_expire(glamor_priv);
>  }
>
>  static void
> @@ -264,8 +262,8 @@ _glamor_block_handler(ScreenPtr screen, void *timeout)
>  {
>  glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
>
> -glamor_make_current(glamor_priv);
> -glFlush();
> +glamor_block_handler(screen);
> +glamor_fbo_expire(glamor_priv);
>
>  screen->BlockHandler = glamor_priv->saved_procs.block_handler;
>  screen->BlockHandler(screen, timeout);
> diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
> index a531f6052..c40de9bd1 100644
> --- a/glamor/glamor_fbo.c
> +++ b/glamor/glamor_fbo.c
> @@ -30,11 +30,6 @@
>
>  #include "glamor_priv.h"
>
> -#define GLAMOR_CACHE_EXPIRE_MAX 100
> -
> -#define GLAMOR_CACHE_DEFAULT0
> -#define GLAMOR_CACHE_EXACT_SIZE 1
> -
>  //#define NO_FBO_CACHE 1
>  #define FBO_CACHE_THRESHOLD  (256*1024*1024)
>
> @@ -155,9 +150,13 @@ glamor_pixmap_fbo_cache_put(glamor_screen_private 
> *glamor_priv,
>  #else
>  n_format = cache_format(fbo->format);
>
> -if (fbo->fb == 0 || fbo->external || n_format == -1
> -|| glamor_priv->fbo_cache_watermark >= FBO_CACHE_THRESHOLD) {
> -glamor_priv->tick += GLAMOR_CACHE_EXPIRE_MAX;
> +if (fbo->fb == 0 || fbo->external || n_format == -1) {
> +glamor_purge_fbo(glamor_priv, fbo);
> +return;
> +}
> +
> +glamor_priv->fbo_cache_watermark += fbo->width * fbo->height;
> +if (glamor_priv->fbo_cache_watermark >= FBO_CACHE_THRESHOLD) {
>  glamor_fbo_expire(glamor_priv);
>  glamor_purge_fbo(glamor_priv, fbo);
>  return;
> @@ -182,9 +181,7 @@ glamor_pixmap_fbo_cache_put(glamor_screen_private 
> *glamor_priv,
>  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_A, GL_ALPHA);
>  }
>
> -glamor_priv->fbo_cache_watermark += fbo->width * fbo->height;
>  xorg_list_add(>list, cache);
> -fbo->expire = glamor_priv->tick + GLAMOR_CACHE_EXPIRE_MAX;
>  #endif
>  }
>
> @@ -281,12 +278,6 @@ glamor_fbo_expire(glamor_screen_private *glamor_priv)
>  cache = _priv->fbo_cache[i][j][k];
>  xorg_list_for_each_entry_safe_reverse(fbo_entry, tmp, cache,
>list) {
> -if (GLAMOR_TICK_AFTER(fbo_entry->expire, 
> glamor_priv->tick)) {
> -break;
> -}
> -
> -glamor_priv->fbo_cache_watermark -=
> -fbo_entry->width * fbo_entry->height;
>  xorg_list_del(_entry->list);
>  DEBUGF("cache %p fbo %p expired %d current %d \n", cache,
> fbo_entry, fbo_entry->expire, glamor_priv->tick);
> @@ -294,6 +285,7 @@ glamor_fbo_expire(glamor_screen_private *glamor_priv)
>  }
>  }
>
> +glamor_priv->fbo_cache_watermark = 0;
>  }
>
>  void
> diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
> index a9377ace1..ad7afec7e 100644
> --- a/glamor/glamor_priv.h
> +++ b/glamor/glamor_priv.h
> @@ -189,11 +189,7 @@ struct glamor_saved_procs {
>  #define CACHE_BUCKET_WCOUNT 4
>  #define CACHE_BUCKET_HCOUNT 4
>
> -#define GLAMOR_TICK_AFTER(t0, t1)  \
> -   (((int)(t1) - (int)(t0)) < 0)
> -
>  typedef struct glamor_screen_private {
> -unsigned int tick;
>  enum glamor_gl_flavor gl_flavor;
>  int glsl_version;
>  Boo

2017 X.Org Foundation Membership deadline for voting in the election

[Alex Deucher]

The 2017 X.Org Foundation elections are rapidly approaching. We will
be forwarding the election schedule and nominating process to the
membership shortly.

Please note that only current members can vote in the upcoming
election, and that the deadline for new memberships or renewals to
vote in the upcoming election is 05 March 2017 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:
https://members.x.org/

Alex Deucher, on behalf of the X.Org elections committee
___
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 5/5] mi: Add include guards to migc.h

[Alex Deucher]

On Thu, Feb 16, 2017 at 1:03 PM, Adam Jackson <a...@redhat.com> wrote:
> Signed-off-by: Adam Jackson <a...@redhat.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  mi/migc.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/mi/migc.h b/mi/migc.h
> index 8d06a6f..add601a 100644
> --- a/mi/migc.h
> +++ b/mi/migc.h
> @@ -26,6 +26,9 @@ from The Open Group.
>
>  */
>
> +#ifndef _MIGC_H
> +#define _MIGC_H
> +
>  extern _X_EXPORT void miChangeGC(GCPtr  pGC,
>   unsigned long  mask);
>
> @@ -47,3 +50,5 @@ extern _X_EXPORT void miCopyGC(GCPtrpGCSrc,
>
>  extern _X_EXPORT void miComputeCompositeClip(GCPtr  pGC,
>   DrawablePtrpDrawable);
> +
> +#endif
> --
> 2.9.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
___
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/3] xfake: Remove

[Alex Deucher]

On Thu, Feb 16, 2017 at 12:46 PM, Adam Jackson <a...@redhat.com> wrote:
> We already have Xvfb for a dummy DDX.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Seems reasonable to me.  Series is:
Acked-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  configure.ac   |   3 -
>  hw/kdrive/Makefile.am  |   9 +-
>  hw/kdrive/fake/.gitignore  |   2 -
>  hw/kdrive/fake/Makefile.am |  31 
>  hw/kdrive/fake/fake.c  | 444 
> -
>  hw/kdrive/fake/fake.h  | 131 -
>  hw/kdrive/fake/fakeinit.c  | 119 
>  hw/kdrive/fake/kbd.c   |  75 
>  hw/kdrive/fake/mouse.c |  64 ---
>  hw/kdrive/fake/os.c|  62 ---
>  10 files changed, 2 insertions(+), 938 deletions(-)
>  delete mode 100644 hw/kdrive/fake/.gitignore
>  delete mode 100644 hw/kdrive/fake/Makefile.am
>  delete mode 100644 hw/kdrive/fake/fake.c
>  delete mode 100644 hw/kdrive/fake/fake.h
>  delete mode 100644 hw/kdrive/fake/fakeinit.c
>  delete mode 100644 hw/kdrive/fake/kbd.c
>  delete mode 100644 hw/kdrive/fake/mouse.c
>  delete mode 100644 hw/kdrive/fake/os.c
>
> diff --git a/configure.ac b/configure.ac
> index 4dcf8b5..f801858 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -655,7 +655,6 @@ AC_ARG_ENABLE(glamor, 
> AS_HELP_STRING([--enable-glamor], [Build glamor di
>  dnl kdrive and its subsystems
>  AC_ARG_ENABLE(kdrive, AS_HELP_STRING([--enable-kdrive], [Build 
> kdrive servers (default: no)]), [KDRIVE=$enableval], [KDRIVE=no])
>  AC_ARG_ENABLE(xephyr, AS_HELP_STRING([--enable-xephyr], [Build the 
> kdrive Xephyr server (default: auto)]), [XEPHYR=$enableval], [XEPHYR=auto])
> -AC_ARG_ENABLE(xfake,  AS_HELP_STRING([--enable-xfake], [Build the 
> kdrive 'fake' server (default: auto)]), [XFAKE=$enableval], [XFAKE=auto])
>  AC_ARG_ENABLE(xfbdev, AS_HELP_STRING([--enable-xfbdev], [Build the 
> kdrive framebuffer device server (default: auto)]), [XFBDEV=$enableval], 
> [XFBDEV=auto])
>  dnl kdrive options
>  AC_ARG_ENABLE(kdrive-evdev,   AS_HELP_STRING([--enable-kdrive-evdev], [Build 
> evdev driver for kdrive (default: auto)]), [KDRIVE_EVDEV=$enableval], 
> [KDRIVE_EVDEV=auto])
> @@ -2471,7 +2470,6 @@ AM_CONDITIONAL(TSLIB, [test "x$HAVE_TSLIB" = xyes])
>  AM_CONDITIONAL(KDRIVEFBDEV, [test "x$XFBDEV" = xyes])
>  AM_CONDITIONAL(XEPHYR, [test "x$KDRIVE" = xyes && test "x$XEPHYR" = xyes])
>  AM_CONDITIONAL(BUILD_KDRIVEFBDEVLIB, [test "x$KDRIVE" = xyes && test 
> "x$KDRIVEFBDEVLIB" = xyes])
> -AM_CONDITIONAL(XFAKESERVER, [test "x$KDRIVE" = xyes && test "x$XFAKE" = 
> xyes])
>
>  dnl Xwayland DDX
>
> @@ -2652,7 +2650,6 @@ hw/xquartz/xpr/Makefile
>  hw/kdrive/Makefile
>  hw/kdrive/ephyr/Makefile
>  hw/kdrive/ephyr/man/Makefile
> -hw/kdrive/fake/Makefile
>  hw/kdrive/fbdev/Makefile
>  hw/kdrive/linux/Makefile
>  hw/kdrive/src/Makefile
> diff --git a/hw/kdrive/Makefile.am b/hw/kdrive/Makefile.am
> index 471ca89..eee3f0c 100644
> --- a/hw/kdrive/Makefile.am
> +++ b/hw/kdrive/Makefile.am
> @@ -2,10 +2,6 @@ if BUILD_KDRIVEFBDEVLIB
>  FBDEV_SUBDIRS = fbdev
>  endif
>
> -if XFAKESERVER
> -XFAKE_SUBDIRS = fake
> -endif
> -
>  if XEPHYR
>  XEPHYR_SUBDIRS = ephyr
>  endif
> @@ -16,15 +12,14 @@ endif
>
>  SERVER_SUBDIRS =   \
> $(FBDEV_SUBDIRS)\
> -   $(XEPHYR_SUBDIRS)   \
> -   $(XFAKE_SUBDIRS)
> +   $(XEPHYR_SUBDIRS)
>
>  SUBDIRS =  \
> src \
> $(LINUX_SUBDIRS)\
> $(SERVER_SUBDIRS)
>
> -DIST_SUBDIRS = fbdev ephyr src linux fake
> +DIST_SUBDIRS = fbdev ephyr src linux
>
>  relink:
> $(AM_V_at)for i in $(SERVER_SUBDIRS) ; do $(MAKE) -C $$i relink || 
> exit 1 ; done
> diff --git a/hw/kdrive/fake/.gitignore b/hw/kdrive/fake/.gitignore
> deleted file mode 100644
> index 12a25cc..000
> --- a/hw/kdrive/fake/.gitignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -#  Add & Override for this directory and it's subdirectories
> -Xfake
> diff --git a/hw/kdrive/fake/Makefile.am b/hw/kdrive/fake/Makefile.am
> deleted file mode 100644
> index d28bd27..000
> --- a/hw/kdrive/fake/Makefile.am
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -AM_CPPFLAGS =  \
> -   @KDRIVE_INCS@   \
> -   @KDRIVE_CFLAGS@
> -
> -noinst_LTLIBRARIES = libfake.la
> -
> -bin_PROGRAMS = Xfake
> -
> -libfake_la_SOURCES =   

Re: [PATCH 0/7] ScrnInfoRec cleanup

[Alex Deucher]

On Tue, Feb 14, 2017 at 3:30 PM, Adam Jackson <a...@redhat.com> wrote:
> ScrnInfoRec is xfree86's subclass of ScreenRec. It's... showing its age.
> Much of it is only relevant to the pre-PCI world where probing the
> hardware was fraught with uncertainty and configuration overrides were
> common. This is a first cut at cleaning it up a bit, mostly dropping
> unused or under-used fields. A few of these changes (noted in the commit
> messages) will require minor driver fixes; I'll be happy to do those
> before merging the series.
>
> One big change I'd like to follow this with is removing fixed dotclock
> support, on the way to unifying the pre- and post-RANDR-1.2 setup paths.
> As far as I can tell this would only affect a few ancient mach64, trident,
> or chips (ahem) chips. Quite possibly all of them are already unsupported
> because they're not PCI.

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  common/xf86Config.c|1 -
>  common/xf86Configure.c |1 -
>  common/xf86Mode.c  |   26 ++
>  common/xf86str.h   |   42 --
>  doc/ddxDesign.xml  |   48 
> 
>  man/xorg.conf.man  |6 --
>  parser/Device.c|8 
>  parser/xf86Parser.h|1 -
>  parser/xf86tokens.h|1 -
>  9 files changed, 10 insertions(+), 124 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
___
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 v2] damage: Validate source pictures bound to windows before unwrapping

[Alex Deucher]

On Wed, Feb 8, 2017 at 1:06 PM, Adam Jackson <a...@nwnk.net> wrote:
> On Tue, 2017-02-07 at 11:57 -0500, Alex Deucher wrote:
>> On Tue, Feb 7, 2017 at 3:38 AM, Michel Dänzer <mic...@daenzer.net>
>> wrote:
>> > From: Michel Dänzer <michel.daen...@amd.com>
>> >
>> > The lower layers also do this, but no damage may be reported there,
>> > since we unwrap before calling down.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99220
>> > Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>>
>> Makes sense to me.
>> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
>
> Mmm. I might like the original patch better, I think I'd rather have
> composite be aware of how damage works than damage be aware of every
> possible way a caller might abuse it. So I reserve the right to flip
> this back the other way at some point in the future, if we ever get
> around to dix-level damage.

No objections from me.  I don't have a strong preference.

Alex

>
> But this does work, and I do give preference to patches that other
> people review instead of things I have to review as the last resort,
> so, merged:
>
> remote: I: patch #137290 updated using rev 
> 38696ea56854e055c31bd2730adfc7c39aa115b0.
> remote: I: 1 patch(es) updated to state Accepted.
> To ssh://git.freedesktop.org/git/xorg/xserver
>1c78bec..38696ea  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 v2] damage: Validate source pictures bound to windows before unwrapping

[Alex Deucher]

On Tue, Feb 7, 2017 at 3:38 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> The lower layers also do this, but no damage may be reported there,
> since we unwrap before calling down.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99220
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Makes sense to me.
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>
> v2: Update code comment
>
> This is an alternative to https://patchwork.freedesktop.org/patch/136721/ .
>
>  configure.ac  |  2 +-
>  miext/damage/damage.c | 10 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 95aa297da..4dcf8b5c2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1847,7 +1847,7 @@ if test "x$XNEST" = xyes; then
> if test "x$have_xnest" = xno; then
> AC_MSG_ERROR([Xnest build explicitly requested, but required 
> modules not found.])
> fi
> -   XNEST_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB 
> $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB  $DRI3_LIB $PRESENT_LIB 
> $MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB 
> $XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
> +   XNEST_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB 
> $GLX_LIBS $RANDR_LIB $DAMAGE_LIB  $DRI3_LIB $PRESENT_LIB $MIEXT_SYNC_LIB 
> $MIEXT_DAMAGE_LIB $RENDER_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB 
> $XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
> XNEST_SYS_LIBS="$XNESTMODULES_LIBS $GLX_SYS_LIBS"
> AC_SUBST([XNEST_LIBS])
> AC_SUBST([XNEST_SYS_LIBS])
> diff --git a/miext/damage/damage.c b/miext/damage/damage.c
> index d6a36142d..2fae03fc2 100644
> --- a/miext/damage/damage.c
> +++ b/miext/damage/damage.c
> @@ -34,6 +34,7 @@
>  #include
>  #include
>  #include"mi.h"
> +#include"mipict.h"
>  #include"regionstr.h"
>  #include"globals.h"
>  #include"gcstruct.h"
> @@ -499,6 +500,15 @@ damageComposite(CARD8 op,
>  if (BOX_NOT_EMPTY(box))
>  damageDamageBox(pDst->pDrawable, , pDst->subWindowMode);
>  }
> +/*
> + * Validating a source picture bound to a window may trigger other
> + * composite operations. Do it before unwrapping to make sure damage
> + * is reported correctly.
> + */
> +if (pSrc->pDrawable && WindowDrawable(pSrc->pDrawable->type))
> +miCompositeSourceValidate(pSrc);
> +if (pMask && pMask->pDrawable && WindowDrawable(pMask->pDrawable->type))
> +miCompositeSourceValidate(pMask);
>  unwrap(pScrPriv, ps, Composite);
>  (*ps->Composite) (op,
>pSrc,
> --
> 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
___
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

X.Org Foundation Membership Renewal

[Alex Deucher]

On January 19th all xorg members were expired as part of the regular
process to remove inactive members.  If you would still like to be a
member of the X.Org Foundation, please renew your membership.  To
renew or to become a first time member, go to https://members.x.org/ .
For renewals, log in and click the renewal link.  For new members,
click the Join Now link.  The X.org Foundation is a non-profit
organization under the SPI umbrella which acts as a steward for the X
Window System and related projects.  Board elections are coming up so
renew or join today!

Thanks!

Alex Deucher
___
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/2] present: Allow flipping with PRIME slave outputs

[Alex Deucher]

On Wed, Feb 1, 2017 at 4:35 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Turned out to be easier than I thought, and doesn't require any ABI
> changes.
>
> Michel Dänzer (2):
>   prime: Sync shared pixmap from root window instead of screen pixmap
>   present: Allow flipping with PRIME slave outputs

For the series:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  dix/pixmap.c  | 16 
>  present/present.c | 16 
>  2 files changed, 12 insertions(+), 20 deletions(-)
>
> --
> 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
___
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 v2 xserver 00/11] modesetting: MS_ALL_IN_ONE

[Alex Deucher]

On Mon, Jan 9, 2017 at 3:27 AM, Hans de Goede  wrote:
> Hi,
>
> On 09-01-17 02:52, Yu, Qiang wrote:
>>
>>
>> Hi Hans,
>>
>> I forgot there is another difference, PRIME solution has to copy screen
>> once before display
>> to iGPU while MS_ALL_IN_ONE don't have to and can display what full screen
>> app draws
>> directly by page flip (for DRI2) which may be important for embedded
>> platforms with week
>> GPU and limited memory bandwidths.
>
>
> Hmm, I guess you're talking imx6 + etnaviv now right, because with a
> discrete GPU
> + iGPU displaying the rendered frame, we are always going to need one copy
> from
> discrete-GPU RAM to system RAM. But I agree that getting rid of the extra
> copy for
> imx6 would be really good, I even dare to call it a must-have feature.

Qiang can correct me if I'm wrong, but I think there are some cases
where it makes more sense for the dGPU to directly access system
memory rather than use vram and copy.

Alex

>
>> Benefit from common interface of drm/gbm/egl, may be modesetting can play
>> a bigger role
>> of span multi drm devices to give more optimization like this and:
>> 1. multi render node, a single protocol screen to accept request and
>> dispatch to each render
>> node for render
>> 2. multi display node associate with the render node (some display node
>> has the same drm
>> device with render node), so no need to handle bo tile-linear copy and
>> each render node can
>> handle request of its related display node.
>
>
> Ack I agree that we would need to do better here, but I don't believe this
> should be some
> special mode activated by some special means, e.g. in the imx6 + etnaviv
> case the modesetting
> driver should simply recognize that they are sharing RAM and use
> page-flipping (passing buffer
> ownership between the 2) rather then copying, without the user needing to do
> anything
> special.
>
> Regards,
>
> Hans
>
> ___
> 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

Re: [PATCH xserver v2] present: Only call present_flip_notify if vblank->queued == FALSE

[Alex Deucher]

On Sat, Jan 7, 2017 at 3:36 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>
> Any takers?
>
> In the absence of a negative review, I'll push this next week, since
> more people are running into this.


Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>
> On 28/11/16 10:54 AM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> We are no longer using the present_flip_queue list only for presents
>> which have already been submitted to the driver for page flipping, but
>> also for those which we are queueing up to be flipped later, marked
>> with vblank->queued == TRUE. We were incorrectly calling
>> present_flip_notify for such entries, failing the assertion in
>> present_flip_notify (or presumably resulting in other undesirable
>> behaviour with assertions disabled).
>>
>> Reproduction recipe: Run the JavaFX test case referenced by
>> https://bugs.freedesktop.org/show_bug.cgi?id=98831#c6 and alt-tab out
>> of it while it's fullscreen. May take a few attempts to hit the
>> assertion failure.
>>
>> Fixes: bab0f450a719 ("present: Fix presentation of flips out of order")
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98854
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>> ---
>>
>> v2: Add bugzilla reference
>>
>>  present/present.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/present/present.c b/present/present.c
>> index a7ca06e..ef89045 100644
>> --- a/present/present.c
>> +++ b/present/present.c
>> @@ -536,7 +536,10 @@ present_event_notify(uint64_t event_id, uint64_t ust, 
>> uint64_t msc)
>>  }
>>  xorg_list_for_each_entry(vblank, _flip_queue, event_queue) {
>>  if (vblank->event_id == event_id) {
>> -present_flip_notify(vblank, ust, msc);
>> +if (vblank->queued)
>> +present_execute(vblank, ust, msc);
>> +else
>> +present_flip_notify(vblank, ust, msc);
>>  return;
>>  }
>>  }
>>
>
>
> --
> 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
___
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 fbdev] Fix shadow fb allocation size (v2)

[Alex Deucher]

On Wed, Jan 4, 2017 at 10:30 AM, Adam Jackson <a...@redhat.com> wrote:
> ->bitsPerPixel is rather obviously eight times too large.
>
> v2: Use ->displayWidth - the pitch - not ->virtualX (Keith Packard)
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  src/fbdev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/fbdev.c b/src/fbdev.c
> index 2c658fe..4309d76 100644
> --- a/src/fbdev.c
> +++ b/src/fbdev.c
> @@ -827,8 +827,8 @@ FBDevScreenInit(SCREEN_INIT_ARGS_DECL)
> fPtr->fbstart = fPtr->fbmem + fPtr->fboff;
>
> if (fPtr->shadowFB) {
> -   fPtr->shadow = calloc(1, pScrn->virtualX * pScrn->virtualY *
> - pScrn->bitsPerPixel);
> +   fPtr->shadow = calloc(1, pScrn->displayWidth * pScrn->virtualY *
> + ((pScrn->bitsPerPixel + 7) / 8));
>
> if (!fPtr->shadow) {
> xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> --
> 2.9.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
___
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 fbdev] Fix shadow fb allocation size

[Alex Deucher]

On Tue, Jan 3, 2017 at 4:25 PM, Adam Jackson <a...@redhat.com> wrote:
> ->bitsPerPixel is rather obviously eight times too large.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  src/fbdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/fbdev.c b/src/fbdev.c
> index 2c658fe..dbc09bf 100644
> --- a/src/fbdev.c
> +++ b/src/fbdev.c
> @@ -828,7 +828,7 @@ FBDevScreenInit(SCREEN_INIT_ARGS_DECL)
>
> if (fPtr->shadowFB) {
> fPtr->shadow = calloc(1, pScrn->virtualX * pScrn->virtualY *
> - pScrn->bitsPerPixel);
> + ((pScrn->bitsPerPixel + 7) / 8));
>
> if (!fPtr->shadow) {
> xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> --
> 2.9.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
___
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] edid: Add quirk for ADA 1024x600 7" display.

[Alex Deucher]

On Thu, Dec 15, 2016 at 12:56 AM, Kai-Heng Feng
<kai.heng.f...@canonical.com> wrote:
> Detailed mode reports 108 mm x 68 mm which is for smaller display.
> Maximum image size reports 15 cm x 10 cm which aligns with its physical
> size, use this size instead.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.f...@canonical.com>

Acked-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/modes/xf86EdidModes.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/hw/xfree86/modes/xf86EdidModes.c 
> b/hw/xfree86/modes/xf86EdidModes.c
> index f24294e..f0e1e97 100644
> --- a/hw/xfree86/modes/xf86EdidModes.c
> +++ b/hw/xfree86/modes/xf86EdidModes.c
> @@ -153,6 +153,11 @@ quirk_detailed_v_in_cm(int scrnIndex, xf86MonPtr DDC)
>  static Bool
>  quirk_detailed_use_maximum_size(int scrnIndex, xf86MonPtr DDC)
>  {
> +/* ADA 1024x600 7" display */
> +if (memcmp(DDC->vendor.name, "ADA", 4) == 0 &&
> +DDC->vendor.prod_id == 4)
> +return TRUE;
> +
>  /* Bug #21324: Iiyama Vision Master 450 */
>  if (memcmp(DDC->vendor.name, "IVM", 4) == 0 && DDC->vendor.prod_id == 
> 6400)
>  return TRUE;
> --
> 2.10.2
>
> ___
> 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

Re: [PATCH cirrus] alpine: Default to 16bpp

[Alex Deucher]

On Thu, Dec 8, 2016 at 9:39 AM, Adam Jackson <a...@redhat.com> wrote:
> 24bpp support is going away, so since we can't do 32bpp and these cards
> have basically no VRAM to begin with, drop to 16bpp.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  src/alp_driver.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/src/alp_driver.c b/src/alp_driver.c
> index 39802de..60c5edd 100644
> --- a/src/alp_driver.c
> +++ b/src/alp_driver.c
> @@ -454,7 +454,6 @@ AlpPreInit(ScrnInfoPtr pScrn, int flags)
> vgaHWPtr hwp;
> MessageType from, from1;
> int i;
> -   int defaultdepth;
> int depth_flags;
> ClockRangePtr clockRanges;
> char *s;
> @@ -541,22 +540,11 @@ AlpPreInit(ScrnInfoPtr pScrn, int flags)
>SupportConvert32to24 |
>PreferConvert32to24;
>
> -   /* use 16bpp in virt and on XenSource */
> -   #ifndef PCI_CHIP_QEMU
> -   #define PCI_CHIP_QEMU 0x1af4
> -   #endif
> -   #define PCI_CHIP_XENSOURCE 0x5853
> -   if (((pCir->PciInfo->subvendor_id & 0x) == PCI_CHIP_QEMU) ||
> -   ((pCir->PciInfo->subvendor_id & 0x) == PCI_CHIP_XENSOURCE))
> -   defaultdepth = 16;
> -   else
> -   defaultdepth = 24;
> -
> /*
>  * The first thing we should figure out is the depth, bpp, etc.
>  * We support both 24bpp and 32bpp layouts, so indicate that.
>  */
> -   if (!xf86SetDepthBpp(pScrn, 0, 0, defaultdepth, depth_flags)) {
> +   if (!xf86SetDepthBpp(pScrn, 0, 0, 16, depth_flags)) {
> return FALSE;
> } else {
> /* Check that the returned depth is one we support */
> --
> 2.9.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
___
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] DRI2: Sync radeonsi_pci_ids.h from Mesa

[Alex Deucher]

On Mon, Oct 17, 2016 at 5:48 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Fixes DRI2 client driver name mapping for newer AMD GPUs with the
> modesetting driver, allowing the DRI2 extension to initialize.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index 4df8e9d..20c1583 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -184,12 +184,24 @@ CHIPSET(0x7300, FIJI_, FIJI)
>
>  CHIPSET(0x67E0, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E1, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E3, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E7, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E8, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E9, POLARIS11_, POLARIS11)
>  CHIPSET(0x67EB, POLARIS11_, POLARIS11)
> +CHIPSET(0x67EF, POLARIS11_, POLARIS11)
>  CHIPSET(0x67FF, POLARIS11_, POLARIS11)
>
>  CHIPSET(0x67C0, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C1, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C2, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C4, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C7, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C8, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C9, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CA, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CC, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CF, POLARIS10_, POLARIS10)
>  CHIPSET(0x67DF, POLARIS10_, POLARIS10)
>
>  CHIPSET(0x98E4, STONEY_, STONEY)
> --
> 2.9.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
___
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] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

[Alex Deucher]

On Mon, Sep 19, 2016 at 11:31 AM, Alex Deucher <alexdeuc...@gmail.com> wrote:
> On Sat, Sep 17, 2016 at 6:00 AM, Hans de Goede <hdego...@redhat.com> wrote:
>> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
>> dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
>> code. Leaving pScrn->ChangeGamma NULL in most cases.
>>
>> This triggers the BadImplementation error in xf86ChangeGamma() :
>>
>> if (pScrn->ChangeGamma)
>> return (*pScrn->ChangeGamma) (pScrn, gamma);
>>
>> return BadImplementation;
>>
>> Which causes X-apps using XF86VidModeSetGamma to crash with a
>> X protocol error.
>>
>> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
>> helper removed by the commit and adjusting it to work with the new
>> combined palette / gamma code.
>>
>> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
>> Signed-off-by: Hans de Goede <hdego...@redhat.com>
>
> Not too familiar with the code in question, but it looks sane to me.

For the series:

> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
>
>> ---
>>  hw/xfree86/modes/xf86RandR12.c | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
>> index 36767b3..7b3b97b 100644
>> --- a/hw/xfree86/modes/xf86RandR12.c
>> +++ b/hw/xfree86/modes/xf86RandR12.c
>> @@ -1916,6 +1916,34 @@ xf86RandR12LoadPalette(ScrnInfoPtr pScrn, int 
>> numColors, int *indices,
>>  }
>>  }
>>
>> +/*
>> + * Compatibility with XF86VidMode's gamma changer.  This necessarily 
>> clobbers
>> + * any per-crtc setup.  You asked for it...
>> + */
>> +
>> +static int
>> +xf86RandR12ChangeGamma(ScrnInfoPtr pScrn, Gamma gamma)
>> +{
>> +RRCrtcPtr randr_crtc = xf86CompatRRCrtc(pScrn);
>> +int size;
>> +
>> +if (!randr_crtc)
>> +return Success;
>> +
>> +size = max(0, randr_crtc->gammaSize);
>> +if (!size)
>> +return Success;
>> +
>> +init_one_component(randr_crtc->gammaRed, size, gamma.red);
>> +init_one_component(randr_crtc->gammaGreen, size, gamma.green);
>> +init_one_component(randr_crtc->gammaBlue, size, gamma.blue);
>> +xf86RandR12CrtcSetGamma(xf86ScrnToScreen(pScrn), randr_crtc);
>> +
>> +pScrn->gamma = gamma;
>> +
>> +return Success;
>> +}
>> +
>>  static Bool
>>  xf86RandR12EnterVT(ScrnInfoPtr pScrn)
>>  {
>> @@ -2115,6 +2143,7 @@ xf86RandR12Init12(ScreenPtr pScreen)
>>  rp->rrProviderDestroy = xf86RandR14ProviderDestroy;
>>
>>  pScrn->PointerMoved = xf86RandR12PointerMoved;
>> +pScrn->ChangeGamma = xf86RandR12ChangeGamma;
>>
>>  randrp->orig_EnterVT = pScrn->EnterVT;
>>  pScrn->EnterVT = xf86RandR12EnterVT;
>> --
>> 2.9.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
___
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] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

[Alex Deucher]

On Sat, Sep 17, 2016 at 6:00 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
> dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
> code. Leaving pScrn->ChangeGamma NULL in most cases.
>
> This triggers the BadImplementation error in xf86ChangeGamma() :
>
> if (pScrn->ChangeGamma)
> return (*pScrn->ChangeGamma) (pScrn, gamma);
>
> return BadImplementation;
>
> Which causes X-apps using XF86VidModeSetGamma to crash with a
> X protocol error.
>
> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
> helper removed by the commit and adjusting it to work with the new
> combined palette / gamma code.
>
> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Not too familiar with the code in question, but it looks sane to me.
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/modes/xf86RandR12.c | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
> index 36767b3..7b3b97b 100644
> --- a/hw/xfree86/modes/xf86RandR12.c
> +++ b/hw/xfree86/modes/xf86RandR12.c
> @@ -1916,6 +1916,34 @@ xf86RandR12LoadPalette(ScrnInfoPtr pScrn, int 
> numColors, int *indices,
>  }
>  }
>
> +/*
> + * Compatibility with XF86VidMode's gamma changer.  This necessarily clobbers
> + * any per-crtc setup.  You asked for it...
> + */
> +
> +static int
> +xf86RandR12ChangeGamma(ScrnInfoPtr pScrn, Gamma gamma)
> +{
> +RRCrtcPtr randr_crtc = xf86CompatRRCrtc(pScrn);
> +int size;
> +
> +if (!randr_crtc)
> +return Success;
> +
> +size = max(0, randr_crtc->gammaSize);
> +if (!size)
> +return Success;
> +
> +init_one_component(randr_crtc->gammaRed, size, gamma.red);
> +init_one_component(randr_crtc->gammaGreen, size, gamma.green);
> +init_one_component(randr_crtc->gammaBlue, size, gamma.blue);
> +xf86RandR12CrtcSetGamma(xf86ScrnToScreen(pScrn), randr_crtc);
> +
> +pScrn->gamma = gamma;
> +
> +return Success;
> +}
> +
>  static Bool
>  xf86RandR12EnterVT(ScrnInfoPtr pScrn)
>  {
> @@ -2115,6 +2143,7 @@ xf86RandR12Init12(ScreenPtr pScreen)
>  rp->rrProviderDestroy = xf86RandR14ProviderDestroy;
>
>  pScrn->PointerMoved = xf86RandR12PointerMoved;
> +pScrn->ChangeGamma = xf86RandR12ChangeGamma;
>
>  randrp->orig_EnterVT = pScrn->EnterVT;
>  pScrn->EnterVT = xf86RandR12EnterVT;
> --
> 2.9.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
___
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] Add SyncSharedPixmap ScreenRec hook

[Alex Deucher]

On Wed, Aug 31, 2016 at 4:56 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  include/scrnintstr.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/scrnintstr.h b/include/scrnintstr.h
> index 5330714..52e8382 100644
> --- a/include/scrnintstr.h
> +++ b/include/scrnintstr.h
> @@ -347,6 +347,24 @@ typedef Bool (*SharePixmapBackingProcPtr)(PixmapPtr, 
> ScreenPtr, void **);
>
>  typedef Bool (*SetSharedPixmapBackingProcPtr)(PixmapPtr, void *);
>
> +#define HAS_SYNC_SHARED_PIXMAP 1
> +/* The SyncSharedPixmap hook has two purposes:
> + *
> + * 1. If the master driver has it, the slave driver can use it to
> + * synchronize the shared pixmap contents with the screen pixmap.
> + * 2. If the slave driver has it, the master driver can expect the slave
> + * driver to call the master screen's SyncSharedPixmap hook, so the master
> + * driver doesn't have to synchronize the shared pixmap contents itself,
> + * e.g. from the BlockHandler.
> + *
> + * A driver must only set the hook if it handles both cases correctly.
> + *
> + * The argument is the slave screen's pixmap_dirty_list entry, the hook is
> + * responsible for finding the corresponding entry in the master screen's
> + * pixmap_dirty_list.
> + */
> +typedef void (*SyncSharedPixmapProcPtr)(PixmapDirtyUpdatePtr);
> +
>  typedef Bool (*StartPixmapTrackingProcPtr)(PixmapPtr, PixmapPtr,
> int x, int y,
> int dst_x, int dst_y,
> @@ -616,6 +634,7 @@ typedef struct _Screen {
>
>  StartPixmapTrackingProcPtr StartPixmapTracking;
>  StopPixmapTrackingProcPtr StopPixmapTracking;
> +SyncSharedPixmapProcPtr SyncSharedPixmap;
>
>  SharedPixmapNotifyDamageProcPtr SharedPixmapNotifyDamage;
>  RequestSharedPixmapNotifyDamageProcPtr RequestSharedPixmapNotifyDamage;
> --
> 2.9.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
___
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 v3] glamor: Handle bitplane in glamor_copy_fbo_cpu

[Alex Deucher]

On Thu, Aug 18, 2016 at 5:42 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> This can significantly speed up at least some CopyPlane cases, e.g.
> indirectly for stippled fills.
>
> v2:
> * Make temporary pixmap the same size as the destination pixmap
>   (instead of the destination drawable size), and fix coordinate
>   parameters passed to fbCopyXtoX and glamor_upload_boxes. Fixes
>   incorrect rendering rendering with x11perf -copyplane* and crashes
>   with the xscreensaver phosphor hack.
> v3:
> * Make the change a bit more compact and hopefully more readable by
>   re-using the existing src_* locals in the bitplane case as well.
>
> Reported-by: Keith Raghubar <keith.raghu...@amd.com>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_copy.c | 40 +---
>  1 file changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c
> index 3501a0d..5b5f0e6 100644
> --- a/glamor/glamor_copy.c
> +++ b/glamor/glamor_copy.c
> @@ -220,11 +220,37 @@ glamor_copy_cpu_fbo(DrawablePtr src,
>
>  glamor_get_drawable_deltas(dst, dst_pixmap, _xoff, _yoff);
>
> -fbGetDrawable(src, src_bits, src_stride, src_bpp, src_xoff, src_yoff);
> +if (bitplane) {
> +PixmapPtr src_pix = fbCreatePixmap(screen, 
> dst_pixmap->drawable.width,
> +   dst_pixmap->drawable.height,
> +   dst->depth, 0);
> +
> +if (!src_pix) {
> +glamor_finish_access(src);
> +goto bail;
> +}
>
> -glamor_upload_boxes(dst_pixmap, box, nbox, src_xoff + dx, src_yoff + dy,
> -dst_xoff, dst_yoff,
> -(uint8_t *) src_bits, src_stride * sizeof (FbBits));
> +fbGetDrawable(_pix->drawable, src_bits, src_stride, src_bpp, 
> src_xoff,
> +  src_yoff);
> +
> +if (src->bitsPerPixel > 1)
> +fbCopyNto1(src, _pix->drawable, gc, box, nbox,
> +   dst_xoff + dx, dst_yoff + dy, reverse, upsidedown,
> +   bitplane, closure);
> +else
> +fbCopy1toN(src, _pix->drawable, gc, box, nbox,
> +   dst_xoff + dx, dst_yoff + dy, reverse, upsidedown,
> +   bitplane, closure);
> +
> +glamor_upload_boxes(dst_pixmap, box, nbox, 0, 0, 0, 0,
> +(uint8_t *) src_bits, src_stride * 
> sizeof(FbBits));
> +fbDestroyPixmap(src_pix);
> +} else {
> +fbGetDrawable(src, src_bits, src_stride, src_bpp, src_xoff, 
> src_yoff);
> +glamor_upload_boxes(dst_pixmap, box, nbox, src_xoff + dx, src_yoff + 
> dy,
> +dst_xoff, dst_yoff,
> +(uint8_t *) src_bits, src_stride * sizeof 
> (FbBits));
> +}
>  glamor_finish_access(src);
>
>  return TRUE;
> @@ -616,9 +642,9 @@ glamor_copy_gl(DrawablePtr src,
>  return glamor_copy_fbo_fbo_draw(src, dst, gc, box, nbox, dx, 
> dy,
>  reverse, upsidedown, 
> bitplane, closure);
>  }
> -if (bitplane == 0)
> -return glamor_copy_cpu_fbo(src, dst, gc, box, nbox, dx, dy,
> -   reverse, upsidedown, bitplane, 
> closure);
> +
> +return glamor_copy_cpu_fbo(src, dst, gc, box, nbox, dx, dy,
> +   reverse, upsidedown, bitplane, closure);
>  } else if (GLAMOR_PIXMAP_PRIV_HAS_FBO(src_priv) &&
> dst_priv->type != GLAMOR_DRM_ONLY &&
> bitplane == 0) {
> --
> 2.9.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
___
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] xfree86/modes: Handle no palette case better in xf86RandR12CrtcSetGamma

[Alex Deucher]

On Mon, Aug 1, 2016 at 3:46 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 29.07.2016 17:51, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Just use the RandR gamma ramp directly.
>>
>> Fixes random on-monitor colours with drivers which don't call
>> xf86HandleColormaps, e.g. modesetting.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97154
>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>> ---
>>  hw/xfree86/modes/xf86RandR12.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
>> index 4e0e4a8..c28a4e0 100644
>> --- a/hw/xfree86/modes/xf86RandR12.c
>> +++ b/hw/xfree86/modes/xf86RandR12.c
>> @@ -1310,9 +1310,17 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
>> randr_crtc)
>>
>>  if (randrp->palette_size) {
>>  xf86RandR12CrtcComputeGamma(pScreen, randr_crtc);
>> -xf86RandR12CrtcReloadGamma(randr_crtc);
>> +} else {
>> +memcpy(crtc->gamma_red, randr_crtc->gammaRed,
>> +   crtc->gamma_size * sizeof(crtc->gamma_red[0]));
>> +memcpy(crtc->gamma_green, randr_crtc->gammaGreen,
>> +   crtc->gamma_size * sizeof(crtc->gamma_green[0]));
>> +memcpy(crtc->gamma_blue, randr_crtc->gammaBlue,
>> +   crtc->gamma_size * sizeof(crtc->gamma_blue[0]));
>>  }
>>
>> +xf86RandR12CrtcReloadGamma(randr_crtc);
>> +
>>  return TRUE;
>>  }
>>
>>
>
>
> --
> 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
___
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 RFC xserver] dix: Work around non-premultiplied ARGB cursor data

[Alex Deucher]

On Tue, Jun 28, 2016 at 4:22 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Some games incorrectly use non-premultiplied ARGB cursor data, presumably
> because that's what Windows uses. On some hardware (and with SWcursor),
> this breaks areas of the cursor which are supposed to be transparent
> (and presumably also translucent areas, but that's less noticeable).
>
> This change checks for pixels with alpha == 0 and any non-alpha component
> != 0. If any such pixel is found, the data is assumed to be
> non-premultiplied and fixed up by multiplying the RGB components with the
> alpha component.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92309
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>
> I'm on the fence about whether this is a good or bad idea.
>
> Pro:
> * Allows users with affected setups to play broken games
> * Less overhead than a corresponding workaround in the driver
>
> Con:
> * Makes the problem completely invisible to game developers, so once
>   it's in we can probably never remove it again
>
> Opinions?

Seems like a good idea to me.
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>


>
>  dix/cursor.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/dix/cursor.c b/dix/cursor.c
> index e459456..25d6767 100644
> --- a/dix/cursor.c
> +++ b/dix/cursor.c
> @@ -288,6 +288,29 @@ AllocARGBCursor(unsigned char *psrcbits, unsigned char 
> *pmaskbits,
>  goto error;
>
>  *ppCurs = pCurs;
> +
> +if (argb) {
> +size_t i, size = bits->width * bits->height;
> +
> +for (i = 0; i < size; i++) {
> +if ((argb[i] & 0xff00) == 0 && (argb[i] & 0xff) != 0) {
> +/* ARGB data doesn't seem pre-multiplied, fix it */
> +for (i = 0; i < size; i++) {
> +CARD32 a, ar, ag, ab;
> +
> +a = argb[i] >> 24;
> +ar = a * ((argb[i] >> 16) & 0xff) / 0xff;
> +ag = a * ((argb[i] >> 8) & 0xff) / 0xff;
> +ab = a * (argb[i] & 0xff) / 0xff;
> +
> +argb[i] = a << 24 | ar << 16 | ag << 8 | ab;
> +}
> +
> +break;
> +}
> +}
> +}
> +
>  return Success;
>
>   error:
> --
> 2.8.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
___
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 v3 xserver 3/3] xfree86: Hook up colormaps and RandR 1.2 gamma code

[Alex Deucher]

On Tue, Jun 21, 2016 at 11:12 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Instead of breaking the former when the driver supports the latter,
> hook them up so that the hardware LUTs reflect the combination of the
> current colourmap and gamma states. I.e. combine the colourmap, the
> global gamma value/ramp and the RandR 1.2 per-CRTC gamma ramps into one
> combined LUT per CRTC.
>
> Fixes e.g. gamma sliders not working in games.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27222
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>
> v3: Free randrp->palette in xf86RandR12CloseScreen, fixes memory leak.

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  hw/xfree86/common/xf86Helper.c |   7 +-
>  hw/xfree86/common/xf86cmap.c   |  55 ++---
>  hw/xfree86/modes/xf86RandR12.c | 175 
> +
>  hw/xfree86/modes/xf86RandR12.h |   5 ++
>  4 files changed, 119 insertions(+), 123 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
> index bceb017..6f3a608 100644
> --- a/hw/xfree86/common/xf86Helper.c
> +++ b/hw/xfree86/common/xf86Helper.c
> @@ -54,7 +54,6 @@
>  #include "xf86Xinput.h"
>  #include "xf86InPriv.h"
>  #include "mivalidate.h"
> -#include "xf86Crtc.h"
>
>  /* For xf86GetClocks */
>  #if defined(CSRG_BASED) || defined(__GNU__)
> @@ -908,11 +907,7 @@ xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma)
>  scrp->gamma.green = 1.0;
>  scrp->gamma.blue = 1.0;
>  }
> -/* Pretend we succeeded if we support better a gamma system.
> - * This avoids a confusing message.
> - */
> -if (xf86_crtc_supports_gamma(scrp))
> -return TRUE;
> +
>  xf86DrvMsg(scrp->scrnIndex, from,
> "Using gamma correction (%.1f, %.1f, %.1f)\n",
> scrp->gamma.red, scrp->gamma.green, scrp->gamma.blue);
> diff --git a/hw/xfree86/common/xf86cmap.c b/hw/xfree86/common/xf86cmap.c
> index ba0b277..1f21a0b 100644
> --- a/hw/xfree86/common/xf86cmap.c
> +++ b/hw/xfree86/common/xf86cmap.c
> @@ -49,6 +49,7 @@
>  #include "xf86_OSproc.h"
>  #include "xf86str.h"
>  #include "micmap.h"
> +#include "xf86RandR12.h"
>  #include "xf86Crtc.h"
>
>  #ifdef XFreeXDGA
> @@ -132,9 +133,6 @@ static void CMapUnwrapScreen(ScreenPtr pScreen);
>  Bool
>  xf86ColormapAllocatePrivates(ScrnInfoPtr pScrn)
>  {
> -/* If we support a better colormap system, then pretend we succeeded. */
> -if (xf86_crtc_supports_gamma(pScrn))
> -return TRUE;
>  if (!dixRegisterPrivateKey(, PRIVATE_SCREEN, 0))
>  return FALSE;
>
> @@ -157,10 +155,6 @@ xf86HandleColormaps(ScreenPtr pScreen,
>  int *indices;
>  int elements;
>
> -/* If we support a better colormap system, then pretend we succeeded. */
> -if (xf86_crtc_supports_gamma(pScrn))
> -return TRUE;
> -
>  if (!maxColors || !sigRGBbits || !loadPalette)
>  return FALSE;
>
> @@ -193,7 +187,12 @@ xf86HandleColormaps(ScreenPtr pScreen,
>  pScreen->InstallColormap = CMapInstallColormap;
>  pScreen->StoreColors = CMapStoreColors;
>
> -pScrn->LoadPalette = loadPalette;
> +if (xf86_crtc_supports_gamma(pScrn)) {
> +pScrn->LoadPalette = xf86RandR12LoadPalette;
> +if (!xf86RandR12InitGamma(pScrn, elements))
> +return FALSE;
> +} else
> +pScrn->LoadPalette = loadPalette;
>  pScrn->SetOverscan = setOverscan;
>  pScreenPriv->maxColors = maxColors;
>  pScreenPriv->sigRGBbits = sigRGBbits;
> @@ -1005,19 +1004,6 @@ xf86ChangeGammaRamp(ScreenPtr pScreen,
>  CMapScreenPtr pScreenPriv;
>  CMapLinkPtr pLink;
>
> -if (xf86_crtc_supports_gamma(pScrn)) {
> -RRCrtcPtr crtc = xf86CompatRRCrtc(pScrn);
> -
> -if (crtc) {
> -if (crtc->gammaSize != size)
> -return BadValue;
> -
> -RRCrtcGammaSet(crtc, red, green, blue);
> -
> -return Success;
> -}
> -}
> -
>  if (!CMapScreenKeyRegistered)
>  return BadImplementation;
>
> @@ -1077,16 +1063,8 @@ xf86ChangeGammaRamp(ScreenPtr pScreen,
>  int
>  xf86GetGammaRampSize(ScreenPtr pScreen)
>  {
> -ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
>  CMapScreenPtr pScreenPriv;
>
> -if (xf86_crtc_supports_gamma(pScrn)) {
> -RRCrtcPtr crtc = xf86CompatRRCrtc(pScrn);
> -
> -if (

Re: [PATCH v2 xserver 3/3] xfree86: Hook up colormaps and RandR 1.2 gamma code

[Alex Deucher]

On Tue, Jun 21, 2016 at 5:45 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Instead of breaking the former when the driver supports the latter,
> hook them up so that the hardware LUTs reflect the combination of the
> current colourmap and gamma states. I.e. combine the colourmap, the
> global gamma value/ramp and the RandR 1.2 per-CRTC gamma ramps into one
> combined LUT per CRTC.
>
> Fixes e.g. gamma sliders not working in games.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27222
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>
> v2: Fixes for issues introduced in the last minute before sending out v1:
> * No CamelCase for palette struct members
> * Initialize palette_size and palette struct members, fixes crash on
>   server startup

I'm not really an expert with respect to the colormap code, but the
changes look sane to me.  For the series:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  hw/xfree86/common/xf86Helper.c |   7 +-
>  hw/xfree86/common/xf86cmap.c   |  55 ++---
>  hw/xfree86/modes/xf86RandR12.c | 174 
> +
>  hw/xfree86/modes/xf86RandR12.h |   5 ++
>  4 files changed, 118 insertions(+), 123 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
> index bceb017..6f3a608 100644
> --- a/hw/xfree86/common/xf86Helper.c
> +++ b/hw/xfree86/common/xf86Helper.c
> @@ -54,7 +54,6 @@
>  #include "xf86Xinput.h"
>  #include "xf86InPriv.h"
>  #include "mivalidate.h"
> -#include "xf86Crtc.h"
>
>  /* For xf86GetClocks */
>  #if defined(CSRG_BASED) || defined(__GNU__)
> @@ -908,11 +907,7 @@ xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma)
>  scrp->gamma.green = 1.0;
>  scrp->gamma.blue = 1.0;
>  }
> -/* Pretend we succeeded if we support better a gamma system.
> - * This avoids a confusing message.
> - */
> -if (xf86_crtc_supports_gamma(scrp))
> -return TRUE;
> +
>  xf86DrvMsg(scrp->scrnIndex, from,
> "Using gamma correction (%.1f, %.1f, %.1f)\n",
> scrp->gamma.red, scrp->gamma.green, scrp->gamma.blue);
> diff --git a/hw/xfree86/common/xf86cmap.c b/hw/xfree86/common/xf86cmap.c
> index ba0b277..1f21a0b 100644
> --- a/hw/xfree86/common/xf86cmap.c
> +++ b/hw/xfree86/common/xf86cmap.c
> @@ -49,6 +49,7 @@
>  #include "xf86_OSproc.h"
>  #include "xf86str.h"
>  #include "micmap.h"
> +#include "xf86RandR12.h"
>  #include "xf86Crtc.h"
>
>  #ifdef XFreeXDGA
> @@ -132,9 +133,6 @@ static void CMapUnwrapScreen(ScreenPtr pScreen);
>  Bool
>  xf86ColormapAllocatePrivates(ScrnInfoPtr pScrn)
>  {
> -/* If we support a better colormap system, then pretend we succeeded. */
> -if (xf86_crtc_supports_gamma(pScrn))
> -return TRUE;
>  if (!dixRegisterPrivateKey(, PRIVATE_SCREEN, 0))
>  return FALSE;
>
> @@ -157,10 +155,6 @@ xf86HandleColormaps(ScreenPtr pScreen,
>  int *indices;
>  int elements;
>
> -/* If we support a better colormap system, then pretend we succeeded. */
> -if (xf86_crtc_supports_gamma(pScrn))
> -return TRUE;
> -
>  if (!maxColors || !sigRGBbits || !loadPalette)
>  return FALSE;
>
> @@ -193,7 +187,12 @@ xf86HandleColormaps(ScreenPtr pScreen,
>  pScreen->InstallColormap = CMapInstallColormap;
>  pScreen->StoreColors = CMapStoreColors;
>
> -pScrn->LoadPalette = loadPalette;
> +if (xf86_crtc_supports_gamma(pScrn)) {
> +pScrn->LoadPalette = xf86RandR12LoadPalette;
> +if (!xf86RandR12InitGamma(pScrn, elements))
> +return FALSE;
> +} else
> +pScrn->LoadPalette = loadPalette;
>  pScrn->SetOverscan = setOverscan;
>  pScreenPriv->maxColors = maxColors;
>  pScreenPriv->sigRGBbits = sigRGBbits;
> @@ -1005,19 +1004,6 @@ xf86ChangeGammaRamp(ScreenPtr pScreen,
>  CMapScreenPtr pScreenPriv;
>  CMapLinkPtr pLink;
>
> -if (xf86_crtc_supports_gamma(pScrn)) {
> -RRCrtcPtr crtc = xf86CompatRRCrtc(pScrn);
> -
> -if (crtc) {
> -if (crtc->gammaSize != size)
> -return BadValue;
> -
> -RRCrtcGammaSet(crtc, red, green, blue);
> -
> -return Success;
> -}
> -}
> -
>  if (!CMapScreenKeyRegistered)
>  return BadImplementation;
>
> @@ -1077,16 +1063,8 @@ xf86ChangeGammaRamp(ScreenPtr pScreen,
>  int
>  xf86GetGammaRampSize(ScreenPtr pScre

Re: [PATCH xserver] glamor: Adjust for drawable x/y in composite's copy optimization

[Alex Deucher]

On Fri, May 27, 2016 at 2:05 PM, Keith Packard <kei...@keithp.com> wrote:
> Patch b64108fa305e956e4edaae9d53071ff0abee268e added a short cut that
> identifies composite operations that can be performed with a simple
> copy instead.
>
> glamor_copy works in absolute coordinates, so the dx and dy values
> passed in need to be converted from drawable-relative to absolute by
> adding the drawable x/y values.
>
> Signed-off-by: Keith Packard <kei...@keithp.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_render.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index 9c5cca6..165bced 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -1436,6 +1436,10 @@ glamor_composite_clipped_region(CARD8 op,
>   || (op == PictOpOver
>   && source->format == dest->format
>   && !PICT_FORMAT_A(source->format)) {
> +x_source += source->pDrawable->x;
> +y_source += source->pDrawable->y;
> +x_dest += dest->pDrawable->x;
> +y_dest += dest->pDrawable->y;
>  glamor_copy(source->pDrawable, dest->pDrawable, NULL,
>  box, nbox, x_source - x_dest,
>  y_source - y_dest, FALSE, FALSE, 0, NULL);
> --
> 2.8.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
___
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] glamor: Check for composite operations which are equivalent to copies

[Alex Deucher]

On Wed, May 25, 2016 at 6:09 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Increases x11perf -compwinwin500 numbers by a factor of 10 for me with
> radeonsi.
>
> Conditions copied from exaComposite().
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_render.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index 65f7059..33091c1 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -1394,6 +1394,29 @@ glamor_composite_clipped_region(CARD8 op,
>  DEBUGF("clipped (%d %d) (%d %d) (%d %d) width %d height %d \n",
> x_source, y_source, x_mask, y_mask, x_dest, y_dest, width, 
> height);
>
> +/* Is the composite operation equivalent to a copy? */
> +if (!mask && !source->alphaMap && !dest->alphaMap
> +&& source->pDrawable && !source->transform
> +&& ((op == PictOpSrc
> + && ((source->format == dest->format
> +  || (PICT_FORMAT_COLOR(dest->format)
> +  && PICT_FORMAT_COLOR(source->format)
> +  && dest->format == 
> PICT_FORMAT(PICT_FORMAT_BPP(source->format),
> + 
> PICT_FORMAT_TYPE(source->format),
> + 0,
> + 
> PICT_FORMAT_R(source->format),
> + 
> PICT_FORMAT_G(source->format),
> + 
> PICT_FORMAT_B(source->format
> + || (op == PictOpOver
> + && source->format == dest->format
> + && !PICT_FORMAT_A(source->format)) {
> +glamor_copy(source->pDrawable, dest->pDrawable, NULL,
> +box, nbox, x_source - x_dest,
> +y_source - y_dest, FALSE, FALSE, 0, NULL);
> +ok = TRUE;
> +goto out;
> +}
> +
>  /* XXX is it possible source mask have non-zero drawable.x/y? */
>  if (source
>  && ((!source->pDrawable
> --
> 2.8.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
___
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] glamor: Fix sampling outside of RGBx source/mask pictures

[Alex Deucher]

On Tue, May 24, 2016 at 5:12 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> RENDER requires that sampling outside of any source/mask picture results
> in alpha == 0.0.
>
> The OpenGL border colour cannot set alpha = 0.0 if the texture format
> doesn't have an alpha channel, so we have to use the RepeatFix handling
> in that case.
>
> Also, only force alpha = 1.0 when sampling inside of RGBx source/mask
> pictures.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94514
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_render.c | 36 
>  1 file changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index 65f7059..cc03136 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -105,7 +105,7 @@ glamor_create_composite_fs(struct shader_key *key)
>  /* The texture and the pixmap size is not match eaxctly, so can't sample 
> it directly.
>   * rel_sampler will recalculate the texture coords.*/
>  const char *rel_sampler =
> -" vec4 rel_sampler(sampler2D tex_image, vec2 tex, vec4 wh, int 
> repeat)\n"
> +" vec4 rel_sampler_rgba(sampler2D tex_image, vec2 tex, vec4 wh, int 
> repeat)\n"
>  "{\n"
>  "  if (repeat >= RepeatFix) {\n"
>  "  tex = rel_tex_coord(tex, wh, repeat);\n"
> @@ -117,6 +117,19 @@ glamor_create_composite_fs(struct shader_key *key)
>  "  }\n"
>  "  }\n"
>  "  return texture2D(tex_image, tex);\n"
> +"}\n"
> +" vec4 rel_sampler_rgbx(sampler2D tex_image, vec2 tex, vec4 wh, int 
> repeat)\n"
> +"{\n"
> +"  if (repeat >= RepeatFix) {\n"
> +"  tex = rel_tex_coord(tex, wh, repeat);\n"
> +"  if (repeat == RepeatFix + RepeatNone) {\n"
> +"  if (tex.x < 0.0 || tex.x >= 1.0 || \n"
> +"  tex.y < 0.0 || tex.y >= 1.0)\n"
> +"  return vec4(0.0, 0.0, 0.0, 0.0);\n"
> +"  tex = (fract(tex) / wh.xy);\n"
> +"  }\n"
> +"  }\n"
> +"  return vec4(texture2D(tex_image, tex).rgb, 1.0);\n"
>  "}\n";
>
>  const char *source_solid_fetch =
> @@ -131,8 +144,8 @@ glamor_create_composite_fs(struct shader_key *key)
>  "uniform vec4 source_wh;"
>  "vec4 get_source()\n"
>  "{\n"
> -"  return rel_sampler(source_sampler, source_texture,\n"
> -" source_wh, source_repeat_mode);\n"
> +"  return rel_sampler_rgba(source_sampler, source_texture,\n"
> +"  source_wh, source_repeat_mode);\n"
>  "}\n";
>  const char *source_pixmap_fetch =
>  "varying vec2 source_texture;\n"
> @@ -140,9 +153,8 @@ glamor_create_composite_fs(struct shader_key *key)
>  "uniform vec4 source_wh;\n"
>  "vec4 get_source()\n"
>  "{\n"
> -"  return vec4(rel_sampler(source_sampler, source_texture,\n"
> -"  source_wh, source_repeat_mode).rgb,\n"
> -"  1.0);\n"
> +"  return rel_sampler_rgbx(source_sampler, source_texture,\n"
> +"  source_wh, source_repeat_mode);\n"
>  "}\n";
>  const char *mask_none =
>  "vec4 get_mask()\n"
> @@ -161,8 +173,8 @@ glamor_create_composite_fs(struct shader_key *key)
>  "uniform vec4 mask_wh;\n"
>  "vec4 get_mask()\n"
>  "{\n"
> -"  return rel_sampler(mask_sampler, mask_texture,\n"
> -" mask_wh, mask_repeat_mode);\n"
> +"  return rel_sampler_rgba(mask_sampler, mask_texture,\n"
> +"  mask_wh, mask_repeat_mode);\n"
>  "}\n";
>  const char *mask_pixmap_fetch =
>  "varying vec2 mask_texture;\n"
> @@ -1

Re: [PATCH xserver] glamor: Disable logic ops when doing compositing

[Alex Deucher]

On Fri, May 13, 2016 at 7:29 AM, Keith Packard <kei...@keithp.com> wrote:
> If the logic op gets left enabled, it overrides the blending
> operation, causing incorrect contents on the display.
>
> Signed-off-by: Keith Packard <kei...@keithp.com>

Makes sense.
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  glamor/glamor_program.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
> index 0a94de6..a43ee6e 100644
> --- a/glamor/glamor_program.c
> +++ b/glamor/glamor_program.c
> @@ -499,6 +499,7 @@ glamor_set_blend(CARD8 op, glamor_program_alpha alpha, 
> PicturePtr dst)
>  }
>
>  glEnable(GL_BLEND);
> +glDisable(GL_COLOR_LOGIC_OP);
>  glBlendFunc(src_blend, dst_blend);
>  }
>
> --
> 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
___
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 2/2] modesetting: port clean start code from amdgpu. (v2)

[Alex Deucher]

On Mon, May 2, 2016 at 4:54 PM, Dave Airlie <airl...@gmail.com> wrote:
> From: Dave Airlie <airl...@redhat.com>
>
> Both radeon and amdgpu don't set the mode until the first blockhandler,
> this means everything should be rendered on the screen correctly by then.
>
> This ports this code, it also removes the tail call of EnterVT from
> ScreenInit, it really isn't necessary and causes us to set a dirty
> mode with -modesetting always anyways.
>
> v2: reorder set desired modes vs block handler as done for amdgpu.
>
> Reviewed-by: Eric Anholt <e...@anholt.net>
> Signed-off-by: Dave Airlie <airl...@redhat.com>

For the series:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/drivers/modesetting/driver.c  | 21 
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 25 
> +---
>  hw/xfree86/drivers/modesetting/drmmode_display.h |  2 +-
>  3 files changed, 36 insertions(+), 12 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> index 6c4bac3..fe5d5e1 100644
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -614,6 +614,17 @@ msBlockHandler(ScreenPtr pScreen, void *pTimeout, void 
> *pReadmask)
>  }
>
>  static void
> +msBlockHandler_oneshot(ScreenPtr pScreen, void *pTimeout, void *pReadmask)
> +{
> +ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
> +modesettingPtr ms = modesettingPTR(pScrn);
> +
> +msBlockHandler(pScreen, pTimeout, pReadmask);
> +
> +drmmode_set_desired_modes(pScrn, >drmmode, TRUE);
> +}
> +
> +static void
>  FreeRec(ScrnInfoPtr pScrn)
>  {
>  modesettingPtr ms;
> @@ -972,7 +983,7 @@ CreateScreenResources(ScreenPtr pScreen)
>  ret = pScreen->CreateScreenResources(pScreen);
>  pScreen->CreateScreenResources = CreateScreenResources;
>
> -if (!drmmode_set_desired_modes(pScrn, >drmmode))
> +if (!drmmode_set_desired_modes(pScrn, >drmmode, pScrn->is_gpu))
>  return FALSE;
>
>  if (!drmmode_glamor_handle_new_screen_pixmap(>drmmode))
> @@ -1235,7 +1246,7 @@ ScreenInit(ScreenPtr pScreen, int argc, char **argv)
>  pScreen->CloseScreen = CloseScreen;
>
>  ms->BlockHandler = pScreen->BlockHandler;
> -pScreen->BlockHandler = msBlockHandler;
> +pScreen->BlockHandler = msBlockHandler_oneshot;
>
>  pScreen->SharePixmapBacking = msSharePixmapBacking;
>  pScreen->SetSharedPixmapBacking = msSetSharedPixmapBacking;
> @@ -1289,7 +1300,9 @@ ScreenInit(ScreenPtr pScreen, int argc, char **argv)
>  }
>  #endif
>
> -return EnterVT(pScrn);
> +pScrn->vtSema = TRUE;
> +
> +return TRUE;
>  }
>
>  static void
> @@ -1336,7 +1349,7 @@ EnterVT(ScrnInfoPtr pScrn)
>
>  SetMaster(pScrn);
>
> -if (!drmmode_set_desired_modes(pScrn, >drmmode))
> +if (!drmmode_set_desired_modes(pScrn, >drmmode, TRUE))
>  return FALSE;
>
>  return TRUE;
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index e0d624f..546673b 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -1853,7 +1853,7 @@ drmmode_adjust_frame(ScrnInfoPtr pScrn, drmmode_ptr 
> drmmode, int x, int y)
>  }
>
>  Bool
> -drmmode_set_desired_modes(ScrnInfoPtr pScrn, drmmode_ptr drmmode)
> +drmmode_set_desired_modes(ScrnInfoPtr pScrn, drmmode_ptr drmmode, Bool 
> set_hw)
>  {
>  xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
>  int c;
> @@ -1866,8 +1866,10 @@ drmmode_set_desired_modes(ScrnInfoPtr pScrn, 
> drmmode_ptr drmmode)
>
>  /* Skip disabled CRTCs */
>  if (!crtc->enabled) {
> -drmModeSetCrtc(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
> -   0, 0, 0, NULL, 0, NULL);
> +if (set_hw) {
> +drmModeSetCrtc(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
> +   0, 0, 0, NULL, 0, NULL);
> +}
>  continue;
>  }
>
> @@ -1898,10 +1900,19 @@ drmmode_set_desired_modes(ScrnInfoPtr pScrn, 
> drmmode_ptr drmmode)
>  crtc->desiredY = 0;
>  }
>
> -if (!crtc->funcs->
> -set_mode_major(crtc, >desiredMode, crtc->desiredRotation,
> -   crtc->desiredX, crtc->desiredY))
> -return FALSE;
> +if (set_hw) {
> +if (!crtc->funcs->
&

Re: misc prime/modesetting fixes

[Alex Deucher]

On Fri, Apr 29, 2016 at 12:01 AM, Dave Airlie <airl...@gmail.com> wrote:
> The first patch is picked from Alex Goins' series as a cleanup,
> I then got distracted fixing other minor things I found just testing
> prime with modesetting.
>
> Finally Alex's series showed up a bug we have currently leaking
> the slave BO, his fix wasn't very symmetrical, however to make a
> nice fix I had to break the ABI by passing a NULL where we didn't
> before.

patches 1-5 are:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
> Dave.
>
> ___
> 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

Re: [PATCH xserver 4/4] xfree86/parser: simplify #ifdef ladder

[Alex Deucher]

On Sun, Apr 17, 2016 at 3:30 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> Rather than 'hacking' around symbol names and providing macros such as
> 'Local' just fold things and make the code more readable.
>
> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>
> If people prefer we can split out the different implementations
> (HAS_SAVED_IDS_AND_SETEUID vs not) to separate functions and call if
> from xf86writeConfigFile(). I don't mind either way.
>
> -Emil
>
>  hw/xfree86/parser/write.c | 31 +--
>  1 file changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/hw/xfree86/parser/write.c b/hw/xfree86/parser/write.c
> index 8792783..9a24dd6 100644
> --- a/hw/xfree86/parser/write.c
> +++ b/hw/xfree86/parser/write.c
> @@ -73,14 +73,7 @@
>  #define HAS_NO_UIDS
>  #endif
>
> -#ifdef HAS_NO_UIDS
> -#define doWriteConfigFile xf86writeConfigFile
> -#define Local /**/
> -#else
> -#define Local static
> -#endif
> -
> -Local int
> +static int
>  doWriteConfigFile(const char *filename, XF86ConfigPtr cptr)
>  {
>  FILE *cf;
> @@ -134,24 +127,19 @@ doWriteConfigFile(const char *filename, XF86ConfigPtr 
> cptr)
>  return 1;
>  }
>
> -#ifndef HAS_NO_UIDS
> -
>  int
>  xf86writeConfigFile(const char *filename, XF86ConfigPtr cptr)
>  {
> +#ifndef HAS_NO_UIDS
>  int ret;
>
> -#if !defined(HAS_SAVED_IDS_AND_SETEUID)
> -int pid, p;
> -int status;
> -void (*csig) (int);
> -#else
> -int ruid, euid;
> -#endif
> -
>  if (getuid() != geteuid()) {
>
>  #if !defined(HAS_SAVED_IDS_AND_SETEUID)
> +int pid, p;
> +int status;
> +void (*csig) (int);
> +
>  /* Need to fork to change ruid without loosing euid */
>  csig = signal(SIGCHLD, SIG_DFL);
>  switch ((pid = fork())) {
> @@ -178,6 +166,7 @@ xf86writeConfigFile(const char *filename, XF86ConfigPtr 
> cptr)
>  return 0;
>
>  #else   /* HAS_SAVED_IDS_AND_SETEUID */
> +int ruid, euid;
>
>  ruid = getuid();
>  euid = geteuid();
> @@ -198,9 +187,7 @@ xf86writeConfigFile(const char *filename, XF86ConfigPtr 
> cptr)
>  #endif  /* HAS_SAVED_IDS_AND_SETEUID */
>
>  }
> -else {
> +else
> +#endif  /* !HAS_NO_UIDS */
>  return doWriteConfigFile(filename, cptr);
> -}
>  }
> -
> -#endif  /* !HAS_NO_UIDS */
> --
> 2.8.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

Re: [PATCH xserver] dri3: remove unused file dri3int.h

[Alex Deucher]

On Sun, Apr 17, 2016 at 3:34 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> Copied during the prototyping stage and never used.
>
> Cc: Keith Packard <kei...@keithp.com>
> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  dri3/dri3int.h | 26 --
>  1 file changed, 26 deletions(-)
>  delete mode 100644 dri3/dri3int.h
>
> diff --git a/dri3/dri3int.h b/dri3/dri3int.h
> deleted file mode 100644
> index 7f53eba..000
> --- a/dri3/dri3int.h
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -/*
> - * Copyright © 2011 Daniel Stone
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> - * DEALINGS IN THE SOFTWARE.
> - *
> - * Author: Daniel Stone <dan...@fooishbar.org>
> - */
> -
> -extern Bool DRI2ModuleSetup(void);
> --
> 2.8.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

Re: [xrandr v2] Select NearestNeighbour filtering for pixel exact scaling

[Alex Deucher]

On Mon, Apr 4, 2016 at 4:34 PM, Chris Wilson <ch...@chris-wilson.co.uk> 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 <alexander.deuc...@amd.com>

> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
>  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

Re: [PATCH xserver] DRI2: add Polaris PCI IDs

[Alex Deucher]

On Mon, Mar 28, 2016 at 3:36 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Sonny Jiang <sonny.ji...@amd.com>
>
> Signed-off-by: Sonny Jiang <sonny.ji...@amd.com>
> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com> (Polaris10)
> Reviewed-by: Michel Dänzer <michel.daen...@amd.com> (Polaris11)
>
> (Ported from Mesa commit f00c840578a70e479ffb99f6b64c73dc420179fa)
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index bcf15a1..4df8e9d 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -182,4 +182,14 @@ CHIPSET(0x9877, CARRIZO_, CARRIZO)
>
>  CHIPSET(0x7300, FIJI_, FIJI)
>
> +CHIPSET(0x67E0, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E1, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E8, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E9, POLARIS11_, POLARIS11)
> +CHIPSET(0x67EB, POLARIS11_, POLARIS11)
> +CHIPSET(0x67FF, POLARIS11_, POLARIS11)
> +
> +CHIPSET(0x67C0, POLARIS10_, POLARIS10)
> +CHIPSET(0x67DF, POLARIS10_, POLARIS10)
> +
>  CHIPSET(0x98E4, STONEY_, STONEY)
> --
> 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
___
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: [PATCHv2] modesetting: Add common widescreen resolutions

[Alex Deucher]

On Sun, Feb 21, 2016 at 6:12 AM, Adel Gadllah  wrote:
> Stolen from the intel ddx driver, see:
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=26fd6bec
> https://bugs.freedesktop.org/show_bug.cgi?id=37858
>
> it makes those common modes selectable when using the modesetting driver.
>
> Signed-off-by: Adel Gadllah 

NACK.  There's no reason to add this to the modesetting ddx.  Just fix
it in the xserver.  E.g., they should be added to
hw/xfree86/etc/extramodes.c as per
https://bugs.freedesktop.org/show_bug.cgi?id=37858#c4

Alex

> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 107 
> ++-
>  1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0d34ca1..4faabcd 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -953,6 +953,111 @@ has_panel_fitter(xf86OutputPtr output)
>  return FALSE;
>  }
>
> +static struct pixel_count {
> +   int16_t width, height;
> +} common_16_9[] = {
> +   { 640, 360 },
> +   { 720, 405 },
> +   { 864, 486 },
> +   { 960, 540 },
> +   { 1024, 576 },
> +   { 1280, 720 },
> +   { 1366, 768 },
> +   { 1600, 900 },
> +   { 1920, 1080 },
> +   { 2048, 1152 },
> +   { 2560, 1440 },
> +   { 2880, 1620 },
> +   { 3200, 1800 },
> +   { 3840, 2160 },
> +   { 4096, 2304 },
> +   { 5120, 2880 },
> +   { 7680, 4320 },
> +   { 15360, 8640 },
> +}, common_16_10[] = {
> +   { 1280, 800 },
> +   { 1400, 900 },
> +   { 1680, 1050 },
> +   { 1920, 1200 },
> +   { 2560, 1600 },
> +};
> +
> +static bool
> +drmmode_output_is_duplicate_mode(DisplayModePtr modes, DisplayModePtr m)
> +{
> +   if (m == NULL)
> +   return false;
> +
> +   while (modes) {
> +   if (xf86ModesEqual(modes, m))
> +   return true;
> +
> +   modes = modes->next;
> +   }
> +
> +   return false;
> +}
> +
> +static DisplayModePtr
> +drmmode_output_get_default_modes(DisplayModePtr preferred)
> +{
> +DisplayModePtr modes;
> +int n;
> +
> +modes = xf86GetDefaultModes();
> +if (preferred) {
> +   DisplayModePtr m;
> +
> +   /* Add a half-resolution mode useful for large panels */
> +   m = xf86GTFMode(preferred->HDisplay / 2,
> +   preferred->VDisplay / 2,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 9 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 9 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_9); n++) {
> +   if (preferred->HDisplay <= 
> common_16_9[n].width ||
> +   preferred->VDisplay <= 
> common_16_9[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_9[n].width,
> +   common_16_9[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +   }
> +   }
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 10 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 10 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_10); n++) {
> +   if (preferred->HDisplay <= 
> common_16_10[n].width ||
> +   preferred->VDisplay <= 
> common_16_10[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_10[n].width,
> +   common_16_10[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +  

Google Summer of Code 2016

[Alex Deucher]

Hi,

It's time to start thinking about the Google Summer of Code for 2016!
The Xorg GSoC project is open to all projects related to graphics,
windowing systems, and related technologies (Mesa, Wayland, X, input,
kernel, OpenGL, OpenCL, etc.).

For mentors and developers, please start thinking of ideas and update
your Summer of Code ideas pages.  The main Xorg page is available
here:
http://www.xorg-foundation.org/wiki/SummerOfCodeIdeas/
If you have trouble updating it directly, let me know and I can post
your updated content.

For students, please start your community bonding.  Get on the mailing
lists and start reading code and asking questions.  Think about what
you might want to work on who would be a good mentor.  Don't be afraid
to ask questions!  You can use current and past GSoC ideas as a
starting point for your own.

If anyone has any questions, please don't hesitate to ask.

Thanks!

Alex
___
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: Hybrid graphics - "radeon" driver unloaded, "modesetting" loaded?

[Alex Deucher]

On Wed, Feb 10, 2016 at 7:58 AM, Lennert Van Alboom
 wrote:
> On Fri, Feb 05, 2016 at 11:24:12AM +0900, Michel Dänzer wrote:
>> On 04.02.2016 19:05, Lennert Van Alboom wrote:
>> > Hello. I've got a HP Elitebook 850g1 with hybrid graphics:
>> >
>> > $ lspci | grep VGA
>> > 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT 
>> > Integrated Graphics Controller (rev 0b)
>> > 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
>> > [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
>> >
>> > $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
>> > 0:IGD:+:Pwr::00:02.0
>> > 1:DIS-Audio: :Off::03:00.1
>> > 2:DIS: :DynOff::03:00.0
>> >
>> > I'm running Debian (sid, x86_64) with kernel 4.4.0-trunk-amd64 (same 
>> > happens with the 4.3.0-1-amd64 kernel) and Xorg 1:7.7+13 (1.18.0).
>> > I'm having an odd issue where Xorg loads the correct "radeon" driver, but 
>> > after a split second, unloads it again and loads "modesetting":
>> >
>> > [13.688] (II) config/udev: removing GPU device 
>> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1 /dev/dri/card1
>> > [13.688] xf86: remove device 1 
>> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1
>> > [13.693] (II) UnloadModule: "radeon"
>> > [13.693] (II) UnloadSubModule: "fb"
>> > [13.693] (II) Unloading fb
>> > [13.693] (II) UnloadSubModule: "glamoregl"
>> > [13.693] (II) Unloading glamoregl
>> > [13.693] (II) config/udev: Adding drm device (/dev/dri/card1)
>> > [13.693] (II) xfree86: Adding drm device (/dev/dri/card1)
>> > [13.693] (II) LoadModule: "modesetting"
>> > [13.693] (II) Loading 
>> > /usr/lib/xorg/modules/drivers/modesetting_drv.so
>> >
>> > Full Xorg log at http://ziff.soleus.nu/Xorg.0.log.txt. I don't have a 
>> > xorg.conf, and no snippets in xorg.conf.d either.
>> >
>> > This results in two providers in xrandr, Intel and modesetting (as opposed 
>> > to radeon, as I had before):
>> >
>> > $ xrandr --listproviders
>> > Providers: number : 2
>> > Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink 
>> > Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel
>> > Provider 1: id: 0x140 cap: 0x3, Source Output, Sink Output crtcs: 2 
>> > outputs: 2 associated providers: 0 name:modesetting
>> >
>> > I can't set an offload sink:
>> >
>> > $ xrandr --setprovideroffloadsink modesetting Intel
>> > X Error of failed request:  BadValue (integer parameter out of range 
>> > for operation)
>> > Major opcode of failed request:  140 (RANDR)
>> > Minor opcode of failed request:  34 (RRSetProviderOffloadSink)
>> > Value in failed request:  0x140
>> > Serial number of failed request:  16
>> > Current serial number in output stream:  17
>> >
>> > And, I suppose this is normal because of the above, DRI_PRIME doesn't do 
>> > much:
>> >
>> > $ glxinfo | grep "OpenGL renderer"
>> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
>> > $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
>> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
>> >
>> > Strangely enough, the /sys device link for "card1", as mentioned in the 
>> > Xorg log, still points to the "correct" ATI device:
>> >
>> > $ ls -l /sys/class/drm/card1/device
>> > lrwxrwxrwx 1 root root 0 Feb  3 21:14 /sys/class/drm/card1/device -> 
>> > ../../../:03:00.0
>> >
>> >
>> > I'm a bit stumped here. How can I get my radeon device back in the xrandr 
>> > providers and working via DRI_PRIME?
>>
>> I can see two problems here: Xorg unloads the radeon driver and loads
>> the modesetting driver instead, and the modesetting driver doesn't
>> advertise PRIME render offloading capability. I don't think either is a
>> radeon driver issue though, so the xorg-devel list seems more
>> appropriate. Moving there.
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>
>
> Okay. The second problem isn't much of a problem (for me, personally) if the
> first gets resolved, so I suppose it makes sense to look at that first.
>
> Why would Xorg unload a valid driver for a card and load another instead? And,
> more to the point, is there a way of preventing it from happening?

Possibly an old version of the driver that is missing the pci id for
the asic you have.

Alex
___
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 1/5] Start using stdbool.h instead of Xlib or custom bools.

[Alex Deucher]

On Mon, Feb 1, 2016 at 4:48 PM, Eric Anholt  wrote:
> I have a hard time typing anything else at this point.
>
> Signed-off-by: Eric Anholt 
> ---
>  main.c   | 21 ++
>  ops.c|  2 +-
>  rendercheck.h| 58 +++-
>  t_blend.c|  8 +++
>  t_bug7366.c  | 32 +--
>  t_composite.c| 12 +-
>  t_dstcoords.c|  6 ++---
>  t_fill.c |  6 ++---
>  t_gradient.c | 32 +--
>  t_gtk_argb_xbgr.c|  8 +++
>  t_libreoffice_xrgb.c | 10 -
>  t_repeat.c   | 22 +--
>  t_srccoords.c| 14 ++--
>  t_triangles.c| 24 ++--
>  t_tsrccoords.c   | 12 +-
>  t_tsrccoords2.c  | 14 ++--
>  tests.c  | 62 
> ++--
>  17 files changed, 171 insertions(+), 172 deletions(-)
>
> diff --git a/main.c b/main.c
> index a7035b9..b5d67cc 100644
> --- a/main.c
> +++ b/main.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>
> -Bool is_verbose = FALSE, minimalrendering = FALSE;
> +bool is_verbose = false, minimalrendering = false;
>  int enabled_tests = ~0;/* Enable all tests by default */
>
>  int format_whitelist_len = 0;
> @@ -163,7 +163,8 @@ int main(int argc, char **argv)
> Display *dpy;
> XEvent ev;
> int i, o, maj, min;
> -   static Bool is_sync = FALSE, print_version = FALSE;
> +   static int is_sync = false, print_version = false;

Did you mean bool here rather than int?

Alex
___
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] modesetting: Require sufficiently new libdrm

[Alex Deucher]

On Wed, Jan 27, 2016 at 11:50 AM, Adam Jackson <a...@redhat.com> wrote:
> Bugzilla: https://bugs.freedesktop.org/93883
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  configure.ac | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index ac3bb64..312fc69 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2035,8 +2035,7 @@ if test "x$XORG" = xyes; then
>
> if test "x$DRM" = xyes; then
> dnl 2.4.46 is required for cursor hotspot support.
> -   PKG_CHECK_EXISTS(libdrm >= 2.4.46)
> -   XORG_DRIVER_MODESETTING=yes
> +   PKG_CHECK_EXISTS(libdrm >= 2.4.46, 
> XORG_DRIVER_MODESETTING=yes, XORG_DRIVER_MODESETTING=no)
> fi
>
> AC_SUBST([XORG_LIBS])
> --
> 2.5.0
>
> ___
> 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
___
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] xfree86/modes: Set RandR primary output from CreateScreenResources

[Alex Deucher]

On Thu, Jan 14, 2016 at 4:09 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Fixes XRRGetOutputPrimary and xrandr not reporting a primary output after
> startup. This was especially confusing when an output was explicitly
> marked as primary using Option "Primary" in Section "Monitor".
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>


> ---
>  hw/xfree86/modes/xf86RandR12.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
> index eae7016..ac02b30 100644
> --- a/hw/xfree86/modes/xf86RandR12.c
> +++ b/hw/xfree86/modes/xf86RandR12.c
> @@ -1626,6 +1626,7 @@ xf86RandR12CreateScreenResources12(ScreenPtr pScreen)
>  {
>  int c;
>  ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
> +rrScrPrivPtr rp = rrGetScrPriv(pScreen);
>  xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
>
>  if (xf86RandR12Key == NULL)
> @@ -1638,6 +1639,13 @@ xf86RandR12CreateScreenResources12(ScreenPtr pScreen)
>   config->maxWidth, config->maxHeight);
>
>  xf86RandR12CreateMonitors(pScreen);
> +
> +if (!pScreen->isGPU) {
> +rp->primaryOutput = config->output[0]->randr_output;
> +RROutputChanged(rp->primaryOutput, FALSE);
> +rp->layoutChanged = TRUE;
> +}
> +
>  return TRUE;
>  }
>
> --
> 2.6.2
>
> ___
> 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
___
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] prime: Damage full destination rectangle when we start dirty tracking

[Alex Deucher]

On Thu, Dec 3, 2015 at 3:04 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> This makes sure that the destination pixmap contents will be fully
> initialized. Without this, a PRIME output starts out with garbage.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  dix/pixmap.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/dix/pixmap.c b/dix/pixmap.c
> index 05aebc4..11d83fe 100644
> --- a/dix/pixmap.c
> +++ b/dix/pixmap.c
> @@ -173,6 +173,9 @@ PixmapStartDirtyTracking(PixmapPtr src,
>  {
>  ScreenPtr screen = src->drawable.pScreen;
>  PixmapDirtyUpdatePtr dirty_update;
> +RegionPtr damageregion;
> +RegionRec dstregion;
> +BoxRec box;
>
>  dirty_update = calloc(1, sizeof(PixmapDirtyUpdateRec));
>  if (!dirty_update)
> @@ -205,6 +208,24 @@ PixmapStartDirtyTracking(PixmapPtr src,
>  return FALSE;
>  }
>
> +/* Damage destination rectangle so that the destination pixmap contents
> + * will get fully initialized
> + */
> +box.x1 = dirty_update->x;
> +box.y1 = dirty_update->y;
> +if (dirty_update->rotation == RR_Rotate_90 ||
> +dirty_update->rotation == RR_Rotate_270) {
> +box.x2 = dirty_update->x + slave_dst->drawable.height;
> +box.y2 = dirty_update->y + slave_dst->drawable.width;
> +} else {
> +box.x2 = dirty_update->x + slave_dst->drawable.width;
> +box.y2 = dirty_update->y + slave_dst->drawable.height;
> +}
> +RegionInit(, , 1);
> +damageregion = DamageRegion(dirty_update->damage);
> +RegionUnion(damageregion, damageregion, );
> +RegionUninit();
> +
>  DamageRegister(>drawable, dirty_update->damage);
>  xorg_list_add(_update->ent, >pixmap_dirty_list);
>  return TRUE;
> --
> 2.6.2
>
> ___
> 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
___
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 3/4] modesetting: Remove XF86_CRTC_VERSION checks

[Alex Deucher]

On Thu, Oct 29, 2015 at 9:58 AM, Daniel Martin
<daniel.mar...@secunet.com> wrote:
> From: Daniel Martin <consume.no...@gmail.com>
>
> The ifdef checks for XF86_CRTC_VERSION >= 3/5 are remnants from the
> out-of-tree driver. Within the tree, we can rely on:
> xf86Crtc.h:#define XF86_CRTC_VERSION 6
>
> Signed-off-by: Daniel Martin <consume.no...@gmail.com>

For 1-3:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 2684bae..4421578 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -462,11 +462,8 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
> mode,
>  crtc->y = saved_y;
>  crtc->rotation = saved_rotation;
>  crtc->mode = saved_mode;
> -}
> -#if defined(XF86_CRTC_VERSION) && XF86_CRTC_VERSION >= 3
> -else
> +} else
>  crtc->active = TRUE;
> -#endif
>
>  free(output_ids);
>
> @@ -1789,9 +1786,7 @@ drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr 
> drmmode, int cpp)
>  drmmode_clones_init(pScrn, drmmode, mode_res);
>
>  drmModeFreeResources(mode_res);
> -#if XF86_CRTC_VERSION >= 5
>  xf86ProviderSetup(pScrn, NULL, "modesetting");
> -#endif
>
>  xf86InitialConfiguration(pScrn, TRUE);
>
> --
> 2.6.1
>
> ___
> 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
___
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] DRI2: Sync radeonsi_pci_ids.h from Mesa

[Alex Deucher]

On Mon, Oct 26, 2015 at 10:51 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Fixes DRI2 client driver name mapping for newer AMD GPUs with the
> modesetting driver, allowing the DRI2 extension to initialize.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 28 
>  1 file changed, 28 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index 571e863..bcf15a1 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -63,6 +63,7 @@ CHIPSET(0x6608, OLAND_6608, OLAND)
>  CHIPSET(0x6610, OLAND_6610, OLAND)
>  CHIPSET(0x6611, OLAND_6611, OLAND)
>  CHIPSET(0x6613, OLAND_6613, OLAND)
> +CHIPSET(0x6617, OLAND_6617, OLAND)
>  CHIPSET(0x6620, OLAND_6620, OLAND)
>  CHIPSET(0x6621, OLAND_6621, OLAND)
>  CHIPSET(0x6623, OLAND_6623, OLAND)
> @@ -85,6 +86,7 @@ CHIPSET(0x6651, BONAIRE_6651, BONAIRE)
>  CHIPSET(0x6658, BONAIRE_6658, BONAIRE)
>  CHIPSET(0x665C, BONAIRE_665C, BONAIRE)
>  CHIPSET(0x665D, BONAIRE_665D, BONAIRE)
> +CHIPSET(0x665F, BONAIRE_665F, BONAIRE)
>
>  CHIPSET(0x9830, KABINI_9830, KABINI)
>  CHIPSET(0x9831, KABINI_9831, KABINI)
> @@ -155,3 +157,29 @@ CHIPSET(0x67B8, HAWAII_67B8, HAWAII)
>  CHIPSET(0x67B9, HAWAII_67B9, HAWAII)
>  CHIPSET(0x67BA, HAWAII_67BA, HAWAII)
>  CHIPSET(0x67BE, HAWAII_67BE, HAWAII)
> +
> +CHIPSET(0x6900, ICELAND_, ICELAND)
> +CHIPSET(0x6901, ICELAND_, ICELAND)
> +CHIPSET(0x6902, ICELAND_, ICELAND)
> +CHIPSET(0x6903, ICELAND_, ICELAND)
> +CHIPSET(0x6907, ICELAND_, ICELAND)
> +
> +CHIPSET(0x6920, TONGA_, TONGA)
> +CHIPSET(0x6921, TONGA_, TONGA)
> +CHIPSET(0x6928, TONGA_, TONGA)
> +CHIPSET(0x6929, TONGA_, TONGA)
> +CHIPSET(0x692B, TONGA_, TONGA)
> +CHIPSET(0x692F, TONGA_, TONGA)
> +CHIPSET(0x6930, TONGA_, TONGA)
> +CHIPSET(0x6938, TONGA_, TONGA)
> +CHIPSET(0x6939, TONGA_, TONGA)
> +
> +CHIPSET(0x9870, CARRIZO_, CARRIZO)
> +CHIPSET(0x9874, CARRIZO_, CARRIZO)
> +CHIPSET(0x9875, CARRIZO_, CARRIZO)
> +CHIPSET(0x9876, CARRIZO_, CARRIZO)
> +CHIPSET(0x9877, CARRIZO_, CARRIZO)
> +
> +CHIPSET(0x7300, FIJI_, FIJI)
> +
> +CHIPSET(0x98E4, STONEY_, STONEY)
> --
> 2.6.1
>
> ___
> 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
___
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] Only align screen / scanout pixmap height where necessary

[Alex Deucher]

On Fri, Oct 2, 2015 at 5:11 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> When using glamor acceleration, the pixmap's header has to have a height
> that matches exactly what the actual height is minus the GPU memory
> alignment. Otherwise CRTCs scanning out from the main scanout buffer
> (e.g. every CRTC that isn't rotated or transformed in some way) won't
> always work. This results in a bug where rotating one monitor in a
> multi-monitor setup won't always work properly. Easiest way to reproduce
> this:
>
> - Have two monitors (I've gotten this working with a 1920x1080 and
>   1280x1024, along with two 1920x1080s)
> - Rotate one of them from 0° to 90°, then rotate the same monitor from
>   90° to 180°. The monitor that hasn't been rotated won't properly
>   update, and will stay on a blank screen
>
> This doesn't seem to make any difference when using EXA for
> acceleration.
>
> Compared to Stephen Chandler's patch, this drops the height alignment
> in most places and only keeps it where it's really necessary.
>
> Reported-by: Stephen Chandler Paul <cp...@redhat.com>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

Anyone want to port this to amdgpu?

Alex

> ---
>
> Stephen Chandler,
>
> thanks for the good catch, but I think we can take this even further.
> Does this fix the problem for you as well?
>
>  src/drmmode_display.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index efc35f0..623124e 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -525,6 +525,7 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
> RADEONInfoPtr info = RADEONPTR(pScrn);
> drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> drmmode_ptr drmmode = drmmode_crtc->drmmode;
> +   int aligned_height;
> int size;
> int ret;
> unsigned long rotate_pitch;
> @@ -547,9 +548,9 @@ drmmode_crtc_scanout_allocate(xf86CrtcPtr crtc,
> rotate_pitch =
> RADEON_ALIGN(width, drmmode_get_pitch_align(pScrn, 
> drmmode->cpp, 0))
> * drmmode->cpp;
> -   height = RADEON_ALIGN(height, drmmode_get_height_align(pScrn, 0));
> +   aligned_height = RADEON_ALIGN(height, drmmode_get_height_align(pScrn, 
> 0));
> base_align = drmmode_get_base_align(pScrn, drmmode->cpp, 0);
> -   size = RADEON_ALIGN(rotate_pitch * height, RADEON_GPU_PAGE_SIZE);
> +   size = RADEON_ALIGN(rotate_pitch * aligned_height, 
> RADEON_GPU_PAGE_SIZE);
>
> scanout->bo = radeon_bo_open(drmmode->bufmgr, 0, size, base_align,
>  RADEON_GEM_DOMAIN_VRAM, 0);
> @@ -633,7 +634,6 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
> mode,
> drmModeModeInfo kmode;
> int pitch;
> uint32_t tiling_flags = 0;
> -   int height;
>
> if (info->allowColorTiling) {
> if (info->ChipFamily >= CHIP_FAMILY_R600)
> @@ -644,14 +644,13 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
> mode,
>
> pitch = RADEON_ALIGN(pScrn->displayWidth, 
> drmmode_get_pitch_align(pScrn, info->pixel_bytes, tiling_flags)) *
> info->pixel_bytes;
> -   height = RADEON_ALIGN(pScrn->virtualY, 
> drmmode_get_height_align(pScrn, tiling_flags));
> if (info->ChipFamily >= CHIP_FAMILY_R600) {
> pitch = info->front_surface.level[0].pitch_bytes;
> }
>
> if (drmmode->fb_id == 0) {
> ret = drmModeAddFB(drmmode->fd,
> -  pScrn->virtualX, height,
> +  pScrn->virtualX, pScrn->virtualY,
> pScrn->depth, pScrn->bitsPerPixel,
>pitch,
>info->front_bo->handle,
> @@ -1789,6 +1788,7 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, 
> int height)
> ScreenPtr   screen = xf86ScrnToScreen(scrn);
> uint32_told_fb_id;
> int i, pitch, old_width, old_height, old_pitch;
> +   int aligned_height;
> uint32_t screen_size;
> int cpp = info->pixel_bytes;
> struct radeon_bo *front_bo;
> @@ -1822,8 +1822,8 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, 
> int height)
> }
>
> pitch = RADEON_ALIGN(width, drmmode_get_pitch_align(scrn, cpp, 
&g

Re: via_ati_questions

[Alex Deucher]

On Thu, Aug 6, 2015 at 9:55 AM, Doug Lasse yeaohyea...@gmail.com wrote:
 Hi,

 I'm writing to you cause I have several questions about my 2 graphics card
 which are VIA K8N800/K8M800/K8N800A Unichrome Pro IGP and ATI Radeon 8500.

 For my VIA : I've tried openchrome and proprietary via driver but without
 any success. Is there an old openchrome I could download ? Cause the link at
 freedesktop.org seems to be dead.

 For my Radeon : I've all the fglrx I could (olders and newers) but none work
 fine. So I tried with the generic driver radeon : but I works fine but only
 without hardware acceleration : neither 2D nor 3D.
 I know there's a radeon or fglrx which could suit me perfectly cause I tried
 Mandriva 2006 or 2010 and I had 3D acceleration working perfectly : prove :
 Neverball was more than ok for graphicals.

 If the drivers method doesn't work at all I'd like to downgrade xorg : could
 you please tell me how to do it properly without breaking the kernel ?

 I've tried many methods and know I'm bored so I ask to you : who can be more
 qualifified than a developper to answer me and show me the right way ?

The open source radeon driver should work out of the box an most
distros.  Nothing extra to install.  If you are using debian, make
sure to install the firmware packages.

Alex



 Thanks a lot in advance for you answer.

 Regards, Doug.

 ___
 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
___
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] [RFC] modesetting: add zaphod support (v2)

[Alex Deucher]

On Tue, Aug 4, 2015 at 6:18 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
 Hi Dave,

 thanks for implementing this!

 This one is

 Reviewed-and-tested-by: Mario Kleiner mario.kleiner...@gmail.com

 I tested on intel/nouveau/radeon-kms with different combos of one/two/three
 x-screen with one/two/three ZaphohHeads outputs and also regular
 single-x-screen multi-display.

 In combination with the additional series of patches i just sent out for
 handling  1 output per x-screen and for some nvidia cards, on top of your
 patch, this works fine on all tested setups.

 Maybe we could squash all the Zaphod patches into one patch, throwing away
 my commit messages, so we have one nice patch to show the state of the art
 in ZaphodHeads enablement?

Both Dave and Mario's patches are:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 thanks,
 -mario


 On 07/27/2015 01:43 AM, Dave Airlie wrote:

 From: Dave Airlie airl...@redhat.com

 This adds zaphod and ZaphodHeads support
 to the the in-server modesetting driver.

 this is based on a request from Mario,
 and on the current radeon driver.

 v2: fixup vblank fd registring.

 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
   hw/xfree86/drivers/modesetting/driver.c  | 191
 ++-
   hw/xfree86/drivers/modesetting/driver.h  |  32 ++--
   hw/xfree86/drivers/modesetting/drmmode_display.c |  47 +-
   hw/xfree86/drivers/modesetting/drmmode_display.h |   5 +
   hw/xfree86/drivers/modesetting/vblank.c  |  23 ++-
   5 files changed, 209 insertions(+), 89 deletions(-)

 diff --git a/hw/xfree86/drivers/modesetting/driver.c
 b/hw/xfree86/drivers/modesetting/driver.c
 index 324b8bd..5dcc6a0 100644
 --- a/hw/xfree86/drivers/modesetting/driver.c
 +++ b/hw/xfree86/drivers/modesetting/driver.c
 @@ -118,24 +118,17 @@ static SymTabRec Chipsets[] = {
   {-1, NULL}
   };

 -typedef enum {
 -OPTION_SW_CURSOR,
 -OPTION_DEVICE_PATH,
 -OPTION_SHADOW_FB,
 -OPTION_ACCEL_METHOD,
 -OPTION_PAGEFLIP,
 -} modesettingOpts;
 -
   static const OptionInfoRec Options[] = {
   {OPTION_SW_CURSOR, SWcursor, OPTV_BOOLEAN, {0}, FALSE},
   {OPTION_DEVICE_PATH, kmsdev, OPTV_STRING, {0}, FALSE},
   {OPTION_SHADOW_FB, ShadowFB, OPTV_BOOLEAN, {0}, FALSE},
   {OPTION_ACCEL_METHOD, AccelMethod, OPTV_STRING, {0}, FALSE},
   {OPTION_PAGEFLIP, PageFlip, OPTV_BOOLEAN, {0}, FALSE},
 +{OPTION_ZAPHOD_HEADS, ZaphodHeads, OPTV_STRING, {0}, FALSE},
   {-1, NULL, OPTV_NONE, {0}, FALSE}
   };

 -int modesettingEntityIndex = -1;
 +int ms_entity_index = -1;

   static MODULESETUPPROTO(Setup);

 @@ -187,6 +180,15 @@ Identify(int flags)
 Chipsets);
   }

 +modesettingEntPtr ms_ent_priv(ScrnInfoPtr scrn)
 +{
 +DevUnion *pPriv;
 +modesettingPtr ms = modesettingPTR(scrn);
 +pPriv = xf86GetEntityPrivate(ms-pEnt-index,
 + ms_entity_index);
 +return pPriv-ptr;
 +}
 +
   static int
   open_hw(const char *dev)
   {
 @@ -366,6 +368,7 @@ ms_platform_probe(DriverPtr driver,
 intptr_t match_data)
   {
   ScrnInfoPtr scrn = NULL;
 +EntityInfoPtr pEnt;
   const char *path = xf86_platform_device_odev_attributes(dev)-path;
   int scr_flags = 0;

 @@ -374,12 +377,39 @@ ms_platform_probe(DriverPtr driver,

   if (probe_hw(path, dev)) {
   scrn = xf86AllocateScreen(driver, scr_flags);
 +if (xf86IsEntitySharable(entity_num))
 +xf86SetEntityShared(entity_num);
   xf86AddEntityToScreen(scrn, entity_num);

   ms_setup_scrn_hooks(scrn);

   xf86DrvMsg(scrn-scrnIndex, X_INFO,
  using drv %s\n, path ? path : default device);
 +
 +pEnt = xf86GetEntityInfo(entity_num);
 +{
 +DevUnion *pPriv;
 +modesettingEntPtr pMSEnt;
 +
 +xf86SetEntitySharable(entity_num);
 +
 +if (ms_entity_index == -1)
 +ms_entity_index = xf86AllocateEntityPrivateIndex();
 +
 +pPriv = xf86GetEntityPrivate(pEnt-index,
 + ms_entity_index);
 +
 +xf86SetEntityInstanceForScreen(scrn, pEnt-index,
 xf86GetNumEntityInstances(pEnt-index) - 1);
 +
 +if (!pPriv-ptr) {
 +pPriv-ptr = xnfcalloc(sizeof(modesettingEntRec), 1);
 +pMSEnt = pPriv-ptr;
 +} else {
 +pMSEnt = pPriv-ptr;
 +}
 +pMSEnt-platform_dev = dev;
 +}
 +
   }

   return scrn != NULL;
 @@ -596,19 +626,25 @@ FreeRec(ScrnInfoPtr pScrn)
   pScrn-driverPrivate = NULL;

   if (ms-fd  0) {
 +modesettingEntPtr ms_ent;
   int ret;

 -if (ms-pEnt-location.type == BUS_PCI)
 -ret = drmClose(ms-fd);
 -else
 +ms_ent = ms_ent_priv(pScrn);
 +ms_ent-fd_ref--;
 +if (!ms_ent-fd_ref) {
 +if (ms-pEnt-location.type == BUS_PCI

Re: [PATCH xf86-video-sis] Remove upload / download EXA hooks

[Alex Deucher]

On Mon, Aug 3, 2015 at 1:24 PM, Connor Behan connor.be...@gmail.com wrote:
 Support based on something other than libc memcpy was never added, so
 these functions did not improve upon software fallback at all.

 Signed-off-by: Connor Behan connor.be...@gmail.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  src/sis300_accel.c |  7 ---
  src/sis310_accel.c | 54 
 --
  src/sis_accel.c|  6 --
  3 files changed, 67 deletions(-)

 diff --git a/src/sis300_accel.c b/src/sis300_accel.c
 index af0527d..7176b4f 100644
 --- a/src/sis300_accel.c
 +++ b/src/sis300_accel.c
 @@ -59,10 +59,7 @@

  #ifdef SIS_USE_EXA
  extern void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area);
 -extern Bool SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, 
 char *src, int src_pitch);
  extern Bool SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst);
 -extern Bool SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h,
 -   char *dst, int dst_pitch);
  #endif /* EXA */

  extern UChar SiSGetCopyROP(int rop);
 @@ -1273,10 +1270,6 @@ SiS300AccelInit(ScreenPtr pScreen)

  /* Composite not supported */

 -/* Upload, download to/from Screen */
 -pSiS-EXADriverPtr-UploadToScreen = SiSUploadToScreen;
 -pSiS-EXADriverPtr-DownloadFromScreen = 
 SiSDownloadFromScreen;
 -
   } else {

  xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
 diff --git a/src/sis310_accel.c b/src/sis310_accel.c
 index 1a6f639..40b6941 100644
 --- a/src/sis310_accel.c
 +++ b/src/sis310_accel.c
 @@ -129,9 +129,7 @@ static CARD32 SiSDstTextureFormats32[3] = { 
 PICT_x8r8g8b8, PICT_a8r8g8b8, 0 };

  #ifdef SIS_USE_EXA /* EXA */
  void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area);
 -Bool SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, char 
 *src, int src_pitch);
  Bool SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst);
 -Bool SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h, char 
 *dst, int dst_pitch);
  #endif /* EXA */

  #ifdef INCL_YUV_BLIT_ADAPTOR
 @@ -1870,30 +1868,6 @@ SiSDoneComposite(PixmapPtr pDst)
  #endif

  Bool
 -SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, char *src, int 
 src_pitch)
 -{
 -   ScrnInfoPtr pScrn = xf86ScreenToScrn(pDst-drawable.pScreen);
 -   SISPtr pSiS = SISPTR(pScrn);
 -   unsigned char *dst = pDst-devPrivate.ptr;
 -   int dst_pitch = exaGetPixmapPitch(pDst);
 -
 -   (pSiS-SyncAccel)(pScrn);
 -
 -   if(pDst-drawable.bitsPerPixel  8)
 -  return FALSE;
 -
 -   dst += (x * pDst-drawable.bitsPerPixel / 8) + (y * src_pitch);
 -   while(h--) {
 -  SiSMemCopyToVideoRam(pSiS, dst, (unsigned char *)src,
 -   (w * pDst-drawable.bitsPerPixel / 8));
 -  src += src_pitch;
 -  dst += dst_pitch;
 -   }
 -
 -   return TRUE;
 -}
 -
 -Bool
  SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst)
  {
 ScrnInfoPtr pScrn = xf86ScreenToScrn(pSrc-drawable.pScreen);
 @@ -1947,30 +1921,6 @@ SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst)

 return TRUE;
  }
 -
 -Bool
 -SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h, char *dst, 
 int dst_pitch)
 -{
 -   ScrnInfoPtr pScrn = xf86ScreenToScrn(pSrc-drawable.pScreen);
 -   SISPtr pSiS = SISPTR(pScrn);
 -   unsigned char *src = pSrc-devPrivate.ptr;
 -   int src_pitch = exaGetPixmapPitch(pSrc);
 -   int size = src_pitch  dst_pitch ? src_pitch : dst_pitch;
 -
 -   (pSiS-SyncAccel)(pScrn);
 -
 -   if(pSrc-drawable.bitsPerPixel  8)
 -  return FALSE;
 -
 -   src += (x * pSrc-drawable.bitsPerPixel / 8) + (y * src_pitch);
 -   while(h--) {
 -  SiSMemCopyFromVideoRam(pSiS, (unsigned char *)dst, src, size);
 -  src += src_pitch;
 -  dst += dst_pitch;
 -   }
 -
 -   return TRUE;
 -}
  #endif /* EXA */

  /* Helper for xv video blitter */
 @@ -2303,10 +2253,6 @@ SiS315AccelInit(ScreenPtr pScreen)
   }
  #endif

 - /* Upload, download to/from Screen */
 - pSiS-EXADriverPtr-UploadToScreen = SiSUploadToScreen;
 - pSiS-EXADriverPtr-DownloadFromScreen = SiSDownloadFromScreen;
 -
}
  #endif

 diff --git a/src/sis_accel.c b/src/sis_accel.c
 index c2c24c7..dc45f2b 100644
 --- a/src/sis_accel.c
 +++ b/src/sis_accel.c
 @@ -53,9 +53,7 @@

  #ifdef SIS_USE_EXA
  extern void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area);
 -extern Bool SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, 
 char *src, int src_pitch);
  extern Bool SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst);
 -extern Bool SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int 
 h, char *dst, int dst_pitch);
  #endif /* EXA */

  extern UChar SiSGetCopyROP(int rop);
 @@ -801,10 +799,6

Re: [PATCH 1/2] Add Bonaire 0x665F

[Alex Deucher]

On Sun, Jul 26, 2015 at 5:35 PM, Josef Larsson josla...@student.liu.se wrote:
 The PCI ID was missing so the xorg radeon driver could not find my
 graphics card (XFX Radeon R7 360), so I added it and now it works fine:

 # lspci | grep VGA
 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
 [AMD/ATI] Device 665f (rev 81)

 Perhaps one should should also assume that a 0x665e revision also exists
 (I did not include this in the patches).

 This patch is for xserver, and I am not sure if it is necessary. The
 second patch (in next message) for xf86-video-ati however is absolutely
 necessary. Please note that this patch was applied on the tag
 xf86-video-ati-7.5.0 and will not apply cleanly on the master branch.

It's already included in xf86-video-ati:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=7c4b78ab10b82c6dba9f72034ff7583859cca63d

Alex


 From 4f7417e6cfe36fdb6fbef003fc47a21ed00d10cc Mon Sep 17 00:00:00 2001
 From: Josef Larsson josla...@student.liu.se
 Date: Sun, 26 Jul 2015 00:30:31 +0200
 Subject: [PATCH] Add Bonaire 0x665F

 ---
  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
 b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
 index 571e863..cd5da99 100644
 --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
 +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
 @@ -85,6 +85,7 @@ CHIPSET(0x6651, BONAIRE_6651, BONAIRE)
  CHIPSET(0x6658, BONAIRE_6658, BONAIRE)
  CHIPSET(0x665C, BONAIRE_665C, BONAIRE)
  CHIPSET(0x665D, BONAIRE_665D, BONAIRE)
 +CHIPSET(0x665F, BONAIRE_665F, BONAIRE)

  CHIPSET(0x9830, KABINI_9830, KABINI)
  CHIPSET(0x9831, KABINI_9831, KABINI)
 --
 2.3.6
 ___
 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
___
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 1/4] modesetting: Implement 32-24 bpp conversion in shadow update

[Alex Deucher]

On Wed, Jul 22, 2015 at 12:14 PM, Adam Jackson a...@redhat.com wrote:
 From: Dave Airlie airl...@redhat.com

 24bpp front buffers tend to be the least well tested path for client
 rendering.  On the qemu cirrus emulation, and on some Matrox G200 server
 chips, the hardware can't do 32bpp at all.  It's better to just allocate
 a 32bpp shadow and downconvert in the upload hook than expose a funky
 pixmap format to clients.

 [ajax: Ported from RHEL and separate modesetting driver, lifted kbpp
 into the drmmode struct, cleaned up commit message, fixed 16bpp]

 Reviewed-by: Adam Jackson a...@redhat.com
 Signed-off-by: Dave Airlied airl...@redhat.com

For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  hw/xfree86/drivers/modesetting/Makefile.am   |   2 +
  hw/xfree86/drivers/modesetting/driver.c  |  41 ---
  hw/xfree86/drivers/modesetting/drmmode_display.c |  24 ++--
  hw/xfree86/drivers/modesetting/drmmode_display.h |   2 +
  hw/xfree86/drivers/modesetting/sh3224.c  | 140 
 +++
  hw/xfree86/drivers/modesetting/sh3224.h  |   7 ++
  6 files changed, 193 insertions(+), 23 deletions(-)
  create mode 100644 hw/xfree86/drivers/modesetting/sh3224.c
  create mode 100644 hw/xfree86/drivers/modesetting/sh3224.h

 diff --git a/hw/xfree86/drivers/modesetting/Makefile.am 
 b/hw/xfree86/drivers/modesetting/Makefile.am
 index 82c4f2f..ca7e05a 100644
 --- a/hw/xfree86/drivers/modesetting/Makefile.am
 +++ b/hw/xfree86/drivers/modesetting/Makefile.am
 @@ -51,6 +51,8 @@ modesetting_drv_la_SOURCES = \
  dumb_bo.c \
  dumb_bo.h \
  present.c \
 +sh3224.c \
 +sh3224.h \
  vblank.c \
  $(NULL)

 diff --git a/hw/xfree86/drivers/modesetting/driver.c 
 b/hw/xfree86/drivers/modesetting/driver.c
 index 324b8bd..68a865f 100644
 --- a/hw/xfree86/drivers/modesetting/driver.c
 +++ b/hw/xfree86/drivers/modesetting/driver.c
 @@ -60,6 +60,7 @@
  #endif

  #include driver.h
 +#include sh3224.h

  static void AdjustFrame(ScrnInfoPtr pScrn, int x, int y);
  static Bool CloseScreen(ScreenPtr pScreen);
 @@ -770,10 +771,16 @@ PreInit(ScrnInfoPtr pScrn, int flags)
  }
  #endif
  drmmode_get_default_bpp(pScrn, ms-drmmode, defaultdepth, defaultbpp);
 -if (defaultdepth == 24  defaultbpp == 24)
 -bppflags = SupportConvert32to24 | Support24bppFb;
 -else
 -bppflags = PreferConvert24to32 | SupportConvert24to32 | 
 Support32bppFb;
 +if (defaultdepth == 24  defaultbpp == 24) {
 +   ms-drmmode.force_24_32 = TRUE;
 +   ms-drmmode.kbpp = 24;
 +   xf86DrvMsg(pScrn-scrnIndex, X_INFO,
 +  Using 24bpp hw front buffer with 32bpp shadow\n);
 +   defaultbpp = 32;
 +} else {
 +   ms-drmmode.kbpp = defaultbpp;
 +}
 +bppflags = PreferConvert24to32 | SupportConvert24to32 | Support32bppFb;

  if (!xf86SetDepthBpp
  (pScrn, defaultdepth, defaultdepth, defaultbpp, bppflags))
 @@ -827,18 +834,24 @@ PreInit(ScrnInfoPtr pScrn, int flags)
  } else {
  Bool prefer_shadow = TRUE;

 -ret = drmGetCap(ms-fd, DRM_CAP_DUMB_PREFER_SHADOW, value);
 -if (!ret) {
 -prefer_shadow = !!value;
 -}
 +   if (ms-drmmode.force_24_32) {
 +   prefer_shadow = TRUE;
 +   ms-drmmode.shadow_enable = TRUE;
 +   } else {
 +   ret = drmGetCap(ms-fd, DRM_CAP_DUMB_PREFER_SHADOW, value);
 +   if (!ret) {
 +   prefer_shadow = !!value;
 +   }

 -ms-drmmode.shadow_enable = xf86ReturnOptValBool(ms-Options,
 - OPTION_SHADOW_FB,
 - prefer_shadow);
 +   ms-drmmode.shadow_enable = xf86ReturnOptValBool(ms-Options,
 +OPTION_SHADOW_FB,
 +prefer_shadow);
 +   }

  xf86DrvMsg(pScrn-scrnIndex, X_INFO,
 ShadowFB: preferred %s, enabled %s\n,
 prefer_shadow ? YES : NO,
 +  ms-drmmode.force_24_32 ? FORCE :
 ms-drmmode.shadow_enable ? YES : NO);

  ms-drmmode.pageflip = FALSE;
 @@ -894,7 +907,7 @@ msShadowWindow(ScreenPtr screen, CARD32 row, CARD32 
 offset, int mode,
  modesettingPtr ms = modesettingPTR(pScrn);
  int stride;

 -stride = (pScrn-displayWidth * pScrn-bitsPerPixel) / 8;
 +stride = (pScrn-displayWidth * ms-drmmode.kbpp) / 8;
  *size = stride;

  return ((uint8_t *) ms-drmmode.front_bo.dumb-ptr + row * stride + 
 offset);
 @@ -915,6 +928,7 @@ CreateScreenResources(ScreenPtr pScreen)
  Bool ret;
  void *pixels = NULL;
  int err;
 +Bool use_ms_shadow = ms-drmmode.force_24_32  pScrn-bitsPerPixel == 
 32;

  pScreen-CreateScreenResources = ms-createScreenResources;
  ret = pScreen-CreateScreenResources

Re: [PATCH 1/7] glamor: Drop a redundant check.

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 Above, we've already checked for -fbo  -fbo-fb and returned.

 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_pixmap.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
 index f2bf223..0e51550 100644
 --- a/glamor/glamor_pixmap.c
 +++ b/glamor/glamor_pixmap.c
 @@ -897,8 +897,7 @@ glamor_pixmap_upload_prepare(PixmapPtr pixmap, GLenum 
 format, int no_alpha,
  }

  if ((flag == GLAMOR_CREATE_FBO_NO_FBO
 -  pixmap_priv-fbo  pixmap_priv-fbo-tex)
 -|| (flag == 0  pixmap_priv-fbo  pixmap_priv-fbo-fb))
 +  pixmap_priv-fbo  pixmap_priv-fbo-tex))
  return 0;

  if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP)
 --
 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
___
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 7/7] glamor: Use ARRAY_SIZE in a couple more places for consistency.

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_program.c | 6 ++
  glamor/glamor_render.c  | 5 +
  2 files changed, 3 insertions(+), 8 deletions(-)

 diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
 index 5619216..416c54a 100644
 --- a/glamor/glamor_program.c
 +++ b/glamor/glamor_program.c
 @@ -145,8 +145,6 @@ static glamor_location_var location_vars[] = {
  },
  };

 -#define NUM_LOCATION_VARS   (sizeof location_vars / sizeof 
 location_vars[0])
 -
  static char *
  add_var(char *cur, const char *add)
  {
 @@ -170,7 +168,7 @@ vs_location_vars(glamor_program_location locations)
  int l;
  char *vars = strdup();

 -for (l = 0; vars  l  NUM_LOCATION_VARS; l++)
 +for (l = 0; vars  l  ARRAY_SIZE(location_vars); l++)
  if (locations  location_vars[l].location)
  vars = add_var(vars, location_vars[l].vs_vars);
  return vars;
 @@ -182,7 +180,7 @@ fs_location_vars(glamor_program_location locations)
  int l;
  char *vars = strdup();

 -for (l = 0; vars  l  NUM_LOCATION_VARS; l++)
 +for (l = 0; vars  l  ARRAY_SIZE(location_vars); l++)
  if (locations  location_vars[l].location)
  vars = add_var(vars, location_vars[l].fs_vars);
  return vars;
 diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
 index 22480cd..004cd89 100644
 --- a/glamor/glamor_render.c
 +++ b/glamor/glamor_render.c
 @@ -770,10 +770,7 @@ combine_pict_format(PictFormatShort * des, const 
 PictFormatShort src,
  return TRUE;
  }

 -for (i = 0;
 - i 
 - sizeof(pict_format_combine_tab) /
 - sizeof(pict_format_combine_tab[0]); i++) {
 +for (i = 0; i  ARRAY_SIZE(pict_format_combine_tab); i++) {
  if ((src_type == pict_format_combine_tab[i][0]
mask_type == pict_format_combine_tab[i][1])
  || (src_type == pict_format_combine_tab[i][1]
 --
 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
___
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 5/7] glamor: Make a bunch of single-file glamor functions static.

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_largepixmap.c | 10 +++---
  glamor/glamor_priv.h| 22 --
  glamor/glamor_render.c  |  4 ++--
  3 files changed, 9 insertions(+), 27 deletions(-)

 diff --git a/glamor/glamor_largepixmap.c b/glamor/glamor_largepixmap.c
 index cbfd033..9a6c95e 100644
 --- a/glamor/glamor_largepixmap.c
 +++ b/glamor/glamor_largepixmap.c
 @@ -2,6 +2,10 @@

  #include glamor_priv.h

 +static void
 +glamor_get_transform_extent_from_box(struct pixman_box32 *box,
 + struct pixman_transform *transform);
 +
  static inline glamor_pixmap_private *
  __glamor_large(glamor_pixmap_private *pixmap_priv) {
  assert(glamor_pixmap_priv_is_large(pixmap_priv));
 @@ -681,7 +685,7 @@ glamor_compute_clipped_regions(PixmapPtr pixmap,
  /* XXX overflow still exist. maybe we need to change to use region32.
   * by default. Or just use region32 for repeat cases?
   **/
 -glamor_pixmap_clipped_regions *
 +static glamor_pixmap_clipped_regions *
  glamor_compute_transform_clipped_regions(PixmapPtr pixmap,
   struct pixman_transform *transform,
   RegionPtr region, int *n_region,
 @@ -876,7 +880,7 @@ glamor_merge_clipped_regions(PixmapPtr pixmap,
   * boundary and can avoid some overhead.
   *
   **/
 -Bool
 +static Bool
  glamor_get_transform_block_size(struct pixman_transform *transform,
  int block_w, int block_h,
  int *transformed_block_w,
 @@ -925,7 +929,7 @@ glamor_get_transform_block_size(struct pixman_transform 
 *transform,
 p.v[0] = x;  \
 p.v[1] = y;  \
 p.v[2] = 1.0; } while (0)
 -void
 +static void
  glamor_get_transform_extent_from_box(struct pixman_box32 *box,
   struct pixman_transform *transform)
  {
 diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
 index 43c1231..7e7bae7 100644
 --- a/glamor/glamor_priv.h
 +++ b/glamor/glamor_priv.h
 @@ -651,12 +651,6 @@ void glamor_fini_composite_shaders(ScreenPtr screen);
  void glamor_composite_rects(CARD8 op,
  PicturePtr pDst,
  xRenderColor *color, int nRect, xRectangle 
 *rects);
 -PicturePtr glamor_convert_gradient_picture(ScreenPtr screen,
 -   PicturePtr source,
 -   int x_source,
 -   int y_source, int width, int 
 height);
 -
 -void *glamor_setup_composite_vbo(ScreenPtr screen, int n_verts);

  /* glamor_trapezoid.c */
  void glamor_trapezoids(CARD8 op,
 @@ -733,14 +727,6 @@ glamor_compute_clipped_regions_ext(PixmapPtr pixmap,
 int inner_block_w, int inner_block_h,
 int reverse, int upsidedown);

 -glamor_pixmap_clipped_regions *
 -glamor_compute_transform_clipped_regions(PixmapPtr pixmap,
 - struct pixman_transform *transform,
 - RegionPtr region,
 - int *n_region, int dx, int dy,
 - int repeat_type, int reverse,
 - int upsidedown);
 -
  Bool glamor_composite_largepixmap_region(CARD8 op,
   PicturePtr source,
   PicturePtr mask,
 @@ -756,14 +742,6 @@ Bool glamor_composite_largepixmap_region(CARD8 op,
   INT16 x_dest, INT16 y_dest,
   CARD16 width, CARD16 height);

 -Bool glamor_get_transform_block_size(struct pixman_transform *transform,
 - int block_w, int block_h,
 - int *transformed_block_w,
 - int *transformed_block_h);
 -
 -void glamor_get_transform_extent_from_box(struct pixman_box32 *temp_box,
 -  struct pixman_transform 
 *transform);
 -
  /**
   * Upload a picture to gl texture. Similar to the
   * glamor_upload_pixmap_to_texture. Used in rendering.
 diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
 index 05eee91..0c776af 100644
 --- a/glamor/glamor_render.c
 +++ b/glamor/glamor_render.c
 @@ -660,7 +660,7 @@ glamor_composite_with_copy(CARD8 op,
  return ret;
  }

 -void *
 +static void *
  glamor_setup_composite_vbo(ScreenPtr screen, int n_verts)
  {
  glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
 @@ -1301,7 +1301,7 @@ glamor_composite_with_shader(CARD8 op,
  return ret;
  }

 -PicturePtr
 +static PicturePtr

Re: [PATCH 2/7] glamor: Fix up some weird formatting in _glamor_create_fbo_array().

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_fbo.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
 index cab2ff9..acb5d0d 100644
 --- a/glamor/glamor_fbo.c
 +++ b/glamor/glamor_fbo.c
 @@ -424,8 +424,8 @@ glamor_create_fbo_array(glamor_screen_private 
 *glamor_priv,

   cleanup:
  for (i = 0; i  block_wcnt * block_hcnt; i++)
 -if ((fbo_array)[i])
 -glamor_destroy_fbo(glamor_priv, (fbo_array)[i]);
 +if (fbo_array[i])
 +glamor_destroy_fbo(glamor_priv, fbo_array[i]);
  free(box_array);
  free(fbo_array);
  return NULL;
 --
 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
___
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 4/7] glamor: Drop dead glamor_es2_pixmap_read_prepare().

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 It's been unused since I killed glamor_download_pixmap_to_cpu().

 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_pixmap.c | 70 
 --
  glamor/glamor_priv.h   |  6 -
  2 files changed, 76 deletions(-)

 diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
 index 0e51550..9a14527 100644
 --- a/glamor/glamor_pixmap.c
 +++ b/glamor/glamor_pixmap.c
 @@ -1059,73 +1059,3 @@ glamor_upload_pixmap_to_texture(PixmapPtr pixmap)

  return ret;
  }
 -
 -/*
 - * as gles2 only support a very small set of color format and
 - * type when do glReadPixel,
 - * Before we use glReadPixels to get back a textured pixmap,
 - * Use shader to convert it to a supported format and thus
 - * get a new temporary pixmap returned.
 - * */
 -
 -glamor_pixmap_fbo *
 -glamor_es2_pixmap_read_prepare(PixmapPtr source, int x, int y, int w, int h,
 -   GLenum format, GLenum type, int no_alpha,
 -   int revert, int swap_rb)
 -{
 -glamor_pixmap_private *source_priv;
 -glamor_screen_private *glamor_priv;
 -ScreenPtr screen;
 -glamor_pixmap_fbo *temp_fbo;
 -float temp_xscale, temp_yscale, source_xscale, source_yscale;
 -static float vertices[8];
 -static float texcoords[8];
 -
 -screen = source-drawable.pScreen;
 -
 -glamor_priv = glamor_get_screen_private(screen);
 -source_priv = glamor_get_pixmap_private(source);
 -temp_fbo = glamor_create_fbo(glamor_priv, w, h, format, 0);
 -if (temp_fbo == NULL)
 -return NULL;
 -
 -glamor_make_current(glamor_priv);
 -temp_xscale = 1.0 / w;
 -temp_yscale = 1.0 / h;
 -
 -glamor_set_normalize_vcoords((struct glamor_pixmap_private *) NULL,
 - temp_xscale, temp_yscale, 0, 0, w, h,
 - vertices);
 -
 -glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT, GL_FALSE,
 -  2 * sizeof(float), vertices);
 -glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
 -
 -pixmap_priv_get_scale(source_priv, source_xscale, source_yscale);
 -glamor_set_normalize_tcoords(source_priv, source_xscale,
 - source_yscale,
 - x, y,
 - x + w, y + h,
 - texcoords);
 -
 -glVertexAttribPointer(GLAMOR_VERTEX_SOURCE, 2, GL_FLOAT, GL_FALSE,
 -  2 * sizeof(float), texcoords);
 -glEnableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
 -
 -glActiveTexture(GL_TEXTURE0);
 -glBindTexture(GL_TEXTURE_2D, source_priv-fbo-tex);
 -glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
 -glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 -
 -glamor_set_destination_pixmap_fbo(glamor_priv, temp_fbo, 0, 0, w, h);
 -glamor_set_alu(screen, GXcopy);
 -glUseProgram(glamor_priv-finish_access_prog[no_alpha]);
 -glUniform1i(glamor_priv-finish_access_revert[no_alpha], revert);
 -glUniform1i(glamor_priv-finish_access_swap_rb[no_alpha], swap_rb);
 -
 -glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
 -
 -glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
 -glDisableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
 -return temp_fbo;
 -}
 diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
 index c12bf28..43c1231 100644
 --- a/glamor/glamor_priv.h
 +++ b/glamor/glamor_priv.h
 @@ -615,12 +615,6 @@ void 
 glamor_set_destination_pixmap_fbo(glamor_screen_private *glamor_priv, glamo
   * */
  void glamor_set_destination_pixmap_priv_nc(glamor_screen_private 
 *glamor_priv, PixmapPtr pixmap, glamor_pixmap_private *pixmap_priv);

 -glamor_pixmap_fbo *glamor_es2_pixmap_read_prepare(PixmapPtr source, int x,
 -  int y, int w, int h,
 -  GLenum format, GLenum type,
 -  int no_alpha, int revert,
 -  int swap_rb);
 -
  Bool glamor_set_alu(ScreenPtr screen, unsigned char alu);
  Bool glamor_set_planemask(int depth, unsigned long planemask);
  RegionPtr glamor_bitmap_to_region(PixmapPtr pixmap);
 --
 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
___
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 3/7] glamor: Restore the hook to glamor_composite_rectangles().

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 It was apparently accidentally dropped in keithp's removal of _nf
 functions in 90d326fcc687e6d6d4b308f6272ededcf8145a17.

 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/glamor/glamor.c b/glamor/glamor.c
 index 71ca4f4..295f415 100644
 --- a/glamor/glamor.c
 +++ b/glamor/glamor.c
 @@ -544,7 +544,7 @@ glamor_init(ScreenPtr screen, unsigned int flags)
  ps-AddTraps = glamor_add_traps;

  glamor_priv-saved_procs.composite_rects = ps-CompositeRects;
 -ps-CompositeRects = miCompositeRects;
 +ps-CompositeRects = glamor_composite_rectangles;

  glamor_priv-saved_procs.glyphs = ps-Glyphs;
  ps-Glyphs = glamor_composite_glyphs;
 --
 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
___
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] prime: add rotation support for offloaded outputs (v2)

[Alex Deucher]

On Tue, Jun 30, 2015 at 12:54 AM, Dave Airlie airl...@gmail.com wrote:
 One of the lacking features with output offloading was
 that screen rotation didn't work at all.

 This patch makes 0/90/180/270 rotation work with USB output
 and GPU outputs.

 When it allocates the shared pixmap it allocates it rotated,
 and any updates to the shared pixmap are done using a composite
 path that does the rotation. The slave GPU then doesn't need
 to know about the rotation and just displays the pixmap.

 v2:
 rewrite the sync dirty helper to use the dst pixmap, and
 avoid any strange hobbits and rotations.

 This breaks ABI in two places.

 Signed-off-by: Dave Airlie airl...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  dix/pixmap.c | 180 
 +--
  hw/xfree86/drivers/modesetting/driver.c  |   2 +-
  hw/xfree86/drivers/modesetting/drmmode_display.c |   2 +-
  hw/xfree86/modes/xf86Rotate.c|   2 +
  include/pixmap.h |  14 +-
  include/pixmapstr.h  |   5 +
  include/scrnintstr.h |   5 +-
  randr/rrcrtc.c   |  60 +---
  8 files changed, 197 insertions(+), 73 deletions(-)

 diff --git a/dix/pixmap.c b/dix/pixmap.c
 index 00e298f..05aebc4 100644
 --- a/dix/pixmap.c
 +++ b/dix/pixmap.c
 @@ -40,7 +40,9 @@ from The Open Group.
  #include gcstruct.h
  #include servermd.h
  #include site.h
 -
 +#include X11/extensions/render.h
 +#include picturestr.h
 +#include randrstr.h
  /*
   *  Scratch pixmap management and device independent pixmap allocation
   *  function.
 @@ -164,9 +166,10 @@ PixmapPtr PixmapShareToSlave(PixmapPtr pixmap, ScreenPtr 
 slave)
  }

  Bool
 -PixmapStartDirtyTracking2(PixmapPtr src,
 - PixmapPtr slave_dst,
 - int x, int y, int dst_x, int dst_y)
 +PixmapStartDirtyTracking(PixmapPtr src,
 + PixmapPtr slave_dst,
 + int x, int y, int dst_x, int dst_y,
 + Rotation rotation)
  {
  ScreenPtr screen = src-drawable.pScreen;
  PixmapDirtyUpdatePtr dirty_update;
 @@ -181,11 +184,22 @@ PixmapStartDirtyTracking2(PixmapPtr src,
  dirty_update-y = y;
  dirty_update-dst_x = dst_x;
  dirty_update-dst_y = dst_y;
 -
 +dirty_update-rotation = rotation;
  dirty_update-damage = DamageCreate(NULL, NULL,
  DamageReportNone,
  TRUE, src-drawable.pScreen,
  src-drawable.pScreen);
 +
 +if (rotation != RR_Rotate_0) {
 +RRTransformCompute(x, y,
 +   slave_dst-drawable.width,
 +   slave_dst-drawable.height,
 +   rotation,
 +   NULL,
 +   dirty_update-transform,
 +   dirty_update-f_transform,
 +   dirty_update-f_inverse);
 +}
  if (!dirty_update-damage) {
  free(dirty_update);
  return FALSE;
 @@ -197,14 +211,6 @@ PixmapStartDirtyTracking2(PixmapPtr src,
  }

  Bool
 -PixmapStartDirtyTracking(PixmapPtr src,
 -PixmapPtr slave_dst,
 -int x, int y)
 -{
 -   return PixmapStartDirtyTracking2(src, slave_dst, x, y, 0, 0);
 -}
 -
 -Bool
  PixmapStopDirtyTracking(PixmapPtr src, PixmapPtr slave_dst)
  {
  ScreenPtr screen = src-drawable.pScreen;
 @@ -220,42 +226,16 @@ PixmapStopDirtyTracking(PixmapPtr src, PixmapPtr 
 slave_dst)
  return TRUE;
  }

 -/*
 - * this function can possibly be improved and optimised, by clipping
 - * instead of iterating
 - */
 -Bool PixmapSyncDirtyHelper(PixmapDirtyUpdatePtr dirty, RegionPtr 
 dirty_region)
 +static void
 +PixmapDirtyCopyArea(PixmapPtr dst,
 +PixmapDirtyUpdatePtr dirty,
 +RegionPtr dirty_region)
  {
  ScreenPtr pScreen = dirty-src-drawable.pScreen;
  int n;
  BoxPtr b;
 -RegionPtr region = DamageRegion(dirty-damage);
  GCPtr pGC;
 -PixmapPtr dst;
 -SourceValidateProcPtr SourceValidate;
 -
 -/*
 - * SourceValidate is used by the software cursor code
 - * to pull the cursor off of the screen when reading
 - * bits from the frame buffer. Bypassing this function
 - * leaves the software cursor in place
 - */
 -SourceValidate = pScreen-SourceValidate;
 -pScreen-SourceValidate = NULL;
 -
 -RegionTranslate(dirty_region, dirty-x, dirty-y);
 -RegionIntersect(dirty_region, dirty_region, region);
 -
 -if (RegionNil(dirty_region)) {
 -RegionUninit(dirty_region);
 -return FALSE;
 -}

 -dst = dirty-slave_dst-master_pixmap;
 -if (!dst)
 -dst = dirty-slave_dst;
 -
 -RegionTranslate(dirty_region, -dirty-x, -dirty-y

Re: [PATCH 6/7] glamor: Mark a bunch of single-file data static.

[Alex Deucher]

On Tue, Jun 30, 2015 at 6:58 PM, Eric Anholt e...@anholt.net wrote:
 This gives the compiler a chance to optimize when the data is never
 changed -- for example, with pict_format_combine_tab, the compiler
 ends up inlining the 24 bytes of data into just 10 more bytes of code.

 Signed-off-by: Eric Anholt e...@anholt.net

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  glamor/glamor_core.c| 2 +-
  glamor/glamor_program.c | 8 
  glamor/glamor_render.c  | 2 +-
  3 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
 index 965024e..7c31b69 100644
 --- a/glamor/glamor_core.c
 +++ b/glamor/glamor_core.c
 @@ -294,7 +294,7 @@ glamor_fini_finish_access_shaders(ScreenPtr screen)
  glDeleteProgram(glamor_priv-finish_access_prog[1]);
  }

 -GCOps glamor_gc_ops = {
 +static GCOps glamor_gc_ops = {
  .FillSpans = glamor_fill_spans,
  .SetSpans = glamor_set_spans,
  .PutImage = glamor_put_image,
 diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
 index 1dc5f19..5619216 100644
 --- a/glamor/glamor_program.c
 +++ b/glamor/glamor_program.c
 @@ -499,7 +499,7 @@ use_source_solid(CARD8 op, PicturePtr src, PicturePtr 
 dst, glamor_program *prog)
  return TRUE;
  }

 -const glamor_facet glamor_source_solid = {
 +static const glamor_facet glamor_source_solid = {
  .name = render_solid,
  .fs_exec =vec4 source = fg;\n,
  .locations = glamor_program_location_fg,
 @@ -517,7 +517,7 @@ use_source_picture(CARD8 op, PicturePtr src, PicturePtr 
 dst, glamor_program *pro
prog-fill_size_inv_uniform);
  }

 -const glamor_facet glamor_source_picture = {
 +static const glamor_facet glamor_source_picture = {
  .name = render_picture,
  .vs_exec = fill_pos = (fill_offset + primitive.xy + pos) * 
 fill_size_inv;\n,
  .fs_exec = vec4 source = texture2D(sampler, fill_pos);\n,
 @@ -533,14 +533,14 @@ use_source_1x1_picture(CARD8 op, PicturePtr src, 
 PicturePtr dst, glamor_program
  return glamor_set_texture_pixmap((PixmapPtr) src-pDrawable);
  }

 -const glamor_facet glamor_source_1x1_picture = {
 +static const glamor_facet glamor_source_1x1_picture = {
  .name = render_picture,
  .fs_exec = vec4 source = texture2D(sampler, vec2(0.5));\n,
  .locations = glamor_program_location_fillsamp,
  .use_render = use_source_1x1_picture,
  };

 -const glamor_facet *glamor_facet_source[glamor_program_source_count] = {
 +static const glamor_facet *glamor_facet_source[glamor_program_source_count] 
 = {
  [glamor_program_source_solid] = glamor_source_solid,
  [glamor_program_source_picture] = glamor_source_picture,
  [glamor_program_source_1x1_picture] = glamor_source_1x1_picture,
 diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
 index 0c776af..22480cd 100644
 --- a/glamor/glamor_render.c
 +++ b/glamor/glamor_render.c
 @@ -723,7 +723,7 @@ glamor_flush_composite_rects(ScreenPtr screen)
  }
  }

 -int pict_format_combine_tab[][3] = {
 +static const int pict_format_combine_tab[][3] = {
  {PICT_TYPE_ARGB, PICT_TYPE_A, PICT_TYPE_ARGB},
  {PICT_TYPE_ABGR, PICT_TYPE_A, PICT_TYPE_ABGR},
  };
 --
 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
___
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] [RFC] cursor: drop ARGB_CURSOR

[Alex Deucher]

On Tue, Jun 9, 2015 at 1:31 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 I doubt anyone builds with this turned off or has done for a long
 time.

 It helps my eyes bleed slightly less when reading the code, I've left
 the define in place as some drivers use it.

 Signed-off-by: Dave Airlie airl...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  dix/cursor.c   |  8 
  hw/kdrive/ephyr/ephyrcursor.c  |  4 
  hw/xfree86/modes/xf86Cursors.c |  8 
  hw/xfree86/ramdac/xf86Cursor.c |  2 --
  hw/xfree86/ramdac/xf86Cursor.h |  4 
  hw/xfree86/ramdac/xf86HWCurs.c |  6 --
  hw/xquartz/xpr/xprCursor.c |  2 --
  include/cursorstr.h|  2 --
  mi/midispcur.c | 20 +---
  xfixes/cursor.c|  2 --
  10 files changed, 1 insertion(+), 57 deletions(-)

 diff --git a/dix/cursor.c b/dix/cursor.c
 index 1525857..e459456 100644
 --- a/dix/cursor.c
 +++ b/dix/cursor.c
 @@ -80,9 +80,7 @@ FreeCursorBits(CursorBitsPtr bits)
  return;
  free(bits-source);
  free(bits-mask);
 -#ifdef ARGB_CURSOR
  free(bits-argb);
 -#endif
  dixFiniPrivates(bits, PRIVATE_CURSOR_BITS);
  if (bits-refcnt == 0) {
  GlyphSharePtr *prev, this;
 @@ -165,7 +163,6 @@ CheckForEmptyMask(CursorBitsPtr bits)
  while (n--)
  if (*(msk++) != 0)
  return;
 -#ifdef ARGB_CURSOR
  if (bits-argb) {
  CARD32 *argb = bits-argb;

 @@ -174,7 +171,6 @@ CheckForEmptyMask(CursorBitsPtr bits)
  if (*argb++  0xff00)
  return;
  }
 -#endif
  bits-emptyMask = TRUE;
  }

 @@ -259,9 +255,7 @@ AllocARGBCursor(unsigned char *psrcbits, unsigned char 
 *pmaskbits,
  dixInitPrivates(bits, bits + 1, PRIVATE_CURSOR_BITS)
  bits-source = psrcbits;
  bits-mask = pmaskbits;
 -#ifdef ARGB_CURSOR
  bits-argb = argb;
 -#endif
  bits-width = cm-width;
  bits-height = cm-height;
  bits-xhot = cm-xhot;
 @@ -400,9 +394,7 @@ AllocGlyphCursor(Font source, unsigned sourceChar, Font 
 mask, unsigned maskChar,
  dixInitPrivates(bits, bits + 1, PRIVATE_CURSOR_BITS);
  bits-source = srcbits;
  bits-mask = mskbits;
 -#ifdef ARGB_CURSOR
  bits-argb = 0;
 -#endif
  bits-width = cm.width;
  bits-height = cm.height;
  bits-xhot = cm.xhot;
 diff --git a/hw/kdrive/ephyr/ephyrcursor.c b/hw/kdrive/ephyr/ephyrcursor.c
 index 852be33..808b3c7 100644
 --- a/hw/kdrive/ephyr/ephyrcursor.c
 +++ b/hw/kdrive/ephyr/ephyrcursor.c
 @@ -100,7 +100,6 @@ ephyrRealizeCoreCursor(EphyrScrPriv *scr, CursorPtr 
 cursor)
  xcb_free_pixmap(conn, mask);
  }

 -#ifdef ARGB_CURSOR
  static xcb_render_pictformat_t
  get_argb_format(void)
  {
 @@ -170,7 +169,6 @@ can_argb_cursor(void)

  return v-major_version == 0  v-minor_version = 5;
  }
 -#endif

  static Bool
  ephyrRealizeCursor(DeviceIntPtr dev, ScreenPtr screen, CursorPtr cursor)
 @@ -179,11 +177,9 @@ ephyrRealizeCursor(DeviceIntPtr dev, ScreenPtr screen, 
 CursorPtr cursor)
  KdScreenInfo *kscr = pScreenPriv-screen;
  EphyrScrPriv *scr = kscr-driver;

 -#ifdef ARGB_CURSOR
  if (cursor-bits-argb  can_argb_cursor())
  ephyrRealizeARGBCursor(scr, cursor);
  else
 -#endif
  {
  ephyrRealizeCoreCursor(scr, cursor);
  }
 diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
 index 379a27a..321cde7 100644
 --- a/hw/xfree86/modes/xf86Cursors.c
 +++ b/hw/xfree86/modes/xf86Cursors.c
 @@ -258,9 +258,7 @@ xf86_crtc_convert_cursor_to_argb(xf86CrtcPtr crtc, 
 unsigned char *src)
  CARD32 bits;
  const Rotation rotation = xf86_crtc_cursor_rotation(crtc);

 -#ifdef ARGB_CURSOR
  crtc-cursor_argb = FALSE;
 -#endif

  for (y = 0; y  cursor_info-MaxHeight; y++)
  for (x = 0; x  cursor_info-MaxWidth; x++) {
 @@ -458,9 +456,7 @@ xf86_crtc_load_cursor_image(xf86CrtcPtr crtc, CARD8 *src)
  CARD8 *cursor_image;
  const Rotation rotation = xf86_crtc_cursor_rotation(crtc);

 -#ifdef ARGB_CURSOR
  crtc-cursor_argb = FALSE;
 -#endif

  if (rotation == RR_Rotate_0)
  cursor_image = src;
 @@ -632,12 +628,10 @@ xf86_cursors_init(ScreenPtr screen, int max_width, int 
 max_height, int flags)
  cursor_info-HideCursor = xf86_hide_cursors;
  cursor_info-ShowCursor = xf86_show_cursors;
  cursor_info-UseHWCursor = xf86_use_hw_cursor;
 -#ifdef ARGB_CURSOR
  if (flags  HARDWARE_CURSOR_ARGB) {
  cursor_info-UseHWCursorARGB = xf86_use_hw_cursor_argb;
  cursor_info-LoadCursorARGBCheck = xf86_load_cursor_argb;
  }
 -#endif

  xf86_config-cursor = NULL;
  xf86_hide_cursors(scrn);
 @@ -691,11 +685,9 @@ xf86_reload_cursors(ScreenPtr screen)
  void *src =
  dixLookupScreenPrivate(cursor-devPrivates, CursorScreenKey,
 screen);
 -#ifdef ARGB_CURSOR

Re: [PATCH 1/4] present: static cleanup

[Alex Deucher]

On Tue, Jun 2, 2015 at 11:37 AM, Adam Jackson a...@redhat.com wrote:
 Signed-off-by: Adam Jackson a...@redhat.com

For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  present/present_event.c   | 2 +-
  present/present_priv.h| 2 --
  present/present_request.c | 4 ++--
  3 files changed, 3 insertions(+), 5 deletions(-)

 diff --git a/present/present_event.c b/present/present_event.c
 index d3a59ea..c586c9a 100644
 --- a/present/present_event.c
 +++ b/present/present_event.c
 @@ -26,7 +26,7 @@

  #include present_priv.h

 -RESTYPE present_event_type;
 +static RESTYPE present_event_type;

  static int
  present_free_event(void *data, XID id)
 diff --git a/present/present_priv.h b/present/present_priv.h
 index f5c1652..996292e 100644
 --- a/present/present_priv.h
 +++ b/present/present_priv.h
 @@ -147,8 +147,6 @@ present_window_priv(WindowPtr window)
  present_window_priv_ptr
  present_get_window_priv(WindowPtr window, Bool create);

 -extern RESTYPE present_event_type;
 -
  /*
   * present.c
   */
 diff --git a/present/present_request.c b/present/present_request.c
 index 7c53e72..35320b6 100644
 --- a/present/present_request.c
 +++ b/present/present_request.c
 @@ -234,7 +234,7 @@ proc_present_query_capabilities (ClientPtr client)
  return Success;
  }

 -int (*proc_present_vector[PresentNumberRequests]) (ClientPtr) = {
 +static int (*proc_present_vector[PresentNumberRequests]) (ClientPtr) = {
  proc_present_query_version,/* 0 */
  proc_present_pixmap,   /* 1 */
  proc_present_notify_msc,   /* 2 */
 @@ -319,7 +319,7 @@ sproc_present_query_capabilities (ClientPtr client)
  return (*proc_present_vector[stuff-presentReqType]) (client);
  }

 -int (*sproc_present_vector[PresentNumberRequests]) (ClientPtr) = {
 +static int (*sproc_present_vector[PresentNumberRequests]) (ClientPtr) = {
  sproc_present_query_version,   /* 0 */
  sproc_present_pixmap,  /* 1 */
  sproc_present_notify_msc,  /* 2 */
 --
 2.4.1

 ___
 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
___
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] xfree86: attempt to autoconfig gpu slave devices (v3)

[Alex Deucher]

On Tue, Apr 21, 2015 at 9:08 PM, Dave Airlie airl...@gmail.com wrote:
 On 1 April 2015 at 11:33, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 This allows us to skip the screen section, the first
 Device section will get assigned to the screen,
 any remaining ones will get assigned to the GPUDevice
 sections for the screen.

 v2: fix the skipping unsuitable screen logic (Aaron)
 v3: fix segfault if not conf file (me, 5s after sending v2)

 Anyone care to r-b this?

I'm not too familiar with the code in question, but the logic seems correct.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 Dave.
 ___
 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
___
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] Add amdgpu as a default driver for AMD GPUs

[Alex Deucher]

On Mon, Apr 20, 2015 at 11:08 PM, Michel Dänzer mic...@daenzer.net wrote:
 From: Michel Dänzer michel.daen...@amd.com

 Its Probe hook bails cleanly when it can't initialize, in which case the
 ati driver will be tried next.

 Signed-off-by: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  hw/xfree86/common/xf86pciBus.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
 index e86ecb9..f84bc99 100644
 --- a/hw/xfree86/common/xf86pciBus.c
 +++ b/hw/xfree86/common/xf86pciBus.c
 @@ -1105,7 +1105,8 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
  driverList[0] = ast;
  break;
  case 0x1002:
 -driverList[0] = ati;
 +driverList[0] = amdgpu;
 +driverList[1] = ati;
  break;
  case 0x102c:
  driverList[0] = chips;
 --
 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
___
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 0/5] Trivial randr cleanups

[Alex Deucher]

On Thu, Mar 19, 2015 at 9:01 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Hello all,

 Noticed that as optimus support landed in randr, the latter became extra
 chatty, flooding the logs on said systems. Afaict the messages are not
 really meaningful outside the development stage, so I've decided to
 remove them. Alternatively we can change them to LogMessageVerb(X_INFO,
 3...) or similar.

 While there, my editor pointed out a few long lines so I've decided to
 address those as well :-)

 Any and all input will be appreciated.

For the series:

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 Cheers
 Emil


 Emil Velikov (5):
   randr: remove chatty error messages
   randr: use randr: prefix in ErrorF()
   randr: use local variables where possible
   randr: wrap long line
   randr: coding style fixes

  randr/rrcrtc.c   | 42 ++
  randr/rrscreen.c |  7 +++
  2 files changed, 25 insertions(+), 24 deletions(-)

 ___
 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
___
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 2/2] modesetting: Include dix-config.h from dumb_bo.c

[Alex Deucher]

On Mon, Mar 16, 2015 at 9:21 PM, Michel Dänzer mic...@daenzer.net wrote:
 From: Michel Dänzer michel.daen...@amd.com

 Fixes mmap failures with 32-bit builds.

 Signed-off-by: Michel Dänzer mic...@daenzer.net

For the series:

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  hw/xfree86/drivers/modesetting/dumb_bo.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/hw/xfree86/drivers/modesetting/dumb_bo.c 
 b/hw/xfree86/drivers/modesetting/dumb_bo.c
 index 58d420e..cf13f0a 100644
 --- a/hw/xfree86/drivers/modesetting/dumb_bo.c
 +++ b/hw/xfree86/drivers/modesetting/dumb_bo.c
 @@ -25,6 +25,10 @@
   *
   */

 +#ifdef HAVE_DIX_CONFIG_H
 +#include dix-config.h
 +#endif
 +
  #include dumb_bo.h

  #include errno.h
 --
 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
___
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 2/2] exa: Verify non-null pSrc in mgaDownloadFromScreen()

[Alex Deucher]

On Tue, Mar 3, 2015 at 2:21 PM, Tormod Volden lists.tor...@gmail.com wrote:
 On Tue, Mar 3, 2015 at 3:18 AM, Michel Dänzer wrote:
 On 03.03.2015 05:01, Tormod Volden wrote:
  mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h,
char *dst, int dst_pitch)
  {
 +if (!pSrc)
 + return FALSE;
 +
  PMGA(pSrc);

  char *src = pMga-ExaDriver-memoryBase + exaGetPixmapOffset(pSrc);


 This isn't necessary. Only pScrPict-pDrawable and pMaskPict-pDrawable
 can be NULL in mgaCheckComposite. EXA never calls driver hooks with NULL
 PixmapPtrs.

 Hi Michel,

 Thanks for the response. OK, good to know. I was wondering about that,
 so I left it in a separate patch.



 About patch 1, since mgaDownloadFromScreen doesn't do anything fancier
 than memcpy, you can just remove it altogether and leave
 pExa-DownloadFromScreen NULL. EXA then does basically the same thing
 mgaDownloadFromScreen does.

 Yes, Connor also suggested that. However, I would like in any case to
 correct the old code first. Does the general EXA also do the
 equivalent to QUIESCE_DMA()?


It calls waitMarker before doing sw ops if that is what you are asking.

Alex
___
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 2/2] exa: Verify non-null pSrc in mgaDownloadFromScreen()

[Alex Deucher]

On Tue, Mar 3, 2015 at 3:50 PM, Tormod Volden lists.tor...@gmail.com wrote:
 On Tue, Mar 3, 2015 at 9:21 PM, Alex Deucher wrote:
 On Tue, Mar 3, 2015 at 2:21 PM, Tormod Volden wrote:
 On Tue, Mar 3, 2015 at 3:18 AM, Michel Dänzer wrote:
 About patch 1, since mgaDownloadFromScreen doesn't do anything fancier
 than memcpy, you can just remove it altogether and leave
 pExa-DownloadFromScreen NULL. EXA then does basically the same thing
 mgaDownloadFromScreen does.

 Yes, Connor also suggested that. However, I would like in any case to
 correct the old code first. Does the general EXA also do the
 equivalent to QUIESCE_DMA()?


 It calls waitMarker before doing sw ops if that is what you are asking.

 Thanks. I took a look, they do different things, and QUIESCE_DMA()
 goes into mga_dri.c and places sprinkled with FIXME what about EXA?.
 Anyway, I think I leave further changes to someone who can test :)

If anything, it's likely to be more correct if you let EXA do it if
there are a bunch of fixme's in the QUIESCE_DMA code.

Alex
___
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

GSoC Ideas!

[Alex Deucher]

Hi everyone!

It's that time of year again.  Time to start coming up with GSoC
ideas.  Martin and I are organizing this year's Xorg entry.  We need
to fill in our ideas page with some good possible projects for
students.  The project ideas should be something that a student could
accomplish over the summer so keep the scope focused.  Please use the
templates on
http://www.x.org/wiki/SummerOfCodeIdeas/ and update the wiki or post
the ideas on the mailing list.  Martin and I will update the page as
the ideas come in.

Thanks!

Alex
___
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: check max native ALU instructions

[Alex Deucher]

On Wed, Jan 28, 2015 at 4:55 PM, Ian Romanick i...@freedesktop.org wrote:
 On 01/28/2015 01:00 PM, Olivier Fourdan wrote:
 On 28/01/15 21:17, Ian Romanick wrote:

 Do we know which GPUs cannot meet this limit and also do not have true
 integer support?  I wonder if we should go ahead and do the
 GL_MESA_shading_language_130 or GL_MESA_gpu_shader_int32 extensions that
 we had previously discussed, and remove support for desktop OpenGL
 drivers that cannot do those.

 The issue has been reported on i945GM and G31/G33 at least, but I dunno
 if those have true integer support.

 They do not.  I only know of a small set of non-GL 3.0 GPUs that can:
 Intel i965 through Iron Lake and vc4.  I'm not sure where R400 and R500
 (or older NVIDIA chips supported by nouveau) lie in the spectrum.

No integer support on pre-R600 hardware.

Alex
___
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: [xf86-video-ati] dri2: Enable BufferAge support

[Alex Deucher]

On Mon, Jan 19, 2015 at 6:00 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 For BufferAge support, we just have to guarrantee that we were not using
 the DRI2Buffer-flags field for anything else (i.e. it is always 0) and
 then to make sure that we exchange the flags field after buffer
 exchanges. radeon does not support TripleBuffering so we do not have to
 worry about perserving the flags when injecting the third buffer.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Dave Airlie airl...@redhat.com
 Cc: Jerome Glisse jgli...@redhat.com
 Cc: Alex Deucher alexander.deuc...@amd.com
 Cc: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  src/radeon_dri2.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
 index 0fbe96c..091cd06 100644
 --- a/src/radeon_dri2.c
 +++ b/src/radeon_dri2.c
 @@ -764,6 +764,11 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
 DRI2BufferPtr front, DRI2BufferPt
  front-name = back-name;
  back-name = tmp;

 +/* Swap flags so BufferAge works */
 +tmp = front-flags;
 +front-flags = back-flags;
 +back-flags = tmp;
 +
  /* Swap pixmap bos */
  front_bo = radeon_get_pixmap_bo(front_priv-pixmap);
  back_bo = radeon_get_pixmap_bo(back_priv-pixmap);
 @@ -1647,6 +1652,11 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
  dri2_info.CopyRegion2 = radeon_dri2_copy_region2;
  #endif

 +#if DRI2INFOREC_VERSION = 10
 +dri2_info.version = 10;
 +dri2_info.bufferAge = 1;
 +#endif
 +
  info-dri2.enabled = DRI2ScreenInit(pScreen, dri2_info);
  return info-dri2.enabled;
  }
 --
 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
___
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] randr/prime: Don't stop on the first pipe when disabling ReplaceScanoutPixmap

[Alex Deucher]

On Fri, Jan 16, 2015 at 4:40 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Oct 07, 2014 at 07:22:27AM +0100, Chris Wilson wrote:
 On Mon, Oct 06, 2014 at 10:02:22AM +0100, Chris Wilson wrote:
  As we define sizeFits based on whether a CRTC is active, and skip trying
  to redirect the scanout on a disable pipe, we then attempt to undo it
  later and fail because crtc-scanout_pixmap != DRI2_Pixmap and
  !sizeFits. Paper over this failure by skipping unredirected CRTC when
  disabling.
 
  v2: Unwind upon failure

 Reported-by: Christoph Haag haa...@frickel.club
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84653
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: Dave Airlie airl...@redhat.com
 Tested-by: Christoph Haag haa...@frickel.club

 Ping?

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 -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: http://lists.x.org/mailman/listinfo/xorg-devel
___
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: [PATCHv2] dri2: Set vdpau driver name if ddx does not provide any driver name

[Alex Deucher]

On Sat, Jan 3, 2015 at 3:12 PM, Adel Gadllah adel.gadl...@gmail.com wrote:
 Currently when the ddx does not set any driver name we set DRI2 driver but
 not the VDPAU driver name. The result is that VDPAU drivers will not get found
 by libvdpau when the modesetting driver is being used.

 Just assume that the VDPAU driver matches the DRI2 driver name, this is true
 for nouveau, r300, r600 and radeonsi i.e all VDPAU drivers currently supported
 by mesa.

 Signed-off-by: Adel Gadllah adel.gadl...@gmail.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  hw/xfree86/dri2/dri2.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
 index c8fcd62..68518c4 100644
 --- a/hw/xfree86/dri2/dri2.c
 +++ b/hw/xfree86/dri2/dri2.c
 @@ -1573,15 +1573,15 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)

  if (info-version == 3 || info-numDrivers == 0) {
  /* Driver too old: use the old-style driverName field */
 -ds-numDrivers = 1;
 -ds-driverNames = malloc(sizeof(*ds-driverNames));
 +ds-numDrivers = info-driverName ? 1 : 2;
 +ds-driverNames = malloc(ds-numDrivers * sizeof(*ds-driverNames));
  if (!ds-driverNames)
  goto err_out;

  if (info-driverName) {
  ds-driverNames[0] = info-driverName;
  } else {
 -ds-driverNames[0] = dri2_probe_driver_name(pScreen, info);
 +ds-driverNames[0] = ds-driverNames[1] = 
 dri2_probe_driver_name(pScreen, info);
  if (!ds-driverNames[0])
  return FALSE;
  }
 --
 2.1.0

 ___
 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
___
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