Re: Another protocol repository merge attempt

[Keith Packard]

Alan Coopersmith  writes:

> Honestly, I think the versions of Java I've used for generating the docs
> just uses fontconfig to find local fonts, but we do ship with a bunch of
> commercially licensed fonts from way back when that should be automatically
> added to those paths.

I'm not surprised that Oracle has AWT configured right; just frustrated
that Debian does not.

The documents specify fonts that I have installed (deja vu), so I'm
reasonably sure it's a local configuration problem. Note that I couldn't
make docbook work in another context either, and resorted to copying the
desired fonts alongside the document and hand-configuring docbook to
find them.

Given that the fonts we specify have free licenses; is there any problem
with just including them in the repo? That would avoid all font issues
when building the docs.

-- 
-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: Another protocol repository merge attempt

[Alan Coopersmith]

On 12/14/17 04:21 PM, Keith Packard wrote:

Of course, bugs in the fonts will involve copying new versions into our
repo. I don't have a great solution here. I do suspect the Oracle has
their AWT configured to find local fonts so that the docbook toolchain
works, but that isn't true for me, and relies on having the right fonts
on the build system anyways.


Honestly, I think the versions of Java I've used for generating the docs
just uses fontconfig to find local fonts, but we do ship with a bunch of
commercially licensed fonts from way back when that should be automatically
added to those paths.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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 util/macros] Drop -fno-strict-aliasing from XORG_CWARNFLAGS

[Peter Harris]

On 2017-12-14 11:35 AM, Michel Dänzer wrote:
> I don't think compilers can reliably warn about all strict aliasing
> violations yet (ever?).
> 
> Is this really worth the risk? Do you have any numbers showing tangible
> benefits of this change?

The main benefit is in code cleanliness, not necessarily performance.

The risk if we don't make this change is to those of us with non-gcc
compilers (that don't have -fno-strict-aliasing or an equivalent as an
option). Replacing -fno-strict-aliasing with -Werror=strict-aliasing is
a step in the right direction.

Peter Harris
-- 
   Open Text Connectivity Solutions Group
Peter Harrishttp://connectivity.opentext.com/
Research and DevelopmentPhone: +1 905 762 6001
phar...@opentext.comToll Free: 1 877 359 4866
___
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: Another protocol repository merge attempt

[Keith Packard]

Eric Anholt  writes:

> I like that it's just commits and merges instead of filter-branch.

Yeah, it makes the history really easy to see, and (if we don't move
files), the per-file history easy to track.

> I think it would make more sense if the headers matched the structure they
> are installed into, but that could be a thing we could move later.

That's a good idea. Having the source reflect the installed tree would
be nice.

> Similarly, the Makefile.am is gross, but if it's autogenerated then it's
> also pretty believable and easy to fix up by hand later.

Yes, it's entirely autogenerated with a script (which is in the
repo). I'd suggest cleaning it up as we move files around later on.

One question I have remaining is what to do with the specs -- having
them all mashed into the 'specs' directory is pretty ugly. I guess we
can clean that up in the same manner as cleaning up the header file
locations?

Oh -- I can't build any of the specs correctly; none of the fonts are
selected right. I've fixed that in other projects by actually shipping
the fonts as a part of the documentation source and referencing them
directly from the fop configuration file. This seems kinda messy, but it
results in reliably built documentation, which is something of a
feature.

Of course, bugs in the fonts will involve copying new versions into our
repo. I don't have a great solution here. I do suspect the Oracle has
their AWT configured to find local fonts so that the docbook toolchain
works, but that isn't true for me, and relies on having the right fonts
on the build system anyways.

-- 
-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 2/2] glx: Enable GLX_ARB_create_context_no_error

[Eric Anholt]

Adam Jackson  writes:

> This is mostly for the client library's convenience, if this extension
> is listed then it can know the attribute won't be rejected. Note that we
> don't _do_ anything with this attribute, meaning indirect contexts will
> not be no-error. That's fine, we don't want to introduce undefined
> behavior into a potentially privileged process anyway.

I agree, but don't we need to accept GLX_CONTEXT_OPENGL_NO_ERROR_ARB and
drop it on the floor instead of falling through to createcontext.c's:

default:
if (!req->isDirect)
return BadValue;
break;


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 1/2] glx: Stop printing messages about what GLX extensions we enable

[Eric Anholt]

Adam Jackson  writes:

> glxinfo already exists, use it.

Yes, please.

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: Another protocol repository merge attempt

[Eric Anholt]

Keith Packard  writes:

> [ Unknown signature status ]
>
> The idea of merging all of our X protocol repositories came up again,
> and Adam Jackson asked if I wanted to wait for this before merging my
> randr lease/non-desktop changes.
>
> Not really? But, I'm still interested in a merge of the protocol
> repositories; we've got way too many, and they're mostly tiny.
>
> Ok, so I gave another run at this, with a slightly different goal. I
> want to avoid renaming files as that makes history tracking a bit harder
> to manage. So, what I did was find all of the filenames which are
> duplicated between repositories. It's a short list:
>
> .gitignore
> AUTHORS
> autogen.sh
> configure.ac
> COPYING
> docbook.am
> Makefile.am
> README
> specs/Makefile.am
> specs/.gitignore
>
> Then I generated some scripts that would merge in a repo, move the
> (potentially) conflicting files to a directory named after the source
> repo and commit that move.
>
> Another script to merge the Makefile.am contents and I've got a
> repository which installs all of the header files at least. It doesn't
> build the docs for anything, and in fact all of the docs are mashed into
> a 'specs' sub-directory
>
> I don't know if this is more or less useful than the earlier plan which
> placed each extension in a sub-directory; I'm good either way, I just
> want to finish this up and get back to more interesting work.
>
> Take a look and let me know what you think.
>
> git clone git://people.freedesktop.org/~keithp/mergeproto
>
> This was less than an hours work; if the consensus is 'yuck', you won't
> hurt my feelings at all.

