Re: [PATCH 1/1] dix: Hold the input_lock() when accessing the miEventQueue through checkForInput

Jeremy Huddleston Sequoia writes: > Thoughts? Sounds like a plan. For functions which aren't called frequently, just grabbing the input_lock would be fine, I was mostly concerned with the dispatch loop. -- -keith signature.asc Description: PGP signature

Re: [PATCH 1/1] dix: Hold the input_lock() when accessing the miEventQueue through checkForInput

Jeremy Huddleston Sequoia writes: > Yeah, I made the change mainly to shutup the analyzer while I was > looking for other races. I decided to propose it in case we want to > be strict here. Thanks. Keeping our request processing overhead low seems important enough to me

Re: [PATCH xserver 02/14 v2] dix: Incroduce CursorConfinedTo vfunc in Screen

Jonas Ådahl writes: > This function will be called when a pointer is grabbed non-root window > set as the 'confineTo'. This will enable the ddx to handle the > confinement their own way. > > Signed-off-by: Jonas Ådahl > Reviewed-by: Peter Hutterer

Re: [PATCH xserver 01/14 v2] dix: Introduce CursorWarpedTo vfunc in Screen

Jonas Ådahl writes: > This new vfunc will be called, if set, after a client has issued a > WarpPointer request. This is necessary for implementing pointer warp > emulation in Xwayland. > > Signed-off-by: Jonas Ådahl > Reviewed-by: Peter Hutterer

Re: [PATCH 1/1] dix: Hold the input_lock() when accessing the miEventQueue through checkForInput

Jeremy Huddleston Sequoia writes: > == > WARNING: ThreadSanitizer: data race (pid=4943) > Read of size 4 at 0x00010c4e3854 by thread T8: > #0 WaitForSomething WaitFor.c:237 (X11.bin+0x00010049216c) > #1 Dispatch dispatch.c:413

Re: os/log.c thread safety

Jeremy Huddleston Sequoia writes: > FWIW, the issues surround these globals: > bufferUnused > bufferPos > LogSWrite.newline How about creating a separate mutex for these? It looks like we can do some minor reordering of code so that the mutex wouldn't need to be

Re: os/log.c thread safety

Jeremy Huddleston Sequoia writes: > [ Unknown signature status ] > I noticed a data race in XQuartz. We call ErrorF in a couple places off of > the main server thread. I could fix it by simply moving this logging onto > the server thread (or not doing it with os/log), but

Re: [PATCH 1/2] os/connection: Call ClientReady() based on a level trigger rather than an edge trigger

Matthieu Herrb writes: > this doesn't fix an issue I'm seeing on OpenBSD with xterm not beeing > able to start (it makes the X server spin at 100% CPU in > WaitForSomething()), while Jeremy's patches do fix the issue for me. I think Jeremy's patch will cause the server to

Re: [PATCH 2/2] os/connection: Remove NewOutputPending

Jeremy Huddleston Sequoia writes: > Use any_output_pending() instead. These aren't equivalent -- NewOutputPending is set when there is output pending and we haven't detected that all of the clients with output are blocked. There's a patch for a bug in FlushAllOutput to set

Re: [PATCH 1/2] os/connection: Call ClientReady() based on a level trigger rather than an edge trigger

Jeremy Huddleston Sequoia writes: > On encountering an EAGAIN, FlushClient() re-adds the client to the > pending list and returns, but FlushClient() doesn't get called again. > We would expect it to be called via FlushAllOutput() via > WaitForSomething(), but that only

Re: CARD32 vs uint32_t

Jeremy Huddleston Sequoia writes: > I'd really like to see us use stdint.h in Xmd.h. Are there any > arguments against doing such a change? We can't for client side because Xlib, but I'd love to switch the X server to stdint. I think that would be pretty easy? -- -keith

Re: [ANNOUNCE] xorg-server 1.18.99.2

Jeremy Huddleston Sequoia <jerem...@apple.com> writes: > [ Unknown signature status ] > >> On Sep 16, 2016, at 13:57, Keith Packard <kei...@keithp.com> wrote: >> >> >> I think we're ready for RC1 at this point, but wanted to give people a >>

Re: [PATCH xserver 1/2] modesetting: Fix reverse prime partial update issues on secondary GPU outputs

