Re: [PATCH inputproto] specs: Set TZ=UTC before calling asciidoc

[Peter Hutterer]

On Thu, Mar 31, 2016 at 03:00:16PM +0200, Andreas Boll wrote:
> 2016-03-30 6:26 GMT+02:00 Peter Hutterer :
> > On Fri, Dec 11, 2015 at 10:49:33AM +0100, Andreas Boll wrote:
> >> Set TZ=UTC before calling asciidoc to make the embedded dates invariant
> >> to timezones in order to make the package build reproducibly.
> >
> > quick check shows that the date embedded includes a timestamp with seconds
> > granularity. So unless your build system forces the exact same time for
> > every build, the result is still not reproducible. And if the build system
> > forces the time, why can't it force the timezone too?
> >
> > what am I missing here?
> >
> > Cheers,
> >Peter
> 
> From [1] "The date is based in the last modified date of the source
> file, but is sensible to the timezone."
> 
> In this case the source files are specs/XI2proto.txt and specs/XIproto.txt.
> So the timestamps in the generated html files depend only on the build
> system's timezone which could be overridden via TZ=UTC.

ah, ok, that makes sense then. Verified here, repeated makes don't update
the timestamp.

   7c7c2c1..1dbdc29  master -> master

thanks

Cheers,
   Peter

> 
> An alternate solution which could remove the timestamp from the
> generated html file has been proposed to asciidoc but unfortunately
> upstream hasn't merged that patch so far [2].
> 
> Thanks,
> Andreas
> 
> [1] 
> https://wiki.debian.org/ReproducibleBuilds/TimestampsInDocumentationGeneratedByAsciidoc
> [2] https://github.com/asciidoc/asciidoc/pull/9
> 
> 
> >>
> >> Fixes bug:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795981
> >>
> >> v2: Set TZ=UTC after $(AM_V_GEN) (fixes non-verbose build)
> >>
> >> Suggested-by: Eduard Sanou 
> >> Signed-off-by: Andreas Boll 
> >> ---
> >>  specs/Makefile.am | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/specs/Makefile.am b/specs/Makefile.am
> >> index a83cf40..f2454bc 100644
> >> --- a/specs/Makefile.am
> >> +++ b/specs/Makefile.am
> >> @@ -6,7 +6,7 @@ doc_DATA = XI2proto.html XIproto.html
> >>  dist_doc_DATA = XI2proto.txt XIproto.txt
> >>
> >>  %.html: %.txt
> >> - $(AM_V_GEN)$(ASCIIDOC) -o $@ $<
> >> + $(AM_V_GEN)TZ=UTC $(ASCIIDOC) -o $@ $<
> >>
> >>  CLEANFILES = $(doc_DATA)
> >>
> >> --
> >> 2.1.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: ARMSOC X11 plugin issues

[Jasper St. Pierre]

ARMSOC isn't a well-written driver, basically. Is there a reason
you're not using modesetting if it works better for you?

On Thu, Mar 31, 2016 at 1:54 AM, Maxime Ripard
 wrote:
> On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
>> Hi David, Marico,
>>
>> I've been developping a DRM/KMS driver for the Allwinner SoCs[1], with
>> an additional patch to allocate GPU buffers [2]. Since those SoCs also use
>> a Mali GPU, using the armsoc X11 plugin seemed like a logical choice.
>>
>> I added support for the driver based on the 1.4 plugin [3], and
>> started using it, which turned out pretty well, we get something
>> displayed, GLES works, good.
>>
>> However, after testing it for a while, the first thing we noticed was
>> that some (large) buffer allocations would start to fail. Indeed, the
>> plugin seems to do a lot of rather small (and for most temporary ?)
>> buffer allocations, which eventually depletes the reserved memory
>> pool. The allocation then fails, and the application crashes.
>>
>> Then, we noticed (using xfce4, on debian jessie) that the systray
>> icons were not displayed for some reason. There's also some game
>> (alex4 [4]), that starts, runs, but the window content remains black
>> (but it remains interactive, audio plays and if we take a screenshot,
>> the content is on the image, but the screen remains black).
>>
>> The weird thing about it is that when using the X generic modesetting
>> plugin, everything starts to work. It seems to be allocating only one
>> buffer per plane, so we never have the memory allocation
>> failures. Which raises my first question: why is the armsoc plugin
>> behaving differently there?
>>
>> Then the graphics issues we were seeing are not there anymore, which
>> seems to indicate that it's related to the plugin. I'm a bit oblivious
>> to how X works exactly, and how applications interacts with it, but on
>> the ioctl side, nothing really stands out. Let me know if you need any
>> more tests or logs or anything.
>
> Anyone ?
>
> Thanks,
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.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



