Re: [PATCH xserver 5/9] Create a threaded mechanism for input [v5]

Emil Velikov writes: > This will enable it on more platforms than just Linux. Right, the goal is to use it where available. > You can use AX_PTHREAD here, instead of open-coding it. Thanks. I've updated the series to do this; it's on my input-thread branch in

[PATCH xserver] Use separate name for --with-bundle-version help variable

AC_DEFAULT_BUNDLE_VERSION for the m4 variable avoids this problem. At the same time, remove an extra newline in the m4 value. Signed-off-by: Keith Packard <kei...@keithp.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac

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

Signed-off-by: Keith Packard <kei...@keithp.com> Acked-by: Peter Hutterer <peter.hutte...@who-t.net> --- 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 b415a86..4119b08 100644 ---

[PATCH xserver 6/9] 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 <kei...@keithp.com> --- mi/mieq.c | 103 +++--- 1 file changed, 32 insertions(

[PATCH xserver 7/9] 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 Signed-off-by: Keith Packard <kei...@keithp.com> Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> --- dix/touch.c | 89 +---

[PATCH xserver 5/9] Create a threaded mechanism for input [v5]

that expose the same API/ABI. Respond to style comments from Peter Hutterer. v5: use __func__ in inputthread debug and error mesages. Respond to style comments from Peter Hutterer. Signed-off-by: Adam Jackson <a...@redhat.com> Signed-off-by: Keith Packard <kei...@keithp.c

[PATCH xserver 3/9] xfree86: Remove unnecessary errno save/restore in xf86ReadInput

When this code was called from SIGIO, saving and restoring errno could possibly have made sense in some strange environment. Now that this will not be called from a signal handler, there is no reason to do that. Signed-off-by: Keith Packard <kei...@keithp.com> --- hw/xfree86/common/xf86Ev

[PATCH xserver 1/9] xfree86: Set xf86CrtcConfigRec cursor pointer to NULL in HideCursor

, xf86CurrentCursor, which returns the current cursor. With this new function, we can eliminate the cursor pointer from the xf86CrtcConfigRec, once drivers are converted over to use it. Signed-off-by: Keith Packard <kei...@keithp.com> --- hw/xfree86/modes/xf86Cursors.c | 17 + hw/xfree86/

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

Switch the XFree86 DDX over to threaded input v2: Rewrite comment in xf86Helper about silken mouse Signed-off-by: Keith Packard <kei...@keithp.com> Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> --- hw/xfree86/common/xf86Events.c | 4 ++-- hw/xfree86/common/xf86H

[PATCH xserver 2/9] Remove SIGIO support for input [v3]

Signed-off-by: Keith Packard <kei...@keithp.com> --- Xi/exevents.c | 4 +- config/config.c | 4 +- configure.ac | 14 --- dix/devices.c | 10 +-

[PATCH xserver 4/9] 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 <kei...@keithp.com> --- xkb/xkbActions.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index afe5edf..048ed44

[PATCH xserver] xfree86: Set xf86CrtcConfigRec cursor pointer to NULL in HideCursor

, xf86CurrentCursor, which returns the current cursor. With this new function, we can eliminate the cursor pointer from the xf86CrtcConfigRec, once drivers are converted over to use it. Signed-off-by: Keith Packard <kei...@keithp.com> --- hw/xfree86/modes/xf86Cursors.c | 17 + hw/xfree86/

Re: [PATCH xserver] present: Only requeue for next MSC after flip failure

t was supposed to, in which case vblank->target_msc will be exactly crtc_msc+1, or it's being done late, in which case that will have passed and we'll copy it immediately. Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature _

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

mageCheck function doesn't get the CursorPtr. So, we need the xf86CurrentCursor function that I had written before. From c133e4d9fac39862d7922f59080cc7ce40d1108b Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Wed, 9 Mar 2016 11:13:14 -0800 Subject: [PATCH xserver] xfree86:

Re: [PATCH xserver 2/3] xfree86/modes: Check for CRTC transforms in xf86_use_hw_cursor(_argb) (v2)

v2: Check crtc->transformPresent instead of crtc->transform_in_use. The > latter is TRUE for rotation as well, which we handle correctly. > Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature __

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

Michel Dänzer writes: > Unfortunately, the reality is that at least the radeon and amdgpu > drivers do use it. Even modesetting uses it; there isn't any other public interface to get the current cursor. What do you think about eliminating the RefCursor/FreeCursor bits and

Re: [PATCH xserver 1/3] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor (v2)

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> > > This reduces code duplication. > > v2: No functional change this time. > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

Michel Dänzer writes: > It seems to work fine in my quick testing. However, I'm not sure it's > worth it, given that v2 of patch 1 fixes holding on to the last HW > cursor indefinitely, and given the churn it would cause for external > drivers. I guess I don't see how this

Re: [PATCH 2/2] pixmap: add wait shared pixmap

Dave Airlie <airl...@gmail.com> writes: > Signed-off-by: Dave Airlie <airl...@redhat.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org devel

Re: [PATCH 1/2] present: fail flipping if we have any slave outputs.

le of times to make sure the outputs all get repainted, and that should end up calling ClipNotify on any flip window. So, Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip (v2)

s slightly simplified, exploiting >> the fact that this function is only ever called with a valid flip >> pixmap. >> >> v2: Assert that flip_pixmap is non-NULL instead of testing and bailing >> on NULL, preserve test for flip_window being non-NULL before calling >> pr

Re: [PATCH xserver 3/3] present: Call present_restore_screen_pixmap from present_set_abort_flip

eady the case in other present code. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org dev

Re: [PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip

Michel Dänzer writes: > From: Michel Dänzer > > The following fix will use the refactored function. This isn't a simple refactor; the semantics of the new function are different from the replaced code. I'd love to see a separate patch which changed

Re: [PATCH xserver 1/3] present: Only update screen pixmap from flip pixmap once per unflip

n switching a flipping window out of fullscreen, a repeated unflip > copy could leave artifacts of the flip pixmap on the desktop. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@keithp.com> > +/* Update the screen pixmap wi

Re: [PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip

Michel Dänzer writes: Here's another review, now that I've more carefully looked at the other two patches. > +if (!flip_window || !flip_pixmap) > +return; In the original code, this didn't abort the operation entirely... This operation would have been skipped:

Re: [PATCH xserver] randr: Send ConfigNotify when manual monitor list changes

Dave Airlie writes: > Seems like a good thing to do. > > Reviewed-by: Dave Airlie Merged. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives:

[PATCH xserver] randr: Send ConfigNotify when manual monitor list changes

This lets clients know that the layout of the monitors on the screen has changed so they can adapt appropriately. Signed-off-by: Keith Packard <kei...@keithp.com> --- randr/rrmonitor.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/randr/rrmonitor.c b

Re: [PATCH xserver 1/3] res: Simplify QueryClientPixmapBytes

Adam Jackson writes: > I suspect this code predates the common resource hooks for computing > sizes. It's ugly in any case since the Resource extension shouldn't > need to know which extensions can take a reference on pixmaps. Instead, > let's just walk every resource for the

Re: [PATCH xserver 1/3] res: Simplify QueryClientPixmapBytes

Adam Jackson writes: > I don't really understand your objection about pixmaps not in the > resdb, because ResQueryClientPixmapBytes is _already_ not accounting > for those, and it's not clear to me how it even could. Sorry, that code has gotten a lot more sophisticated since I

Re: [PATCH xserver 1/2] xfree86/modes: Fix HW cursor clipping for crtc->driverIsPerformingTransform

Michel Dänzer writes: > I'm not sure that makes sense; e.g. it seems inconsistent with leaving > the cursor image untransformed in the driverIsPerformingTransform case. > It seems to me like the idea behind driverIsPerformingTransform was to > leave all transformations to the

Re: [PATCH xserver 1/2] xfree86/modes: Fix HW cursor clipping for crtc->driverIsPerformingTransform

Aaron Plattner <aplatt...@nvidia.com> writes: > On 01/29/2016 07:23 AM, Keith Packard wrote: >> Michel Dänzer <mic...@daenzer.net> writes: >> >>> I'm not sure that makes sense; e.g. it seems inconsistent with leaving >>> the cursor image untransf

Re: [PATCH xserver 2/2] dri3: Refuse to work for remote clients (v2)

gt; > v2: Return BadMatch instead of BadRequest (Keith Packard) > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@keithp.com> (might want to update the DRI3 spec to reflect this change?) --

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

Eric Anholt writes: > Yes, it's supposed to, but we don't actually store 16bpp anything in > glamor, because we suck. Ouch. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives:

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

Eric Anholt writes: > if (op == PictOpSrc) { > +/* We can't do direct copies between different depths at 16bpp > + * because r,g,b are allocated to different bits. > + */ > +if (dst->pDrawable->bitsPerPixel == 16 && > +

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

gt; +} > + These should probably get declared as inline, although the compiler will probably just inline them anyways. I also won't be surprised if we end needing to expose these in a header for other code to use too. Should we just do that now so that someone needing to compare values find

Re: [PATCH] glamor: fallback if font is too large for FBO size.

heck for that as well then, just in case the driver has some other crazy error states. Sorry for not adding my Reviewed-by: Keith Packard <kei...@keithp.com> before! -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org:

Re: [PATCH] glamor: fallback if font is too large for FBO size.

Dave Airlie writes: > From: Dave Airlie > > running xfontsel on haswell here, with a max texture size > of 8kx8k, one font wants 9711 height. This fallsback to > sw in this case. > > A proper solution probably involves using an array texture. Given that

Re: [PATCH] glamor: store old fonts in double width textures.

> tx = (col - firstCol) * glyph_spacing_x; > +/* adjust for second row layout */ > +tx += second_row * glamor_font->row_width * 8; I'm not OK using a Bool for multiplication here. Just declare it as an int and initialize to zero and we'll be good. Otherwi

Re: [PATCH] glamor: fallback if font is too large for FBO size.

Dave Airlie writes: > From: Dave Airlie > > running xfontsel on haswell here, with a max texture size > of 8kx8k, one font wants 9711 height. This fallsback to > sw in this case. > > A proper solution probably involves using an array texture. > >

Re: [PATCH xserver 0/9] Rewrite root window property setup

Adam Jackson writes: > Leo's patch to fix the EDID atom leak is probably correct, in the sense that > it fixes the leak, but xf86RegisterRootWindowProperty is fairly ugly to > begin with so I'd rather see it eliminated. This series adds a generic > callback for screen

Re: [PATCH:xserver] Fix uninitialized variable warnings reported by clang. (was Re: [PATCH:xf86-video-ati] Fix uninitialized variable warnings reported by clang.)

Adam Jackson writes: > Oops. This turns out to cause a crash on init, I've pushed a revert > until I figure out why. The patch turns one statement into two; presumably that matters somewhere. -- -keith signature.asc Description: PGP signature

Re: [PATCH:xserver] Avoid segfault in CloseWellKnownConnections when using -displayfd

TransConns entries before the point that ListenTransFds > was allocated & initialized, so CloseWellKnownConnections would > segfault trying to read entries from a NULL ListenTransFds pointer. > > Introduced by commit 7b02f0b8 > > Signed-off-by: Alan Coopersmith <alan.coopersm...@o

Making MST work for me

I finally dug a 4k monitors out and plugged it into my laptop. Of course, my laptop needs to use MST to drive it at 60Hz. I got to fix version 2.24 of gtk+: https://bugzilla.gnome.org/show_bug.cgi?id=759912 Next, I wanted to automatically configure things when I plugged and unplugged

Re: [PATCH xserver 1/2] xfree86/modes: Fix HW cursor clipping for crtc->driverIsPerformingTransform

Michel Dänzer writes: > From: Michel Dänzer > > Even if the driver is handling the transform, we still need to transform > the cursor position for clipping, otherwise we may hide the HW cursor > when the cursor is actually inside the area covered by

Re: [PATCH xserver 2/2] xfree86/modes: Eliminate redundant local variable in_range

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> Yeah, looks cleaner this way. Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ x

Re: [PATCH xserver 1/2] xfree86/modes: Fix HW cursor clipping for crtc->driverIsPerformingTransform

Michel Dänzer <mic...@daenzer.net> writes: > On 26.12.2015 04:08, Keith Packard wrote: >> Michel Dänzer <mic...@daenzer.net> writes: >> >>> From: Michel Dänzer <michel.daen...@amd.com> >>> >>> Even if the driver is handling the t

Re: [PATCH xserver 3/5] xfree86: Re-set current cursor after RandR 1.2 CRTC configuration change

anymore. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://list

Re: [PATCH xserver 4/5] modesetting: Remove xf86_reload_cursors call

Michel Dänzer writes: > From: Michel Dänzer > > It was already disabled, but it's definitely no longer needed now that > xf86CursorResetCursor is getting called for each CRTC configuration > change. I think we can remove xf86_reload_cursors from the

Re: [PATCH xserver 5/5] modesetting: Allow CRTC transforms to actually take effect

.2 cursor code handles transforms correctly, we can > allow them to properly take effect. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> I've already marked this as: Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver 2/5] xfree86/modes: Check for CRTC transforms in xf86_use_hw_cursor(_argb)

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> > > We currently don't handle transforms for the HW cursor image, so return > FALSE to signal a software cursor must be used if a transform is in use > on any CRTC. Revi

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

ld' work. From da2e5c4f6e08b765a6a3e7337c0da8dd60b531e0 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Thu, 24 Dec 2015 09:51:49 -0800 Subject: [PATCH xserver] xfree86/modes: Remove extra reference to current cursor Just use the cursor reference in the xf86CursorScree

Re: [PATCH xserver 5/5] modesetting: Allow CRTC transforms to actually take effect

s this right above the call to set_mode_major, making this change "obviously" correct). Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archi

Re: [PATCH xserver 3/5] modesetting: Implement CRTC use_hw_cursor_argb hook

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> > > This will disable the HW cursor while a transform is active on the CRTC. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packar

Re: [PATCH xserver 1/5] xfree86: Add xf86CursorResetCursor

Michel Dänzer <mic...@daenzer.net> writes: > From: Michel Dänzer <michel.daen...@amd.com> > > This allows switching between HW and SW cursor depending on the current > state. Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.

Re: [PATCH xserver 4/5] modesetting: Call xf86CursorResetCursor on modeset

Michel Dänzer writes: > From: Michel Dänzer > > This will switch from HW cursor to SW cursor in the following cases: > * A transform is present on a CRTC > * This screen is a GPU screen acting as an output slave for another > screen Could this be

Re: [PATCH xserver 2/5] xfree86/modes: Add use_hw_cursor(_argb) CRTC hooks

Michel Dänzer writes: > From: Michel Dänzer > > Allows drivers to report whether or not the HW cursor can be used on a > per-CRTC basis. If the driver reports that the HW cursor cannot be used > on any CRTC, SW cursor has to be used for the screen. >

Re: [PATCH xserver 4/5] modesetting: Call xf86CursorResetCursor on modeset

Michel Dänzer writes: > New series addressing this on the way. Thanks for your review of this > series. Cool! Love it when review makes things better. -- -keith signature.asc Description: PGP signature ___

Re: [PATCH 0/5] Switching from HW cursor to SW cursor

Michel Dänzer writes: > Without this patch, there's no way for a driver using the code in > xf86Cursors.c to force an SW cursor. Ok, sorry I was just being dense and not understanding what the code was actually doing. Thanks for the explanation, I understand the aim of the

Re: [PATCH 0/5] Switching from HW cursor to SW cursor

Michel Dänzer writes: > This series addresses two cases in which a HW cursor cannot be used: > > 1) When a transform is active on a CRTC. Patch 2 adds a CRTC hook >use_hw_cursor_argb, which allows drivers to force SW cursor on a >per-CRTC basis. However, this hook

