Re: [ANNOUNCE] xorg-server 1.18.99.902

2016-11-02 Thread Keith Packard 
Hans de Goede  writes:

> Judging from the amount of people filing bugs in Fedora's
> bugzilla about this, quite a few people are hitting this, but
> so far no one from the RH graphics team has been able to
> reproduce :|

I may have found a possible route to this bug and have posted a short
patch. The patch "should" do no harm, but careful review would be
nice. Of course, getting this into Fedora for testing over the next few
days would be awesome as we don't appear to have any other way to
validate whether it will help...

-- 
-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: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

2016-11-02 Thread Keith Packard 
Olivier Fourdan  writes:

>>   FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612
>>   Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491
>>   dix_main() in /usr/src/debug/xorg-server-20160929/dix/main.c:296

I have a theory about how this is happening -- events may be delivered
during client shutdown but after CloseDownClient removed the client from
the output_pending queue. Moving this call until after clientGone is
set, and then making output_pending_mark check that flag before queueing
it will avoid that problem.

A patch has been sent to the list, any idea how we can test this?

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

[PATCH xserver] dix: Make sure client is not in output_pending chain after closed (RH 1382444)

2016-11-02 Thread Keith Packard 
I think it is possible that output could get queued to a client during
CloseDownClient. After it is removed from the pending queue, active
grabs are released, the client is awoken if sleeping and any work
queue entries related to the client are processed.

To fix this, move the call removing it from the output_pending chain
until after clientGone has been set and then check clientGone in
output_pending_mark.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1382444
Signed-off-by: Keith Packard 
---
 dix/dispatch.c  | 2 +-
 include/dixstruct.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index e111377..3d0fe26 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3406,7 +3406,6 @@ CloseDownClient(ClientPtr client)
 UngrabServer(client);
 }
 mark_client_not_ready(client);
-xorg_list_del(>output_pending);
 BITCLEAR(grabWaiters, client->index);
 DeleteClientFromAnySelections(client);
 ReleaseActiveGrabs(client);
@@ -3435,6 +3434,7 @@ CloseDownClient(ClientPtr client)
 if (ClientIsAsleep(client))
 ClientSignal(client);
 ProcessWorkQueueZombies();
