[PATCH libXfont] Convert to non-recursive build.

--- Because two Makefiles are better than ten. Makefile.am | 114 ++- configure.ac | 10 + src/FreeType/Makefile.am | 15 --- src/Makefile.am | 68 src/bitmap/Makefile.am | 29

Re: CC_CHECK_FLAGS_APPEND (was Re: libXfont: Changes to 'master')

On Tue, Dec 8, 2015 at 10:51 PM, Jeremy Huddleston Sequoia wrote: > ./configure: line 19194: syntax error near unexpected token `with_cflags,' > ./configure: line 19194: ` CC_CHECK_FLAGS_APPEND(with_cflags, CFLAGS, \' > > From what I can tell, CC_CHECK_FLAGS_APPEND comes

Re: [PATCH] sync: Don't allow creating a system counter before sync is initialized

Hi, On 8 December 2015 at 20:08, Adam Jackson wrote: > It probably doesn't work very well since there's other extension setup > we're not doing on this path, and in any event it's not a thing that > happens currently. I can't for the life of me remember what provoked

Re: [PATCH] os: Treat ssh as a non-local client

On 09.12.2015 03:55, Adam Jackson wrote: > By the time we get to ComputeLocalClient, we've already done > NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming > we're built with #define CLIENTIDS), so we can look up the name of the > client process and refuse to treat ssh's X

Re: [PATCH RFC kdrive/ephyr v2] Match host X server's keymap

2015-12-08 16:55 GMT-02:00 Uli Schlachter : > Could you check xcb_get_extension_data(HostX.conn, _xkb_id)->present > first? > I don't know why XKB's UseExtension has a supported field, but without this > suggested check, the XCB connection will just go in an error state if the >

[PATCH RFC kdrive/ephyr v3] Match host X server's keymap

Analogous to Xnest implementation at 83fef4235db86343477b4ec9858c6ba35e1aa7d9. v3 changes: - Several changes in XCB code following Uli Schlachter's advices. v2 changes: - Keep struct KdKeyboardInfo untouched. - Move XkbApplyMappingChange()+XkbDDXChangeControls() call to

[PATCH RFC kdrive/ephyr v4] Match host X server's keymap

Analogous to Xnest implementation at 83fef4235db86343477b4ec9858c6ba35e1aa7d9. v4 changes: - Just a last-minute simplification in EphyrKeyboardInit(): there's no need to test explicitely if keySyms.map is NULL anymore, because hostx_load_keymap() now returns FALSE if that one can't be

Re: [PATCH 0/5] Remove DRI1

> From: Adam Jackson > Date: Tue, 8 Dec 2015 17:41:35 -0500 > > DRI1 hasn't really been a supported option for a while now, Mesa hasn't > supplied any drivers for it in years, and the design really isn't > compatible with KMS-like drivers. Also, Keith has some upcoming work to

Re: [PATCH xserver 0/6] Use a thread for input

> From: Keith Packard > Date: Tue, 8 Dec 2015 15:44:48 -0800 > > Here's a series which revives Tiago's ancient threaded input > patch. This has been cleaned up to make sure that it does locking > correctly, and then patches for xf86 and kdrive/fbdev hook the code to > a

Re: [PATCH] xres: Return the atom naming the type, not its internal type number

On 08/12/15 20:08, Adam Jackson wrote: Signed-off-by: Adam Jackson --- Xext/xres.c | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/Xext/xres.c b/Xext/xres.c index 83cc691..5d3faa3 100644 --- a/Xext/xres.c +++

[PATCH xserver] autogen: Set a default subject prefix for patches

Per discussion at XDC2015, we want this so we can easily distinguish which module a patch is for. There's no way to set this in the server-side config, so setting a default at autogen time is about the best we can do. Signed-off-by: Adam Jackson --- autogen.sh | 3 +++ 1 file

Re: xvfb: add randr support (v2)

On Wed, 2015-06-17 at 13:34 -0400, Adam Jackson wrote: > On Mon, 2015-06-08 at 22:14 +, Siim Põder wrote: > > Hi > > > > This was sent to xorg-devel a few years ago. It still applies and still > > appears > > to work. I resending this because it affects me. Comments or application to > >

Re: [PATCH] xres: Return the atom naming the type, not its internal type number

On Wed, 2015-12-09 at 13:37 +, Eric Engestrom wrote: > On 08/12/15 20:08, Adam Jackson wrote: > > > +resourceTypeAtom(int i) > > +{ > > +CARD32 ret; > > + > > +const char *name = LookupResourceName(i); > > +if (strcmp(name, XREGISTRY_UNKNOWN)) > > +ret = MakeAtom(name,

Re: [PATCH xserver 2/6] Remove SIGIO support.

Peter Hutterer writes: >> /* Call PIE here so we don't try to dereference a device that's >> * already been removed. */ >> -OsBlockSignals(); >> ProcessInputEvents(); >> +input_lock(); > > this is a behaviour change, was this intended? I'd rather

Re: [PATCH libXfont] Convert to non-recursive build.

Matt Turner writes: > --- > Because two Makefiles are better than ten. Seems like a fine change; I wonder why you bothered? -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Maintainer status update

I'll be very away from the keyboard from 11 through 20 December, and back only intermittently between then and 4 January. I anticipate spending most of that time on a snowboard or working on more artistic interests, but I've got a few X and GL projects I'll be poking at over that time, and I'll

Re: [PATCH 04/11] xf86: Add PRIME flipping functions to ScreenRec

> > Yeah, there's no open source implementation of these right now, but > > essentially > > they just allow the source driver to do whatever specific setup necessary to > > present to either of the two supplied shared buffers from the same > > headsurface, > > as well as having presentation

Re: [PATCH xserver 6/6] dix: Reallocate touchpoint buffer at input event time

On Wed, Dec 09, 2015 at 11:46:37AM -0800, Keith Packard wrote: > Peter Hutterer writes: > > > > this hunk took me a while, wouldn't it be easier do do something like: > > do { > >for (i = 0, ...) { > >... > >} > > > >if (!ti) > >

Re: [PATCH xserver 2/6] Remove SIGIO support.

On Wed, Dec 09, 2015 at 11:13:14AM -0800, Keith Packard wrote: > Peter Hutterer writes: > > >> /* Call PIE here so we don't try to dereference a device that's > >> * already been removed. */ > >> -OsBlockSignals(); > >> ProcessInputEvents(); > >> +

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

Emil Velikov writes: >> -BOOL serverRunning = FALSE; >> +Bool serverRunning; > Deliberate change ? The declaration in the headers is still using BOOL. Oops. So many edits; I thought for a while that we'd want to use this code to make the input thread wait for the

Re: [PATCH xserver 2/6] Remove SIGIO support.

Peter Hutterer writes: > this is a behaviour change, was this intended? I'd rather not have this > hidden in a giant patch that is otherwise mostly search and replace. Ok, I've pushed out a new series which creates a recursive (counting) mutex that makes all of this

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

On 9 December 2015 at 23:12, Keith Packard wrote: > --- a/dix/main.c > +++ b/dix/main.c > @@ -121,12 +121,9 @@ Equipment Corporation. > extern void Dispatch(void); > > #ifdef XQUARTZ > -#include > - > -BOOL serverRunning = FALSE; > +Bool serverRunning; Deliberate change ?

[PATCH xserver 1/8] Add stubs to input.h

--- include/input.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/input.h b/include/input.h index d8bd9c6..5bc60f0 100644 --- a/include/input.h +++ b/include/input.h @@ -712,4 +712,10 @@ extern _X_HIDDEN void input_constrain_cursor(DeviceIntPtr pDev, ScreenPtr screen

[PATCH xserver 2/8] Remove SIGIO support for input [v2]

This removes all of the SIGIO handling support used for input throughout the X server, preparing the way for using threads for input handling instead. Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls to stub functions input_lock/input_unlock so that we don't lose this

[PATCH xserver 4/8] Create a threaded mechanism for input [v3]

The current SIGIO signal handler method, used at generation of input events, has a bunch of oddities. This patch introduces an alternative way using a thread, which is used to select()s all input device file descriptors. A mutex was used to control the access to input structures by the main and

[PATCH xserver 5/8] mi: Grow event queue while reading events

Now that events are read at normal process time, we can use malloc to grow the event queue instead of discarding events. Signed-off-by: Keith Packard --- mi/mieq.c | 103 +++--- 1 file changed, 32 insertions(+), 71

[PATCH xserver 6/8] dix: Reallocate touchpoint buffer at input event time

Now that input is threaded, malloc can be used at event time to resize the touchpoint buffer as needed.x --- dix/touch.c | 89 + 1 file changed, 30 insertions(+), 59 deletions(-) diff --git a/dix/touch.c b/dix/touch.c index

[PATCH xserver 3/8] xkb: Hold input lock across injected key event processing

This makes the code more consistent with other versions of out-of-queue event processing Signed-off-by: Keith Packard --- xkb/xkbActions.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index afe5edf..048ed44 100644

[PATCH xserver 7/8] xfree86: Use threaded input mechanism

Switch the XFree86 DDX over to threaded input Signed-off-by: Keith Packard --- hw/xfree86/common/xf86Events.c | 4 ++-- hw/xfree86/common/xf86Helper.c | 2 +- hw/xfree86/common/xf86Init.c | 3 +++ 3 files changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH xserver 0/8] Use a separate thread for input [v2]

This is the second version of this series, the big change it to switch to a counting mutex using a thread-local variable. This makes the existing input_lock/input_unlock stuff 'just work' as the old OsBlockSIGIO stuff had a counter too. There's one change in locking; injected xkb events were being

[PATCH xserver 8/8] kdrive: Use threaded input

Signed-off-by: Keith Packard --- hw/kdrive/src/kinput.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c index 8527a9e..446883b 100644 --- a/hw/kdrive/src/kinput.c +++ b/hw/kdrive/src/kinput.c @@ -131,7

Re: [PATCH xserver 4/8] Create a threaded mechanism for input [v3]

> From: Keith Packard > Date: Wed, 09 Dec 2015 16:04:08 -0800 > > >> +extern _X_EXPORT pthread_mutex_t input_mutex; > >> +extern _X_EXPORT __thread int input_mutex_count; > >> + > > Are these really meant to be exported - a wild guess will be that the > > input drivers won't

Re: [PATCH xserver 0/6] Use a thread for input

Mark Kettenis writes: > Most of my objections to this Tiago's patch still apply. Threads > severely impact debuggability and this needs a full audit of all the > drivers; not just the server. I added the change which makes -dumbSched disable input threading to ease

Re: [PATCH xserver 6/6] dix: Reallocate touchpoint buffer at input event time

Peter Hutterer writes: > this hunk took me a while, wouldn't it be easier do do something like: > do { >for (i = 0, ...) { >... >} > >if (!ti) >TouchResizeQueue(dev)) > } while (!ti); It's similar, but you still