Eric Anholt writes: > glFlush by the spec does (not) provide any guarantees that things have > made it to the kernel. We have just assumed that, but I think the > Radeon driver may be violating that assumption these days. I'd say the radeon driver needs fixing then; we really

[PATCH xf86-input-libinput] Initializing strip association with wrong index

This looks like a cut coding error to me, and it generated a compiler warning about possibly uninitialized value. Signed-off-by: Keith Packard <kei...@keithp.com> --- src/xf86libinput.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xf86libinput.c b/src/xf86libi

Re: Proposed X server 1.19 schedule

Hans de Goede writes: Looks like all of these have been merged, thanks for tracking what remained to be done! > https://patchwork.freedesktop.org/patch/106849/ > https://patchwork.freedesktop.org/patch/106850/ > > https://patchwork.freedesktop.org/patch/105350/ >

Re: [PATCH xserver] xfree86/modes: Set RandR primary output from CreateScreenResources

>> Signed-off-by: Michel Dänzer > > Reviewed-by: Alex Deucher Merged. bd8ecd9..5b9f3ea master -> master -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH xserver] Add SyncSharedPixmap ScreenRec hook

>> Signed-off-by: Michel Dänzer > > Reviewed-by: Alex Deucher Merged. 7f6fa4e..bd8ecd9 master -> master -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH xserver] damage: Add screen func called before damage event delivery

Michel Dänzer writes: > I'm afraid I'm not sure this is going in a good direction. Yeah, with the WriteToClient changes from a few months ago, I think we need to do something though. We used to be able to rely on no events being delivered before the BlockHandler was invoked.

Re: [PATCH xserver] modesetting: fix compile error when --disable-glamor

Michel Dänzer writes: > But either way, with the bugzilla tag fixed, > > Reviewed-by: Michel Dänzer Merged with commit message updated as suggested. d81f9ce..7f6fa4e master -> master -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver 1/2] modesetting: Fix reverse prime partial update issues on secondary GPU outputs

Michel Dänzer writes: > I'm afraid not, because your patch only affects damage records for clients. Right, but it exposes a screen func for doing drawable-specific flushing. I thought that might be useful. -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver 1/2] modesetting: Fix reverse prime partial update issues on secondary GPU outputs

Michel Dänzer writes: > Yes, glamor_flush is sufficient if the kernel drivers handle fences > correctly. I sent out a patch to flush rendering to a specific drawable for use by the Damage extension. I wonder if that might be useful here? -- -keith signature.asc

Re: [PATCH 1/1] dix/dispatch: Fix SmartScheduleClient interval adjustment to use best rather than pClient

Keith Packard <kei...@keithp.com> writes: >> Regressed-in: 8f1edf4bd3a1f050ce9eeb5eac45dd1a8f7a6d5e >> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> > > Reviewed-by: Keith Packard <kei...@keithp.com> Merged. 265c4e6..d81f9ce master -

Re: [PATCH 1/1] dix/dispatch: Fix SmartScheduleClient interval adjustment to use best rather than pClient

thread_start (libsystem_pthread.dylib+0x39f6) > #6 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc) > > Regressed-in: 8f1edf4bd3a1f050ce9eeb5eac45dd1a8f7a6d5e > Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> Reviewed-by: Keith Packard &l

[PATCH xserver] damage: Add screen func called before damage event delivery

This lets the video driver flush rendering to the kernel before the client receives a damage event to a pixmap which the client has direct rendering access to. Signed-off-by: Keith Packard <kei...@keithp.com> --- damageext/damageext.c | 1 + glamor/glamor.c

Re: [PULL] Windows-DRI extension

Jon Turney writes: > Add Windows-DRI extension (2016-09-15 20:10:29 +0100) Merged. 3caf671..265c4e6 master -> master -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH xserver] config/dbus: Initialize dbus fd to -1 so teardown doesn't use fd 0

Peter Hutterer <peter.hutte...@who-t.net> writes: >> Signed-off-by: Keith Packard <kei...@keithp.com> > > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> Merged. 52d6a1e..3caf671 master -> master -- -keith signatu

Re: [PULL] Windows-DRI extension

Jon Turney writes: >> Do you want this included in 1.19? > > Yes please, if possible. > > I apologise for missing the feature cut-off date. I'm fine with that; you're pretty much in charge of the xwin code anyways. -- -keith signature.asc Description: PGP

Re: [PULL] Windows-DRI extension

