Re: how do I build xf86-video-ati
Hi It works fine here, so I'm guessing you're missing a part of autotools or don't have a new enough version Here's what I get: ./autogen.sh autoreconf-2.69: Entering directory `.' autoreconf-2.69: configure.ac: not using Gettext autoreconf-2.69: running: aclocal --force -I m4 aclocal-1.16: warning: couldn't open directory 'm4': No such file or directory autoreconf-2.69: configure.ac: tracing autoreconf-2.69: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' autoreconf-2.69: running: /usr/bin/autoconf-2.69 --force autoreconf-2.69: running: /usr/bin/autoheader-2.69 --force autoreconf-2.69: running: automake --add-missing --copy --force-missing configure.ac:38: installing './compile' configure.ac:44: installing './config.guess' configure.ac:44: installing './config.sub' configure.ac:37: installing './install-sh' configure.ac:37: installing './missing' src/Makefile.am: installing './depcomp' autoreconf-2.69: Leaving directory `.' The the configure script runs Cheers Mike On Thu, 23 Aug 2018 at 01:53 John Lumby wrote: > I usually build xorg using jhbuild. > The last time I successfully built the xf86-video-ati package was in 2016, > when the cloned build tree contained a complete autoconf setup with an > aclocal.m4 > and also various other build-related bits and pieces,and jhbuild ran > autogen.sh and ./configure and so on and built it cleanly. > > But now there is no aclocal.m4 nor is there an m4 subdirectory, and > autogen.sh fails with > aclocal: error: couldn't open directory 'm4': No such file or directory, > and all my attempts to build it manually, e.g. pointing the M4PATH at > xorg-build/share/aclocal also fail. > > Obviously I am missing something or have omitted some step or dependency. > Could someone in the know please point me at the right way to build it. > > Thanks John Lumby > ___ > 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
how do I build xf86-video-ati
I usually build xorg using jhbuild. The last time I successfully built the xf86-video-ati package was in 2016, when the cloned build tree contained a complete autoconf setup with an aclocal.m4 and also various other build-related bits and pieces, and jhbuild ran autogen.sh and ./configure and so on and built it cleanly. But now there is no aclocal.m4 nor is there an m4 subdirectory, and autogen.sh fails with aclocal: error: couldn't open directory 'm4': No such file or directory, and all my attempts to build it manually, e.g. pointing the M4PATH at xorg-build/share/aclocal also fail. Obviously I am missing something or have omitted some step or dependency. Could someone in the know please point me at the right way to build it. Thanks John Lumby ___ 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
X.Org security advisory: August 22, 2018
X.Org security advisory: August 22, 2018 Out-of-bounds write in libXcursor prior to 1.1.15 = libXcursor could write one byte out of bounds when processing Xcursor theme files. In certain cases, such as when used in the Firefox web browser, this could be used as part of an exploit chain to allow further attacks on an X client process, as reported via Mozilla's ASan Nightly project. This issue has been assigned CVE-2015-9262. Patches === A patch for this issue was committed to the libXcursor git repository in 2015, and included in the libXcursor 1.1.15 release. https://gitlab.freedesktop.org/xorg/lib/libxcursor/commit/897213f36baf6926daf6d192c709cf627aa5fd05 Thanks == X.Org thanks Shubham Shrivastav of Samsung for reporting this issue to X.Org originally, and Alex Gaynor of Mozilla for helping us understand how this could be exploited by an attacker. -- -Alan Coopersmith- alan.coopersm...@oracle.com X.Org Security Response Team - xorg-secur...@lists.x.org ___ 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: [PULL xserver] Remove old colormap special cases from xfree86
Adam Jackson writes: > This makes xf86 colormap setup not as weird as other DDXes, and removes > matching special-casing from the devPrivate system. The trident and > xgixp drivers would be affected by this, losing the ability to set the > overscan border color. Either user is encouraged to speak up. > > The following changes since commit 1fc20b985cc888345bc8c6fce7b43f10ce71fe43: > > meson: Add detection of libsystemd-daemon. (2018-08-09 13:42:54 -0400) > > are available in the Git repository at: > > ssh://g...@gitlab.freedesktop.org/ajax/xserver xf86cmap > > for you to fetch changes up to 5e01650d190fa046a53139a4955b0ef7aedcbaad: > > xfree86: Remove the rest of ->SetOverscan (2018-08-20 14:55:35 > -0400) For the series: Reviewed-by: Keith Packard -- -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
[PULL xserver] Remove old colormap special cases from xfree86
This makes xf86 colormap setup not as weird as other DDXes, and removes matching special-casing from the devPrivate system. The trident and xgixp drivers would be affected by this, losing the ability to set the overscan border color. Either user is encouraged to speak up. The following changes since commit 1fc20b985cc888345bc8c6fce7b43f10ce71fe43: meson: Add detection of libsystemd-daemon. (2018-08-09 13:42:54 -0400) are available in the Git repository at: ssh://g...@gitlab.freedesktop.org/ajax/xserver xf86cmap for you to fetch changes up to 5e01650d190fa046a53139a4955b0ef7aedcbaad: xfree86: Remove the rest of ->SetOverscan (2018-08-20 14:55:35 -0400) Adam Jackson (8): xf86cmap: Factor out private lookup xf86cmap: Remove numColors from the colormap private xf86cmap: Remove overscan machinery xf86cmap: Always recalculate colors xf86cmap: Compute colors as needed xf86cmap: Remove the colormap private dix: Remove colormap private fixup xfree86: Remove the rest of ->SetOverscan dix/privates.c | 21 +--- hw/xfree86/common/xf86Init.c | 2 - hw/xfree86/common/xf86cmap.c | 322 -- hw/xfree86/common/xf86cmap.h | 2 +- hw/xfree86/common/xf86str.h | 2 - hw/xfree86/doc/ddxDesign.xml | 27 +- hw/xfree86/vgahw/vgaHW.c | 30 +- include/privates.h | 2 +- 8 files changed, 50 insertions(+), 358 deletions(-) - 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
Re: [PATCH xserver] glamor_egl: request GL2.1 when requesting Desktop GL context
于 2018年8月22日 GMT+08:00 下午8:24:09, Emil Velikov 写到:
>On 21 August 2018 at 17:01, Icenowy Zheng wrote:
>> Some devices cannot support OpenGL 2.1, which is the minimum desktop
>GL
>> version required by glamor. However, they may support OpenGL ES 2.0,
>> which is the GLES version required by glamor. Usually in this
>situation
>> the desktop GL version supported is 2.0 or 1.4.
>>
>> Currently, as no requirements are passed when creating desktop GL
>> context, a OpenGL 1.4/2.0 context will be created, and glamor will
>> arguing that the context is not suitable, although the GPU supports a
>> suitable GLES context.
>>
>> Add version number 2.1 requirement when requesting non-core desktop
>GL
>> context (core context has at least 3.1), so it will fall back to
>create
>> GLES contexts when the version number requirement is not met.
>>
>I don't know glamor enough to say if OpenGL 2.1 or another version
>should be required.
I think there's other code saying OpenGL 2.1 is required in glamor.c .
>Small mildly related note below.
>
>> Tested on a Intel 945GMS integrated GPU, which supports GL 1.4 and
>GLES
>> 2.0. Before applying this, it will fail to launch X server when no
>> configuration is present because of glamor initialization failure,
>after
>> applying glamor will start with GLES.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> glamor/glamor.h | 4
>> glamor/glamor_egl.c | 4
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/glamor/glamor.h b/glamor/glamor.h
>> index 09e9c895c..abee6a3e8 100644
>> --- a/glamor/glamor.h
>> +++ b/glamor/glamor.h
>> @@ -75,6 +75,10 @@ typedef Bool (*GetDrawableModifiersFuncPtr)
>(DrawablePtr draw,
>> #define GLAMOR_GL_CORE_VER_MAJOR 3
>> #define GLAMOR_GL_CORE_VER_MINOR 1
>>
>> +/* We need OpenGL 2.1 to work at least */
>> +#define GLAMOR_GL_VER_MAJOR 2
>> +#define GLAMOR_GL_VER_MINOR 1
>> +
>> /* @glamor_init: Initialize glamor internal data structure.
>> *
>> * @screen: Current screen pointer.
>> diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
>> index b33d8ef15..8da8d2731 100644
>> --- a/glamor/glamor_egl.c
>> +++ b/glamor/glamor_egl.c
>> @@ -946,6 +946,10 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
>> EGL_NONE
>> };
>> static const EGLint config_attribs[] = {
>> +EGL_CONTEXT_MAJOR_VERSION_KHR,
>> + GLAMOR_GL_VER_MAJOR,
>> + EGL_CONTEXT_MINOR_VERSION_KHR,
>The EGL attributes are part of EGL_KHR_create_context, which we do not
>check currently.
>Since EGL_CONTEXT_MAJOR_VERSION_KHR is effectively an alias for
>EGL_CONTEXT_CLIENT_VERSION one could use the latter and GL_VERSION of
>the created context.
>
>it's technically correct, although it feels like an overkill.
>Worth checking what others think on the topic.
>
>HTH
>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 xserver] glamor_egl: request GL2.1 when requesting Desktop GL context
On 21 August 2018 at 17:01, Icenowy Zheng wrote:
> Some devices cannot support OpenGL 2.1, which is the minimum desktop GL
> version required by glamor. However, they may support OpenGL ES 2.0,
> which is the GLES version required by glamor. Usually in this situation
> the desktop GL version supported is 2.0 or 1.4.
>
> Currently, as no requirements are passed when creating desktop GL
> context, a OpenGL 1.4/2.0 context will be created, and glamor will
> arguing that the context is not suitable, although the GPU supports a
> suitable GLES context.
>
> Add version number 2.1 requirement when requesting non-core desktop GL
> context (core context has at least 3.1), so it will fall back to create
> GLES contexts when the version number requirement is not met.
>
I don't know glamor enough to say if OpenGL 2.1 or another version
should be required.
Small mildly related note below.
> Tested on a Intel 945GMS integrated GPU, which supports GL 1.4 and GLES
> 2.0. Before applying this, it will fail to launch X server when no
> configuration is present because of glamor initialization failure, after
> applying glamor will start with GLES.
>
> Signed-off-by: Icenowy Zheng
> ---
> glamor/glamor.h | 4
> glamor/glamor_egl.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/glamor/glamor.h b/glamor/glamor.h
> index 09e9c895c..abee6a3e8 100644
> --- a/glamor/glamor.h
> +++ b/glamor/glamor.h
> @@ -75,6 +75,10 @@ typedef Bool (*GetDrawableModifiersFuncPtr) (DrawablePtr
> draw,
> #define GLAMOR_GL_CORE_VER_MAJOR 3
> #define GLAMOR_GL_CORE_VER_MINOR 1
>
> +/* We need OpenGL 2.1 to work at least */
> +#define GLAMOR_GL_VER_MAJOR 2
> +#define GLAMOR_GL_VER_MINOR 1
> +
> /* @glamor_init: Initialize glamor internal data structure.
> *
> * @screen: Current screen pointer.
> diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
> index b33d8ef15..8da8d2731 100644
> --- a/glamor/glamor_egl.c
> +++ b/glamor/glamor_egl.c
> @@ -946,6 +946,10 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
> EGL_NONE
> };
> static const EGLint config_attribs[] = {
> +EGL_CONTEXT_MAJOR_VERSION_KHR,
> + GLAMOR_GL_VER_MAJOR,
> + EGL_CONTEXT_MINOR_VERSION_KHR,
The EGL attributes are part of EGL_KHR_create_context, which we do not
check currently.
Since EGL_CONTEXT_MAJOR_VERSION_KHR is effectively an alias for
EGL_CONTEXT_CLIENT_VERSION one could use the latter and GL_VERSION of
the created context.
it's technically correct, although it feels like an overkill.
Worth checking what others think on the topic.
HTH
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
