[PATCH] arch: Fix image and bitmap byte order for ppc64le

From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h

Re: [PATCH] arch: Fix image and bitmap byte order for ppc64le

X-Original-To: xorg-devel@lists.x.org From: Egbert Eich e...@freedesktop.org Date: Mon, 24 Feb 2014 10:57:23 +0100 From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Isn't it safer to revert the logic? I'm not sure all

[PATCH v2] arch: Fix image and bitmap byte order for ppc64le

From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/servermd.h b/include/servermd.h

[PATCH 0/2] Build Xi and DPMS stubs as convenience libraries

On 03/11/2011 14:27, Jon TURNEY wrote: Build Xi and DPMS stubs as convenience libraries, rather than once for each DDX which wants to use them. The tangled history of fbcmap_mi.c is a little hard to unweave, but I suspect that can be put back into libfb. Unfortunately, miinitext.c is a much

[PATCH 2/2] Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- Xi/Makefile.am | 5 +++-- hw/vfb/Makefile.am | 4 ++-- hw/xnest/Makefile.am | 4 ++-- hw/xwin/Makefile.am | 4 ++-- test/Makefile.am | 4 ++-- 5 files changed, 11 insertions(+), 10 deletions(-) diff --git a/Xi/Makefile.am

[PATCH 1/2] Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- Xext/Makefile.am | 4 +++- hw/vfb/Makefile.am | 4 ++-- hw/xnest/Makefile.am | 4 ++-- hw/xwin/Makefile.am | 6 +++--- test/Makefile.am | 2 +- 5 files changed, 11 insertions(+), 9 deletions(-) diff --git a/Xext/Makefile.am

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

Am 24.02.2014 11:36, schrieb Egbert Eich: From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org --- include/servermd.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-)

Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time

On 14-02-23 11:46 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. That would risk breaking little endian platforms that failed to define this. Safest to limit the

Re: [PATCH 0/2] Build Xi and DPMS stubs as convenience libraries

On 14-02-24 07:07 AM, Jon TURNEY wrote: Jon TURNEY (2): Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it Xext/Makefile.am

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

From: Egbert Eich e...@freedesktop.org Date: Mon, 24 Feb 2014 11:36:54 +0100 From: Dinar Valeev dval...@suse.com So far PPC was big endian for sure. For ppc64le this is no longer true. Signed-off-by: Egbert Eich e...@freedesktop.org Reviewed-by: Mark Kettenis kette...@openbsd.org

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

On Mon, 2014-02-24 at 08:09:33 -0800, Keith Packard wrote: walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. That would risk breaking little

Re: [PULL] reviewed glamor changes

Eric Anholt e...@anholt.net writes: Eric Anholt (17): glamor: Convert to using libepoxy. glamor: Rename glamor_get/put_dispatch to glamor_get/put_context. glamor: Put in a pluggable context switcher for GLX versus EGL. glamor: Drop useless

Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time

Hi, On 24 February 2014 15:28, Gaetan Nadon mems...@videotron.ca wrote: There are those three other cases to handle: nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/Xext/dpmsstubs.c \

Re: [RFC] Automatic modifier update of slave devices

Hi, Overall, I think it's close to the best we can make of a bad situation (in hindsight, I think we both would've done things differently ...), but Keith's pretty on the money: On 24 February 2014 06:57, Keith Packard kei...@keithp.com wrote: Peter Hutterer peter.hutte...@who-t.net writes:

Re: [RFC] Automatic modifier update of slave devices

Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Are you saying that we should only mirror the locking modifier state From master to slaves? That seems plausible, but seems more complicated

Re: [RFC] Automatic modifier update of slave devices

Hi, On 24 February 2014 21:28, Keith Packard kei...@keithp.com wrote: Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device. Are you saying that we should only mirror the locking modifier state

Re: [RFC] Automatic modifier update of slave devices

Daniel Stone dan...@fooishbar.org writes: I'm suggesting the minimal change possible to solve the stated problem (which is essentially that new slaves don't inherit the LED - i.e. lock - state of their masters). Ok, that seems like a fine plan to me I'm pretty wary of the full push to

Re: [RFC] Automatic modifier update of slave devices

On Mon, Feb 24, 2014 at 09:32:57PM +, Daniel Stone wrote: Hi, On 24 February 2014 21:28, Keith Packard kei...@keithp.com wrote: Daniel Stone dan...@fooishbar.org writes: whilst not doing anything surprising like having a base modifier down which was never pressed on that device.

Re: [RFC] Automatic modifier update of slave devices

Peter Hutterer peter.hutte...@who-t.net writes: the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect that most people expect from their keyboards. comments? That seems even

Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time