Jon Turney writes: > Please consider pulling into master. > > The following changes since commit 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8: > > Hold input lock for deviceProc (2016-09-15 07:50:38 +1000) > > are available in the git repository at: > >

Re: Proposed X server 1.19 schedule

Keith Packard <kei...@keithp.com> writes: > [ Unknown signature status ] > > Following the 'release early and often' mantra, we should probably get > 1.19 out the door and let people start using the new code. > > I'd like to propose that we figure out what remaining non

[PATCH xserver] config/dbus: Initialize dbus fd to -1 so teardown doesn't use fd 0

The dbus teardown code is called when the server fatal errors even if that is before dbus has ever been initialized. By statically initializing the value of bus_info.fd, we avoid calling RemoveNotifyFd on stdin. Signed-off-by: Keith Packard <kei...@keithp.com> --- config/dbus-core.c | 2

Re: [PATCH:xserver] Use pthread_setname_np to set thread names if available

Alan Coopersmith writes: > Autoconf logic borrowed from glib This seems kinda nice to me, but I'd like to know how many configurations you've found to test this on? -- -keith signature.asc Description: PGP signature

Re: [PATCH:xserver] OsSigHandler should not show rtld errors for unrelated signals

Alan Coopersmith <alan.coopersm...@oracle.com> writes: > Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ x

Re: [PATCH xserver 00/12] xwayland: Pointer confinement and warping

Peter Hutterer writes: > Keith, I think the ABI changes should go in before we lock down, this is a > pretty important feature for the Wayland transition and our release cycles > aren't exactly predictable at this point. Yeah, the ABI changes look harmless enough,

Re: [PATCH xserver 1/2] Hold input lock for deviceProc

Peter Hutterer writes: > not needed but it won't hurt. Right, it seemed easier to just hold locks across all calls than to try to document why locks weren't required everywhere. I did have one place where I didn't want to grab the lock and added a comment there. >

[PATCH xserver 0/2] Hold input lock around all input device funcs

Two patches which ensure that input drivers aren't re-entered from the xserver, the first is for deviceProc, the second for setProperty. Reading input events is already taken care of by the input thread. -- -keith ___ xorg-devel@lists.x.org: X.Org

[PATCH xserver 2/2] Hold input lock while calling input device SetProperty callback

This keeps the input driver SetProperty function from being called while input events are being processed. Signed-off-by: Keith Packard <kei...@keithp.com> --- Xi/xiproperty.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c index 26d1206..b7a1f59

[PATCH xserver 1/2] Hold input lock for deviceProc

This ensures that the deviceProc is never called while the input thread is processing data from the device. Signed-off-by: Keith Packard <kei...@keithp.com> --- dix/devices.c | 22 +++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/dix/devices.c b/dix/dev

Re: [PATCH v2 xserver] glamor: Fix crash when master gpu is using glamor and another gpu is hotplugged

Hans de Goede <hdego...@redhat.com> writes: > Signed-off-by: Hans de Goede <hdego...@redhat.com> > --- > Changes in v2: > -Set lastGLContext to NULL instead of saving and restoring the current > context Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith

Re: [PATCH v5 xserver 1/7] dix: Add dixPrivatesCreated helper function

1/7: Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Proposed X server 1.19 schedule

Adam Jackson writes: > ... move the non-critical bug deadline to 2016-10-01? Still leaves > three weeks for critical fixes. Either way, looks plausible to me. I > don't personally have any non-bug changes I want to land before 1.19. Yeah, sounds good. We don't usually get many

Re: [PATCH v5 xserver 1/7] dix: Add dixPrivatesCreated helper function

Hans de Goede writes: > From: Dave Airlie > > This is a preparation patch for adding prime hw-cursor support. I'm fine with this function, but the prime hw-cursor support which uses it is a pretty ugly kludge, depending on the hot-plugged device never

Re: Proposed X server 1.19 schedule

Hans de Goede writes: > That is quick :) Fine by me, but I've a whole bunch of > modesetting / prime patches (all bugfixes really) I would like to get in > before then. As you can see, bug fixes are welcome until 9-24. All that closes 9-10 is new feature development. If

Re: [PATCH xserver] cursor: add hw cursor support for prime

