---
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
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 f937c3d501. I'm 100%
sure it
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 from glib. Can we pl
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 forwa
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
EphyrKeyboardInit
2015-12-08 16:55 GMT-02:00 Uli Schlachter :
> Could you check xcb_get_extension_data(HostX.conn, &xcb_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
> XKB
> connecti
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 al
> 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 couple of X servers to sh
> 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
> thread input han
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
+++ b/Xext/xres.c
@@ -274,6 +27
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 changed, 3 insertio
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, strl
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
> > the
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 not have this
> hidden in
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
Archives: http://lists.x.or
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 debugging, although I haven't
On Wed, Dec 9, 2015 at 11:14 AM, Keith Packard wrote:
> Matt Turner writes:
>
>> ---
>> Because two Makefiles are better than ten.
>
> Seems like a fine change; I wonder why you bothered?
I think at the time I did it (early September) I was trying to
determine if automake-1.14's new %reldir%/%ca
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 need to deal with the poss
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 try
> > 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 drive
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();
> >> +input_lock();
> >
> > thi
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)
> >TouchResizeQueu
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 stuff quite easy. Nice to hav
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
--- a/xkb/xkbActions.
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 a/hw/xfree86/common/xf86Events.c b/h
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
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 +131,7 @@ static void
---
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
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
informati
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 in
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 deletions(-)
diff --git
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 4c0412a..1d12
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 ? The declaration in th
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 server.
>> +extern _X_EXPORT pt
> 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 need access to these
35 matches
Mail list logo