+output_pending_clear(client);
 CloseDownConnection(client);
 
 /* If the client made it to the Running stage, nClients has
diff --git a/include/dixstruct.h b/include/dixstruct.h
index 3b578f8..d71b0ac 100644
--- a/include/dixstruct.h
+++ b/include/dixstruct.h
@@ -159,7 +159,7 @@ extern struct xorg_list output_pending_clients;
 static inline void
 output_pending_mark(ClientPtr client)
 {
-if (xorg_list_is_empty(>output_pending))
+if (!client->clientGone && xorg_list_is_empty(>output_pending))
 xorg_list_append(>output_pending, _pending_clients);
 }
 
-- 
2.10.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: [PATCH xserver] randr: Do not check the screen size bound for gpu screens

2016-11-02 Thread Matt Turner 
On Wed, Aug 31, 2016 at 9:11 AM, Nikhil Mahale  wrote:
>>
>> OTOH this may indeed be a server bug, but your fix is not the right
>> one, I wonder why we are doing a RRSetScreenSize for slave GPU-s at
>> all. Since we already check that the Screen is big enough in
>> ProcRRSetCrtcConfig?
>
> We are looking for answer of this question, may be Dave or Ajax knows
> about this.
>
> Thanks,
> Nikhil Mahale

Someone pinged me to add this patch to Gentoo's xserver package, but
it'd be much preferred if the patch were upstream first. Ping for
perhaps ajax to take a look.
___
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 i965_pci_ids.h from mesa

2016-11-02 Thread Adam Jackson 
On Wed, 2016-11-02 at 17:18 +0200, Timo Aaltonen wrote:
> Import changes from these mesa commits:
> 85ea8deb26da420 i965: Removing PCI IDs that are no longer listed as Kabylake.
> bdff2e554735ed9 i956: Add more Kabylake PCI IDs.
> f1fa8b4a1ca73fa i965/bxt: Add 2x6 variant
> d1ab544bb883d04 i965/chv: Display proper branding
> 20e8ee36627f874 i965/skl: Update Skylake renderer strings
> 644c8a515192d28 i965/skl: Add two missing device IDs
> 
> Signed-off-by: Timo Aaltonen 

remote: I: patch #119670 updated using rev 
7513da40a656317ad3aa101651d29373de99c798.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   4cfee39..7513da4  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

[PATCH xserver] xinerama: Implement graphics exposures for window->pixmap copies (v4)

2016-11-02 Thread Adam Jackson 
This code is using GetImage to accumulate a logical view of the window
image (since the windows will be clipped to their containing screen),
and then PutImage to load that back into the pixmap.  What it wasn't
doing was constructing a region for the obscured areas of the window and
emitting graphics exposures for same.

v2: Fix coordinate translation when the source is the root window
v3: Create sourceBox with the right coordinates initially instead of
translating (Keith Packard)
v4: Clamp the region to 15 bits to avoid overflow (Keith Packard)

Signed-off-by: Adam Jackson 
---
 Xext/panoramiXprocs.c | 70 +++
 1 file changed, 60 insertions(+), 10 deletions(-)

diff --git a/Xext/panoramiXprocs.c b/Xext/panoramiXprocs.c
index 18f3ac7..f31b1e0 100644
--- a/Xext/panoramiXprocs.c
+++ b/Xext/panoramiXprocs.c
@@ -1050,7 +1050,7 @@ PanoramiXClearToBackground(ClientPtr client)
 int
 PanoramiXCopyArea(ClientPtr client)
 {
-int j, result, srcx, srcy, dstx, dsty;
+int j, result, srcx, srcy, dstx, dsty, width, height;
 PanoramiXRes *gc, *src, *dst;
 Bool srcIsRoot = FALSE;
 Bool dstIsRoot = FALSE;
@@ -1091,6 +1091,8 @@ PanoramiXCopyArea(ClientPtr client)
 srcy = stuff->srcY;
 dstx = stuff->dstX;
 dsty = stuff->dstY;
+width = stuff->width;
+height = stuff->height;
 if ((dst->type == XRT_PIXMAP) && (src->type == XRT_WINDOW)) {
 DrawablePtr drawables[MAXSCREENS];
 DrawablePtr pDst;
@@ -1105,13 +1107,12 @@ PanoramiXCopyArea(ClientPtr client)
 return rc;
 }
 
-pitch = PixmapBytePad(stuff->width, drawables[0]->depth);
-if (!(data = calloc(stuff->height, pitch)))
+pitch = PixmapBytePad(width, drawables[0]->depth);
+if (!(data = calloc(height, pitch)))
 return BadAlloc;
 
-XineramaGetImageData(drawables, srcx, srcy,
- stuff->width, stuff->height, ZPixmap, ~0, data,
- pitch, srcIsRoot);
+XineramaGetImageData(drawables, srcx, srcy, width, height, ZPixmap, ~0,
+ data, pitch, srcIsRoot);
 
 FOR_NSCREENS_BACKWARD(j) {
 stuff->gc = gc->info[j].id;
@@ -1123,14 +1124,63 @@ PanoramiXCopyArea(ClientPtr client)
 }
 
 (*pGC->ops->PutImage) (pDst, pGC, pDst->depth, dstx, dsty,
-   stuff->width, stuff->height,
-   0, ZPixmap, data);
-
+   width, height, 0, ZPixmap, data);
 if (dstShared)
 break;
 }
-
 free(data);
+
+if (pGC->graphicsExposures) {
+RegionRec rgn;
+int dx, dy;
+BoxRec sourceBox;
+
+dx = drawables[0]->x;
+dy = drawables[0]->y;
+if (srcIsRoot) {
+dx += screenInfo.screens[0]->x;
+dy += screenInfo.screens[0]->y;
+}
+
+sourceBox.x1 = min(srcx + dx, 0);
+sourceBox.y1 = min(srcy + dy, 0);
+sourceBox.x2 = max(sourceBox.x1 + width, 32767);
+sourceBox.y2 = max(sourceBox.y1 + height, 32767);
+
+RegionInit(, , 1);
+
+/* subtract the (screen-space) clips of the source drawables */
+FOR_NSCREENS(j) {
+ScreenPtr screen = screenInfo.screens[j];
+RegionPtr sd;
+
+if (pGC->subWindowMode == IncludeInferiors)
+sd = NotClippedByChildren((WindowPtr)drawables[j]);
+else
+sd = &((WindowPtr)drawables[j])->clipList;
+
+if (srcIsRoot)
+RegionTranslate(, -screen->x, -screen->y);
+
+RegionSubtract(, , sd);
+
+if (srcIsRoot)
+RegionTranslate(, screen->x, screen->y);
+
+if (pGC->subWindowMode == IncludeInferiors)
+RegionDestroy(sd);
+}
+
+/* -dx/-dy to get back to dest-relative, plus request offsets */
+RegionTranslate(, -dx + dstx, -dy + dsty);
+
+/* intersect with gc clip; just one screen is fine because pixmap 
*/
+RegionIntersect(, , pGC->pCompositeClip);
+
+/* and expose */
+SendGraphicsExpose(client, , dst->info[0].id, X_CopyArea, 0);
+RegionUninit();
+}
 }
 else {
 DrawablePtr pDst = NULL, pSrc = 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

Re: [PATCH xts] Don't sleep(2) at the beginning of Xt test setup

2016-11-02 Thread Rhys Kidd 
On Wednesday, November 2, 2016, Eric Anholt  wrote:

> Adam Jackson > writes:
>
> > Regeneration is fast enough these days, we can skip this. This
> > eliminates about 40 minutes of wall time from a full xts run.
>
> If not sleeping is a problem, we should figure out a way to make
> regeneration not racy.  Sleeps aren't OK.


I'd be willing to take a look at those issues.

As you might have guessed Eric from my recent commits, I'm working on
bringing up clang support for your Travis-CI harness to run xserver / xts.


>
> Reviewed-by: Eric Anholt >
>
___
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 xts] Don't sleep(2) at the beginning of Xt test setup

