Re: [PATCH xserver] dix: Allow secondary threads to use the work queue

Peter Hutterer writes: > looking at this again because I realised that timers are used as well and it > turns out they already have input_lock(), see 8174daa6bd3f. Can we just use > input_lock()/input_unlock() here rather than a new mutex? A fine plan. We should call

[PATCH xf86-input-libinput 3/3] Open sysfs files directly instead of going through the server

Only use-case here are pad mode LEDs that now live in /sys/class/leds. Asking the server to open them is pointless, the server only knows how to open Option "Device". And since the LEDs are in sysfs we should have access to them anyway, so no need for jumping through or hula-ing hoops.

[PATCH xf86-input-libinput 1/3] Add streq() macro, replace strcmp instances with it

And why isn't this a thing in glibc yet Signed-off-by: Peter Hutterer --- src/xf86libinput.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 703d872..c1214b7 100644 ---

[PATCH xf86-input-libinput 2/3] Update pad modes in a workproc, not during the input thread

Updating the property directly causes us to send events from the input thread which has some "interesting" side effects like messing up the reply order or just crashing the server. Schedule a work proc instead and update it whenever the server is back in the main thread. Signed-off-by: Peter

Re: [PATCH xserver] dix: Allow secondary threads to use the work queue

On Fri, Feb 24, 2017 at 07:31:32AM +1000, Peter Hutterer wrote: > On Thu, Feb 23, 2017 at 04:25:35PM -0500, Adam Jackson wrote: > > The work queue code is reentrant with itself on a single thread, but not > > when the queue is modified from thread A while being run on thread B. > > We will only

Re: [PATCH xserver] edid: Prune duplicates after adding modes from DDC

On 24/02/17 05:21 AM, Emil Velikov wrote: > On Wednesday, 22 February 2017, Michel Dänzer > wrote: > > @@ -1198,21 +1198,19 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr > Monitor, xf86MonPtr DDC) > if (!Monitor->nHsync ||

Re: [PATCH xserver] edid: Prune duplicates after adding modes from DDC

On 23/02/17 06:46 AM, Chen, Xiaogang wrote: >> From: Michel Dänzer [mailto:mic...@daenzer.net] >> >> Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by running >> xrandr) would potentially keep adding the same modes, causing the Monitor- >>> Modes list to keep growing larger and

Re: Virtual Touch Events for XTEST

Thanks for your valuable help peter. As you suggested, I am able to simulate touch events by using uinput "virtual touch driver" and modified xorg.conf to load it. But the only quirk is, I have to create a separate "virtual touch device" and xorg.conf for each instance of X session. Commands I

Re: [PATCH xserver] Xi: Hold the input lock when sending events

On Thu, Feb 23, 2017 at 12:51:39PM -0500, Adam Jackson wrote: > On Thu, 2017-02-23 at 09:00 +1000, Peter Hutterer wrote: > > On Wed, Feb 22, 2017 at 10:48:24AM +0100, Olivier Fourdan wrote: > > > > > > @@ -203,10 +203,12 @@ send_property_event(DeviceIntPtr dev, Atom > > > property, int what) > >

Re: Virtual Touch Events for XTEST

On Thu, Feb 23, 2017 at 07:00:34PM +0530, Prakash P wrote: > Thanks for your valuable help peter. > > As you suggested, I am able to simulate touch events by using uinput > "virtual touch driver" and modified xorg.conf to load it. But the only > quirk is, I have to create a separate "virtual

Re: Virtual Touch Events for XTEST

On Thu, Feb 23, 2017 at 02:16:40PM +0700, Antoine Martin wrote: > On 23/02/17 09:59, Peter Hutterer wrote: > > On Wed, Feb 22, 2017 at 12:25:07PM +0530, Prakash P wrote: > >> ​​ > >> Hi, > >> > >> I want to create an virtual test environment for my web application. I got > >> it working with the

[PATCH v2 xserver] os: log a bug whenever WriteToClient is called from the input thread

The input thread should generate events, not send them. Make it easier to find the instances where it's doing so. Signed-off-by: Peter Hutterer Tested-by: Olivier Fourdan --- Changes to v1: - add check for InputThreadInfo to avoid null-pointer

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

