Re: [PATCH xserver 2/2] Xi: add forgotten byte-swaps for Valuator fields

[Peter Hutterer]

On Thu, Jun 07, 2018 at 03:31:42AM +0200, Roman Kapl wrote:
> This has caused nonsensical values in xinput output.
> 
> Signed-off-by: Roman Kapl 
> ---
>  Xi/xiquerydevice.c | 3 +++
>  1 file changed, 3 insertions(+)

pushed, thanks

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: E: failed to find patch for rev 
cefbc6a9356e5c6cf935b61557efa897762defae.
remote: I: patch #228063 updated using rev 
40586cc4f8faa271d62fd84fe98c41debb878984.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/xserver
   9b8999411..40586cc4f  master -> master

Cheers,
   Peter

> 
> diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c
> index 5f5a5f82f..fbb51fe81 100644
> --- a/Xi/xiquerydevice.c
> +++ b/Xi/xiquerydevice.c
> @@ -383,6 +383,9 @@ SwapValuatorInfo(DeviceIntPtr dev, xXIValuatorInfo * info)
>  swapl(>min.frac);
>  swapl(>max.integral);
>  swapl(>max.frac);
> +swapl(>value.integral);
> +swapl(>value.frac);
> +swapl(>resolution);
>  swaps(>number);
>  swaps(>sourceid);
>  }
> -- 
> 2.17.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] Improve the ButtonInfo description.

[Peter Hutterer]

On Thu, Jun 07, 2018 at 03:32:08AM +0200, Roman Kapl wrote:
> It failed to mention it is followed by a bit-mask and then the atoms.
> 
> Signed-off-by: Roman Kapl 
> ---
>  include/X11/extensions/XI2proto.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Patch content is correct, thanks. But what repository did you make this
patch to?  This should go into the inputproto repo but it has the XI2proto.h
in the root tree.

Cheers,
   Peter