Hans de Goede writes: > +if (!dixPrivatesCreated(PRIVATE_CURSOR)) > +dixRegisterScreenPrivateKey(, pScreen, > +PRIVATE_CURSOR, 0); > + I don't understand what you're trying to do here; you're only registering the screen

Proposed X server 1.19 schedule

Following the 'release early and often' mantra, we should probably get 1.19 out the door and let people start using the new code. I'd like to propose that we figure out what remaining non-bug changes we'd like to get merged in the next week (or two?), then move into a non-critical bug fix period

Re: [PATCH xserver] modesetting: Do not use function local static variables

n a per screen struct. While at it actually make it per > crtc data as in theory different crtc's could have different hw-cursor > support. > > Signed-off-by: Hans de Goede <hdego...@redhat.com> The things you find if you look long enough... Reviewed-by: Keith Packard <kei

Re: [PATCH v2 xserver 1/3] modesetting: ms_covering_crtc: Remove unused arguments, make static

eaner. > > Signed-off-by: Hans de Goede <hdego...@redhat.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 v2 xserver 1/2] glamor: Add glamor_shareable_fd_from_pixmap()

ixmapBacking callback. > > Signed-off-by: Hans de Goede <hdego...@redhat.com> For the series: Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Arc

Re: [PATCH xserver 0/6] modesetting: add DRI2 page flip support

Michel Dänzer writes: > This does mean though that if one has only up to patch 3 applied (e.g. > during a bisection), one is exposed to the issues fixed by patch 4. So > maybe patch 4 should be squashed into patch 3. That's a very important point -- developing code in small

Re: [PATCH] xace: Fix XaceCensorImage to actually censor the right part of the image

Aaron Plattner writes: > Aargh, stupid borders. I always forget about them. I guess this is why > we have regression tests. You just don't recall the whole original fight about borders. Left in X11 solely for X10 compatibility. Aren't you glad we have them? -- -keith

Re: [PATCH xf86-input-libinput] Always delay hotplugging subdevices

Peter Hutterer writes: > Avoid creating new devices from within the input thread which was the case for > tablet tools. It requires a lot more care about locking and has a potential to > mess up things. > > Instead, schedule a WorkProc and buffer all events until we

Re: [PATCH xserver] modesetting: Fix msSharePixmapBacking returning a non-linear bo

Hans de Goede writes: > An alternative solution would be to add a flag argument to > glamor_fd_from_pixmap, so that callers like this one which > know for sure they want a linear bo can specify that through > a flag, and other callers can just pass in: fd_from_pixmap is the

Re: Michel Dänzer is invited to help maintain master X server branch

Michel Dänzer writes: > Many glamor changes have been pushed by Adam or Keith lately. Is that > intentional, i.e. is it okay for others to push glamor changes which are > ready, or should we always get in touch with Eric first? Would saying "it depends" help at all? When

Re: [PATCH xserver] glamor: Declare "pos" in the composite glyph GLSL 1.20 vertex shader

inv; > } > (EE) Fatal server error: > (EE) GLSL compile failure > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97300 > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Descript

Re: [PATCH xserver] Fix Xorg -configure not working anymore

Adam Jackson writes: > Perhaps we'd want to move to a model where xorg.conf.d comes pre- > populated with the default settings (possibly just commented out). If > done properly we could entirely throw out xf86AutoConfig.c, which > certainly has its appeal. I wonder if the main

Re: [PATCH xserver] modesetting: Fix msSharePixmapBacking returning a non-linear bo

Hans de Goede writes: > Some code paths end up in msSharePixmapBacking with a pixmap > which does not have its usage_hint set to sharable. > > This causes glamor_fd_from_pixmap() to create a non-linear bo, > which is wrong for a shared pixmap. > > This commits sets the

[PATCH xserver] config: Hold input lock across udev socket handling

This avoids having the server running inside libudev from two threads at once, which it appears to not like. Signed-off-by: Keith Packard <kei...@keithp.com> --- config/udev.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/config/udev.c b/config/udev.c index 2

