From: Keith Packard kei...@keithp.com
Date: Tue, 19 Nov 2013 22:36:50 -0800
Keith Packard kei...@keithp.com writes:
This makes the xshmfence stuff only used if the driver specifies it,
allowing drivers to specify other FD-passing based fences, and also
avoiding errors if a driver
From: Keith Packard kei...@keithp.com
Date: Tue, 19 Nov 2013 22:35:13 -0800
Keith Packard kei...@keithp.com writes:
The new MIT-SHM CreateSegment request needs to stick the requested
shared memory file someplace in the file system. Precisely where it
needs to live depends on the
Date: Tue, 12 Nov 2013 07:21:19 +0100
From: Matthieu Herrb matth...@herrb.eu
On Mon, Nov 11, 2013 at 11:22:56PM +0100, Mark Kettenis wrote:
From: Mark Kettenis kette...@openbsd.org
A char array on the stack is not guaranteed to have more than byte
alignment. This means that casting
On Wednesday 20 November 2013, Keith Packard wrote:
Keith Packard kei...@keithp.com writes:
This makes the xshmfence stuff only used if the driver specifies it,
allowing drivers to specify other FD-passing based fences, and also
avoiding errors if a driver doesn't initialize any
This uses pthread mutexes and condition variables instead of futexes.
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 25 +
src/Makefile.am | 10 +++-
src/xshmfence_pthread.c | 132
Keith, can you please fix the xshmfence API to use either 'void *' or
an opaque 'struct xshmfence *' instead of 'int32_t *' before we have
to live with this design mistake forever?
I spent this morning cleaning up libxshmfence; it should now work on
non-Linux systems that support process
Signed-off-by: Keith Packard kei...@keithp.com
---
Makefile.am | 2 +-
configure.ac | 1 +
test/Makefile.am | 9 +++
test/xshmfence_test.c | 178 ++
4 files changed, 189 insertions(+), 1 deletion(-)
create mode 100644
Expose only the official API.
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 43 +++
src/xshmfence.h | 16 +---
xshmfence.pc.in | 2 +-
3 files changed, 53 insertions(+), 8 deletions(-)
diff --git a/configure.ac
This splits the futex-specific code out into a separate file so that
future versions of the library could use some other underlying primitive.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/Makefile.am | 7 ++-
src/xshmfence.c | 158
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 43 +++
src/xshmfence.c | 6 +-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 2780ac5..02359e1 100644
--- a/configure.ac
+++
This will allow other implementations to use alternate
representations, as well as providing additional typechecking.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/xshmfence.c| 36
src/xshmfence.h| 16 +---
src/xshmfenceint.h | 1
Signed-off-by: Keith Packard kei...@keithp.com
---
src/xshmfence.c| 14 ++
src/xshmfenceint.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/xshmfence.c b/src/xshmfence.c
index ecf2f4a..ed2b4c4 100644
--- a/src/xshmfence.c
+++ b/src/xshmfence.c
@@
Fredrik Höglund fred...@kde.org writes:
I also decided to try passing a regular sync fence to DRI3FDFromFence.
I expected it to generate an error, but it didn't. Instead it returned
a valid file descriptor. I don't know if this is a bug or not.
Nice catch. miSyncFDFromFence is supposed to
Mark Kettenis mark.kette...@xs4all.nl writes:
I still think the X server should not be concerned with picking a
suitable directory, but instead should use shm_open/shm_unlink...
shm_open has security problems, so it's just a non-starter.
...but some thought is required on how to use
On Sun, 2013-11-17 at 10:24 -0800, Alan Coopersmith wrote:
No point building linking empty *.o files into the drivers.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives:
On Fri, 2013-11-15 at 17:00 -0800, Connor Behan wrote:
Signed-off-by: Connor Behan connor.be...@gmail.com
Series:
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives:
On Sat, 2013-11-16 at 20:42 -0800, Alan Coopersmith wrote:
C89 or bust! This was documented as being needed for only Lynx,
Linux-libc5, OS/2 and has never been enabled in modular builds,
since none of those platforms have had anyone step up to add support
since the X11R7 conversion to
On Sat, 2013-11-16 at 20:43 -0800, Alan Coopersmith wrote:
File exists as a placeholder in case someone someday decides to add
additional auth methods on top of what libICE provides, but it's been
two decades and no one has, so stop spending time compiling linking
for now.
Signed-off-by:
On Mon, 2013-11-18 at 16:58 -0800, Keith Packard wrote:
Signed-off-by: Keith Packard kei...@keithp.com
---
Note that this changes the API to the library; the X server, in
particular, requires changes before this can be merged.
Looks like a reasonable change, but it'd be a little unfortunate
Hi
I'm having a hard time with the following problem concerning an eGalaxTouch
device.
At first sight, everything seems to be working fine using the evdev driver
with libmtdev. I have no problem with pinch/zoom etc. But after a short
time Xserver emits button-press events immediately after
On Mon, 2013-11-18 at 21:14 +0100, Matthieu Herrb wrote:
Makes it possible to run the nv driver without XAA on cards where
EXA is not supported.
Signed-off-by: Matthieu Herrb matth...@herrb.eu
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
Here's a series of patches which provide DRI3 and Present support in
the Intel 2D driver. The first two patches pave the way by
synthesizing 64-bit vblank counters and extending the DRM event
handling to allow for both DRI2 and DRI3 events. Then there's a patch
to add DRI2 and miSyncShm support
This refactors the drm interrupt handling logic quite a bit, both to
allow for either DRI2 or Present handlers, but also to eliminate
passing pointers through the kernel. Passing pointers left the kernel
holding the only reference to some internal X server data structures.
After a server reset,
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac | 14
src/uxa/Makefile.am| 7 ++
src/uxa/intel.h| 17 +
src/uxa/intel_dri3.c | 184 +
src/uxa/intel_driver.c | 13
src/uxa/intel_sync.c |
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 15 ++
src/uxa/Makefile.am | 6 +
src/uxa/intel.h | 15 ++
src/uxa/intel_driver.c | 4 +
src/uxa/intel_present.c | 406
5 files changed, 446
The kernel sometimes reports bogus MSC values, especially when
suspending and resuming the machine. Deal with this by tracking an
offset to ensure that the MSC seen by applications increases
monotonically, and at a reasonable pace.
Also, provide a full 64 bits of MSC value by noticing wrapping
On Sun, 2013-11-17 at 00:01 -0800, Keith Packard wrote:
1) Handle string constants by declaring lots of stuff as
'const char *'. We use string constants all over the server,
and carelessly store them in 'char *' variables. This introduces
lots of potential for accidentially
On Tue, 2013-11-19 at 22:51 -0800, Keith Packard wrote:
I've gotten a couple more bugs in Present resolved, and I'd love to
have some review of the current set of five tiny patches before I
merge them to master. Three of these are a repost, the last two are
new
Again, I'm soliciting any
Adam Jackson a...@nwnk.net writes:
Looks like a reasonable change, but it'd be a little unfortunate to
break building older server on newer fontsproto, which is what would
happen if I read you right.
Indeed. The X server does things something like:
fpe-name = malloc()
Adam Jackson a...@nwnk.net writes:
I'm not totally happy with this. Casting away const on the argument to
free() potentially hides bugs, because the point is you _shouldn't_ be
able to free() things in .rodata, ie, actually constant values.
Agreed. The issue is that different parts of the X
On Wed, 2013-11-20 at 11:55 -0800, Keith Packard wrote:
Keith, can you please fix the xshmfence API to use either 'void *' or
an opaque 'struct xshmfence *' instead of 'int32_t *' before we have
to live with this design mistake forever?
I spent this morning cleaning up libxshmfence; it
Adam Jackson a...@nwnk.net writes:
I've not had the chance to test these, but they all appear to do what
they say on the box, so:
Reviewed-by: Adam Jackson a...@redhat.com
Thanks muchly!
Merged.
da9997f..6403cbb master - master
--
keith.pack...@intel.com
pgpp3GeZOS6au.pgp
On Wed, Nov 20, 2013 at 1:51 AM, Keith Packard kei...@keithp.com wrote:
I've gotten a couple more bugs in Present resolved, and I'd love to
have some review of the current set of five tiny patches before I
merge them to master. Three of these are a repost, the last two are
new
Again, I'm
On Fri, Nov 15, 2013 at 06:03:25PM -0800, Alan Coopersmith wrote:
libX11-xcb only accesses data structures defined in X11 headers,
it doesn't call any functions or reference any global variables
in libX11 itself. (Seems to have been left from previous XCL
implementation.)
Signed-off-by:
The issue is that different parts of the X server use either const
values or allocated values and store those in the same structure
members. Each part knows what it has done; const values are
never freed, while allocated values always are.
So, we have three choices:
1) Stick casts where
On 11/20/13 02:50 AM, Mark Kettenis wrote:
Date: Tue, 12 Nov 2013 07:21:19 +0100
From: Matthieu Herrb matth...@herrb.eu
On Mon, Nov 11, 2013 at 11:22:56PM +0100, Mark Kettenis wrote:
From: Mark Kettenis kette...@openbsd.org
A char array on the stack is not guaranteed to have more than byte
Alex Deucher alexdeuc...@gmail.com writes:
For anyone interested in fixing this for pre-present xserver, Ilija
fixed it similarly in the ddx for radeon:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6981a5c087165b126c15ba0025cffdba218ab652
Nice that this avoids the current
37 matches
Mail list logo