Gaetan Nadon mems...@videotron.ca writes: Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. Sure would be nice if

Re: [PATCH] Add devd config backend for FreeBSD (and GNU/kFreeBSD)

On 22/02/2014 16:12, Guillem Jover wrote: Hi, Just a quick review skimming over. The C code has a mix of indentation by tab and spaces, not just 4 spaces, no cudled braces, etc. I've ignored other style issues too. I just went through the style rules in http://www.x.org/wiki/CodingStyle/

Re: [RFC] Automatic modifier update of slave devices

On Mon, Feb 24, 2014 at 02:28:55PM -0800, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect that

Re: [RFC] Automatic modifier update of slave devices

Hi, On 24 February 2014 22:28, Keith Packard kei...@keithp.com wrote: Peter Hutterer peter.hutte...@who-t.net writes: the less-intrusive alternative would be to force only the indicator state down to the slaves. won't change keyboard behaviour as seen by the client and still has the effect

Re: [RFC] Automatic modifier update of slave devices

PH == Peter Hutterer peter.hutte...@who-t.net writes: PH the less-intrusive alternative would be to force only the indicator state PH down to the slaves. won't change keyboard behaviour as seen by the client PH and still has the effect that most people expect from their keyboards. PH comments?

[PATCH libXau] Constify XauGetBestAuthByAddr type_names argument

The type names are merely accessed, not changed. So make it const to avoid warnings in other projects (like libxcb) which pass in a static table of string literals. Signed-off-by: Ran Benita ran...@gmail.com --- AuGetBest.c | 2 +- include/X11/Xauth.h | 2 +- man/Xau.man | 2 +-

Re: [RFC] Automatic modifier update of slave devices

Hi, On 24 February 2014 22:56, James Cloos cl...@jhcloos.com wrote: So hitting compose on one keyboard would light the compose led on all associated keyboards but only intitiate a compose sequence on the one? Or caps-lock? Or level shifts? Or group toggles? If I read that right, that

Re: [RFC] Automatic modifier update of slave devices

Peter Hutterer peter.hutte...@who-t.net writes: there is no good solution here, it's just a question which foot we prefer shooting at. Yeah, that part seems clear enough at least. So, it seems like we have a list of options: 1) Mirror nothing. Indicators and modifiers for each slave are

Re: [PULL] sync: Avoid ridiculously long timeouts

Matthieu Herrb matthieu.he...@laas.fr writes: Mark Kettenis (1): sync: Avoid ridiculously long timeouts Rescued from obscurity and merged. c85ea92..1940508 master - master -- keith.pack...@intel.com pgpCiIOT72Hl3.pgp Description: PGP signature

Re: [PATCH] gcc 4.2.1 doesn't support #pragma GCC diagnostic ignored

Matthieu Herrb matthieu.he...@laas.fr writes: Signed-off-by: Matthieu Herrb matth...@herrb.eu Merged. 1940508..e67f2d7 master - master -- keith.pack...@intel.com pgpfEWxr4gw3j.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH 1/2] Fix test/signal-logging to work on Solaris

Peter Hutterer peter.hutte...@who-t.net writes: On Sun, Feb 09, 2014 at 11:13:50PM -0800, Alan Coopersmith wrote: For some reason, Solaris libc sprintf() doesn't add 0x to the %p output as glibc does, causing the test to fail for not matching the exact output. Since the 0x is desirable, we

Re: [PATCH] V2: Add check for link from output to crtc before optimizing out a CrtcSet call

David Sodman dsod...@chromium.org writes: Signed-off-by: David Sodman dsod...@chromium.org Reviewed-by: Stéphane Marchesin marc...@chromium.org Merged. 249565a..caf1dec master - master -- keith.pack...@intel.com pgpjwzlPMEQlT.pgp Description: PGP signature

[PATCH 2/6] xephyr: Pass incoming XCB events to the Xlib event filter.

This is the same thing that Qt ended up doing to get DRI2's event mangling to happen despite using an XCB event loop. Signed-off-by: Eric Anholt e...@anholt.net Reviewed-by: Keith Packard kei...@keithp.com --- hw/kdrive/ephyr/ephyr.c| 3 +++ hw/kdrive/ephyr/ephyr_glamor_glx.c | 39

glamor: Enabling xephyr and Xorg.

Here's a short series to make the server glamor stuff actually testable. I'm now running glamor for my normal desktop, and the xephyr bits work too. I pulled out changes that would have required more from the intel 2d driver: now it's just a matter of not linking to the external module's

[PATCH 3/6] xorg: Build a glamor_egl module.