Re: [PATCH 0/5] Switching from HW cursor to SW cursor

Michel Dänzer writes: > This series addresses two cases in which a HW cursor cannot be used: > > 1) When a transform is active on a CRTC. Patch 2 adds a CRTC hook >use_hw_cursor_argb, which allows drivers to force SW cursor on a >per-CRTC basis. However, this hook

Re: [PATCH 0/5] Switching from HW cursor to SW cursor

Michel Dänzer writes: > 1) When a transform is active on a CRTC. We haven't disabled the HW cursor when transforms are active in the past, although I can imagine it'd be a nice thing to do. -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver 2/9] Remove SIGIO support for input [v2]

* Use silken mouse if requested and if we have threaded input */ pScrn->silkenMouse = useSM && InputThreadEnable; if (serverGeneration == 1) From 399961d249d8483f261824beea9a3a2b0eda97b1 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Tue, 8 Dec

Re: [PATCH xserver 6/9] mi: Grow event queue while reading events

Peter Hutterer writes: > we should really move that lot into a helper function... Well, now that growing the queue happens while queuing events, we might just remove it entirely. Unless we run out of memory, it'll never happen now. >> - >> -return; >> +

Re: [PATCH xserver] xfree86: move check for driver->PreInit up

driver '%s' for '%s'\n", drv->driverName, > +pInfo->name); Probably don't want to move this message; if systemd pauses things, you'll get this message even if the device doesn't end up getting used. Otherwise, this lgtm. Reviewed-by: Keith Packard <kei...@ke

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