I like that it's just commits and merges instead of filter-branch.  I
think it would make more sense if the headers matched the structure they
are installed into, but that could be a thing we could move later.
Similarly, the Makefile.am is gross, but if it's autogenerated then it's
also pretty believable and easy to fix up by hand later.


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] glx: do not pick sRGB config for 32-bit RGBA visual

[Adam Jackson]

On Mon, 2017-12-11 at 07:53 +0200, Tapani Pälli wrote:
> Hi;
> 
> Any comments? Without this change there will be issues with certain 
> Linux desktops when distributions start to use Mesa 17.4.

Merged, thanks:

remote: I: patch #190632 updated using rev 
c2954b16c8730c7ed8441fd8dba25900f3aed265.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   cf7517675d..c2954b16c8  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] composite: Propagate damagedDescendants when reparented

[Peter Harris]

If a window that is fully covered by an automatic-redirected descendant
(even implicitly, eg. via BackingStores) is reparented, the automatic
updates could be broken if the new parent is not marked as having
damaged descendants.

Fix this issue by propagating the damagedDescendants flag whenever a
window is reparented.

Signed-off-by: Peter Harris 
---
 composite/compalloc.c  | 21 +
 composite/compint.h|  2 ++
 composite/compwindow.c |  5 +
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 05ffc7e85..433dc820a 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -67,6 +67,18 @@ compBlockHandler(ScreenPtr pScreen, void *pTimeout)
 cs->BlockHandler = NULL;
 }
 
+void
+compMarkAncestors(WindowPtr pWin)
+{
+pWin = pWin->parent;
+while (pWin) {
+if (pWin->damagedDescendants)
+return;
+pWin->damagedDescendants = TRUE;
+pWin = pWin->parent;
+}
+}
+
 static void
 compReportDamage(DamagePtr pDamage, RegionPtr pRegion, void *closure)
 {
@@ -81,14 +93,7 @@ compReportDamage(DamagePtr pDamage, RegionPtr pRegion, void 
*closure)
 }
 cw->damaged = TRUE;
 
-/* Mark the ancestors */
-pWin = pWin->parent;
-while (pWin) {
-if (pWin->damagedDescendants)
-break;
-pWin->damagedDescendants = TRUE;
-pWin = pWin->parent;
-}
+compMarkAncestors(pWin);
 }
 
 static void
diff --git a/composite/compint.h b/composite/compint.h
index f05c2d8a5..89f6507b9 100644
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -236,6 +236,8 @@ Bool
 compReallocPixmap(WindowPtr pWin, int x, int y,
   unsigned int w, unsigned int h, int bw);
 
+void compMarkAncestors(WindowPtr pWin);
+
 /*
  * compinit.c
  */
diff --git a/composite/compwindow.c b/composite/compwindow.c
index f88238146..e74ce661a 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -432,6 +432,7 @@ compReparentWindow(WindowPtr pWin, WindowPtr pPriorParent)
 {
 ScreenPtr pScreen = pWin->drawable.pScreen;
 CompScreenPtr cs = GetCompScreen(pScreen);
+CompWindowPtr cw = GetCompWindow(pWin);
 
 pScreen->ReparentWindow = cs->ReparentWindow;
 /*
@@ -469,6 +470,10 @@ compReparentWindow(WindowPtr pWin, WindowPtr pPriorParent)
 (*pScreen->ReparentWindow) (pWin, pPriorParent);
 cs->ReparentWindow = pScreen->ReparentWindow;
 pScreen->ReparentWindow = compReparentWindow;
+
+if (pWin->damagedDescendants || (cw && cw->damaged))
+compMarkAncestors(pWin);
+
 compCheckTree(pWin->drawable.pScreen);
 }
 
-- 
2.14.1

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

Re: [PATCH util/macros] Drop -fno-strict-aliasing from XORG_CWARNFLAGS

[Michel Dänzer]

On 2017-12-13 08:47 PM, Adam Jackson wrote:
> On Wed, 2017-12-13 at 11:31 -0800, Keith Packard wrote:
>> Adam Jackson  writes:
>>
>>> This has been "deprecated" since 2011, but because it is still
>>> referenced from XORG_DEFAULT_OPTIONS nothing has ever been updated to
>>> get strict aliasing right. Let's fix that.
>>
>> I don't understand this -- are you getting rid of this option from our
>> compiles or not?
> 
> I mean, the lines in the diff start with "-".  "Let's fix that" here
> means "let's build normally and see what falls out".
> 
>> I can assure you that our code is unlikely to work with
>> out it.
> 
> xserver still passes make check when built without it. Well, the meson
> build does anyway, I haven't gotten around to trying it with the
> autotools build yet, nor adding -Werror=strict-aliasing and rebuilding
> the world, but that would obviously be prerequisite for releasing a
> version of util-macros with this change in it.

I don't think compilers can reliably warn about all strict aliasing
violations yet (ever?).

Is this really worth the risk? Do you have any numbers showing tangible
benefits of this change?


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