This is not exposing the API we want long term, but it should get existing DDX drivers up and running while we massage the API into shape. v2: Use LIBADD instead of LDFLAGS to fix deps on libglamor.la, and use version 0.5.1 (the point it was forked from the external repo). Signed-off-by:

[PATCH 1/6] xephyr: Build support for rendering with glamor using a -glamor option.

v2: Avoid making the Ximage for the screen that we'll never use, and drive the screen pixmap creation for glamor ourselves. Signed-off-by: Eric Anholt e...@anholt.net Reviewed-by: Keith Packard kei...@keithp.com (v1) --- configure.ac | 3 + glamor/glamor.c

[PATCH 6/6] glamor: Add support for DRI3.

The render-nodes case is untested. v2: Add a flag for wayland to suppress the native DRI3 support. Wayland isn't running as a master itself, so it can't do the auth on its own and has to ask the compositor to do it for us. Dropped XXX about randr provider -- the conclusion from

[PATCH 5/6] glamor: Rename the DRI-related pixmap functions.

There was confusion over whether they should have egl in the name, and they had DRI3 in the name even though they're useful to have without DRI3. Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor.c | 10 +- glamor/glamor.h | 54

[PATCH 4/6] xorg: Connect up the glamor XV code, xorg DDX-only for now.

Porting this code to be non-xorg-dependent is going to take significant hacking, so just dump it in the glamoregl module for the moment, so I can hack on it while regression testing. v2: Fix compiler warnings by adding #include dix-config.h at the top, don't try to auto-init (I'll try to fix

Re: [RFC] Automatic modifier update of slave devices

On Mon, Feb 24, 2014 at 05:56:41PM -0500, James Cloos wrote: PH == Peter Hutterer peter.hutte...@who-t.net writes: PH the less-intrusive alternative would be to force only the indicator state PH down to the slaves. won't change keyboard behaviour as seen by the client PH and still has the

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

Guillem Jover guil...@hadrons.org writes: I'm probably missing something (maybe this header cannot include a dix-config.h or equivalent), but why not use AC_C_BIGENDIAN? Yeah, this would be nicer -- AC_C_BIGENDIAN should be more reliable than any presumption about compiler defined symbols. --

Re: [RFC] Automatic modifier update of slave devices

On Mon, Feb 24, 2014 at 04:00:28PM -0800, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: there is no good solution here, it's just a question which foot we prefer shooting at. Yeah, that part seems clear enough at least. So, it seems like we have a list of options:

Re: [RFC] Automatic modifier update of slave devices

Peter Hutterer peter.hutte...@who-t.net writes: I'm fine with either 3 or 4 tbh, though note that from the user's POV we already do 4. open xterm, hit ctrl one one keyboard and C on the other and you'll get a ctrl+c through the core protocol and from the XI2 master. Right, I wanted to

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

On 02/24/14 04:52 AM, walter harms wrote: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every achitecture. You're 25 years too late to stop that - we already define it for every architecture and

Re: [PATCH v2] arch: Fix image and bitmap byte order for ppc64le

On 02/24/14 08:19 AM, Guillem Jover wrote: On Mon, 2014-02-24 at 08:09:33 -0800, Keith Packard wrote: walter harms wha...@bfs.de writes: Assuming that __LITTLE_ENDIAN__ is of general interest, i would avoid defined(__ppc__) and friends otherwise we will need to define this for every

Re: [PATCH xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time

On 14-02-24 05:27 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0

Re: [PATCH xf86-input-synaptics 6/8] Ignore motion the first X ms after a clickpad click

On Fri, Feb 21, 2014 at 10:31:42AM +0100, Hans de Goede wrote: This fixes my #1 anoyance with clickpads, where 2 out of 3 clicks turn into a click + drag unless I hold my finger really really still. do we really need a property and an option for this? I'm tempted to try for a hardcoded value

Re: [PATCH xf86-input-synaptics 8/8] Wait for *new* coordinates on a clickpad click before reporting the click

On Fri, Feb 21, 2014 at 10:31:44AM +0100, Hans de Goede wrote: It is possible for a click to get reported before any related touch events get reported, here is the relevant part of an evemu-record session on a T440s: E: 3.985585 # SYN_REPORT (0) -- E:

Re: [PATCH 6/6] glamor: Add support for DRI3.

Hi, While for XWayland we want to provide our own dri3_open, we still want to have glamor enabling the dri3 support That is rather a GLAMOR_NO_DRI3_SETUP flag and +if (glamor_egl-dri3_capable !(glamor_priv-flags GLAMOR_NO_DRI3)) { +/* Tell the core that we have the interfaces