e list > pointer comparison. Done. > __func__ for all three? I don't understand; do you want __func__ to be displayed in these error and debug printfs? > please wrap the xorg_list loop in { } Done. Here's a new patch which merges 4/9 and 5/9 into 4/8 From 87d71e36185f2e1d7bc085c3f45

Re: [PATCH xserver 5/9] Disable input thread code with --disable-input-thread. RECURSIVE_MUTEX support

Peter Hutterer writes: > typo: uppercase 't' "fixed" by rewriting the commit message. > seems a bit odd to use a case statement for a basic check. can we use a > simple if here? (ignore this if a later patch changes this bit) Sorry, old Bourne shell habit. Fixed. I

[PATCH xserver 7/9] 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 9/9] kdrive: Use threaded input

Signed-off-by: Keith Packard <kei...@keithp.com> --- 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 @@

[PATCH xserver 6/9] 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 <kei...@keithp.com> --- mi/mieq.c | 103 +++--- 1 file changed, 32 insertions(

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

e by default on non-Linux This also splits out the actual enabling of input threads to DDX-specific patches which follow v3: Make the input lock recursive Signed-off-by: Adam Jackson <a...@redhat.com> Signed-off-by: Keith Packard <kei...@keithp.com> recursive lock --- configure.ac

[PATCH xserver 1/9] 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 3/9] 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 <kei...@keithp.com> --- xkb/xkbActions.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index afe5edf..048ed44

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

