Re: [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

2017-03-17 Thread Eric Anholt 
Kenneth Graunke  writes:

> Copied from Mesa with no modifications.  Gives us Geminilake PCI IDs.
>
> Signed-off-by: Kenneth Graunke 

Acked-by: Eric Anholt 


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 v3] autobind GPUs to the screen

2017-03-17 Thread Eric Anholt 
Hans de Goede  writes:

> From: Dave Airlie 
>
> This is a modified version of a patch we've been carry-ing in Fedora and

"carrying"

> RHEL for years now. This patch automatically adds secondary GPUs to the
> master as output sink / offload source making e.g. the use of
> slave-outputs just work, with requiring the user to manually run
> "xrandr --setprovideroutputsource" before he can hookup an external
> monitor to his hybrid graphics laptop.
>
> There is one problem with this patch, which is why it was not upstreamed
> before. What to do when a secondary GPU gets detected really is a policy
> decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
> as such should be under control of the Desktop Environment.
>
> Unconditionally adding autobinding support to the xserver will result
> in races between the DE dealing with the hotplug of a secondary GPU
> and the server itself dealing with it.

Will there actually be races?  In the current patch, at least, doesn't
the new GPU get autoconfigured before the randr change notification goes
out?

> However we've waited for years for any Desktop Environments to actually
> start doing some sort of autoconfiguration of secondary GPUs and there
> is still not a single DE dealing with this, so I believe that it is
> time to upstream this now.
>
> To avoid potential future problems if any DEs get support for doing
> secondary GPU configuration themselves, the new autobind functionality
> is made optional. Since no DEs currently support doing this themselves it
> is enabled by default. When DEs grow support for doing this themselves
> they can disable the servers autobinding through the servers cmdline or a
> xorg.conf snippet.

I think this is a sensible default.  It also helped with getting X up on
my VC4 + CLCD platform.

Reviewed-by: Eric Anholt 


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

[PATCH] dri2: Sync i965_pci_ids.h from Mesa.

2017-03-17 Thread Kenneth Graunke 
Copied from Mesa with no modifications.  Gives us Geminilake PCI IDs.

Signed-off-by: Kenneth Graunke 
---
 hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 40 ++
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h 
b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
index 1566afd65..17504f5cb 100644
--- a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
+++ b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
@@ -109,6 +109,10 @@ CHIPSET(0x162A, bdw_gt3, "Intel(R) Iris Pro P6300 
(Broadwell GT3e)")
 CHIPSET(0x162B, bdw_gt3, "Intel(R) Iris 6100 (Broadwell GT3)")
 CHIPSET(0x162D, bdw_gt3, "Intel(R) Broadwell GT3")
 CHIPSET(0x162E, bdw_gt3, "Intel(R) Broadwell GT3")
+CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherrytrail)")
+CHIPSET(0x22B1, chv, "Intel(R) HD Graphics XXX (Braswell)") /* Overridden 
in brw_get_renderer_string */
+CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)")
+CHIPSET(0x22B3, chv, "Intel(R) HD Graphics (Cherryview)")
 CHIPSET(0x1902, skl_gt1, "Intel(R) HD Graphics 510 (Skylake GT1)")
 CHIPSET(0x1906, skl_gt1, "Intel(R) HD Graphics 510 (Skylake GT1)")
 CHIPSET(0x190A, skl_gt1, "Intel(R) Skylake GT1")