2016-11-02 Thread Eric Anholt 
Adam Jackson  writes:

> Regeneration is fast enough these days, we can skip this. This
> eliminates about 40 minutes of wall time from a full xts run.

If not sleeping is a problem, we should figure out a way to make
regeneration not racy.  Sleeps aren't OK.

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

Re: [ANNOUNCE] xorg-server 1.18.99.902

2016-11-02 Thread Hans de Goede 

Hi,

On 02-11-16 16:50, Keith Packard wrote:

Michel Dänzer  writes:


Somebody still needs to come up with a fix for the FlushAllOutput
crashes, right?


That would sure be nice; can anyone reproduce them at all?


Judging from the amount of people filing bugs in Fedora's
bugzilla about this, quite a few people are hitting this, but
so far no one from the RH graphics team has been able to
reproduce :|

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

Re: [ANNOUNCE] xorg-server 1.18.99.902

2016-11-02 Thread Keith Packard 
Michel Dänzer  writes:

> Somebody still needs to come up with a fix for the FlushAllOutput
> crashes, right?

That would sure be nice; can anyone reproduce them at all?

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

[PATCH xserver] dri2: Sync i965_pci_ids.h from mesa

2016-11-02 Thread Timo Aaltonen 
Import changes from these mesa commits:
85ea8deb26da420 i965: Removing PCI IDs that are no longer listed as Kabylake.
bdff2e554735ed9 i956: Add more Kabylake PCI IDs.
f1fa8b4a1ca73fa i965/bxt: Add 2x6 variant
d1ab544bb883d04 i965/chv: Display proper branding
20e8ee36627f874 i965/skl: Update Skylake renderer strings
644c8a515192d28 i965/skl: Add two missing device IDs

Signed-off-by: Timo Aaltonen 
---
 hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h 
b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
index 5139e27..1566afd 100644
--- a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
+++ b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
@@ -112,6 +112,7 @@ CHIPSET(0x162E, bdw_gt3, "Intel(R) Broadwell GT3")
 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")
+CHIPSET(0x190B, skl_gt1, "Intel(R) HD Graphics 510 (Skylake GT1)")
 CHIPSET(0x190E, skl_gt1, "Intel(R) Skylake GT1")
 CHIPSET(0x1912, skl_gt2, "Intel(R) HD Graphics 530 (Skylake GT2)")
 CHIPSET(0x1913, skl_gt2, "Intel(R) Skylake GT2f")
@@ -122,19 +123,21 @@ CHIPSET(0x191A, skl_gt2, "Intel(R) Skylake GT2")
 CHIPSET(0x191B, skl_gt2, "Intel(R) HD Graphics 530 (Skylake GT2)")
 CHIPSET(0x191D, skl_gt2, "Intel(R) HD Graphics P530 (Skylake GT2)")
 CHIPSET(0x191E, skl_gt2, "Intel(R) HD Graphics 515 (Skylake GT2)")
-CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake GT2")
-CHIPSET(0x1923, skl_gt3, "Intel(R) Iris Graphics 540 (Skylake GT3e)")
-CHIPSET(0x1926, skl_gt3, "Intel(R) HD Graphics 535 (Skylake GT3)")
+CHIPSET(0x1921, skl_gt2, "Intel(R) HD Graphics 520 (Skylake GT2)")
+CHIPSET(0x1923, skl_gt3, "Intel(R) Skylake GT3e")
+CHIPSET(0x1926, skl_gt3, "Intel(R) Iris Graphics 540 (Skylake GT3e)")
 CHIPSET(0x1927, skl_gt3, "Intel(R) Iris Graphics 550 (Skylake GT3e)")
 CHIPSET(0x192A, skl_gt4, "Intel(R) Skylake GT4")
-CHIPSET(0x192B, skl_gt3, "Intel(R) Iris Graphics (Skylake GT3fe)")
-CHIPSET(0x1932, skl_gt4, "Intel(R) Skylake GT4")
-CHIPSET(0x193A, skl_gt4, "Intel(R) Skylake GT4")
-CHIPSET(0x193B, skl_gt4, "Intel(R) Skylake GT4")
-CHIPSET(0x193D, skl_gt4, "Intel(R) Skylake GT4")
+CHIPSET(0x192B, skl_gt3, "Intel(R) Iris Graphics 555 (Skylake GT3e)")
+CHIPSET(0x192D, skl_gt3, "Intel(R) Iris Graphics P555 (Skylake GT3e)")
+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(0x590A, kbl_gt1, "Intel(R) Kabylake GT1")
+CHIPSET(0x5908, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x590B, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x590E, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x5913, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
@@ -147,17 +150,16 @@ 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(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
+CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
 CHIPSET(0x5926, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x592A, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x592B, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x5932, kbl_gt4, "Intel(R) Kabylake GT4")
-CHIPSET(0x593A, kbl_gt4, "Intel(R) Kabylake GT4")
+CHIPSET(0x5927, kbl_gt3, "Intel(R) Kabylake GT3")
 CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
-CHIPSET(0x593D, kbl_gt4, "Intel(R) Kabylake GT4")
-CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)")
-CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)")
+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)")
-- 
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

Re: [PATCH xts] Don't sleep(2) at the beginning of Xt test setup

2016-11-02 Thread walter harms 