this information. xfree86 SIGIO support is reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO. v2: Don't change locking order (Peter Hutterer) Signed-off-by: Keith Packard <kei...@keithp.com> --- Xi/exevents.c | 4 +- config/co

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

Switch the XFree86 DDX over to threaded input Signed-off-by: Keith Packard <kei...@keithp.com> --- 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/x

[PATCH xserver 5/9] Disable input thread code with --disable-input-thread. RECURSIVE_MUTEX support

mutex support in the server. We prefer PTHREAD_RECURSIVE_MUTEX_SUPPORt where available, falling back to __thread/__declspec(thread) support if necessary. Signed-off-by: Keith Packard <kei...@keithp.com> fixup for thread variables --- configure.ac| 14 ++ hw/xfree86/sdks

Re: [PATCH xf86-input-libinput] Drain the fd after opening

Peter Hutterer <peter.hutte...@who-t.net> writes: > fd = xf86OpenSerial(pInfo->options); > + xf86FlushInput(fd); Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ x

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

argv) { int t; pthread_t threads[THREADS]; for (t = 0; t < THREADS; t++) pthread_create([t], NULL, doit, NULL); for (t = 0; t < THREADS; t++) pthread_join(threads[t], NULL); } From 55f483cff8d660e444a65026e57f793c06a66ce3 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com>

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