-- 
  Jasper
___
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: ARMSOC X11 plugin issues

[Maxime Ripard]

On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
> Hi David, Marico,
> 
> I've been developping a DRM/KMS driver for the Allwinner SoCs[1], with
> an additional patch to allocate GPU buffers [2]. Since those SoCs also use
> a Mali GPU, using the armsoc X11 plugin seemed like a logical choice.
> 
> I added support for the driver based on the 1.4 plugin [3], and
> started using it, which turned out pretty well, we get something
> displayed, GLES works, good.
> 
> However, after testing it for a while, the first thing we noticed was
> that some (large) buffer allocations would start to fail. Indeed, the
> plugin seems to do a lot of rather small (and for most temporary ?)
> buffer allocations, which eventually depletes the reserved memory
> pool. The allocation then fails, and the application crashes.
> 
> Then, we noticed (using xfce4, on debian jessie) that the systray
> icons were not displayed for some reason. There's also some game
> (alex4 [4]), that starts, runs, but the window content remains black
> (but it remains interactive, audio plays and if we take a screenshot,
> the content is on the image, but the screen remains black).
> 
> The weird thing about it is that when using the X generic modesetting
> plugin, everything starts to work. It seems to be allocating only one
> buffer per plane, so we never have the memory allocation
> failures. Which raises my first question: why is the armsoc plugin
> behaving differently there?
> 
> Then the graphics issues we were seeing are not there anymore, which
> seems to indicate that it's related to the plugin. I'm a bit oblivious
> to how X works exactly, and how applications interacts with it, but on
> the ioctl side, nothing really stands out. Let me know if you need any
> more tests or logs or anything.

Anyone ?

Thanks,
Maxime



-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

[PATCH libX11 0/4] various fixes

[walter harms]

hi list,

This fixes a bunch of bugs inside libX11. I did some experiments with smatch
https://blogs.oracle.com/linuxkernel/entry/smatch_static_analysis_tool_overview
It found some more but all of them are fixed easily.
These patches will not change the function of the current code

In case of problems you can find all patched here also: 
https://github.com/xtforever/libX11/tree/master/src

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 libX11 4/4] fix shadow char_size

[walter harms]

Signed-off-by: walter harms 
---
fix shadow warning by renaming the var


---
 src/xlibi18n/lcCT.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/xlibi18n/lcCT.c b/src/xlibi18n/lcCT.c