> 
> diff --git a/include/X11/extensions/XI2proto.h 
> b/include/X11/extensions/XI2proto.h
> index 4cdaa0d..28a9062 100644
> --- a/include/X11/extensions/XI2proto.h
> +++ b/include/X11/extensions/XI2proto.h
> @@ -149,8 +149,9 @@ typedef struct {
>  
>  /**
>   * Denotes button capability on a device.
> - * Struct is followed by num_buttons * Atom that names the buttons in the
> - * device-native setup (i.e. ignoring button mappings).
> + * Struct is followed by a button bit-mask (padded to four byte chunks) and
> + * then num_buttons * Atom that names the buttons in the device-native setup
> + * (i.e.  ignoring button mappings).
>   */
>  typedef struct {
>  uint16_ttype;   /**< Always ButtonClass */
> -- 
> 2.17.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

[PATCH xserver] modesetting: Also disable CRTC in drmmode_output_disable()

[Lyude Paul]

So, this did actually work on older kernels at one point in time,
however it seems that this working was a result of some of the Linux
kernel's atomic modesetting helpers not preserving the CRTC's enabled
state in the right spots. This was fixed in:

846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2")

As a result, atomic commits which simply disassociate a DRM connector
with it's CRTC while leaving the CRTC in an enabled state aren't enough
to disable the CRTC, and result in the atomic commit failing. This
currently can cause issues with MST hotplugging where X will end up
failing to disable the MST outputs after they've left the system. A
simple reproducer:

- Start up Xorg
- Connect an MST hub with displays connected to it
- Remove the hub
- Now there should be CRTCs stuck on the orphaned MST connectors, and X
  won't be able to reclaim them.

Signed-off-by: Lyude Paul 
Cc: Louis-Francis Ratté-Boulianne 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 859a21a9d..375be4234 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -695,18 +695,21 @@ drmmode_output_disable(xf86OutputPtr output)
 {
 modesettingPtr ms = modesettingPTR(output->scrn);
 drmmode_output_private_ptr drmmode_output = output->driver_private;
+xf86CrtcPtr crtc = drmmode_output->current_crtc;
 drmModeAtomicReq *req = drmModeAtomicAlloc();
 uint32_t flags = DRM_MODE_ATOMIC_ALLOW_MODESET;
-int ret;
+int ret = 0;
 
 assert(ms->atomic_modeset);
 
 if (!req)
 return 1;
 
-/* XXX Can we disable all outputs without disabling CRTC right away? */
-ret = connector_add_prop(req, drmmode_output,
- DRMMODE_CONNECTOR_CRTC_ID, 0);
+ret |= connector_add_prop(req, drmmode_output,
+  DRMMODE_CONNECTOR_CRTC_ID, 0);
+if (crtc)
+ret |= crtc_add_dpms_props(req, crtc, DPMSModeOff, NULL);
+
 if (ret == 0)
 ret = drmModeAtomicCommit(ms->fd, req, flags, NULL);
 
-- 
2.17.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

[ANNOUNCE] xkbcomp 1.4.2

[Peter Hutterer]

Only one patch, fixing keymap compilation errors when the keycodes maximum
is set to a value above the permitted X11 maximum of 255. While we already
ignored keys with codes above 255, we still failed on the maximum=374;
line that xkeyboard-config 2.24 produces now.

Peter Hutterer (2):
  Ignore xkb_keycodes.maximum of > 255
  xkbcomp 1.4.2

git tag: xkbcomp-1.4.2

https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.bz2
MD5:  12610df19df2af3797f2c130ee2bce97  xkbcomp-1.4.2.tar.bz2
SHA1: 9a39cf7a562c152465e04fc7cf1002c59f883870  xkbcomp-1.4.2.tar.bz2
SHA256: 6dd8bcb9be7e85bd7294abe261b8c7b0539d2fc93e41b80fb8bd013767ce8424  
xkbcomp-1.4.2.tar.bz2
SHA512: 
b00d1eb08c19be86044418c8ea3bfc3c3973406c481878270138a70ed9dab348acb8e4d0af8678879598ffbd7df1c640a63d0abad3d7481758be99af8dd7734e
  xkbcomp-1.4.2.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.gz
MD5:  84b6bafb660181a8c2572981a7fff54d  xkbcomp-1.4.2.tar.gz
SHA1: 02f32b18ba6c61c3b1b991114ed7352e1043e9f6  xkbcomp-1.4.2.tar.gz
SHA256: 962a3d550ad0058c141c2bf16eed6498d0f86d987141f875cb0a5df5696487d7  
xkbcomp-1.4.2.tar.gz
SHA512: 
1d7b07c991b89bcb4748c257e6b1c7f673a0a710d8f98447e21a2783b46d6a4a4e7f860bfbe1c884bb8d3d7973850702db88dd885859da9d730b193243bb2953
  xkbcomp-1.4.2.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.gz.sig



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

[ANNOUNCE] xkbcomp 1.4.2

[Peter Hutterer]

Only one patch, fixing keymap compilation errors when the keycodes maximum
is set to a value above the permitted X11 maximum of 255. While we already
ignored keys with codes above 255, we still failed on the maximum=374;
line that xkeyboard-config 2.24 produces now.

Peter Hutterer (2):
  Ignore xkb_keycodes.maximum of > 255
  xkbcomp 1.4.2

git tag: xkbcomp-1.4.2

https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.bz2
MD5:  12610df19df2af3797f2c130ee2bce97  xkbcomp-1.4.2.tar.bz2
SHA1: 9a39cf7a562c152465e04fc7cf1002c59f883870  xkbcomp-1.4.2.tar.bz2
SHA256: 6dd8bcb9be7e85bd7294abe261b8c7b0539d2fc93e41b80fb8bd013767ce8424  
xkbcomp-1.4.2.tar.bz2
SHA512: 
b00d1eb08c19be86044418c8ea3bfc3c3973406c481878270138a70ed9dab348acb8e4d0af8678879598ffbd7df1c640a63d0abad3d7481758be99af8dd7734e
  xkbcomp-1.4.2.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.gz
MD5:  84b6bafb660181a8c2572981a7fff54d  xkbcomp-1.4.2.tar.gz
SHA1: 02f32b18ba6c61c3b1b991114ed7352e1043e9f6  xkbcomp-1.4.2.tar.gz
SHA256: 962a3d550ad0058c141c2bf16eed6498d0f86d987141f875cb0a5df5696487d7  
xkbcomp-1.4.2.tar.gz
SHA512: 
1d7b07c991b89bcb4748c257e6b1c7f673a0a710d8f98447e21a2783b46d6a4a4e7f860bfbe1c884bb8d3d7973850702db88dd885859da9d730b193243bb2953
  xkbcomp-1.4.2.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.2.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

[PATCH xf86-video-r128 2/2] Move R128InitCrtc2Registers to r128_crtc.c

[Kevin Brace]

It does not make sense for this function to be inside r128_driver.c
since it is only called from a function inside r128_crtc.c.

Signed-off-by: Kevin Brace 
---
 src/r128.h|  1 -
 src/r128_crtc.c   | 82 +++
 src/r128_driver.c | 82 ---
 3 files changed, 82 insertions(+), 83 deletions(-)

diff --git a/src/r128.h b/src/r128.h
index f5b01ce..5e7aeb9 100644
--- a/src/r128.h
+++ b/src/r128.h
@@ -525,7 +525,6 @@ extern BoolR128InitCrtcBase(xf86CrtcPtr crtc, 
R128SavePtr save, int x, i
 extern voidR128InitPLLRegisters(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, double dot_clock);
 extern BoolR128InitDDARegisters(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, DisplayModePtr mode);
 extern BoolR128InitCrtc2Base(xf86CrtcPtr crtc, R128SavePtr save, int 
x, int y);
-extern BoolR128InitCrtc2Registers(xf86CrtcPtr crtc, R128SavePtr save, 
DisplayModePtr mode);
 extern voidR128InitPLL2Registers(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, double dot_clock);
 extern BoolR128InitDDA2Registers(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, DisplayModePtr mode);
 extern voidR128RestoreCommonRegisters(ScrnInfoPtr pScrn, R128SavePtr 
restore);
diff --git a/src/r128_crtc.c b/src/r128_crtc.c
index 6afc267..28e9a44 100644
--- a/src/r128_crtc.c
+++ b/src/r128_crtc.c
@@ -157,6 +157,88 @@ Bool R128InitCrtcRegisters(xf86CrtcPtr crtc, R128SavePtr 
save, DisplayModePtr mo
 return TRUE;
 }
 
+/* Define CRTC2 registers for requested video mode. */
+Bool R128InitCrtc2Registers(xf86CrtcPtr crtc, R128SavePtr save, DisplayModePtr 
mode)
+{
+ScrnInfoPtr pScrn = crtc->scrn;
+R128InfoPtr info  = R128PTR(pScrn);
+
+intformat;
+inthsync_start;
+inthsync_wid;
+inthsync_fudge;
+intvsync_wid;
+inthsync_fudge_default[] = { 0x00, 0x12, 0x09, 0x09, 0x06, 0x05 };
+
+switch (info->CurrentLayout.pixel_code) {
+case 4:  format = 1; break;
+case 8:  format = 2; break;
+case 15: format = 3; break;  /*  555 */
+case 16: format = 4; break;  /*  565 */
+case 24: format = 5; break;  /*  RGB */
+case 32: format = 6; break;  /* xRGB */
+default:
+xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+   "Unsupported pixel depth (%d)\n", info->CurrentLayout.bitsPerPixel);
+return FALSE;
+}
+
+hsync_fudge = hsync_fudge_default[format-1];
+
+save->crtc2_gen_cntl = (R128_CRTC2_EN
+  | (format << 8)
+  | ((mode->Flags & V_DBLSCAN)
+ ? R128_CRTC2_DBL_SCAN_EN
+ : 0));
+/*
+save->crtc2_gen_cntl &= ~R128_CRTC_EXT_DISP_EN;
+save->crtc2_gen_cntl |= (1 << 21);
+*/
+save->crtc2_h_total_disp = mode->CrtcHTotal / 8) - 1) & 0x)
+  | (((mode->CrtcHDisplay / 8) - 1) << 16));
+
+hsync_wid = (mode->CrtcHSyncEnd - mode->CrtcHSyncStart) / 8;
+if (!hsync_wid)   hsync_wid = 1;
+if (hsync_wid > 0x3f) hsync_wid = 0x3f;
+
+hsync_start = mode->CrtcHSyncStart - 8 + hsync_fudge;
+
+save->crtc2_h_sync_strt_wid = ((hsync_start & 0xfff)
+ | (hsync_wid << 16)
+ | ((mode->Flags & V_NHSYNC)
+? R128_CRTC2_H_SYNC_POL
+: 0));
+
+#if 1
+/* This works for double scan mode. */
+save->crtc2_v_total_disp = (((mode->CrtcVTotal - 1) & 0x)
+  | ((mode->CrtcVDisplay - 1) << 16));
+#else
+/* This is what cce/nbmode.c example code
+   does -- is this correct? */
+save->crtc2_v_total_disp = (((mode->CrtcVTotal - 1) & 0x)
+  | ((mode->CrtcVDisplay
+  * ((mode->Flags & V_DBLSCAN) ? 2 : 1) - 1)
+ << 16));
+#endif
+
+vsync_wid = mode->CrtcVSyncEnd - mode->CrtcVSyncStart;
+if (!vsync_wid)   vsync_wid = 1;
+if (vsync_wid > 0x1f) vsync_wid = 0x1f;
+
+save->crtc2_v_sync_strt_wid = (((mode->CrtcVSyncStart - 1) & 0xfff)
+ | (vsync_wid << 16)
+ | ((mode->Flags & V_NVSYNC)
+? R128_CRTC2_V_SYNC_POL
+: 0));
+save->crtc2_pitch   = info->CurrentLayout.displayWidth / 8;
+
+R128TRACE(("Pitch = %d bytes (virtualX = %d, displayWidth = %d)\n",
+ save->crtc2_pitch, pScrn->virtualX,
+ info->CurrentLayout.displayWidth));
+return TRUE;
+}
+
 
 static void r128_crtc_load_lut(xf86CrtcPtr crtc);
 
