On Fri, Mar 28, 2014 at 2:08 PM, James Jones wrote:
>
> Hi Kristian,
>
> This direction seems to conflict with our plans to continue running our DDX
> driver under XWayland. If we can't run > our DDX, we don't have a path to
> support GLX direct rendering under Wayland.
> I know we don't have
DoGetImage chops up an image into IMAGE_BUFSIZE strips.
This predates commit [0] (a pull from XFree86 to X.Org), at which time
IMAGE_BUFSIZE was 8k. Back then the immediate buffers were
allocated with ALLOCATE_LOCAL(), so it made sense to try to keep them
small since at least on some systems, thes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
[quote]
diff --git a/hw/xwayland/xwayland-cvt.c b/hw/xwayland/xwayland-cvt.c
new file mode 100644
index 000..3566559
- --- /dev/null
+++ b/hw/xwayland/xwayland-cvt.c
+/*
+ * Generate a CVT standard mode from HDisplay, VDisplay and VRefresh
Hi!
clang rightfully complains about this code in handler.c:
void
SaveFormattedPage(Widget w, XEvent * event, String * params,
Cardinal * num_params)
{
ManpageGlobals *man_globals;
char cmdbuf[BUFSIZ], error_buf[BUFSIZ];
if (*num_params != 1) {
XtAppWarni
On 03/30/14 06:34 AM, Mark Kettenis wrote:
Date: Sat, 29 Mar 2014 17:26:00 -0700
From: Alan Coopersmith
Do we need to do the same for the SO_RCVBUF as well?
Not really. These connections are local by defenition so in principle
it doesn't really matter whether we queue on the sending side or
On 03/30/14 06:00 AM, Thomas Klausner wrote:
(In fact you could probably put the whole function body in the #else...#endif
clause, but then you'd have to add an attribute to tell the compiler it's
expected that the pInfo argument is unused.)
If you prefer that, please let me know what magic
modifier_map->modifiermap, mapSize);
^~~~~
/archive/build/amd64.clang.20140330/usr/X11R7/include/X11/Xlibint.h:537:15:
note: expanded from macro 'Data'
_XSend(dpy, data, len);\
^
/archive/build/amd64.clang.20140330/usr/X11R7/include/
> Date: Sat, 29 Mar 2014 17:26:00 -0700
> From: Alan Coopersmith
>
> Do we need to do the same for the SO_RCVBUF as well?
Not really. These connections are local by defenition so in principle
it doesn't really matter whether we queue on the sending side or on
the receiving side. On Linux SO_RC
On Tue, Mar 25, 2014 at 05:33:25PM -0700, Alan Coopersmith wrote:
> On 08/19/13 02:14 AM, Thomas Klausner wrote:
> >This makes sure that the xserver and the mouse speak the same
> >protocol version.
> >
> > From Matthew R. Green
> >Signed-off-by: Thomas Klausner
> >---
> > src/mouse.c | 11 +
Hi Alan!
Thanks for the review.
On Tue, Mar 25, 2014 at 05:32:17PM -0700, Alan Coopersmith wrote:
> On 08/19/13 02:14 AM, Thomas Klausner wrote:
> >With a multiplexed device like wsmouse it does not make sense to
> >kill emulate3buttons on the first button-3-pressed event. The
> >button-3 pressed
Signed-off-by: Thomas Klausner
---
radeon/radeon_surface.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 15127d4..101c8f3 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -281,7 +
Signed-off-by: Thomas Klausner
---
intel/test_decode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index b710f34..f9127cf 100644
--- a/intel/test_decode.c
+++ b/intel/test_decode.c
@@ -90,7 +90,10 @@ compare_batch(struct drm_in
unistd.h for close() and xf86drm.h for drmOpen().
Signed-off-by: Thomas Klausner
---
tests/radeon/radeon_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/radeon/radeon_ttm.c b/tests/radeon/radeon_ttm.c
index 246fd99..ac3297a 100644
--- a/tests/radeon/radeon_ttm.c
+++ b/tests/rad
Signed-off-by: Thomas Klausner
---
nouveau/bufctx.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/nouveau/bufctx.c b/nouveau/bufctx.c
index 23d6f09..4f76e5d 100644
--- a/nouveau/bufctx.c
+++ b/nouveau/bufctx.c
@@ -44,12 +44,6 @@ struct nouveau_bufref_priv {
struct nouveau_bufct
14 matches
Mail list logo