On Thu, Feb 23, 2017 at 05:12:10PM +0100, walter harms wrote: > > > Am 23.02.2017 01:22, schrieb Peter Hutterer: > > The input thread should generate events, not send them. Make it easier to > > find the instances where it's doing so. > > > > Signed-off-by: Peter Hutterer

Re: [PATCH xserver] dix: Allow secondary threads to use the work queue

On Thu, Feb 23, 2017 at 04:25:35PM -0500, Adam Jackson wrote: > The work queue code is reentrant with itself on a single thread, but not > when the queue is modified from thread A while being run on thread B. > We will only ever run it from the main thread, but the input thread > wants to be able

Re: [PATCH xserver] configure: Xephyr, xfake and xfbdev require kdrive

On Thu, Feb 23, 2017 at 10:34:30AM +0100, Olivier Fourdan wrote: > Raise an error at configure time if one of the DDX that require kdrive > is enabled but kdrive itself is not. > > That avoids the build to silently ignore Xephyr, Xfake and Xfbdev if > --enable-kdrive is not set as well. > >

[PATCH xserver] dix: Allow secondary threads to use the work queue

The work queue code is reentrant with itself on a single thread, but not when the queue is modified from thread A while being run on thread B. We will only ever run it from the main thread, but the input thread wants to be able to queue work for event emission. Mutex the list so it can do so

Re: [PATCH xserver] edid: Prune duplicates after adding modes from DDC

On Wednesday, 22 February 2017, Michel Dänzer wrote: > From: Michel Dänzer > > > Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by > running xrandr) would potentially keep adding the same modes, causing > the

Re: xserver 1.19.2 call for patches

On Mon, 2017-02-20 at 18:36 +0900, Michel Dänzer wrote: > I nominate the following commits: > > b5b292896f64 ("prime: Sync shared pixmap from root window instead of > screen pixmap") > a6566f9e4dbf ("prime: Clear PixmapDirtyUpdateRec::damage when it's > destroyed") > > Maybe squash these two in

Re: xserver 1.19.2 call for patches

On Fri, 2017-02-17 at 03:05 -0500, Olivier Fourdan wrote: > Hey Adam, > > > I'd like to do another 1.19 soonish, say middle of next week. If you've > > got favorite patches you'd like to see included, please write their > > sha1s on the back of a $50 bill and send them to me. > > > >

Re: [PULL xserver 1.19] intel happy go crashy fixes

On Fri, 2017-02-17 at 15:18 +1000, Peter Hutterer wrote: > Improves the user experience by not crashing frequently. The fixes aren't > intel-specific per-se, but only that driver seems to trigger them. See > https://bugs.freedesktop.org/show_bug.cgi?id=99358 > > This are for 1.19.2, s per subject

Re: [PATCH xserver 2/3] xfbdev: Remove

On Thu, 2017-02-16 at 12:46 -0500, Adam Jackson wrote: > With the shadow framebuffer overallocation bug fixed (ref below), Xorg + > fbdev has tens to hundreds of kilobytes more baseline memory usage than > Xfbdev. That's not nothing, but it's little enough that we should focus > our efforts on the

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Am 23.02.2017 17:16, schrieb Olivier Fourdan: > Hi, > >>> +extern inline int >>> +in_input_thread(void); >>> + >> >> maybe i am old fashion but this should be done with input.h, should it ? > > No, I don't think this is possible (in the middle of a stable release) nor > even suitable, it's

Re: [PATCH xserver] Revert "xwayland: bump wayland-protocols version to 1.7"

On Fri, 2017-02-17 at 09:16 +0100, Olivier Fourdan wrote: > This reverts commit 371ff0c969a38a0013688391bbd7375bc7b6f933. > --- >  I'm really sorry, I got confused, pointer contraints does not require >  1.7 and 1.1 was enough... > >  While it's not a major issue as 1.7 is a released version, we

Re: [PATCH xserver] glamor: Declare "pos" in glamor_dash.c