f conditional code. Here's code which works only with recursive mutexes, initializing it explicitly when PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not available. From 700fb83a0afbfce19bb91967f619cde6ead900a6 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Thu, 10 Dec 2015 11:3

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

Mark Kettenis writes: > However, is there a reason why you didn't use the > PTHREAD_MUTEX_RECURSIVE mtex type that is standardized by POSIX? Sorry, my documentation only mentions a non-portable version of recursive mutexes. I didn't even know that recursive mutexes had

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

Keith Packard <kei...@keithp.com> writes: > Mark Kettenis <mark.kette...@xs4all.nl> writes: > >> However, is there a reason why you didn't use the >> PTHREAD_MUTEX_RECURSIVE mtex type that is standardized by POSIX? > > Sorry, my documentation only mentions a

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

Mark Kettenis writes: > Ugh. Exporting global variables as part of the ABI is generally not > such a good idea. Perhaps it is better to use functions to acquire > and release the input mutex instead? Yeah, it's not a performance sensitive operation, so hiding the

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

Peter Hutterer writes: > in light of Mark's comments to 4/8 these should be an opaque API rather than > inlined so we don't need to export the globals. Yeah, probably a good idea.a -- -keith signature.asc Description: PGP signature

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

fying that if I misspell '__thread' as '__tread' it fails as expected). Here's just the diff from the existing patch; I'll squash this in if it looks reasonable. From ef34d763145deb636c771b9c7bd3fb1bcbaa08ad Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Thu, 10 Dec 2015