Re: [PULL xserver] Gamma fix for modesetting (and any other drivers which don't call xf86HandleColormaps)

Michel Dänzer writes: > Pushed myself, based on Keith's acknowledgement on IRC (thanks): > > MrCooper: [...] I think having you merging patches would be a > good idea at this point though. Thanks! -- -keith signature.asc Description: PGP signature

Michel Dänzer is invited to help maintain master X server branch

be kind to them. * Eric Anholt - glamor * Alan Coopersmith - security * Peter Hutterer - input * Adam Jackson - xfree86 backend * Keith Packard- misc * Michel Dänzer- mode setting stuff? glamor? (please let us know!) A patch is ready for merging when it has been has been

Re: [PATCH xserver] dix: Avoid writing uninitialized bytes in deliverPropertyNotifyEvent

Hans de Goede <hdego...@redhat.com> writes: >> Signed-off-by: Keith Packard <kei...@keithp.com> > Reviewed-by: Hans de Goede <hdego...@redhat.com> Thanks for your review! Merged. 67fc5d6..fa2bc06 master -> master -- -keith signature.

Re: [PATCH xserver 2/2] os: Abandon loop after poll call when array of fds has changed

Peter Hutterer writes: > Reviewed-by: Peter Hutterer Both pushed. 69b782a..67fc5d6 master -> master -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org

Re: [PATCH xserver 2/2] os: Abandon loop after poll call when array of fds has changed

Peter Hutterer writes: >> -#if !HAVE_OSPOLL && HAVE_EPOLL_CREATE1 >> +#if !HAVE_OSPOLL && HAVE_EPOLL_CREATE1 && 0 > > that looks like a leftover? aside from that it looks good. Yeah, sorry, that's how I tested the poll path :-) -- -keith signature.asc Description:

Re: [PATCH xserver] Build glamor when Xorg or Xephyr are built.

Michel Dänzer writes: > What about Xwayland? Sorry, I didn't even think of that! -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel

Re: [PATCH xf86-input-libinput] Ensure parent devices are actual parent devices

her > subdevice on the same already-removed parent). Avoid this by making sure the > matched device is actually a parent device. > > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> Tested-by: Keith Packard <kei...@keithp.com> -- -keith s

[PATCH xf86-input-libinput] Bail when a sub-device is it's own parent

. Signed-off-by: Keith Packard <kei...@keithp.com> --- src/xf86libinput.c | 4 1 file changed, 4 insertions(+) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 45385f7..9be4354 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -2589,6 +2589,10 @@ xf86libinput_pr

[PATCH xserver 0/2] os: Handle ospoll callbacks adding/removing fds

Here are a couple of patches which deal with the case where the fd callback ends up enabling or disabling file descriptors. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info:

[PATCH xserver 2/2] os: Abandon loop after poll call when array of fds has changed

If a file descriptor is added or removed from an ospoll callback, then the arrays containing file descriptor information will have all of their indices changed, so the loop state is no longer consistent. Just bail out and let the caller come back around to try again. Signed-off-by: Keith Packard

[PATCH xserver 1/2] os: Delay freeing of epoll_wait return pointers until epoll is idle.

keeps stale pointers around after the call to epoll_ctl with EPOLL_CTL_DEL. Signed-off-by: Keith Packard <kei...@keithp.com> --- os/ospoll.c | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/os/ospoll.c b/os/ospoll.c index 3c2b80b..2996ac7 100644 --

[PATCH xserver] dix: Avoid writing uninitialized bytes in deliverPropertyNotifyEvent

Make sure the whole event is initialized, instead of leaving the pad bytes unset. Signed-off-by: Keith Packard <kei...@keithp.com> --- dix/property.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/dix/property.c b/dix/property.c index bde2af8..fa4da2d

Re: [PATCH xserver] mi: Remove spurious call to OsReleaseSignals from mieqGrowQueue

Peter Hutterer <peter.hutte...@who-t.net> writes: > On Thu, Aug 11, 2016 at 09:35:35PM -0700, Keith Packard wrote: >> This call wasn't converted to 'input_unlock()' when the SIGIO code was >> removed from the server, and so when the queue growing was reworked to >> be

[PATCH xserver] Build glamor when Xorg or Xephyr are built.

Requires gbm when building Xorg so that xf86-video-modesetting will work. Signed-off-by: Keith Packard <kei...@keithp.com> --- configure.ac | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 2b93a4a..e206e0f

[PATCH xserver] mi: Remove spurious call to OsReleaseSignals from mieqGrowQueue

. Signed-off-by: Keith Packard <kei...@keithp.com> --- configure.ac | 17 +++-- mi/mieq.c| 1 - 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 690035a..e206e0f 100644 --- a/configure.ac +++ b/configure.ac @@ -654,7