On Thu, 2017-02-23 at 13:28 +, Eric Engestrom wrote: > I looked a bit more into this, and while I don't know much about glamor > (or glsl, to be honest), I don't think this fix is correct. > > Was `pos` in glamor_program.c intended to be `gl_Position`, by any > chance?  That would make more

Re: [PATCH xserver v2 5/5] xwayland: use _XWAYLAND_ALLOW_COMMITS property

On Fri, 2017-02-17 at 13:56 +0200, Pekka Paalanen wrote: > The following changes since commit 461aa95591fef046d3b9e8ab9182fd750a6f1de2: > >   tests: fixes for non-enable-xorg build (2017-02-17 12:02:53 +0200) > > are available in the git repository at: > >  

Re: [PATCH v7 xserver] tests: fixes for non-enable-xorg build

On Fri, 2017-02-17 at 12:20 +0200, Pekka Paalanen wrote: > This "patch" fixes those failures for me, and 'make check' is happy. Merged: remote: E: failed to find patch for rev fde5cd78488f3370c92397868ca78929296f7ad1. remote: I: 0 patch(es) updated to state Accepted. To

Re: Bug in xorg-xserver - missing declaration!

On Wed, 2017-02-22 at 12:08 +0100, Stefan Dirsch wrote: > Just tested your patch. I could verify, that it fixes the crash when running > tgif with your special .obj file inside of > >   Xephyr -glamor > > So you have my > >   Tested-by: Stefan Dirsch Merged: remote: E:

Re: [PATCH xserver] Xi: Hold the input lock when sending events

On Thu, 2017-02-23 at 09:00 +1000, Peter Hutterer wrote: > On Wed, Feb 22, 2017 at 10:48:24AM +0100, Olivier Fourdan wrote: > > > > @@ -203,10 +203,12 @@ send_property_event(DeviceIntPtr dev, Atom property, > > int what) > >  .what = what > >  }; > >   > > +input_lock(); > >  

Re: [PATCH RFC xserver] os: Add a mutex to protect io buffers

On Wed, 2017-02-22 at 15:20 -0800, Keith Packard wrote: > > Adam Jackson writes: > > > On Wed, 2017-02-22 at 16:50 +0100, Olivier Fourdan wrote: > > > WriteToClient() can be called from XIChangeDeviceProperty() so from the > > > InputThread which is a problem as it allocates and

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Hi, > > +extern inline int > > +in_input_thread(void); > > + > > maybe i am old fashion but this should be done with input.h, should it ? No, I don't think this is possible (in the middle of a stable release) nor even suitable, it's not a new API intended for drivers to use, it's purely

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Am 23.02.2017 01:22, schrieb Peter Hutterer: > The input thread should generate events, not send them. Make it easier to > find the instances where it's doing so. > > Signed-off-by: Peter Hutterer > --- > include/input.h | 1 + > os/inputthread.c | 7 +++ >

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Hi, > > The input thread should generate events, not send them. Make it easier to > > find the instances where it's doing so. > > > > Signed-off-by: Peter Hutterer > > --- > > include/input.h | 1 + > > os/inputthread.c | 7 +++ > > os/io.c | 6 ++ >

[PATCH xserver] glamor: Declare "pos" in glamor_dash.c

From: "Dr.-Ing. Dieter Jurzitza" Fixes compile failure: Failed to compile VS: 0:13(43): error: `pos' undeclared 0:13(14): error: operands to arithmetic operators must be numeric 0:13(13): error: operands to arithmetic operators must be numeric Program source:

[PATCH xserver] configure: Xephyr, xfake and xfbdev require kdrive

Raise an error at configure time if one of the DDX that require kdrive is enabled but kdrive itself is not. That avoids the build to silently ignore Xephyr, Xfake and Xfbdev if --enable-kdrive is not set as well. Signed-off-by: Olivier Fourdan --- configure.ac | 11

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

> The input thread should generate events, not send them. Make it easier to > find the instances where it's doing so. > > Signed-off-by: Peter Hutterer > --- > include/input.h | 1 + > os/inputthread.c | 7 +++ > os/io.c | 6 ++ > 3 files changed, 14