Re: [PATCH util/macros 1/2] Create CHANGELOG/INSTALL_CMD .tmp files in builddir

2017-01-30 Thread Emil Velikov
On 30 January 2017 at 00:28, Peter Hutterer  wrote:
> On Fri, Jan 27, 2017 at 02:32:48PM +, Emil Velikov wrote:
>> On 27 January 2017 at 04:53, Peter Hutterer  wrote:
>> > On Thu, Jan 26, 2017 at 05:53:19PM +, Emil Velikov wrote:
>> >> From: Emil Velikov 
>> >>
>> >> Under normal build rules one should consider srcdir as RO, thus creating
>> >> files in srcdir is going to fail.
>> >>
>> >> This was flagged with a recent work in release.sh
>> >>
>> >> Cc: Peter Hutterer 
>> >> Cc: Gaetan Nadon 
>> >> Signed-off-by: Emil Velikov 
>> >> ---
>> >>  xorg-macros.m4.in | 6 +++---
>> >>  xorgversion.m4| 6 +++---
>> >>  2 files changed, 6 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
>> >> index 2ed7837..675d07d 100644
>> >> --- a/xorg-macros.m4.in
>> >> +++ b/xorg-macros.m4.in
>> >> @@ -1837,9 +1837,9 @@ m4_ifdef([AM_SILENT_RULES], 
>> >> [AM_SILENT_RULES([yes])],
>> >>  AC_DEFUN([XORG_INSTALL], [
>> >>  AC_REQUIRE([PKG_PROG_PKG_CONFIG])
>> >>  macros_datadir=`$PKG_CONFIG --print-errors --variable=pkgdatadir 
>> >> xorg-macros`
>> >> -INSTALL_CMD="(cp -f "$macros_datadir/INSTALL" 
>> >> \$(top_srcdir)/.INSTALL.tmp && \
>> >> -mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \
>> >> -|| (rm -f \$(top_srcdir)/.INSTALL.tmp; touch \$(top_srcdir)/INSTALL; \
>> >> +INSTALL_CMD="(cp -f "$macros_datadir/INSTALL" 
>> >> \$(top_builddir)/.INSTALL.tmp && \
>> >> +mv \$(top_builddir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \
>> >
>> > aren't you still trying to create files in srcdir here? or is there
>> > something outside the context that makes it sufficient to have 
>> > .INSTALL.tmp?
>> >
>> There's a, small, subtle difference in the rules:
>> INSTALL_CMD has an initial condition/command meaning "do we have
>> xorg-macros on the system" while the changelog one "is git around + is
>> foo/.git a git repo".
>
> the only time we care about generating install or changelog is during make
> dist, and that's done in the worktree now and should assume a RO srcdir,
> right?
>
>> For the latter one can reasonably say - yes the command will succeed
>> _only_ on the first iteration of make dist, with any consecutive
>> iterations/build commands (remember it's a .PHONY thus it gets called
>> everytime we do make) will fall-back to the "else" statement.
>
> it's a dependency of dist-hook though, at least in the server. so it'll only
> get called on make dist.
>
>> While the part "mv builddir/foo.tmp srcdir/foo" seems a bit abusive
>> it's the most elegant solution that I can think of. Note the "touch"
>> in the else case is a no-op since the file should already be there.
>> Admittedly we can omit it and error out in the [extremely unlikely]
>> case that file is missing.
>
> I think you're reading too much into this. all I'm suggesting is a
> s/top_srcdir/top_builddir/ here :) which possibly maybe theoretically should
> just work :)
>
It didn't last time I've checked. File will be created in builddir
thus make clean will have to nuke it.
Since the file(s) are meant to be purged only with make
maintainer-clean (as per the Makefile) thus distcheck bails out with
"remaining file..."

It's perfectly possible that I've butchered something, so please give
it a try on your end.

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

Re: [PATCH util/macros 1/2] Create CHANGELOG/INSTALL_CMD .tmp files in builddir

2017-01-30 Thread Emil Velikov
[adding back the xorg-devel ML]

On 28 January 2017 at 18:35, Gaetan Nadon  wrote:
> On 01/27/2017 09:32 AM, Emil Velikov wrote:
>
> aren't you still trying to create files in srcdir here? or is there
> something outside the context that makes it sufficient to have .INSTALL.tmp?
>
> I failed to understand your response to Peter's question.
In that case, I might not have understood his question I'm afraid. Can
anyone elaborate please ?

> Somehow both the
> INSTALL and the ChangeLog files will be missing from the generated tarball.
> Those files were missing or never up-to-date in git, that is why they are
> generated at build time. They are non of the less "source" files which
> always introduce complications in the build process.
>
Fully agree that the files should always be inside the tarball and
they are a bit picky at times.
I think you're getting confused by the icky looking diff - things work
as expected and files are created as applicable.
I've used the recently updated release.sh [1], which does ./autogen.sh
&& make distcheck.

[1] 
https://cgit.freedesktop.org/xorg/util/modular/commit/?id=b5cffea256d8e2832c683a7231b92de126e99158

> It looks like the patch will work business as usual on RW srcdir, but not on
> RO srcdir. I don't recall anyone ever trying this scenario so this is new
> territory.
>
> In any case, from memory, here are some of the scenarios you should test to
> ensure no regressions:
>
> Extract source from a git repository to an empty directory
>
> run autogen.sh
> make all
> make INSTALL before and after removing it
> make CHANGELOG before and after removing it
> make dist
> The tarball should be complete with INSTALL and ChangeLog
>
Regardless of the above (distcheck) I've done the following:

git clone ...libXi && libXi
./autogen.sh && make all - both install and changelog are OK
make INSTALL - file is OK
rm -f INSTALL && make INSTALL - file is OK
make ChangeLog - file is OK
rm -f ChangeLog && make ChangeLog - file is OK
make dist && tar -xaf libXi...gz  - both files are inside and
correctly generated.

> Same as above but with an "out of source dir"
>
git clean -fxd && rm -rf ../bb && mkdir ../bb && cd ../bb

Then I've repeated the above steps. Barring the
s|./autogen.sh|../autogen.sh| everything was identical - from commands
to results.

> Extract the tarball generated above (assuming the content is complete).
> Preferably run from a terminal with no access to git.
>
> do not run autogen (hopefully the autogen.sh file is absent)
> make all
> make dist
> Inspect the generated tarball after make dist.  The initial tarball contains
> all the source so it can generate a new tarball.
> make INSTALL before and after removing it
> make CHANGELOG before and after removing it
>
> All these scenarios represent real life usage. They are very useful to find
> bugs even if they are not related to the scenario itself.
>
Similarly - things still work as expected (used mv git{,-foo} just in case).
Admittedly the error messages are somewhat misleading so [re]wording
suggestions are appreciated.

Note: It's possible that I coffee hasn't kicked in so please point out
if I'm missing something obvious.

> Note: I am no longer on any X list.
Ack, Thanks for taking a look and your previous work in the area.

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

Re: [PATCH v5 xserver 7/6] tests: fix --disable-xorg build

2017-01-30 Thread Mihail Konev
Split and rebased on top of 7617a0a1 version attached.
Fixes build failures occuring when  not  building xfree86 DDX.
Works for XWin ./configure --enable-static=yes
Works for ./configure --disable-xorg
>From 2949b5229dc6557dd12f1b9c12a10b12d7ab97fd Mon Sep 17 00:00:00 2001
From: Mihail Konev 
Date: Mon, 16 Jan 2017 23:55:36 +0500
Subject: [PATCH xserver 1/3] tests: Fix guards for ld -wrap

Commit 23f6dbc96e47be6cbeed78cc9ef303987c3e29a9 moved -wrap out of
HAVE_LD_WRAP, which made the build fail if linker does not support
the flag.

Signed-off-by: Mihail Konev 
---
 test/Makefile.am | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/test/Makefile.am b/test/Makefile.am
index e7fe587bb858..1c1f1da0e31f 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -54,16 +54,6 @@ AM_CPPFLAGS += \
 tests_CPPFLAGS += $(AM_CPPFLAGS)
 endif
 
-tests_LDFLAGS = \
-	-Wl,-wrap,dixLookupWindow \
-	-Wl,-wrap,dixLookupClient \
-	-Wl,-wrap,WriteToClient \
-	-Wl,-wrap,dixLookupWindow \
-	-Wl,-wrap,XISetEventMask \
-	-Wl,-wrap,AddResource \
-	-Wl,-wrap,GrabButton \
-	$()
-
 tests_LDADD =
 
 tests_SOURCES = \
@@ -100,6 +90,16 @@ tests_SOURCES += \
 	xi2/protocol-eventconvert.c \
 	xi2/xi2.c
 
+tests_LDFLAGS = \
+	-Wl,-wrap,dixLookupWindow \
+	-Wl,-wrap,dixLookupClient \
+	-Wl,-wrap,WriteToClient \
+	-Wl,-wrap,dixLookupWindow \
+	-Wl,-wrap,XISetEventMask \
+	-Wl,-wrap,AddResource \
+	-Wl,-wrap,GrabButton \
+	$()
+
 else !HAVE_LD_WRAP
 
 # Print that xi1-tests were skipped (exit code 77 for automake test harness)
-- 
2.9.2


>From 38ea941be10a59565c89e4f312ffcf3d63e4a02c Mon Sep 17 00:00:00 2001
From: Mihail Konev 
Date: Tue, 17 Jan 2017 00:11:03 +0500
Subject: [PATCH xserver 2/3] tests: Fix guards for xfree86 tests

Commit ead5064581665ff40c177dd1b447949f1420e209 missed that most of
tests were xfre86 DDX only, making them being unconditional.

Signed-off-by: Mihail Konev 
---
 test/Makefile.am | 41 +++--
 test/tests.c | 17 ++---
 2 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/test/Makefile.am b/test/Makefile.am
index 1c1f1da0e31f..e72bfe19bede 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -6,14 +6,11 @@ AM_CPPFLAGS = $(XORG_INCS)
 tests_CPPFLAGS=
 CLEANFILES=
 
-if XORG
-# Tests that require at least some DDX functions in order to fully link
-# For now, requires xf86 ddx, could be adjusted to use another
-if RES
-RES_SRCS = hashtabletest.c
-AM_CPPFLAGS += -DRES_TESTS
-endif
-endif
+tests_SOURCES = \
+tests-common.c \
+list.c \
+string.c \
+tests.c
 
 noinst_PROGRAMS = simple-xinit tests
 
@@ -41,7 +38,13 @@ TESTS_ENVIRONMENT = \
 	$(XORG_MALLOC_DEBUG_ENV) \
 	$(NULL)
 
+tests_LDADD =
+
 if XORG
+
+# Tests that require at least some DDX functions in order to fully link
+# For now, requires xf86 ddx, could be adjusted to use another
+
 AM_CPPFLAGS += \
 	-I$(srcdir)/xi1 \
 	-I$(srcdir)/xi2 \
@@ -52,29 +55,30 @@ AM_CPPFLAGS += \
 	-I$(top_srcdir)/hw/xfree86/ramdac -I$(top_srcdir)/hw/xfree86/dri \
 	-I$(top_srcdir)/hw/xfree86/dri2 -I$(top_srcdir)/dri3
 tests_CPPFLAGS += $(AM_CPPFLAGS)
-endif
-
-tests_LDADD =
 
-tests_SOURCES = \
-tests-common.c \
+tests_SOURCES += \
 fixes.c \
 input.c \
-list.c \
 misc.c \
 signal-logging.c \
-string.c \
 touch.c \
 xfree86.c \
 test_xkb.c \
-xtest.c \
-$(RES_SRCS) \
-tests.c
+xtest.c
+tests_CPPFLAGS += -DXORG_TESTS
+
+if RES
+tests_SOURCES += hashtabletest.c
+tests_CPPFLAGS += -DRES_TESTS
+endif
+
+endif XORG
 
 if HAVE_LD_WRAP
 
 tests_CPPFLAGS += -DLDWRAP_TESTS
 
+if XORG
 tests_SOURCES += \
 	xi1/protocol-xchangedevicecontrol.c \
 	xi2/protocol-common.c \
@@ -99,6 +103,7 @@ tests_LDFLAGS = \
 	-Wl,-wrap,AddResource \
 	-Wl,-wrap,GrabButton \
 	$()
+endif XORG
 
 else !HAVE_LD_WRAP
 
diff --git a/test/tests.c b/test/tests.c
index add51bd4834d..97603822abaf 100644
--- a/test/tests.c
+++ b/test/tests.c
@@ -5,22 +5,23 @@
 int
 main(int argc, char **argv)
 {
-run_test(fixes_test);
-
-#ifdef RES_TESTS
-run_test(hashtabletest_test);
-#endif
+run_test(list_test);
+run_test(string_test);
 
+#ifdef XORG_TESTS
+run_test(fixes_test);
 run_test(input_test);
-run_test(list_test);
 run_test(misc_test);
 run_test(signal_logging_test);
-run_test(string_test);
 run_test(touch_test);
 run_test(xfree86_test);
 run_test(xkb_test);
 run_test(xtest_test);
 
+#ifdef RES_TESTS
+run_test(hashtabletest_test);
+#endif
+
 #ifdef LDWRAP_TESTS
 run_test(protocol_xchangedevicecontrol_test);
 
@@ -37,5 +38,7 @@ main(int argc, char **argv)
 run_test(xi2_test);
 #endif
 
+#endif /* XORG_TESTS */
+
 return 0;
 }
-- 
2.9.2


>From 50a6371d3140685f8b22a23d40387f25bc57ab29 Mon Sep 17 00:00:00 2001
From: Mihail Konev 
Date: Tue, 17 Jan 2017 

Re: [PATCH util/macros 1/2] Create CHANGELOG/INSTALL_CMD .tmp files in builddir

2017-01-30 Thread Emil Velikov
Hi Gaetan,

Thanks for the extensive answer. I hope with my replies below things
should be much clearer.

On 30 January 2017 at 15:18, Gaetan Nadon  wrote:

> I no longer have a development environment so I cannot try anything.
>
> Maybe I missed the core idea of the patches. The srcdir is read only,
> correct?
>
s/is read-only/is read-only outside of the initial make dist/

To elaborate a bit - afaict make distcheck does the following
 - initial make dist
 - extract tarball, and run make all, make check, make dist (I'll
refer to this secondary one) et al.

> Unless I remember it incorrectly, the INSTALL and ChangeLog files are
> generated in the srcdir as they would normally be checked-in in git.
> Automake expects them to be there. It is the Xorg project who decided to
> generate them, not Automake. This situation is not "normal" to begin with.
>
Agreed.

> I assume you tried to build a git repo (AKA module) with the source code
> sitting on a read-only filesystem. Correct?
>
Not quite - I've reworked (simplified?) release.sh which pointed out
the (ab)use here.

> What are the reported failures?  Did the build stop because an O/S error? Or
> was it just that both files did not get generated.
>
In a gist "make distcheck failed" - upon the second `make dist' there
was an IO error.


Note: the INSTALL case is extra picky, so let's assume that all cases
below are dealing with ChangeLog.

> Currently: the INSTALL_CMD copies the INSTALL file from the datadir to
> top_srcdir/.INSTALL.tmp which is RO. That should fail on a RO filesystem,
> correct? IS that the problem you are trying to solve?
>
Precisely.

> Proposed patch: the INSTALL_CMD copies the INSTALL file from the datadir to
> top_builddir/.INSTALL.tmp/ which is RW.  That should work. A .INSTALL.tmp
> file now sits among the object code created by the compiler.
>
Correct.

> Next the top_builddir/.INSTALL.tmp is moved to the top_srcdir/INSTALL on a
> filesystem which is RO. That should equally fail, correct?
>
> I am assuming that if one cannot copy a file onto a RO filesystem, then one
> cannot move a file in there as well. Correct?
>
This part will succeed during the initial "make dist". The secondary
one has srcdir as RO so we'll end up in the "else" statement - rm
.FOO.tmp; touch FOO.

Note that if we reach the "else", we're
a) RO/RW file system and the file is present - touch is a
no-op/succeeds, respectively or
b) RW file system and the file is missing (building from a tarball and
manually removed the file) - touch will create a dummy one.

> On another topic, any change in the macros affect all modules (or git repos)
> in the X project. Extensive testing is required. The fix must also be
> backwards compatible with existing tarballs floating in the field.To get
> started quickly, try a few modules that have generated code and
> documentation. These are good test cases. As I remember it, all modules
> listed in build.sh built successfully with make dist.
>
I might be overly confident, but barring crazy hacks elsewhere things
should work across the board.
Then again, I was expecting xorg-macros to be missing blatant bugs so
I'm updating the script and pulling $world just in case.

Related questions:
Do you know of a script/semi-automated way to create a modfile to feed
into release.sh ?
I'm likely blind, but it seems that build.sh does not have an option
to only pull/clone the repos, without building, does it ? I would be
nice to do so and use release.sh which already does enough build/etc.
checking/testing.

Looking at build.sh I ended up adding 90 missing repos with fonts,
uitils, docs, others still to check/add. Not sure if/how much are
supposed to be legacy/deprecated but we shall see - if the newly added
ones start failing I'll just pull them out.

> A more general question, would a module generating source using lex and yacc
> would build on a RO filesystem?
>
> The requirement here is that the generated code requires lex and yacc
> programs to generate some C code when the repo is "configured" (autogen.sh).
> That generated code is then shipped in a tarball where the tarball builder
> only compiles the C generated code without the need to have the lex and yacc
> programs installed. A tarball builder may not run autogen.sh as this is a
> module configuration step and not a build step.
>
IMHO [definitely _not_ an expert wrt generated files] these ought to
be handled like INSTALL/ChangeLog - generate once at initial [non RO]
make dist, etc. Such that building from tarball is OK, even if one
does make clean.

Tl;Dr; Fully agree.


IIRC in mesa we generate those files in builddir and think that we
purge them in make clean stage.
It's been on my list of things to check/fix but other distractions
keep on coming up ;-)


> If your organization has a build strategy to use shared shared RO
> filesystems, this may not work for some modules. I had never seen this tried
> before. The INSTALL and ChangeLog files are not the only 

[PATCH] xinit: check for correct fork error code

2017-01-30 Thread Tobias Stoeckmann
Even though this code is only active on __sun machines, the fork return
value should be checked for -1, not 1, to detect an error situation.
---
 xinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xinit.c b/xinit.c
index 1b04911..f826b7a 100644
--- a/xinit.c
+++ b/xinit.c
@@ -638,7 +638,7 @@ shutdown(void)
 Fatal("Unable to run program \"%s\"", "kbd_mode");
 break;
 
-case 1:
+case -1:
 Error("fork failed");
 break;
 
-- 
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: [PATCH util/macros 1/2] Create CHANGELOG/INSTALL_CMD .tmp files in builddir

2017-01-30 Thread Peter Hutterer
On Mon, Jan 30, 2017 at 07:09:32PM +, Emil Velikov wrote:
> Related questions:
> Do you know of a script/semi-automated way to create a modfile to feed
> into release.sh ?
> I'm likely blind, but it seems that build.sh does not have an option
> to only pull/clone the repos, without building, does it ? I would be
> nice to do so and use release.sh which already does enough build/etc.
> checking/testing.
> 
> Looking at build.sh I ended up adding 90 missing repos with fonts,
> uitils, docs, others still to check/add. Not sure if/how much are
> supposed to be legacy/deprecated but we shall see - if the newly added
> ones start failing I'll just pull them out.

build.sh -L should list all repos but yeah, there is no option to just clone
all of them short of adding a return in process(). I'd happily merge a patch
for that though because by sheer coincidence I needed it last week ;)

I'd say any modules missing from build.sh should be either abandoned or
added to build.sh, depending on the repository state.

Cheers,
   Peter
___
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] xinit: check for correct fork error code

2017-01-30 Thread Peter Hutterer
On Mon, Jan 30, 2017 at 09:35:37PM +0100, Tobias Stoeckmann wrote:
> Even though this code is only active on __sun machines, the fork return
> value should be checked for -1, not 1, to detect an error situation.

   710ea2c..2effad4  master -> master

thanks

Cheers,
   Peter

> ---
>  xinit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xinit.c b/xinit.c
> index 1b04911..f826b7a 100644
> --- a/xinit.c
> +++ b/xinit.c
> @@ -638,7 +638,7 @@ shutdown(void)
>  Fatal("Unable to run program \"%s\"", "kbd_mode");
>  break;
>  
> -case 1:
> +case -1:
>  Error("fork failed");
>  break;
>  
> -- 
> 2.11.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xinit: check for correct fork error code

2017-01-30 Thread Alan Coopersmith

On 01/30/17 12:35 PM, Tobias Stoeckmann wrote:

Even though this code is only active on __sun machines, the fork return
value should be checked for -1, not 1, to detect an error situation.
---
 xinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xinit.c b/xinit.c
index 1b04911..f826b7a 100644
--- a/xinit.c
+++ b/xinit.c
@@ -638,7 +638,7 @@ shutdown(void)
 Fatal("Unable to run program \"%s\"", "kbd_mode");
 break;

-case 1:
+case -1:
 Error("fork failed");
 break;


Oops!  Thanks for finding & fixing this mistake in the patch I applied out
of our downstream branch, and thanks to whot for pushing it already.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://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 xserver] present: disable page flip only when a slave crtc is active

2017-01-30 Thread Michel Dänzer
On 26/01/17 07:13 PM, Qiang Yu wrote:
> 
> @@ -145,7 +157,7 @@ present_check_flip(RRCrtcPtrcrtc,
>  return FALSE;
>  
>  /* Fail to flip if we have slave outputs */
> -if (screen->output_slaves)
> +if (screen->output_slaves && present_check_output_slaves_active(screen))
>  return FALSE;
>  
>  /* Make sure the window hasn't been redirected with Composite */
> 

Actually, I'm not sure why we need to check for slave outputs here at
all. Dave, did you run into an actual problem without the check, or was
it just a theoretical concern? The commit log says:

   We shouldn't flip if the secondary adapters are attached to the
   pixmap currently [...]

What circumstances were you thinking of where a slave output would be
attached to (meaning scanning out directly from?) "the pixmap" (which one?)?


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

2017-01-30 Thread The Rasterman
On Sun, 29 Jan 2017 23:34:08 -0700 SRC SRC  said:

> Hi,
> 
> I was able to successfully create a translucent window using xlib and then
> set the transparency using the XRender extension, and make the window have
> rounded corners with the Xshape extension and the following code:
> 
> void rectAttributes(XRectangle *rect ,int width, int height, int x, int y) {
>   rect->height = height;
>   rect->width = width;
>   rect->x=x;
>   rect->y=y;
> }
> 
> void createRoundedEdges(int radius, Display *display, Window window) {
>   XWindowAttributes attr;
>   XGetWindowAttributes(display,window, );
>   int windowHeight = attr.height,
>   windowWidth = attr.width,
>   cornerCoordinates[radius],
>   x_bar = windowWidth - radius;
>   XRectangle rect[(radius*4)]; //*4 because of 4 corners
>   /* Populate the firstCorner array */
>   for (int i=radius; i!=0; i--) {
> int y = i,
> x = sqrt((radius*radius)-(y*y));
> cornerCoordinates[radius-i] = x;
>   }
>   for (int i=0,j=radius,k=2*j,l=3*j;i rectAttributes([i],windowWidth,1,x_bar+cornerCoordinates
> [i],i); //top-right rectAttributes([j],windowWidth,1,x_bar
> +cornerCoordinates[(2*radius)-1-j] //bottom-right ,windowHeight-(2*radius)+j);
> rectAttributes([k],windowWidth,1,radius-windowWidth-cornerCoordinates
> [i],i); //top-left rectAttributes([l],windowWidth,1,rect
> [k].x,windowHeight-1-i); //bottom-left }
>   int sizeOfArray = sizeof(rect)/sizeof(rect[0]);
>   XShapeCombineRectangles
> (display,window,0,0,0,rect,sizeOfArray,ShapeSubtract,0); }
> 
> This is what the above code generates:
> 
> If you look closely at the rounded corners, they seem to be not smooth but
> rather jagged, and to make those corners smooth I’d have to do ant-aliasing
> on the window. I could do that in two ways, one is by writing the
> anti-aliasing algorithm and placing pixels with differing alpha values along
> the edges using Xrender, or by finding an extension that does the
> anti-aliasing on the window. So, I was wondering if you could point me to an
> anti-aliasing extension that I can use to make the corners smooth mostly
> because I really don’t want to spend the time writing an antialiasing
> algorithm from scratch if an extension already exists that does just that.

well first... the shape extension is not going to help you at all. it's
boolean. server-side it boils down to a list of rectangles your window occupies
(visibly and event-wise). this is by nature either "inside or outside" your
window on a pixel basis and thus you'll get jaggies.

that's why you have an argb window... you can draw rounded corners with alpha
channels. but you still need a compositor to composite them together... and you
say you cannot have one by definition. the shape extension works without a
wm/compositor as its the server literally clipping your window to this
rectangle set. 

your choices are:

1. hand write pixels yourself one at a time with xrender.
2. save time and just use cairo to draw a rect with rounded corners 
3. pre-draw the rounded corners as images and have a library render them for
you after turning them into a pixmap (xrender, cairo, imlib2 - based on your
previous mail can do that too).

you really want to just start using other libraries to do this work for you and
get yourself a compositor/wm. unless you  have studied/learned enough about x11
to do it all yourself of course... in which case you wouldn't be asking
here. :)

that *IS* what libraries are for. to encapsulate such knowledge and save you
the pain. of course if you wish to learn... you are likely wagging the dog by
it's tail with where you are starting from...  (based on your previous
stackoverflow post) and doing things by pretty much poking in the dark. you are
better off going FROM a higher level working environment TO a simpler one and
learning pieces of the puzzle along the way rather than building up from nil.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
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