diff --git a/src/r128_driver.c b/src/r128_driver.c
index e0de694..45c76d1 100644
--- a/src/r128_driver.c
+++ b/src/r128_driver.c
@@ -2800,88 +2800,6 @@ Bool R128InitCrtc2Base(xf86CrtcPtr crtc, R128SavePtr 
save, int x, int y)
 return TRUE;
 }
 
-/* Define CRTC2 registers for requested video mode. */
-Bool R128InitCrtc2Registers(xf86CrtcPtr crtc, R128SavePtr save, DisplayModePtr 
mode)
-{
-

[PATCH xf86-video-r128 1/2] Move R128InitCrtcRegisters to r128_crtc.c

[Kevin Brace]

It does not make sense for this function to be inside r128_driver.c
since it is only called from a function inside r128_crtc.c.

Signed-off-by: Kevin Brace 
---
 src/r128.h|   1 -
 src/r128_crtc.c   | 111 ++
 src/r128_driver.c | 109 -
 3 files changed, 111 insertions(+), 110 deletions(-)

diff --git a/src/r128.h b/src/r128.h
index ae3e379..f5b01ce 100644
--- a/src/r128.h
+++ b/src/r128.h
@@ -522,7 +522,6 @@ extern voidR128InitRMXRegisters(R128SavePtr orig, 
R128SavePtr save, xf86
 extern voidR128InitFPRegisters(R128SavePtr orig, R128SavePtr save, 
xf86OutputPtr output);
 extern voidR128InitLVDSRegisters(R128SavePtr orig, R128SavePtr save, 
xf86OutputPtr output);
 extern BoolR128InitCrtcBase(xf86CrtcPtr crtc, R128SavePtr save, int x, 
int y);
-extern BoolR128InitCrtcRegisters(xf86CrtcPtr crtc, R128SavePtr save, 
DisplayModePtr mode);
 extern voidR128InitPLLRegisters(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, double dot_clock);
 extern BoolR128InitDDARegisters(xf86CrtcPtr crtc, R128SavePtr save, 
R128PLLPtr pll, DisplayModePtr mode);
 extern BoolR128InitCrtc2Base(xf86CrtcPtr crtc, R128SavePtr save, int 
x, int y);
diff --git a/src/r128_crtc.c b/src/r128_crtc.c
index ed77492..6afc267 100644
--- a/src/r128_crtc.c
+++ b/src/r128_crtc.c
@@ -47,6 +47,117 @@
 #include "r128_probe.h"
 #include "r128_reg.h"
 
+
+/* Define CRTC registers for requested video mode. */
+Bool R128InitCrtcRegisters(xf86CrtcPtr crtc, R128SavePtr save, DisplayModePtr 
mode)
+{
+ScrnInfoPtr pScrn = crtc->scrn;
+R128InfoPtr info  = R128PTR(pScrn);
+xf86OutputPtr output = R128FirstOutput(crtc);
+R128OutputPrivatePtr r128_output = output->driver_private;
+
+intformat;
+inthsync_start;
+inthsync_wid;
+inthsync_fudge;
+intvsync_wid;
+inthsync_fudge_default[] = { 0x00, 0x12, 0x09, 0x09, 0x06, 0x05 };
+inthsync_fudge_fp[]  = { 0x12, 0x11, 0x09, 0x09, 0x05, 0x05 };
+//   inthsync_fudge_fp_crt[]  = { 0x12, 0x10, 0x08, 0x08, 0x04, 0x04 };
+
+switch (info->CurrentLayout.pixel_code) {
+case 4:  format = 1; break;
+case 8:  format = 2; break;
+case 15: format = 3; break;  /*  555 */
+case 16: format = 4; break;  /*  565 */
+case 24: format = 5; break;  /*  RGB */
+case 32: format = 6; break;  /* xRGB */
+default:
+xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+   "Unsupported pixel depth (%d)\n",
+   info->CurrentLayout.bitsPerPixel);
+return FALSE;
+}
+
+if (r128_output->MonType == MT_LCD || r128_output->MonType == MT_DFP)
+hsync_fudge = hsync_fudge_fp[format-1];
+else
+hsync_fudge = hsync_fudge_default[format-1];
+
+save->crtc_gen_cntl = (R128_CRTC_EXT_DISP_EN
+  | R128_CRTC_EN
+  | (format << 8)
+  | ((mode->Flags & V_DBLSCAN)
+ ? R128_CRTC_DBL_SCAN_EN
+ : 0)
+  | ((mode->Flags & V_INTERLACE)
+ ? R128_CRTC_INTERLACE_EN
+ : 0)
+  | ((mode->Flags & V_CSYNC)
+ ? R128_CRTC_CSYNC_EN
+ : 0));
+
+if (r128_output->MonType == MT_LCD || r128_output->MonType == MT_DFP)
+save->crtc_gen_cntl &= ~(R128_CRTC_DBL_SCAN_EN | 
R128_CRTC_INTERLACE_EN);
+
+save->crtc_ext_cntl |= R128_VGA_ATI_LINEAR | R128_XCRT_CNT_EN;
+
+save->crtc_h_total_disp = mode->CrtcHTotal / 8) - 1) & 0x)
+  | (((mode->CrtcHDisplay / 8) - 1) << 16));
+
+hsync_wid = (mode->CrtcHSyncEnd - mode->CrtcHSyncStart) / 8;
+if (!hsync_wid)   hsync_wid = 1;
+if (hsync_wid > 0x3f) hsync_wid = 0x3f;
+
+hsync_start = mode->CrtcHSyncStart - 8 + hsync_fudge;
+
+save->crtc_h_sync_strt_wid = ((hsync_start & 0xfff)
+ | (hsync_wid << 16)
+ | ((mode->Flags & V_NHSYNC)
+? R128_CRTC_H_SYNC_POL
+: 0));
+
+#if 1
+/* This works for double scan mode. */
+save->crtc_v_total_disp = (((mode->CrtcVTotal - 1) & 0x)
+  | ((mode->CrtcVDisplay - 1) << 16));
+#else
+/* This is what cce/nbmode.c example code
+   does -- is this correct? */
+save->crtc_v_total_disp = (((mode->CrtcVTotal - 1) & 0x)
+  | ((mode->CrtcVDisplay
+  * ((mode->Flags & V_DBLSCAN) ? 2 : 1) - 1)
+ << 16));
+#endif
+
+vsync_wid = mode->CrtcVSyncEnd - mode->CrtcVSyncStart;
+if (!vsync_wid)   vsync_wid = 1;
+if (vsync_wid > 0x1f) vsync_wid = 0x1f;
+
+save->crtc_v_sync_strt_wid = (((mode->CrtcVSyncStart - 1) & 0xfff)
+ | (vsync_wid << 16)
+ | ((mode->Flags & V_NVSYNC)
+? R128_CRTC_V_SYNC_POL
+: 0));
+