Re: [PATCH xserver v2] dri3: Refuse to work for remote clients

Michel Dänzer writes: > +if (!client->local) > +return BadRequest; BadRequest is probably not the error code you want here; perhaps BadMatch? -- -keith signature.asc Description: PGP signature ___

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

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

[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 information. xfree86 SIGIO support is reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO. v2: Don't change locking order (Peter Hutterer) Signed-off-by: Keith Packard <kei...@keithp.com> --- Xi/exevents.c | 4 +- config/co

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

e by default on non-Linux This also splits out the actual enabling of input threads to DDX-specific patches which follow v3: Make the input lock recursive Signed-off-by: Adam Jackson <a...@redhat.com> Signed-off-by: Keith Packard <kei...@keithp.com> recursive lock --- configure.ac

[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 <kei...@keithp.com> --- mi/mieq.c | 103 +++--- 1 file changed, 32 insertions(

[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 <kei...@keithp.com> --- xkb/xkbActions.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index afe5edf..048ed44

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

Switch the XFree86 DDX over to threaded input Signed-off-by: Keith Packard <kei...@keithp.com> --- 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/x

[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 <kei...@keithp.com> --- 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 @@

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

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

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 show how it should work. Before applying that, all of the SIGIO support in

<    4   5   6   7   8   9   10   11   12   13   >