index b161300..1f413e9 100644
--- a/src/xlibi18n/lcCT.c
+++ b/src/xlibi18n/lcCT.c
@@ -1021,19 +1021,19 @@ cstoct(
) {
 while (csstr_len > 0 && ct_len > 0) {
 unsigned char ch = * (const unsigned char *) csptr;
-int char_size = (ch < 0xc0 ? 1 :
+int ch_size = (ch < 0xc0 ? 1 :
  ch < 0xe0 ? 2 :
  ch < 0xf0 ? 3 :
  ch < 0xf8 ? 4 :
  ch < 0xfc ? 5 :
  6);
 int i;
-if (!(csstr_len >= char_size && ct_len >= char_size))
+if (!(csstr_len >= ch_size && ct_len >= ch_size))
 break;
-for (i = char_size; i > 0; i--)
+for (i = ch_size; i > 0; i--)
 *ctptr++ = *csptr++;
-csstr_len -= char_size;
-ct_len -= char_size;
+csstr_len -= ch_size;
+ct_len -= ch_size;
 }
 } else {
 while (csstr_len > 0 && ct_len > 0) {
-- 
2.1.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

[PATCH libX11 3/4] remove argument check for free() adjust one inden

[walter harms]

Signed-off-by: walter harms 
---
there is no need to check the argument for free()

---
 modules/im/ximcp/imDefIc.c | 57 +++---
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/modules/im/ximcp/imDefIc.c b/modules/im/ximcp/imDefIc.c
index 143bd59..7564dba 100644
--- a/modules/im/ximcp/imDefIc.c
+++ b/modules/im/ximcp/imDefIc.c
@@ -231,10 +231,9 @@ _XimReCreateIC(ic)

 _XimRegisterFilter(ic);
 MARK_IC_CONNECTED(ic);
-if (save_ic->private.proto.ic_resources)
-   Xfree(save_ic->private.proto.ic_resources);
-if (save_ic->private.proto.ic_inner_resources)
-   Xfree(save_ic->private.proto.ic_inner_resources);
+
+Xfree(save_ic->private.proto.ic_resources);
+Xfree(save_ic->private.proto.ic_inner_resources);
 Xfree(save_ic);
 return True;

@@ -833,7 +832,7 @@ _XimDestroyICCheck(
  && (imid == im->private.proto.imid)
  && (buf_s[2] & XIM_ICID_VALID)
  && (icid == ic->private.proto.icid))
-ret = False;
+ret = False;
 return ret;
 }

@@ -845,22 +844,22 @@ _XimProtoICFree(
 Xim im = (Xim)ic->core.im;
 #endif

-if (ic->private.proto.preedit_font) {
-   Xfree(ic->private.proto.preedit_font);
-   ic->private.proto.preedit_font = NULL;
-}
-if (ic->private.proto.status_font) {
-   Xfree(ic->private.proto.status_font);
-   ic->private.proto.status_font = NULL;
-}
+
+Xfree(ic->private.proto.preedit_font);
+ic->private.proto.preedit_font = NULL;
+
+
+Xfree(ic->private.proto.status_font);
+ic->private.proto.status_font = NULL;
+
 if (ic->private.proto.commit_info) {
_XimFreeCommitInfo(ic);
ic->private.proto.commit_info = NULL;
 }
-if (ic->private.proto.ic_inner_resources) {
-   Xfree(ic->private.proto.ic_inner_resources);
-   ic->private.proto.ic_inner_resources = NULL;
-}
+
+Xfree(ic->private.proto.ic_inner_resources);
+ic->private.proto.ic_inner_resources = NULL;
+

 #ifdef XIM_CONNECTABLE
 if (IS_SERVER_CONNECTED(im) && IS_RECONNECTABLE(im)) {
@@ -868,18 +867,18 @@ _XimProtoICFree(
 }
 #endif /* XIM_CONNECTABLE */

-if (ic->private.proto.saved_icvalues) {
-   Xfree(ic->private.proto.saved_icvalues);
-   ic->private.proto.saved_icvalues = NULL;
-}
-if (ic->private.proto.ic_resources) {
-   Xfree(ic->private.proto.ic_resources);
-   ic->private.proto.ic_resources = NULL;
-}
-if (ic->core.hotkey) {
-   Xfree(ic->core.hotkey);
-   ic->core.hotkey = NULL;
-}
+
+Xfree(ic->private.proto.saved_icvalues);
+ic->private.proto.saved_icvalues = NULL;
+
+
+Xfree(ic->private.proto.ic_resources);
+ic->private.proto.ic_resources = NULL;
+
+
+Xfree(ic->core.hotkey);
+ic->core.hotkey = NULL;
+

 return;
 }
-- 
2.1.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

[PATCH libX11 2/4] _XIOError(dpy); will never return so remore dead

[walter harms]

Signed-off-by: walter harms 
---
remove dead code as _XIOError will never return

---
 src/xcb_io.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/xcb_io.c b/src/xcb_io.c
index bd26a62..4826621 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -700,10 +700,8 @@ Status _XReply(Display *dpy, xReply *rep, int extra, Bool 
discard)
/* it's not an error, but we don't have a reply, so it's an I/O
 * error. */
if(!reply)
-   {
_XIOError(dpy);
-   return 0;
-   }
+   

/* there's no error and we have a reply. */
dpy->xcb->reply_data = reply;
-- 
2.1.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

[PATCH libX11 1/4] fix shadow warning

[walter harms]

Signed-off-by: walter harms 
---
resolve anoying shadow warning from gcc

---
 src/StrKeysym.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/StrKeysym.c b/src/StrKeysym.c
index 12fce68..be77a93 100644
--- a/src/StrKeysym.c
+++ b/src/StrKeysym.c
@@ -115,7 +115,7 @@ XStringToKeysym(_Xconst char *s)
 {
XrmValue result;
XrmRepresentation from_type;
-   char c;
+   char d;
XrmQuark names[2];

names[0] = _XrmInternalStringToQuark(s, p - s - 1, sig, False);
@@ -126,10 +126,10 @@ XStringToKeysym(_Xconst char *s)
val = 0;
for (i = 0; i < result.size - 1; i++)
{
-   c = ((char *)result.addr)[i];
-   if ('0' <= c && c <= '9') val = (val<<4)+c-'0';
-   else if ('a' <= c && c <= 'f') val = (val<<4)+c-'a'+10;
-   else if ('A' <= c && c <= 'F') val = (val<<4)+c-'A'+10;
+   d = ((char *)result.addr)[i];
+   if ('0' <= d && d <= '9') val = (val<<4)+d-'0';
+   else if ('a' <= d && d <= 'f') val = (val<<4)+d-'a'+10;
+   else if ('A' <= d && d <= 'F') val = (val<<4)+d-'A'+10;
else return NoSymbol;
}
return val;
-- 
2.1.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 inputproto] specs: Set TZ=UTC before calling asciidoc

[Andreas Boll]

2016-03-30 6:26 GMT+02:00 Peter Hutterer :
> On Fri, Dec 11, 2015 at 10:49:33AM +0100, Andreas Boll wrote:
>> Set TZ=UTC before calling asciidoc to make the embedded dates invariant
>> to timezones in order to make the package build reproducibly.
>
> quick check shows that the date embedded includes a timestamp with seconds
> granularity. So unless your build system forces the exact same time for
> every build, the result is still not reproducible. And if the build system
> forces the time, why can't it force the timezone too?
>
> what am I missing here?
>
> Cheers,
>Peter

From [1] "The date is based in the last modified date of the source
file, but is sensible to the timezone."

In this case the source files are specs/XI2proto.txt and specs/XIproto.txt.
So the timestamps in the generated html files depend only on the build
system's timezone which could be overridden via TZ=UTC.

An alternate solution which could remove the timestamp from the
generated html file has been proposed to asciidoc but unfortunately
upstream hasn't merged that patch so far [2].

Thanks,
Andreas

[1] 
https://wiki.debian.org/ReproducibleBuilds/TimestampsInDocumentationGeneratedByAsciidoc
[2] https://github.com/asciidoc/asciidoc/pull/9


>>
>> Fixes bug:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795981
>>
>> v2: Set TZ=UTC after $(AM_V_GEN) (fixes non-verbose build)
>>
>> Suggested-by: Eduard Sanou 
>> Signed-off-by: Andreas Boll 
>> ---
>>  specs/Makefile.am | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/specs/Makefile.am b/specs/Makefile.am
>> index a83cf40..f2454bc 100644
>> --- a/specs/Makefile.am
>> +++ b/specs/Makefile.am
>> @@ -6,7 +6,7 @@ doc_DATA = XI2proto.html XIproto.html
>>  dist_doc_DATA = XI2proto.txt XIproto.txt
>>
>>  %.html: %.txt
>> - $(AM_V_GEN)$(ASCIIDOC) -o $@ $<
>> + $(AM_V_GEN)TZ=UTC $(ASCIIDOC) -o $@ $<
>>
>>  CLEANFILES = $(doc_DATA)
>>
>> --
>> 2.1.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