Re: [PATCH xserver] present/wnmd: Preserve window pixmap's screen_x/y on flip

[Keith Packard]

Michel Dänzer  writes:

> From: Michel Dänzer 
>
> The incorrect values could result in the new pixmap's contents
> getting corrupted down the line.
>
> Bugzilla: https://bugs.freedesktop.org/106841
> Fixes: 029608dd8020 "present: Add window flip mode"

Ah. Makes sense. Screen flips are always at 0,0...

Reviewed-by: Keith Packard 

-- 
-keith


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

Re: [PATCH xserver] present/wnmd: Preserve window pixmap's screen_x/y on flip

[Adam Jackson]

On Thu, 2018-06-07 at 18:27 +0200, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> The incorrect values could result in the new pixmap's contents
> getting corrupted down the line.
> 
> Bugzilla: https://bugs.freedesktop.org/106841
> Fixes: 029608dd8020 "present: Add window flip mode"
> Signed-off-by: Michel Dänzer 

Reviewed-by: Adam Jackson 

- 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] xfree86: Inline xf86{Read, Write}Mmio{8, 16, 32} on alpha

[Adam Jackson]

On Thu, 2018-06-07 at 09:31 -0700, Matt Turner wrote:
> In commit 9db2af6f757e (xfree86: Remove xf86{Map,Unmap}VidMem) we
> somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
> function pointer indirection was intended to support dense vs sparse and
> sparse support is now gone, we can just make the functions static inline
> in compiler.h and avoid all of this.
> 
> Bugzilla: https://bugs.gentoo.org/548906
> Tested-by: Christopher May-Townsend 
> Signed-off-by: Matt Turner 