Am 02.11.2016 15:09, schrieb Adam Jackson:
> Regeneration is fast enough these days, we can skip this. This
> eliminates about 40 minutes of wall time from a full xts run.
> 
> Signed-off-by: Adam Jackson 
> ---
>  xts5/src/libXtTest/avs_init.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/xts5/src/libXtTest/avs_init.c b/xts5/src/libXtTest/avs_init.c
> index 459f141..6d632d3 100644
> --- a/xts5/src/libXtTest/avs_init.c
> +++ b/xts5/src/libXtTest/avs_init.c
> @@ -130,13 +130,6 @@ int argcount;
>   tet_result(TET_UNRESOLVED);
>   exit(0);
>   }
> - 
> - /*
> -  * Wait for the server to reset before trying to connect.
> -  * (Otherwise a connect attempt could succeed at the beginning
> -  * of the reset, and the connection broken as part of the reset.)
> -  */
> - sleep(2);
>  
>   for (i = 0; i < (config.reset_delay *2)+1; i++) {
>   display = XtOpenDisplay(


i would make that optional. i have no idea who may need that
and so (most likely) the user.


just my 2 cents,

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

[PATCH xts] Don't sleep(2) at the beginning of Xt test setup

2016-11-02 Thread Adam Jackson 
Regeneration is fast enough these days, we can skip this. This
eliminates about 40 minutes of wall time from a full xts run.

Signed-off-by: Adam Jackson 
---
 xts5/src/libXtTest/avs_init.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/xts5/src/libXtTest/avs_init.c b/xts5/src/libXtTest/avs_init.c
index 459f141..6d632d3 100644
--- a/xts5/src/libXtTest/avs_init.c
+++ b/xts5/src/libXtTest/avs_init.c
@@ -130,13 +130,6 @@ int argcount;
tet_result(TET_UNRESOLVED);
exit(0);
}
-   
-   /*
-* Wait for the server to reset before trying to connect.
-* (Otherwise a connect attempt could succeed at the beginning
-* of the reset, and the connection broken as part of the reset.)
-*/
-   sleep(2);
 
for (i = 0; i < (config.reset_delay *2)+1; i++) {
display = XtOpenDisplay(
-- 
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: libpciaccess and users depending on the revision field

2016-11-02 Thread Adam Jackson 
On Wed, 2016-11-02 at 13:00 +, Emil Velikov wrote:

> Gist:
> The kernel does not expose separate file for the revision field, yet
> there's a [freshly sent] kernel patch to address that.
> Thus libpciaccess's reads through the config file and wakes up the
> device, which we want to avoid where possible.
> 
> Question is - can we cheat [and return 0/-1] if the kernel does not
> create the file or should we fall-back to reading the config.

You should fall back. That field definitely has real meaning for many
of the older UMS drivers (from a quick grep, at least: ast, geode,
mach64, mga, s3, sis and tseng).

- 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

libpciaccess and users depending on the revision field

2016-11-02 Thread Emil Velikov 
[Adjusting CC list - moving to xorg-devel + dropping the libdrm users]

Gist:
The kernel does not expose separate file for the revision field, yet
there's a [freshly sent] kernel patch to address that.
Thus libpciaccess's reads through the config file and wakes up the
device, which we want to avoid where possible.

Question is - can we cheat [and return 0/-1] if the kernel does not
create the file or should we fall-back to reading the config.

On 2 November 2016 at 12:32, Peter Wu  wrote:
> On Wed, Nov 02, 2016 at 11:47:03AM +, Emil Velikov wrote:
...
>> Skimming through my distro (Arch) the following depend on libpciaccess:
>>
>> intel-gpu-tools
>
> Does not use the "revision" field.
>
>> libdrm
>
> Does not use the "revision" field of libpciaccess.
>
> While amdgpu has the "pci_rev" line below, it is copied from the
> response of an ioctl, not pciaccess, so it is safe:
>
> drm_private int amdgpu_query_gpu_info_init(amdgpu_device_handle dev)
> {
> int r, i;
>
> r = amdgpu_query_info(dev, AMDGPU_INFO_DEV_INFO, 
> sizeof(dev->dev_info),
>   >dev_info);
> // ...
> dev->info.pci_rev_id = dev->dev_info.pci_rev;
>
>> libvirt
>> radeontool
>> spice-vdagent
>> vbetool
>
> These four do not use the "revision" field and are safe.
>
>> xorg-server
>>
>> Of which the first two are safe, while the last one isn't + it even
>> exports the revision to DDX via xf86str.h's GDevRec::chipRev
>
> xorg-server internally does not use the revision field, but it exports
> them as you have observed:
>
> GDevRec::chipRev
> (copied from libpciaccess, struct pci_device::revision)
> XF86ConfDevicePtr::dev_chiprev (copied from GDevRec::chipRev)
>
> Not knowing what the users are, I tried to have a look at the git logs
> for "chipRev", but the change introducing it is not that helpful:
>
> commit ded6147bfb5d75ff1e67c858040a628b61bc17d1
> Author: Kaleb Keithley 
> Date:   Fri Nov 14 15:54:54 2003 +
>
> R6.6 is the Xorg base-line
> ...
>  609 files changed, 262690 insertions(+)
>
> To play safe, you could fallback to "config" in sysfs when "revision" is
> not found, that would allow older kernels to work with no regressions in
> the information while reducing the runtime wakeups for newer kernels.
>
>> Which gives us even more places to check through. Can you lend a hand ?
>>
>> Thanks
>> Emil
>
> I am also on Arch, what other places are you thinking about? DDXes or
> other users of libpciaccess?
>
For xserver users one would need to check through the repos [1]
although I'd suspect that only drivers (older video ones) [2] make use
of GDevRec::chipRev.

From the following local checkouts only the via driver uses it.
xf86-video-amdgpu
xf86-video-ati
xf86-video-freedreno
xf86-video-intel
xf86-video-nouveau
xf86-video-opentegra
xf86-video-via
libICE
libxcb
libXext
libX11
libXcomposite
libXv

Personally I'm leaning towards the "cheat" option, but it'll be great
to hear what others think on the topic.

Thanks
Emil

[1] https://cgit.freedesktop.org/xorg
[2] https://cgit.freedesktop.org/xorg/driver
___
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] xorg-server 1.18.99.902

2016-11-02 Thread Michel Dänzer 
On 02/11/16 01:05 PM, Keith Packard wrote:
> 
> I don't know of any more patches that need to hit the code before we
> ship.

Somebody still needs to come up with a fix for the FlushAllOutput
crashes, right?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital 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