@@ -134,8 +138,13 @@ CHIPSET(0x1932, skl_gt4, "Intel(R) Iris Pro Graphics 580 
(Skylake GT4e)")
 CHIPSET(0x193A, skl_gt4, "Intel(R) Iris Pro Graphics P580 (Skylake GT4e)")
 CHIPSET(0x193B, skl_gt4, "Intel(R) Iris Pro Graphics 580 (Skylake GT4e)")
 CHIPSET(0x193D, skl_gt4, "Intel(R) Iris Pro Graphics P580 (Skylake GT4e)")
-CHIPSET(0x5902, kbl_gt1, "Intel(R) Kabylake GT1")
-CHIPSET(0x5906, kbl_gt1, "Intel(R) Kabylake GT1")
+CHIPSET(0x0A84, bxt, "Intel(R) HD Graphics (Broxton)")
+CHIPSET(0x1A84, bxt, "Intel(R) HD Graphics (Broxton)")
+CHIPSET(0x1A85, bxt_2x6, "Intel(R) HD Graphics (Broxton 2x6)")
+CHIPSET(0x5A84, bxt, "Intel(R) HD Graphics 505 (Broxton)")
+CHIPSET(0x5A85, bxt_2x6, "Intel(R) HD Graphics 500 (Broxton 2x6)")
+CHIPSET(0x5902, kbl_gt1, "Intel(R) HD Graphics 610 (Kaby Lake GT1)")
+CHIPSET(0x5906, kbl_gt1, "Intel(R) HD Graphics 610 (Kaby Lake GT1)")
 CHIPSET(0x590A, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x5908, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x590B, kbl_gt1, "Intel(R) Kabylake GT1")
@@ -143,23 +152,16 @@ CHIPSET(0x590E, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x5913, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
 CHIPSET(0x5915, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
 CHIPSET(0x5917, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
-CHIPSET(0x5912, kbl_gt2, "Intel(R) Kabylake GT2")
-CHIPSET(0x5916, kbl_gt2, "Intel(R) Kabylake GT2")
-CHIPSET(0x591A, kbl_gt2, "Intel(R) Kabylake GT2")
-CHIPSET(0x591B, kbl_gt2, "Intel(R) Kabylake GT2")
-CHIPSET(0x591D, kbl_gt2, "Intel(R) Kabylake GT2")
-CHIPSET(0x591E, kbl_gt2, "Intel(R) Kabylake GT2")
+CHIPSET(0x5912, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
+CHIPSET(0x5916, kbl_gt2, "Intel(R) HD Graphics 620 (Kaby Lake GT2)")
+CHIPSET(0x591A, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
+CHIPSET(0x591B, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
+CHIPSET(0x591D, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
+CHIPSET(0x591E, kbl_gt2, "Intel(R) HD Graphics 615 (Kaby Lake GT2)")
 CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
 CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x5926, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x5927, kbl_gt3, "Intel(R) Kabylake GT3")
+CHIPSET(0x5926, kbl_gt3, "Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3)")
+CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3)")
 CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
-CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherrytrail)")
-CHIPSET(0x22B1, chv, "Intel(R) HD Graphics XXX (Braswell)") /* Overridden 
in brw_get_renderer_string */
-CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)")
-CHIPSET(0x22B3, chv, "Intel(R) HD Graphics (Cherryview)")
-CHIPSET(0x0A84, bxt, "Intel(R) HD Graphics (Broxton)")
-CHIPSET(0x1A84, bxt, "Intel(R) HD Graphics (Broxton)")
-CHIPSET(0x1A85, bxt_2x6, "Intel(R) HD Graphics (Broxton 2x6)")
-CHIPSET(0x5A84, bxt, "Intel(R) HD Graphics (Broxton)")
-CHIPSET(0x5A85, bxt_2x6, "Intel(R) HD Graphics (Broxton 2x6)")
+CHIPSET(0x3184, glk, "Intel(R) HD Graphics (Geminilake)")
+CHIPSET(0x3185, glk_2x6, "Intel(R) HD Graphics (Geminilake 2x6)")
-- 
2.12.0

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

Re: [PATCH xserver] glamor: avoid a crash if texture allocation failed

2017-03-17 Thread Eric Anholt 
Olivier Fourdan  writes:

> Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
> is raised, in which case the texture returned is zero.
>
> But the texture value is not checked in glamor_create_fbo() and glamor
> will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:

Reviewed, tagged for stable, and pushed.  Thanks!


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 0/3] Death to 24bpp, v3

2017-03-17 Thread Adam Jackson 
On Fri, 2017-03-17 at 13:47 -0400, Adam Jackson wrote:
> New in this round:
> 
> 1/ fixes a bizzare bit of Xephyr glamor that would zero bitsPerPixel for
> the screen. That, combined with the if (Ones(bpp) != 1) in fbScreenInit,
> meant glamor would crash on init.
> 
> 3/ also removes the now-dead pRotatedPixmap from the GC, and squashes in
> the glamor/exa changes so all the tile handling changes are in one place.
> 
> Otherwise identical.

remote: I: patch #144722 updated using rev 
83c4297d2c4fd501a9d36bc0cb7d357a8d22394c.
remote: E: failed to find patch for rev 
e33be78e2ab63abc84aa0baddff90bcefa9c183a.
remote: I: patch #144729 updated using rev 
0803918e64262482035f042e5e1f2a571d3dea1b.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   fe0b297..0803918  master -> master

No idea why it didn't find patch #144721, sigh.

- 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 3/3] fb: Remove 24bpp support (v3)

2017-03-17 Thread Adam Jackson 
v2:
- Require power-of-two bpp in ScreenInit
- Eliminate fbCreatePixmapBpp

v3
- Squash in the exa and glamor changes so we can remove pRotatedPixmap
  in the same stroke.

Signed-off-by: Adam Jackson 
---
 exa/exa.c|  25 +--
 fb/Makefile.am   |   2 -
 fb/fb.h  | 166 
 fb/fb24_32.c | 548 ---
 fb/fb24_32.h |  44 -
 fb/fbarc.c   |   3 -
 fb/fbbits.c  |  58 --
 fb/fbbits.h  | 133 ++---
 fb/fbblt.c   | 228 -
 fb/fbbltone.c| 287 +--
 fb/fbcopy.c  |   8 +-
 fb/fbgc.c|  30 ---
 fb/fbgetsp.c |   5 -
 fb/fbglyph.c | 185 -
 fb/fbimage.c |  23 +--
 fb/fbline.c  |   6 -
 fb/fboverlay.c   |  64 +-
 fb/fbpixmap.c|  17 +-
 fb/fbpoint.c |  29 +--
 fb/fbscreen.c|  71 ++-
 fb/fbseg.c   | 161 ---
 fb/fbsetsp.c |   4 -
 fb/fbsolid.c | 114 ---
 fb/fbwindow.c|  10 -
 fb/wfbrename.h   |  20 --
 glamor/glamor_core.c |  37 
 include/gcstruct.h   |   7 -
 mi/migc.c|   2 -
 28 files changed, 91 insertions(+), 2196 deletions(-)
 delete mode 100644 fb/fb24_32.c
 delete mode 100644 fb/fb24_32.h

diff --git a/exa/exa.c b/exa/exa.c
index 7266b71..d6ff197 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -505,29 +505,14 @@ exaValidateGC(GCPtr pGC, unsigned long changes, 
DrawablePtr pDrawable)
 ExaScreenPriv(pScreen);
 ExaGCPriv(pGC);
 PixmapPtr pTile = NULL;
-Bool finish_current_tile = FALSE;
 
-/* Either of these conditions is enough to trigger access to a tile 
pixmap. */
-/* With pGC->tileIsPixel == 1, you run the risk of dereferencing an 
invalid tile pixmap pointer. */
+/* Either of these conditions is enough to trigger access to a tile pixmap.
+ * With pGC->tileIsPixel == 1, you run the risk of dereferencing an invalid
+ * tile pixmap pointer.
+ */
 if (pGC->fillStyle == FillTiled ||
 ((changes & GCTile) && !pGC->tileIsPixel)) {
 pTile = pGC->tile.pixmap;
-
-/* Sometimes tile pixmaps are swapped, you need access to:
- * - The current tile if it depth matches.
- * - Or the rotated tile if that one matches depth and !(changes & 
GCTile).
- * - Or the current tile pixmap and a newly created one.
- */
-if (pTile && pTile->drawable.depth != pDrawable->depth &&
-!(changes & GCTile)) {
-PixmapPtr pRotatedTile = fbGetRotatedPixmap(pGC);
-
-if (pRotatedTile &&
-pRotatedTile->drawable.depth == pDrawable->depth)
-pTile = pRotatedTile;
-else
-finish_current_tile = TRUE; /* CreatePixmap will be 
called. */
-}
 }
 
 if (pGC->stipple)
@@ -544,8 +529,6 @@ exaValidateGC(GCPtr pGC, unsigned long changes, DrawablePtr 
pDrawable)
 
 if (pTile)
 exaFinishAccess(>drawable, EXA_PREPARE_SRC);
-if (finish_current_tile && pGC->tile.pixmap)
-exaFinishAccess(>tile.pixmap->drawable, EXA_PREPARE_AUX_DEST);
 if (pGC->stipple)
 exaFinishAccess(>stipple->drawable, EXA_PREPARE_MASK);
 }
diff --git a/fb/Makefile.am b/fb/Makefile.am
index 65b5d94..333aa06 100644
--- a/fb/Makefile.am
+++ b/fb/Makefile.am
@@ -14,8 +14,6 @@ libwfb_la_LIBADD = $(PIXMAN_LIBS)
 
 libfb_la_SOURCES = \
fb.h\
-   fb24_32.c   \
-   fb24_32.h   \
fballpriv.c \
fbarc.c \
fbbits.c\
diff --git a/fb/fb.h b/fb/fb.h
index 8bce67e..7d1e443 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -89,9 +89,6 @@
 #if GLYPHPADBYTES != 4
 #error "GLYPHPADBYTES must be 4"
 #endif
-/* for driver compat - intel UXA needs the second one at least */
-#define FB_24BIT
-#define FB_24_32BIT
 #define FB_STIP_SHIFT  LOG2_BITMAP_PAD
 #define FB_STIP_UNIT   (1 << FB_STIP_SHIFT)
 #define FB_STIP_MASK   (FB_STIP_UNIT - 1)
@@ -331,32 +328,6 @@ extern _X_EXPORT void fbSetBits(FbStip * bits, int stride, 
FbStip data);
 
 #define FbLaneCase(n,a)   FbLaneCase4(n,(CARD8 *) (a),0)
 
-/* Rotate a filled pixel value to the specified alignement */
-#define FbRot24(p,b)   (FbScrRight(p,b) | FbScrLeft(p,24-(b)))
-#define FbRot24Stip(p,b)(FbStipRight(p,b) | FbStipLeft(p,24-(b)))
-
-/* step a filled pixel value to the next/previous FB_UNIT alignment */
-#define FbNext24Pix(p) (FbRot24(p,(24-FB_UNIT%24)))
-#define FbPrev24Pix(p) (FbRot24(p,FB_UNIT%24))
-#define FbNext24Stip(p)(FbRot24(p,(24-FB_STIP_UNIT%24)))
-#define FbPrev24Stip(p)(FbRot24(p,FB_STIP_UNIT%24))
-
-/* step a rotation value to the next/previous rotation value */
-#define FbNext24Rot(r)((r) == 0 ? 16 : (r) - 8)
-#define FbPrev24Rot(r)((r) == 16 ? 0 : (r) + 8)
-
-#if IMAGE_BYTE_ORDER == MSBFirst
-#define FbFirst24Rot(x)

[PATCH xserver] configure.ac: fix checking for libdrm version after 9232835bd

2017-03-17 Thread Mariusz Bialonczyk 
Fix commit 9232835bd16b6948442f7a4588fb9376782cb814
glamor: use drmGetDeviceNameFromFD2 when available

No matter what libdrm version was installed, it always set
the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1.
This obviously leads to compilation problems.

Signed-off-by: Mariusz Bialonczyk 
Cc: Qiang Yu 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index ac11e6572..0f2f68abb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2167,7 +2167,7 @@ if test "x$GLAMOR" = xyes; then
fi
fi
 
-   PKG_CHECK_MODULES(LIBDRM, "libdrm >= 2.4.74",
+   PKG_CHECK_EXISTS(libdrm >= 2.4.74,
[AC_DEFINE(GLAMOR_HAS_DRM_NAME_FROM_FD_2, 1, [Have 
GLAMOR_HAS_DRM_NAME_FROM_FD_2])], [])
 fi
 AM_CONDITIONAL([GLAMOR_EGL], [test "x$GBM" = xyes])
-- 
2.11.0

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

[PATCH xserver 2/3] xfree86: Remove 24bpp pixmap format support (v2)

2017-03-17 Thread Adam Jackson 
There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently ignore the old options that would ask for it.

The cirrus alpine driver has been updated to default to 16bpp, and both
it and the i810 driver can now use the 32->24 conversion code in shadow
if they want. All other drivers support 32bpp. Configurations that
explicitly request 24bpp in order to fit in VRAM will be broken now
though.

v2: Fix command line options to silently ignore 24bpp rather than fail

Signed-off-by: Adam Jackson 
---
 hw/xfree86/common/xf86.h|  5 ---
 hw/xfree86/common/xf86Config.c  | 32 --
 hw/xfree86/common/xf86Globals.c |  3 --
 hw/xfree86/common/xf86Helper.c  | 95 +++--
 hw/xfree86/common/xf86Init.c| 78 +
 hw/xfree86/common/xf86Priv.h|  1 -
 hw/xfree86/common/xf86Privstr.h |  2 -
 hw/xfree86/common/xf86str.h |  8 
 hw/xfree86/man/Xorg.man | 15 ---
 hw/xfree86/man/xorg.conf.man|  8 
 10 files changed, 9 insertions(+), 238 deletions(-)

diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 828bff1..ee24835 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -91,9 +91,6 @@ extern _X_EXPORT Bool VTSwitchEnabled;  /* kbd driver */
 
 #define BOOLTOSTRING(b) ((b) ? "TRUE" : "FALSE")
 
-#define PIX24TOBPP(p) (((p) == Pix24Use24) ? 24 : \
-   (((p) == Pix24Use32) ? 32 : 0))
-
 /* Compatibility functions for pre-input-thread drivers */
 static inline _X_DEPRECATED int xf86BlockSIGIO(void) { input_lock(); return 0; 
}
 static inline _X_DEPRECATED void xf86UnblockSIGIO(int wasset) { 
input_unlock(); }
@@ -290,8 +287,6 @@ extern _X_EXPORT const char *
 xf86GetVisualName(int visual);
 extern _X_EXPORT int
 xf86GetVerbosity(void);
-extern _X_EXPORT Pix24Flags
-xf86GetPix24(void);
 extern _X_EXPORT int
 xf86GetDepth(void);
 extern _X_EXPORT rgb
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 89861e0..49b898d 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -628,7 +628,6 @@ typedef enum {
 FLAG_DPMS_STANDBYTIME,
 FLAG_DPMS_SUSPENDTIME,
 FLAG_DPMS_OFFTIME,
-FLAG_PIXMAP,
 FLAG_NOPM,
 FLAG_XINERAMA,
 FLAG_LOG,
@@ -674,8 +673,6 @@ static OptionInfoRec FlagOptions[] = {
  {0}, FALSE},
 {FLAG_DPMS_OFFTIME, "OffTime", OPTV_INTEGER,
  {0}, FALSE},
-{FLAG_PIXMAP, "Pixmap", OPTV_INTEGER,
- {0}, FALSE},
 {FLAG_NOPM, "NoPM", OPTV_BOOLEAN,
  {0}, FALSE},
 {FLAG_XINERAMA, "Xinerama", OPTV_BOOLEAN,
@@ -715,7 +712,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, XF86OptionPtr 
layoutopts)
 {
 XF86OptionPtr optp, tmp;
 int i;
-Pix24Flags pix24 = Pix24DontCare;
 Bool value;
 MessageType from;
 const char *s;
@@ -922,34 +918,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, 
XF86OptionPtr layoutopts)
i, MAX_TIME_IN_MIN);
 #endif
 
-i = -1;
-xf86GetOptValInteger(FlagOptions, FLAG_PIXMAP, );
-switch (i) {
-case 24:
-pix24 = Pix24Use24;
-break;
-case 32:
-pix24 = Pix24Use32;
-break;
-case -1:
-break;
-default:
-ErrorF("Pixmap option's value (%d) must be 24 or 32\n", i);
-break;
-}
-if (xf86Pix24 != Pix24DontCare) {
-xf86Info.pixmap24 = xf86Pix24;
-xf86Info.pix24From = X_CMDLINE;
-}
-else if (pix24 != Pix24DontCare) {
-xf86Info.pixmap24 = pix24;
-xf86Info.pix24From = X_CONFIG;
-}
-else {
-xf86Info.pixmap24 = Pix24DontCare;
-xf86Info.pix24From = X_DEFAULT;
-}
-
 #ifdef PANORAMIX
 from = X_DEFAULT;
 if (!noPanoramiXExtension)
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index e962b75..ddf7a86 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -117,8 +117,6 @@ xf86InfoRec xf86Info = {
 .vidModeAllowNonLocal = FALSE,
 .miscModInDevEnabled = TRUE,
 .miscModInDevAllowNonLocal = FALSE,
-.pixmap24 = Pix24DontCare,
-.pix24From = X_DEFAULT,
 .pmFlag = TRUE,
 .disableRandR = FALSE,
 .randRFrom = X_DEFAULT,
@@ -189,7 +187,6 @@ char *xf86KeyboardName = NULL;
 int xf86Verbose = DEFAULT_VERBOSE;
 int xf86LogVerbose = DEFAULT_LOG_VERBOSE;
 int xf86FbBpp = -1;
-Pix24Flags xf86Pix24 = Pix24DontCare;
 int xf86Depth = -1;
 rgb xf86Weight = { 0, 0, 0 };
 
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 7d6a374..b745793 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -344,33 +344,15 @@ xf86AddPixFormat(ScrnInfoPtr pScrn, int depth, int bpp, 
int pad)
  *

[PATCH xserver 1/3] ephyr: Don't clobber bitsPerPixel when using glamor

2017-03-17 Thread Adam Jackson 
This ends up passing 0 as the bpp argument to fb screen setup, which is
not really the best plan.

Signed-off-by: Adam Jackson 
---
 hw/kdrive/ephyr/hostx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index a9ea372..d5578de 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -927,7 +927,6 @@ hostx_screen_init(KdScreenInfo *screen,
 #ifdef GLAMOR
 if (ephyr_glamor) {
 *bytes_per_line = 0;
-*bits_per_pixel = 0;
 ephyr_glamor_set_window_size(scrpriv->glamor,
  scrpriv->win_width, scrpriv->win_height);
 return NULL;
-- 
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

[PATCH xserver 0/3] Death to 24bpp, v3

2017-03-17 Thread Adam Jackson 
New in this round:

1/ fixes a bizzare bit of Xephyr glamor that would zero bitsPerPixel for
the screen. That, combined with the if (Ones(bpp) != 1) in fbScreenInit,
meant glamor would crash on init.

3/ also removes the now-dead pRotatedPixmap from the GC, and squashes in
the glamor/exa changes so all the tile handling changes are in one place.

Otherwise identical.

- 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] glamor: avoid a crash if texture allocation failed

2017-03-17 Thread Olivier Fourdan 
Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
is raised, in which case the texture returned is zero.

But the texture value is not checked in glamor_create_fbo() and glamor
will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:

  Truncated backtrace:
  Thread no. 1 (10 frames)
   #4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
   #5 glamor_create_fbo_from_tex at glamor_fbo.c:112
   #6 glamor_create_fbo at glamor_fbo.c:159
   #7 glamor_create_fbo_array at glamor_fbo.c:210
   #8 glamor_create_pixmap at glamor.c:226
   #9 compNewPixmap at compalloc.c:536
   #10 compAllocPixmap at compalloc.c:605
   #11 compCheckRedirect at compwindow.c:167
   #12 compRealizeWindow at compwindow.c:267
   #13 RealizeTree at window.c:2617

Check the value returned by _glamor_create_tex() in glamor_create_fbo()
and return NULL in the texture is zero.

All callers of glamor_create_fbo() actually check the returned value and
will use a fallback code path if it's NULL.

Bugzilla: https://bugzilla.redhat.com/1433305
Signed-off-by: Olivier Fourdan 
---
 glamor/glamor_fbo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index 988bb58..9f1288c 100644
--- a/glamor/glamor_fbo.c
+++ b/glamor/glamor_fbo.c
@@ -156,6 +156,10 @@ glamor_create_fbo(glamor_screen_private *glamor_priv,
   int w, int h, GLenum format, int flag)
 {
 GLint tex = _glamor_create_tex(glamor_priv, w, h, format);
+
+if (!tex) /* Texture creation failed due to GL_OUT_OF_MEMORY */
+return NULL;
+
 return glamor_create_fbo_from_tex(glamor_priv, w, h, format, tex, flag);
 }
 
-- 
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

Re: [PATCH xserver] configure.ac: fix checking for libdrm version after 9232835bd

2017-03-17 Thread Yu, Qiang 
Hi Mariusz,

Thanks. Your patch works for both libdrm >= 2.4.74 and < 2.4.74.
But my PKG_CHECK_MODULES always define the macro. I still don't know
the reason, but your patch is:
Review-and-tested-by: Qiang Yu 

Regards,
Qiang

From: Mariusz Bialonczyk 
Sent: Friday, March 17, 2017 6:20:22 PM
To: xorg-devel@lists.x.org
Cc: Mariusz Bialonczyk; Yu, Qiang
Subject: [PATCH xserver] configure.ac: fix checking for libdrm version after 
9232835bd

Fix commit 9232835bd16b6948442f7a4588fb9376782cb814
glamor: use drmGetDeviceNameFromFD2 when available

No matter what libdrm version was installed, it always set
the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1.
This obviously leads to compilation problems.

Signed-off-by: Mariusz Bialonczyk 
Cc: Qiang Yu 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index ac11e6572..0f2f68abb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2167,7 +2167,7 @@ if test "x$GLAMOR" = xyes; then
fi
fi

-   PKG_CHECK_MODULES(LIBDRM, "libdrm >= 2.4.74",
+   PKG_CHECK_EXISTS(libdrm >= 2.4.74,
[AC_DEFINE(GLAMOR_HAS_DRM_NAME_FROM_FD_2, 1, [Have 
GLAMOR_HAS_DRM_NAME_FROM_FD_2])], [])
 fi
 AM_CONDITIONAL([GLAMOR_EGL], [test "x$GBM" = xyes])
--
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

Re: opengl and drm on a pi 3b?

2017-03-17 Thread jc 
Hi

>> Hi
>>
>> As this isn't an "X" answer I've skipped the list.
>
> And I've put it back so its in the archive FFR.
>
>> What application
>> are you using?  Do you actually need X? do you actually need OpenGL?
>>
> Yes on both counts. The app, linuxcnc, has a nice gui control interface
> which includes a backplot of the machines motions while its carving up a
> block of metal to make something.  Screen refresh rate with what I am
> getting is about 15 frames a second, just noticeably slow. The numbers
> in the digital readout of the cutter location in 3d space, should just
> roll by, but they jump a decade or more in displayed value if the
> machine is moving at 5 inches a minute now.
>
>> I ask these questions 'cos as it stands X + GL + HW Video is still a
>> bit unsupported on the Pi.  If you just want video then junk X & OGL
>> and your life will be a lot better.  X + HW decode can be made to work
>> just about acceptably but it takes some effort, add OGL into the mix
>> and whilst it should make life better by and large it doesn't (yet) as
>> the mmal stacks don't play nice with the GL stacks.
>
> Is there even movement afoot to fix this? If its fixed, the pi 3b can
> easily take over from the power hungry x86 boxes we generally use as the
> driving iron. Not an overnight takeover, but as the x86 boxes age out
> and people are becoming more conscious of the energy bills, it will
> happen.

Yes there is movement to fix this.  Eric is your friend in this regard. 
However having said that I don't anticipate your life getting magically
better when it is fixed as actually using the h/w to do the video decode
requires the app decoding the video to know about it.

Regards

JC

>> Regards
>>
>> JC
> Thanks John.
>>
>> >Hello all, been a while since I rang your doorbell, greetings from
>> > West Virginia;
>> >
>> >I am in the process of converting an old lathe to cnc, and using a pi
>> > 3b as the driver.
>> >
>> >Doing some work on the configuration today, I got curious to see if
>> > the features I was adding to the configuration were pushing the poor
>> > pi to the point of exhaustion. Firing up htop, the various bits and
>> > pieces that together make up linuxcnc, were a total of about 4 or 5%
>> > of the cpu load.  Compton, the x compositor, was burning something
>> > in the region of 165%, or a little over 1.5 of its 4 cores. It was
>> > also a few megabytes into swap, so I rebooted it, after which
>> > compton was only using perhaps 35% of one core.
>> >
>> >But my main reason for posting is to see if any progress is being
>> > made on opengl and drm drivers for that bcm video the pi has.  The
>> > display is just slow enough to be noticeable.  The machine its
>> > driving can move at up to about 100 inches a minute, with bone
>> > breaking force, so it would be a definite safety advantage if the
>> > video could keep up with the machine in something resembling real
>> > time.
>> >
>> >So what, if any, is the status of faster video drivers for the pi's
>> > that use the bcm video?
>> >
>> >Thanks all.
>> >
>> >Cheers, Gene Heskett
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>


___
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: [PATCH xim] modules/im/ximcp: Send display and screen number to XIM server

2017-03-17 Thread Takao Fujiwara 

ping

On 03/14/17 13:39, Takao Fujiwara-san wrote:

Hi,

Would you integrate the patch?

Fujiwara

On 02/18/17 12:22, Takao Fujiwara-san wrote:

Enables that client application sends its screen number to XIM server.
In ZaphodHeads environment, XIM server needs to know the screen
number to launch the lookup window in the right screen.
I think this way keeps the back compatibility.

Signed-off-by: Takao Fujiwara 
---
 modules/im/ximcp/imDefIm.c | 32 
 src/xlibi18n/XimProto.h|  2 +-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/modules/im/ximcp/imDefIm.c b/modules/im/ximcp/imDefIm.c
index 9e877c0..d0b8368 100644
--- a/modules/im/ximcp/imDefIm.c
+++ b/modules/im/ximcp/imDefIm.c
@@ -794,6 +794,35 @@ _XimOpenCheck(
 return False;
 }

+static INT16
+_XimSetDisplayNumber(
+Xim   im,
+CARD8*buf_b,
+INT16 len)
+{
+const char *display_string =  DisplayString(im->core.display);
+buf_b[len] = 0;
+buf_b[len+1] = 0;
+
+if (display_string && (display_string = strchr(display_string, ':')) != 
NULL) {
+display_string++;
+if (*display_string != '\0') {
+int number = atoi(display_string);
+buf_b[len] = (number < 0) ? 0 : (number % 256);
+display_string++;
+if ((display_string = strchr(display_string, '.')) != NULL) {
+display_string++;
+if (*display_string != '\0') {
+number = atoi(display_string);
+buf_b[len+1] = (number < 0) ? 0 : (number % 256);
+}
+}
+}
+}
+
+return sizeof(CARD8) * 2;
+}
+
 static Bool
 _XimOpen(
 Xim im)
@@ -803,6 +832,7 @@ _XimOpen(
 CARD8*buf_b = [XIM_HEADER_SIZE];
 CARD16*buf_s;
 INT16 len;
+INT16 version_len;
 CARD32 reply32[BUFSIZE/4];
 char*reply = (char *)reply32;
 XPointer preply;
@@ -816,6 +846,8 @@ _XimOpen(
 (void)strcpy((char *)_b[1], locale_name);  /* locale name */
 len += sizeof(BYTE);   /* sizeof length */
 XIM_SET_PAD(buf_b, len);   /* pad */
+version_len = _XimSetDisplayNumber(im, buf_b, len);
+len += (version_len + XIM_PAD(version_len));

 _XimSetHeader((XPointer)buf, XIM_OPEN, 0, );
 if (!(_XimWrite(im, len, (XPointer)buf)))
diff --git a/src/xlibi18n/XimProto.h b/src/xlibi18n/XimProto.h
index 6b0096d..881f975 100644
--- a/src/xlibi18n/XimProto.h
+++ b/src/xlibi18n/XimProto.h
@@ -47,7 +47,7 @@ PERFORMANCE OF THIS SOFTWARE.
  * Xim implementation revision
  */
 #define PROTOCOLMAJORVERSION1
-#define PROTOCOLMINORVERSION0
+#define PROTOCOLMINORVERSION1

 /*
  * Major Protocol number



___
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: [ANNOUNCE] xf86-video-amdgpu 1.3.0

2017-03-17 Thread Zhang, Jerry 
> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Friday, March 17, 2017 11:32
> To: Zhang, Jerry
> Cc: xorg@lists.x.org; amd-...@lists.freedesktop.org
> Subject: Re: [ANNOUNCE] xf86-video-amdgpu 1.3.0
> 
> On 17/03/17 11:32 AM, Zhang, Jerry wrote:
> > Hi Michel,
> >
> >> * Use libdrm_amdgpu functionality to determine the GPU marketing name,
> >>   remove corresponding tables from this driver.
> >
> > Could you elaborate it?
> > I'd like to know how DDX(amdgpu) get the marketing name.
> 
> It uses libdrm_amdgpu's amdgpu_get_marketing_name API.

Thanks for your info.
We go the same way :)

> 
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
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: [ANNOUNCE] xf86-video-amdgpu 1.3.0

2017-03-17 Thread Zhang, Jerry 
Hi Michel,

> * Use libdrm_amdgpu functionality to determine the GPU marketing name,
>   remove corresponding tables from this driver.

Could you elaborate it?
I'd like to know how DDX(amdgpu) get the marketing name.
I hope we go the same way in hybrid stack as well.

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Michel D?nzer
> Sent: Thursday, March 16, 2017 16:45
> To: xorg-annou...@lists.x.org
> Cc: xorg@lists.x.org; amd-...@lists.freedesktop.org
> Subject: [ANNOUNCE] xf86-video-amdgpu 1.3.0
> 
> 
> I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu, the Xorg 
> driver
> for AMD Radeon GPUs supported by the amdgpu kernel driver.
> This release supports xserver versions 1.10-1.19.
> 
> Highlights:
> 
> * Allow TearFree to be toggled at runtime via an RandR output property
>   "TearFree". The xorg.conf option "TearFree" now controls the default
>   value of the output properties.
> * Use libdrm_amdgpu functionality to determine the GPU marketing name,
>   remove corresponding tables from this driver.
> * Use DRM render nodes for DRI3 clients when available.
> 
> Plus many other improvements and fixes. Thanks to everybody who contributed
> to this release in any way!
> 
> 
> Emil Velikov (1):
>   autogen.sh: use quoted string variables
> 
> Hans De Goede (1):
>   amdgpu_probe: Do not close server managed drm fds
> 
> Jammy Zhou (1):
>   Use render node for DRI3 if available
> 
> Michel Dänzer (44):
>   Post-release version bump
>   Move struct amdgpu_gpu_info out of amdgpu_get_tile_config
>   Use family information from libdrm_amdgpu / kernel
>   Stop using generated amdgpu_device_match
>   Remove amdpciids.h
>   Stop using AMDGPUPciChipsets
>   Stop using AMDGPU(Unique)Chipsets
>   Remove generated header files
>   Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when
> available
>   Make libdrm >= 2.4.72 requirement explicit
>   Don't install Flush/EventCallback for GPU screens
>   Add amdgpu_is_gpu_screen helper
>   Take current scanout_id into account everywhere involved with TearFree
>   Fix amdgpu_scanout_extents_intersect for GPU screens
>   Call ValidateGC after ChangeClip in amdgpu_sync_scanout_pixmaps
>   Call amdgpu_drm_abort_entry on failure to flip to a scanout pixmap
>   Simplify drmmode_handle_uevents
>   Pass pitch from drmmode_crtc_scanout_allocate to
> drmmode_create_bo_pixmap
>   Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as
> well
>   Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create
>   Handle rotation in the driver also with Xorg 1.12-1.18
>   Fix flip event data leak if calloc or drmModeAddFB fails
>   Don't destroy current FB if drmModeAddFB fails
>   Factor out amdgpu_prime_dirty_to_crtc helper
>   Factor out drmmode_crtc_scanout_update helper
>   Allow toggling TearFree at runtime via output property
>   Use drmmode_crtc_scanout_free in drmmode_fini
>   present: Only call drmModeRmFB after setting modes for unflip
>   present: Wait for GPU idle before setting modes for unflip
>   present: Also flush before using a flip to unflip
>   present: Use async flip for unflip if possible
>   present: Flush before flipping
>   Call drmmode_set_desired_modes from a WindowExposures hook
>   Move DPMS check from amdgpu_scanout_do_update to
> amdgpu_scanout_flip
>   Don't call amdgpu_glamor_flush in drmmode_copy_fb
>   Don't use pScrn->is_gpu in AMDGPUCreateScreenResources_KMS
>   Use local implementation of RegionDuplicate for older xserver
>   Only define transform_region for XF86_CRTC_VERSION >= 4
>   glamor: Don't flush in BlockHandler with Xorg >= 1.19
>   Refactor amdgpu_kernel_close_fd helper
>   glamor: Use glamor_finish when available
>   Skip some initialization steps for GPU screens
>   Pass TRUE to drmmode_set_desired_modes the first time for GPU screens
>   Bump version for 1.3.0 release
> 
> Mihail Konev (1):
>   autogen: add default patch prefix
> 
> Peter Hutterer (1):
>   autogen.sh: use exec instead of waiting for configure to finish
> 
> jimqu (1):
>   udev_monitor_receive_device() will block when hotplug monitor
> 
> git tag: xf86-video-amdgpu-1.3.0
> 
> https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-
> 1.3.0.tar.bz2
> MD5:  e2ee9e16ffbd45ebda68a7ff638a04f2  xf86-video-amdgpu-1.3.0.tar.bz2
> SHA1: 7b89fe6e22e6739257c0f03c9f034c9c579a8bce  xf86-video-amdgpu-
> 1.3.0.tar.bz2
> SHA256:
> c1630f228938be949273f72b29ae70822dde064ad79c3ccb14d55f427e3f4e70  xf86-
> video-amdgpu-1.3.0.tar.bz2
> PGP:  https://xorg.freedesktop.org/archive/individual/driver/xf86-video-
> amdgpu-1.3.0.tar.bz2.sig
> 
>