Reviewed-by: Adam Jackson 

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

[PATCH xserver] xfree86: Inline xf86{Read, Write}Mmio{8, 16, 32} on alpha

[Matt Turner]

In commit 9db2af6f757e (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.

Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend 
Signed-off-by: Matt Turner 
---
 configure.ac|  4 --
 hw/xfree86/common/compiler.h| 67 -
 hw/xfree86/os-support/bsd/Makefile.am   |  3 +-
 hw/xfree86/os-support/linux/Makefile.am | 12 --
 hw/xfree86/os-support/linux/lnx_video.c | 27 -
 hw/xfree86/os-support/meson.build   |  1 -
 6 files changed, 50 insertions(+), 64 deletions(-)

diff --git a/configure.ac b/configure.ac
index ddc47faa2..0075b6ace 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1908,9 +1908,6 @@ if test "x$XORG" = xyes; then
XORG_OS_SUBDIR="linux"
linux_acpi="no"
case $host_cpu in
- alpha*)
-   linux_alpha=yes
-   ;;
  i*86|amd64*|x86_64*|ia64*)
linux_acpi=$enable_linux_acpi
;;
@@ -2075,7 +2072,6 @@ AM_CONDITIONAL([XORG], [test "x$XORG" = xyes])
 AM_CONDITIONAL([XORG_BUS_PCI], [test "x$PCI" = xyes])
 AM_CONDITIONAL([XORG_BUS_BSDPCI], [test "x$xorg_bus_bsdpci" = xyes])
 AM_CONDITIONAL([XORG_BUS_SPARC], [test "x$xorg_bus_sparc" = xyes])
-AM_CONDITIONAL([LINUX_ALPHA], [test "x$linux_alpha" = xyes])
 AM_CONDITIONAL([LNXACPI], [test "x$linux_acpi" = xyes])
 AM_CONDITIONAL([LNXAPM], [test "x$linux_apm" = xyes])
 AM_CONDITIONAL([SOLARIS_VT], [test "x$solaris_vt" = xyes])
diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index eea29dfb5..7144c6a27 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -986,33 +986,64 @@ inl(unsigned PORT_SIZE port)
 #endif
 
 #ifdef __alpha__