Re: [PATCH xserver] xfree86: lock input during PreInit

Peter Hutterer <peter.hutte...@who-t.net> writes: > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-dev

Re: [PATCH xserver] xfree86: fix unbalanced input_lock/unlock in xf86NewInputDevice()

seSignals call is, but it is safer to place it where you have. With the call to OsReleaseSignals removed, this is Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver] os: don't re-remove an already removed fd

db657c11973c457f4eb4 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Thu, 11 Aug 2016 12:34:54 -0700 Subject: [PATCH xserver] os: Allow re-registering fd with InputThreadRegisterDev Calling InputThreadRegisterDev twice with the same fd should replace the existing functio

Re: [PATCH xserver] os: don't re-remove an already removed fd

Peter Hutterer writes: > wacom does. and yes, it needs to get fixed in the driver now that it > doesn't work anymore but meanwhile not crashing is still good. Right, wondering if simply not registering the duplicate FD would also work? -- -keith signature.asc

Re: [PATCH xserver] os: don't re-remove an already removed fd

Peter Hutterer writes: > If a driver calls xf86RemoveEnabledDevice() twice for the same fd we race with > InputThreadDoWork(). If it gets called in between both fd entries are removed. > If InputThreadDoWork() does not get called in between, we merely try to remove >

Re: [PATCH xserver] os: append, rather than prepend, any new input thread fds

can't matter" inside the server, so it makes sense to accept it so wacom keeps working until the driver is fixed. > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith

Re: [JANITOR] Request for review

Kayo Hamid writes: > I'm trying to do one janitor task looking for bad allocations. Someone > could review my diff and see if is okay? > > Thanks. > > -- > Kayo Hamid > diff --git a/dix/enterleave.c b/dix/enterleave.c > index 1b341f2..8cec9a2 100644 > --- a/dix/enterleave.c >

Re: [PATCH xserver] Pass ClientPtr to FlushCallback

Michel Dänzer writes: > I'm afraid that's not feasible: An additional optimization will be to > never flush for clients which aren't sharing any buffers with the server > via DRI. Only the driver can keep track of that. The DRI3 extension and glamor presumably know about

Re: [PATCH] modesetting: prefer primary crtc when picking over nothing

Michel Dänzer writes: > I stand corrected. I was thinking of the primary output as reported by > xrandr. I had to actually go read the code; I had not remembered what 'RRFirstOutput' did either. Shockingly, there's a *comment* describing what it does. What was that author

Re: [PATCH] modesetting: prefer primary crtc when picking over nothing

Michel Dänzer writes: > This can indeed only avoid the problem by accident, since there's no > guarantee that the primary output is even connected. Actually, he used the RRFirstOutput function which does find something connected to an active CRTC, so at least it should work

Re: [PATCH] modesetting: prefer primary crtc when picking over nothing

Dave Airlie writes: > So we had a bug report that epiphany was rendering slow on > modesetting + DRI3, that I tracked down to the fact it was > rendering offscreen to a single buffer. However due to this > rendering being offscreen we were getting the fake crtc > chosen by the

Re: [PATCH xserver] Pass ClientPtr to FlushCallback

Eric Anholt writes: > We glFlush in the BlockHandler in glamor. Sure, what ensures that is called before damage events are delivered? -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver] Pass ClientPtr to FlushCallback

Michel Dänzer writes: > From: Michel Dänzer > > This change has two effects: > > 1. Only calls FlushCallbacks when we're actually flushing data to a >client. The unnecessary FlushCallback calls could cause significant >performance degradation

Re: [PATCH v2 xserver] Autoconfig: Fix the loop adding dectected drivers to the list of screens

for instance). > > Signed-off-by: Matthieu Herrb <matth...@herrb.eu> 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] present: Handle event mask updates as specified v2

Kenneth Graunke writes: >> Signed-off-by: Michel Dänzer > > Reviewed-by: Kenneth Graunke Merged. 0924ac0..c833c08 master -> master -- -keith signature.asc Description: PGP signature

Re: [PATCH xserver] Autoconfig: Fix the loop adding dectected drivers to the list of screens

Matthieu Herrb writes: > @@ -389,8 +389,7 @@ autoConfigDevice(GDevPtr preconf_device) > > /* for each other driver found, copy the first screen, insert it > * into the list of screens and set the driver */ > -i = 0; > -while

