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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
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/
>
>> 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
>> 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
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.
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
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
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
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 -
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
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
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
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
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
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:
>
>
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
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
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
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
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,
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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:
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
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
.
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
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:
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
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
--
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
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
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
.
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
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
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
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
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
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
>
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
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
>
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
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
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
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
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
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
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
Kenneth Graunke writes:
>> Signed-off-by: Michel Dänzer
>
> Reviewed-by: Kenneth Graunke
Merged.
0924ac0..c833c08 master -> master
--
-keith
signature.asc
Description: PGP signature
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
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
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
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.
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
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
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
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
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
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
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
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
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/
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.
501 - 600 of 4634 matches
Mail list logo