-/* entry points for Mmio memory access routines */
-extern _X_EXPORT int (*xf86ReadMmio8) (void *, unsigned long);
-extern _X_EXPORT int (*xf86ReadMmio16) (void *, unsigned long);
-extern _X_EXPORT int (*xf86ReadMmio32) (void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio8) (int, void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio16) (int, void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio32) (int, void *, unsigned long);
+static inline int
+xf86ReadMmio8(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD8 *) ((unsigned long) Base + (Offset));
+}
+
+static inline int
+xf86ReadMmio16(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD16 *) ((unsigned long) Base + (Offset));
+}
+
+static inline int
+xf86ReadMmio32(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD32 *) ((unsigned long) Base + (Offset));
+}
+
+static inline void
+xf86WriteMmio8(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD8 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
+static inline void
+xf86WriteMmio16(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD16 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
+static inline void
+xf86WriteMmio32(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD32 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
 extern _X_EXPORT void xf86SlowBCopyFromBus(unsigned char *, unsigned char *,
int);
 extern _X_EXPORT void xf86SlowBCopyToBus(unsigned char *, unsigned char *, 
int);
 
 /* Some macros to hide the system dependencies for MMIO accesses */
 /* Changed to kill noise generated by gcc's -Wcast-align */
-#define MMIO_IN8(base, offset) (*xf86ReadMmio8)(base, offset)
-#define MMIO_IN16(base, offset) (*xf86ReadMmio16)(base, offset)
-#define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
-
-#define MMIO_OUT32(base, offset, val) \
-do { \
-   write_mem_barrier(); \
-   *(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset)) = (val); \
-} while (0)
+#define MMIO_IN8(base, offset) xf86ReadMmio8(base, offset)
+#define MMIO_IN16(base, offset) xf86ReadMmio16(base, offset)
+#define MMIO_IN32(base, offset) xf86ReadMmio32(base, offset)
 
 #define MMIO_OUT8(base, offset, val) \
-(*xf86WriteMmio8)((CARD8)(val), base, offset)
+xf86WriteMmio8((CARD8)(val), base, offset)
 #define MMIO_OUT16(base, offset, val) \
-(*xf86WriteMmio16)((CARD16)(val), base, offset)
+xf86WriteMmio16((CARD16)(val), base, offset)
+#define MMIO_OUT32(base, offset, val) \
+xf86WriteMmio32((CARD32)(val), base, offset)
 
 #elif defined(__powerpc__) || defined(__sparc__)
  /*
diff --git a/hw/xfree86/os-support/bsd/Makefile.am 
b/hw/xfree86/os-support/bsd/Makefile.am
index b01ea5bca..66ac83805 100644
--- 

Re: new dependency for libtizcore required for mesa?

[Dennis Clarke]

On 6/7/18 11:47 AM, Braiam Peguero wrote:



On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke > wrote:


On 6/7/18 10:44 AM, Michal Srb wrote:

On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:

Package libtizcore was not found in the pkg-config search path.
Perhaps you should add the directory containing `libtizcore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libtizcore' found


This is not a problem. It seems to be optional requirement. I
see the same
message in my build log.

checking for RADEON... yes
checking for RADEON... yes
configure: error: LLVM 3.9.0 or newer is required for r600


This is a problem. As it says, you need LLVM >= 3.9.0 and it did
not find one.


Ah .. oops. Thanks for the reply and I should look closer before jumping
  on the "what?" button.

How very odd :

root@xorg:~# apt-get install llvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@xorg:~#

Yet my old build process fails looking for LLVM?

The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
in the debian package list for that matter. Fine. However llvm is
definately installed and has been for a long while.  I am just doing the
usual per the instructions at :

Testing X servers from git
http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html


That has worked since about 2013 however it has been a while since I
tried. Something odd here ... not sure what it is yet.

Dennis


___
xorg@lists.x.org : X.Org support
Archives: http://lists.freedesktop.org/archives/xorg

Info: https://lists.x.org/mailman/listinfo/xorg

Your subscription address: %(user_address)s


Have you checked that the version installed of llvm is >= 3.9.0?
Debian Stretch by default install 3.8, while you can have 3.9 if
you install the llvm-toolchain-3.9 package. That should be enough.



The issue is definately version.
This is an older debian 8 system and thus  :

root@xorg:~# apt-get install llvm-3.5 llvm-3.5-dev llvm-3.5-runtime 
llvm-3.5-examples llvm-3.5-doc llvm-3.5-tools

Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm-3.5 is already the newest version.
llvm-3.5 set to manually installed.
llvm-3.5-dev is already the newest version.
llvm-3.5-dev set to manually installed.
llvm-3.5-runtime is already the newest version.
llvm-3.5-runtime set to manually installed.
The following extra packages will be installed:
  libjs-underscore
The following NEW packages will be installed:
  libjs-underscore llvm-3.5-doc llvm-3.5-examples llvm-3.5-tools
0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded.
Need to get 1,847 kB of archives.
After this operation, 10.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.ca.debian.org/debian/ jessie/main libjs-underscore all 
1.7.0~dfsg-1 [49.9 kB]
Get:2 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-doc all 
1:3.5-10 [1,461 kB]
Get:3 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-examples all 
1:3.5-10 [181 kB]
Get:4 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-tools amd64 
1:3.5-10 [154 kB]

Fetched 1,847 kB in 3s (598 kB/s)
Selecting previously unselected package libjs-underscore.
(Reading database ... 155535 files and directories currently installed.)
Preparing to unpack .../libjs-underscore_1.7.0~dfsg-1_all.deb ...
Unpacking libjs-underscore (1.7.0~dfsg-1) ...
Selecting previously unselected package llvm-3.5-doc.
Preparing to unpack .../llvm-3.5-doc_1%3a3.5-10_all.deb ...
Unpacking llvm-3.5-doc (1:3.5-10) ...
Selecting previously unselected package llvm-3.5-examples.
Preparing to unpack .../llvm-3.5-examples_1%3a3.5-10_all.deb ...
Unpacking llvm-3.5-examples (1:3.5-10) ...
Selecting previously unselected package llvm-3.5-tools.
Preparing to unpack .../llvm-3.5-tools_1%3a3.5-10_amd64.deb ...
Unpacking llvm-3.5-tools (1:3.5-10) ...
Setting up libjs-underscore (1.7.0~dfsg-1) ...
Setting up llvm-3.5-doc (1:3.5-10) ...
Setting up llvm-3.5-examples (1:3.5-10) ...
Setting up llvm-3.5-tools (1:3.5-10) ...
root@xorg:~# exit
logout
xorg $
xorg $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg
Building to run Linux / x86_64 ()
Thu Jun  7 16:27:03 GMT 2018
Skipping util/macros...
Skipping font/util...
Skipping doc/xorg-sgml-doctools...
Skipping doc/xorg-docs...
Skipping proto/xorgproto...
Skipping 

[PATCH xserver] present/wnmd: Preserve window pixmap's screen_x/y on flip

[Michel Dänzer]

From: Michel Dänzer 

The incorrect values could result in the new pixmap's contents
getting corrupted down the line.

Bugzilla: https://bugs.freedesktop.org/106841
Fixes: 029608dd8020 "present: Add window flip mode"
Signed-off-by: Michel Dänzer 
---
 present/present_wnmd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/present/present_wnmd.c b/present/present_wnmd.c
index 80ffb014e..1e3958bfc 100644
--- a/present/present_wnmd.c
+++ b/present/present_wnmd.c
@@ -469,6 +469,8 @@ present_wnmd_execute(present_vblank_ptr vblank, uint64_t 
ust, uint64_t crtc_msc)
 PixmapPtr old_pixmap = screen->GetWindowPixmap(window);
 
 /* Replace window pixmap with flip pixmap */
+vblank->pixmap->screen_x = old_pixmap->screen_x;
+vblank->pixmap->screen_y = old_pixmap->screen_y;
 present_set_tree_pixmap(toplvl_window, old_pixmap, 
vblank->pixmap);
 vblank->pixmap->refcnt++;
 dixDestroyPixmap(old_pixmap, old_pixmap->drawable.id);
-- 
2.17.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

Re: new dependency for libtizcore required for mesa?

[Brad Rogers]

On Thu, 7 Jun 2018 11:06:30 -0400
Dennis Clarke  wrote:

Hello Dennis,

>That has worked since about 2013 however it has been a while since I 
>tried. Something odd here ... not sure what it is yet.

I'm no programmer/compiling guru, but;

Missing the correct -dev package, perhaps?  Bearing in mind Debian has
multiple versions of LLVM available (3.9 to 6.0, IIRC) having the right
-dev package may be significant.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
My limbs are like palm trees swaying in the breeze
Mirage - Siouxsie & The Banshees


pgpHRQYS5MpE3.pgp
Description: OpenPGP digital signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Obtaining Xorg DDX commit privilege

[Adam Jackson]

On Thu, 2018-06-07 at 00:10 +0200, Kevin Brace wrote:

> I was thinking that it is not really desirable to let VBE start
> tinkering with I2C bus related registers this early in the PreInit
> callback,

That's probably a reasonable intuition, these days. I was just trying
to describe the context behind why it does what it does. In particular,
"just ask VBE" is the kind of broad brush stroke you can do across a
bunch of drivers and have a reasonable expection (in 2000) that it
would work, without needing to know all the details of how to get
initialized far enough to have working I2C.

In this sense ddxDesign.xml is out of date, and it should describe how
RANDRful drivers should defer mode setup until ScreenInit.

> and besides that, if r128 is being used on PowerPC (or Alpha or
> SPARC) platform, there is no INT 10H VBE.

Knda. There's not an x86 system firmware and there's not a vm86
syscall, but the int10 (x86emu really) code knows how to emulate that.
So if you plugged in an r128 with an x86 firmware on it, we really
could POST it, or anyway try to.

Now if that r128 had a PPC firmware with it because it's the one built
into an iMac, then yes vbe wouldn't do anything, but the device would
also already be initialized, and you'd probably be using fbdev.

- 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: new dependency for libtizcore required for mesa?

[Braiam Peguero]

On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke 
wrote:

> On 6/7/18 10:44 AM, Michal Srb wrote:
>
>> On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
>>
>>> Package libtizcore was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `libtizcore.pc'
>>> to the PKG_CONFIG_PATH environment variable
>>> No package 'libtizcore' found
>>>
>>
>> This is not a problem. It seems to be optional requirement. I see the same
>> message in my build log.
>>
>> checking for RADEON... yes
>>> checking for RADEON... yes
>>> configure: error: LLVM 3.9.0 or newer is required for r600
>>>
>>
>> This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find
>> one.
>>
>>
> Ah .. oops. Thanks for the reply and I should look closer before jumping
>  on the "what?" button.
>
> How very odd :
>
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
>
> Yet my old build process fails looking for LLVM?
>
> The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
> in the debian package list for that matter. Fine. However llvm is
> definately installed and has been for a long while.  I am just doing the
> usual per the instructions at :
>
> Testing X servers from git
> http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html
>
> That has worked since about 2013 however it has been a while since I
> tried. Something odd here ... not sure what it is yet.
>
> Dennis
>
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>

Have you checked that the version installed of llvm is >= 3.9.0?
Debian Stretch by default install 3.8, while you can have 3.9 if
you install the llvm-toolchain-3.9 package. That should be enough.

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

Re: new dependency for libtizcore required for mesa?

[Adam Jackson]

On Thu, 2018-06-07 at 11:06 -0400, Dennis Clarke wrote:

> Ah .. oops. Thanks for the reply and I should look closer before jumping
>   on the "what?" button.
> 
> How very odd :
> 
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
> 
> Yet my old build process fails looking for LLVM?

The package named 'llvm' is just the runtime. Typically any package you
need as a build dependency is going to be named llvm-dev on Debian-like 
systems.

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

Re: new dependency for libtizcore required for mesa?

[Nigel Sollars]

Your most likely going to need to add a PPA for the LLVM you mention debian
( latest for deb is normally way behind required ) ..  I would imagine you
may need a couple to cover anything further.

Nige

On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke 
wrote:

> On 6/7/18 10:44 AM, Michal Srb wrote:
>
>> On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
>>
>>> Package libtizcore was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `libtizcore.pc'
>>> to the PKG_CONFIG_PATH environment variable
>>> No package 'libtizcore' found
>>>
>>
>> This is not a problem. It seems to be optional requirement. I see the same
>> message in my build log.
>>
>> checking for RADEON... yes
>>> checking for RADEON... yes
>>> configure: error: LLVM 3.9.0 or newer is required for r600
>>>
>>
>> This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find
>> one.
>>
>>
> Ah .. oops. Thanks for the reply and I should look closer before jumping
>  on the "what?" button.
>
> How very odd :
>
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
>
> Yet my old build process fails looking for LLVM?
>
> The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
> in the debian package list for that matter. Fine. However llvm is
> definately installed and has been for a long while.  I am just doing the
> usual per the instructions at :
>
> Testing X servers from git
> http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html
>
> That has worked since about 2013 however it has been a while since I
> tried. Something odd here ... not sure what it is yet.
>
> Dennis
>
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>



-- 
“Science is a differential equation. Religion is a boundary condition.”

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

Re: new dependency for libtizcore required for mesa?

[Dennis Clarke]

On 6/7/18 10:44 AM, Michal Srb wrote:

On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:

Package libtizcore was not found in the pkg-config search path.
Perhaps you should add the directory containing `libtizcore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libtizcore' found


This is not a problem. It seems to be optional requirement. I see the same
message in my build log.


checking for RADEON... yes
checking for RADEON... yes
configure: error: LLVM 3.9.0 or newer is required for r600


This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one.



Ah .. oops. Thanks for the reply and I should look closer before jumping
 on the "what?" button.

How very odd :

root@xorg:~# apt-get install llvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@xorg:~#

Yet my old build process fails looking for LLVM?

The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
in the debian package list for that matter. Fine. However llvm is
definately installed and has been for a long while.  I am just doing the
usual per the instructions at :

Testing X servers from git
http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html

That has worked since about 2013 however it has been a while since I 
tried. Something odd here ... not sure what it is yet.


Dennis

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

Re: new dependency for libtizcore required for mesa?

[Michal Srb]

On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
> Package libtizcore was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libtizcore.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libtizcore' found

This is not a problem. It seems to be optional requirement. I see the same 
message in my build log.

> checking for RADEON... yes
> checking for RADEON... yes
> configure: error: LLVM 3.9.0 or newer is required for r600

This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one.

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

new dependency for libtizcore required for mesa?

[Dennis Clarke]

Dear X-types:

Is there a new minimal dependency list?

While running a build I see this :

==
==  Processing:  "mesa/mesa"
==configuration options:
Cloning into 'mesa/mesa'...
remote: Counting objects: 1006300, done.
remote: Compressing objects: 100% (150111/150111), done.
remote: Total 1006300 (delta 859623), reused 996318 (delta 851198)
Receiving objects: 100% (1006300/1006300), 175.92 MiB | 5.00 MiB/s, done.
Resolving deltas: 100% (859623/859623), done.
Checking connectivity... done.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /opt/xorg/share/aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'.
libtoolize: copying file `bin/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:61: installing 'bin/ar-lib'
configure.ac:61: installing 'bin/compile'
configure.ac:45: installing 'bin/config.guess'
configure.ac:45: installing 'bin/config.sub'
configure.ac:46: installing 'bin/install-sh'
configure.ac:46: installing 'bin/missing'
src/Makefile.am: installing 'bin/depcomp'
parallel-tests: installing 'bin/test-driver'
autoreconf: Leaving directory `.'
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '16411' is supported by ustar format... yes
checking whether GID '20002' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for grep that handles long lines and -e... /bin/grep
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking dependency style of gcc... gcc3
checking for GNU make... make
checking for python2.7... python2.7
checking for a sed that does not truncate output... /bin/sed
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to 

Re: [PATCH app/xauth 2/2] Sort entries from most specific to most generic.

[Michal Srb]

On čtvrtek 7. června 2018 14:59:44 CEST Walter Harms wrote:
> I was thinking about a more permanent solution and sofar i see the correct
> way would to add the two functions to libXau since i do not see that other
> applications would be more clever that xauth.

That would be nice, sadly libXau does not provide any functions to manipulate 
the list of xauth records. Just functions for writing and reading of a single 
record, locking and matching.

One option would be to change the semantics of XauGetBestAuthByAddr to return 
the most precise match first, instead of returning the first match of any 
kind. But I don't think changing that behavior is good idea.

Alternatively we can just take the patch #1, so that xauth does overwrite 
records with other random records. I believe that is correct fix. And we can 
ignore this patch #2 that does the sorting. I could probably workaround my 
issue by invoking xauth differently. (I could create 1-item list first 
containing the new record and then merge the original list into it, so the new 
record will end up on top.)

Michal Srb
___
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 app/xauth 2/2] Sort entries from most specific to most generic.

[Walter Harms]

> Michal Srb  hat am 6. Juni 2018 um 08:34 geschrieben:
> 
> 
> On úterý 5. června 2018 17:46:05 CEST Walter Harms wrote:
> > MMh, so far i understand you do an add and then sort the whole thing.
> > perhaps it would be more easy to start with a sorted field and insert (add)
> > a key on the correct location ?
> 
> That would work if we have the guarantee that the list is sorted to begin 
> with. The list will be sorted now if it was created by xauth. But if it was 
> made by anything else (e.g. some display manager) it can be in any order. So 
> when adding new entry, xauth will re-sort it.
> 
> Alternative would be to just insert the new entry in front of the first more 
> general entry and ignore any entries that are never used because of their 
> position in the list.
> 
> I don't have opinion on which is better. Both would work for my usecase.
> 

I see your ideas,
I was thinking about a more permanent solution and sofar i see the correct
way would to add the two functions to libXau since i do not see that other
applications would be more clever that xauth.

re,
 wh
___
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] exa: Use PictureMatchFormat for source-only picture format description

[Michel Dänzer]

On 2018-06-06 10:26 PM, Adam Jackson wrote:
> On Fri, 2018-06-01 at 11:58 +0200, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> Their pFormat member is NULL, which resulted in a crash in
>> miRenderColorToPixel.
>>
>> Fixes: 8171d4c2d67b "render: Store and use all 16bpc of precision for
>>  solid pixels (v2.1)"
>> Signed-off-by: Michel Dänzer 
> 
> I'm not entirely sure why a source-only picture would have ->format but
> not ->pFormat?

static PicturePtr
createSourcePicture(void)
{
[...]
pPicture->pFormat = 0;
[...]
pPicture->format = PICT_a8r8g8b8;
[...]
}

The immediate issue is that getting the PictFormatPtr requires the
ScreenPtr, which isn't readily available here. Probably solvable, but
not trivial, so I consider it a SEP. :)


> Still, if that's the case, this would definitely be a correct fix, so.
> 
> Reviewed-by: Adam Jackson 

Thanks!


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

Re: [PATCH xserver] glamor: Enable modifier support for xfree86 too

[Daniel Stone]

On 6 June 2018 at 20:56, Adam Jackson  wrote:
> This was left disabled in 1.20.0, it's time to start being sure it
> works.
>
> Signed-off-by: Adam Jackson 

Acked-by: Daniel Stone 
___
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 xkbcomp] Ignore xkb_keycodes.maximum of > 255

[Daniel Stone]

On 7 June 2018 at 05:13, Peter Hutterer  wrote:
> Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"
>
> A keymap with a key > 255 will have a xkb_keycodes.maximum of that keycode.
> Let's not throw a fatal error on that, just crop it back to the maximum of
> 255. This doesn't set the "high_keycode_warned" on purpose so we get this for
> the first key that actually matters.

Reviewed-by: Daniel Stone 
___
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