Re: [PATCH xserver] xfree86/modes: Use xf86ScrnToScreen in xf86RandR12LoadPalette

ntested patch which should fix this: From f96e5432370b74a7b1bc9ed528f0f971d39a5951 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Fri, 29 Jul 2016 17:45:45 -0700 Subject: [PATCH xserver] xfree86: Set pScrn->pScreen before driver ScreenInit is called Any code called from the dr

Re: [PATCH xserver] present: Handle event mask updates as specified v2

Michel Dänzer <mic...@daenzer.net> writes: > 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.o

Re: [PATCH xserver] present: Handle event mask updates as specified

Michel Dänzer writes: > Thanks, I incorporated almost all your changes in v2, with the exception > of not calling LEGAL_NEW_RESOURCE if mask == 0, due to this spec language: > > If eventContext is an unused XID, then if eventMask is empty > no operation is performed.

Re: [PULL xserver] Hook up colormaps and RandR 1.2 gamma ramps, present crash fix

Michel Dänzer writes: > Michel Dänzer (4): > xfree86/modes: Move gamma initialization to xf86RandR12Init12 v2 > xfree86/modes: Remove xf86RandR12CrtcGetGamma > xfree86: Hook up colormaps and RandR 1.2 gamma code v6 > present: Only call

Re: [PATCH xserver] present: Handle event mask updates as specified

Kenneth Graunke writes: > Looks good to me, thanks for fixing this! > > Reviewed-by: Kenneth Graunke -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver 1/3] xfree86/modes: Move gamma initialization to xf86RandR12Init12 v2

walter harms writes: > 1. I do not want to start an argument here. Your comments are welcome and helpful. > but i seems i need to explain what i wanted to say: > "b and c do not change inside the loop" > > that does *not* mean I have to say: const double or so. Right, the

Re: [PATCH xserver] present: Handle event mask updates as specified

ou don't need to free the object in the failure path. Here's an alternate (untested) patch which shows what I meant; use whatever bits of this seem useful. From 9b5604ee4ea71576c16961af79df2a4cf487acd7 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Thu, 28 Jul 2016 09:46:59 -0

Re: [PATCH xserver 1/3] xfree86/modes: Move gamma initialization to xf86RandR12Init12 v2

Matt Turner writes: > I feel confident the compiler is already doing that transformation. I just tried and couldn't get the compiler to do it as the 'pow' function isn't declared with the 'const' attribute. That appears to be a bug in glibc. This code does what you'd

Re: [PATCH xserver 3/3] xfree86: Hook up colormaps and RandR 1.2 gamma code v6

Michel Dänzer <mic...@daenzer.net> writes: > [ Unknown signature status ] > On 28.07.2016 00:02, Keith Packard wrote: >> Michel Dänzer <mic...@daenzer.net> writes: >> >>> v6: >>> * Handle reallocarray failure in xf86RandR12LoadPalette (Keith Pac

Re: [PATCH xserver 3/3] xfree86: Hook up colormaps and RandR 1.2 gamma code v6

Michel Dänzer <mic...@daenzer.net> writes: > v6: > * Handle reallocarray failure in xf86RandR12LoadPalette (Keith Packard) Yeah, that'll work. Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Descript

Re: [PATCH xserver 3/3] xfree86: Hook up colormaps and RandR 1.2 gamma code v5

Michel Dänzer writes: > +if (randrp->palette_size != palette_size) { > +randrp->palette = reallocarray(randrp->palette, palette_size, > + sizeof(colors[0])); Need error checking here. Wow. Otherwise, this patch looks great

[PATCH xf86-video-nouveau] Use NotifyFd for drm and udev fds

NotifyFd is available after API 22, and must be used after API 23. Signed-off-by: Keith Packard <kei...@keithp.com> --- src/compat-api.h | 4 src/drmmode_display.c | 36 2 files changed, 40 insertions(+) diff --git a/src/compat-api.h b/src/

Re: [PATCH xserver 0/2] hw/xwin build fixes after poll changes

Jon Turney writes: > I haven't tried building this for MinGW, I guess there might be some more > fixes needed there... > > Jon Turney (2): > hw/xwin: Update for removal of AddEnabledDevice > hw/xwin: Update BlockHandler function signature Merged.

<    1   2   3   4   5   6   7   8   9   10   >