Re: XSetBackgroundPixmap question
On Sat, 2012-05-19 at 23:00 +0100, Glynn Clements wrote: I've encountered code which uses a background pixmap to implement a persistent screen, and drawing to the pixmap then calling XClearWindow (without calling XSetWindowBackgroundPixmap in between) results in the updated pixmap contents appearing in the window. So it appears to use reference counting or similar. Any code which does this is being inadvisably friendly with the implementation. From the protocol spec: Subsequent drawing into the background or border pixmap has an undefined effect on the window state. The server might or might not make a copy of the pixmap. The sample implementation (at least at the dix level) has always done the current behaviour of taking a reference on the pixmap, but the sample implementation is not the only X server ever written. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH x11proto-fixes (v2)] fixesproto v6: Pointer barrier thresholds
v2: Use a GenericEvent for BarrierNotify
Add PointerReleased event type
Clarify scope of barrier event-id
Release multiple barriers in a single ReleasePointer call.
---
configure.ac |2 +-
fixesproto.txt | 132 +++-
xfixesproto.h | 64 +++
xfixeswire.h | 20 -
4 files changed, 214 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6035f1d 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -1,5 +1,5 @@
The XFIXES Extension
- Version 5.0
+ Version 6.0
Document Revision 1
2010-11-15
Keith Packard
@@ -650,6 +650,136 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded,
PointerReleased}
+ BarrierEventID: CARD32
+ BarrierEventDetails:{ barrier: BARRIER,
+ type: BarrierEvent,
+ event-id: BarrierEventID }
+
+13.2 Events
+
+BarrierNotify
+
+ type: BYTE
+ extension: CARD8
+ sequenceNumber: CARD16
+ length: CARD32
+ evtype: CARD16
+ window: WINDOW
+ x, y: INT16
+ dx, dy: FP3232
+ raw-dx, raw-dy: FP3232
+ dt: INT16
+ deviceid: DEVICEID
+ details:LISTofBarrierEventDetails
+
+ BarrierNotify uses the X Generic Event extension. Type is thus always
+ GenericEvent (35), extension is the major opcode of this extension,
+ sequenceNumber is the low 16 bits of the request sequence number,
+ length is how much bigger than 32 bytes the event is, in units of
+ 4 bytes. Evtype is the type of this event, which is always
+ BarrierNotify (0).
+
+ (x, y) contain the coordinates of the pointer after restriction by
+ any applicable barriers or server-side clamping (such as to screen
+ edges).
+
+ (dx, dy) and (raw-dx, raw-dy) are the valuators for the input event
+ which caused the BarrierNotify to be emitted, before any clamping
+ (such as to the screen edge, or by a barrier) is applied.
+ (dx, dy) are the values after acceleration, (raw-dx, raw-dy) are the
+ raw values before any acceleration is applied. dt is the server time
+ in milliseconds since the last input event, and deviceid is the id of
+ the input device which triggered the barrier.
+
+ Each item in the details list contains the information for a barrier
+ triggered by this input event. If there are multiple overlapping
+ barriers blocking pointer motion each one will be represented in
+ this list.
+
+ barrier is the ID of the barrier hit.
+
+ Type indicates the trigger of the event:
+Hit when the barrier has prevented pointer movement.
+ThresholdExceeded when the barrier has been hit but has not
+ prevented pointer movement due to the threshold being exceeded.
+PointerReleased when the barrier would have blocked motion but
+ has been rendered permeable by a BarrierReleasePointer request.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier and remains
+ valid until the first input event from deviceid which is not
+ restricted by the barrier. The event-id is unique per-barrier.
+
+ Since a barrier event is associated with a deviceid there can be more
+ than one event active for a given barrier simultaneously.
+
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
Re: [PATCH xf86-input-evdev] Fix some obvious constness-related compile warnings.
On Mon, May 21, 2012 at 01:22:33AM +0200, Marcin Slusarz wrote:
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
There are many more, but they need fixes to xserver API.
this is going to cause some warnings on older servers, but I'll probably
drop those instead of hacking around it.
merged, thanks
Cheers,
Peter
---
src/emuWheel.c |4 ++--
src/evdev.c| 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/emuWheel.c b/src/emuWheel.c
index ae894fa..db989c5 100644
--- a/src/emuWheel.c
+++ b/src/emuWheel.c
@@ -51,7 +51,6 @@ static Atom prop_wheel_timeout = 0;
static Atom prop_wheel_button = 0;
/* Local Funciton Prototypes */
-static BOOL EvdevWheelEmuHandleButtonMap(InputInfoPtr pInfo, WheelAxisPtr
pAxis, char *axis_name);
static int EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr axis, int
value);
/* Filter mouse button events */
@@ -197,7 +196,8 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
axis, int value)
/* Handle button mapping here to avoid code duplication,
returns true if a button mapping was found. */
static BOOL
-EvdevWheelEmuHandleButtonMap(InputInfoPtr pInfo, WheelAxisPtr pAxis, char*
axis_name)
+EvdevWheelEmuHandleButtonMap(InputInfoPtr pInfo, WheelAxisPtr pAxis,
+ const char *axis_name)
{
EvdevPtr pEvdev = (EvdevPtr)pInfo-private;
char *option_string;
diff --git a/src/evdev.c b/src/evdev.c
index 140a633..feb018c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -277,7 +277,7 @@ EvdevRemoveDevice(InputInfoPtr pInfo)
static void
-SetXkbOption(InputInfoPtr pInfo, char *name, char **option)
+SetXkbOption(InputInfoPtr pInfo, const char *name, char **option)
{
char *s;
@@ -2547,7 +2547,7 @@ EvdevUtilButtonEventToButtonNumber(EvdevPtr pEvdev, int
code)
/* Aligned with linux/input.h.
Note that there are holes in the ABS_ range, these are simply replaced
with
MISC here */
-static char* abs_labels[] = {
+static const char *abs_labels[] = {
AXIS_LABEL_PROP_ABS_X, /* 0x00 */
AXIS_LABEL_PROP_ABS_Y, /* 0x01 */
AXIS_LABEL_PROP_ABS_Z, /* 0x02 */
@@ -2610,7 +2610,7 @@ static char* abs_labels[] = {
AXIS_LABEL_PROP_ABS_MT_PRESSURE,/* 0x3a */
};
-static char* rel_labels[] = {
+static const char *rel_labels[] = {
AXIS_LABEL_PROP_REL_X,
AXIS_LABEL_PROP_REL_Y,
AXIS_LABEL_PROP_REL_Z,
@@ -2623,7 +2623,7 @@ static char* rel_labels[] = {
AXIS_LABEL_PROP_REL_MISC
};
-static char* btn_labels[][16] = {
+static const char *btn_labels[][16] = {
{ /* BTN_MISC group offset 0x100*/
BTN_LABEL_PROP_BTN_0, /* 0x00 */
BTN_LABEL_PROP_BTN_1, /* 0x01 */
@@ -2708,7 +2708,7 @@ static void EvdevInitAxesLabels(EvdevPtr pEvdev, int
mode, int natoms, Atom *ato
{
Atom atom;
int axis;
-char **labels;
+const char **labels;
int labels_len = 0;
if (mode == Absolute)
--
1.7.8.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] input: fix mouse wheel support for DGA clients
On Mon, May 21, 2012 at 01:16:40AM +0200, Marcin Slusarz wrote:
xf86-input-evdev (since smooth scrolling support was added) can send mouse
motion and wheel events in one batch, so we need to handle it properly.
Otherwise mouse wheel events which came with motion events are lost
and separate mouse wheel events are handled through non-DGA path.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
hw/xfree86/common/xf86Xinput.c | 77
1 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index d246d2a..bf615ad 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -1059,24 +1059,16 @@ xf86PostMotionEventP(DeviceIntPtr device,
xf86PostMotionEventM(device, is_absolute, mask);
}
-void
-xf86PostMotionEventM(DeviceIntPtr device,
- int is_absolute, const ValuatorMask *mask)
+#if XFreeXDGA
+static int xf86CheckMotionEvent4DGA(DeviceIntPtr device, int is_absolute,
+const ValuatorMask *mask)
{
put the #if inside here (afer stolen = 0), so we don't have two declarations
of the same function.
(also, general note, we require 4-space indentation now, no tabs)
-int flags = 0;
-
-if (valuator_mask_num_valuators(mask) 0) {
-if (is_absolute)
-flags = POINTER_ABSOLUTE;
-else
-flags = POINTER_RELATIVE | POINTER_ACCELERATE;
-}
+int stolen = 0;
-#if XFreeXDGA
/* The evdev driver may not always send all axes across. */
if (valuator_mask_isset(mask, 0) || valuator_mask_isset(mask, 1))
if (miPointerGetScreen(device)) {
-int index = miPointerGetScreen(device)-myNum;
+int idx = miPointerGetScreen(device)-myNum;
any particular reason you changed this name?
int dx = 0, dy = 0;
if (valuator_mask_isset(mask, 0)) {
@@ -1091,11 +1083,66 @@ xf86PostMotionEventM(DeviceIntPtr device,
dy -= device-last.valuators[1];
}
-if (DGAStealMotionEvent(device, index, dx, dy))
-return;
+if (DGAStealMotionEvent(device, idx, dx, dy))
+stolen = 1;
+}
+
+if (valuator_mask_isset(mask, 2))
please wrap this in {} as well
+if (miPointerGetScreen(device)) {
+int idx = miPointerGetScreen(device)-myNum;
+
+if (valuator_mask_get(mask, 2) 0) {
+ if (DGAStealButtonEvent(device, idx, 4, 1)
+ DGAStealButtonEvent(device, idx, 4, 0))
+ stolen = 1;
+} else {
+ if (DGAStealButtonEvent(device, idx, 5, 1)
+ DGAStealButtonEvent(device, idx, 5, 0))
+ stolen = 1;
+}
+}
+
+if (valuator_mask_isset(mask, 3))
+if (miPointerGetScreen(device)) {
+int idx = miPointerGetScreen(device)-myNum;
+
+if (valuator_mask_get(mask, 3) 0) {
+ if (DGAStealButtonEvent(device, idx, 7, 1)
+ DGAStealButtonEvent(device, idx, 7, 0))
+ stolen = 1;
+} else {
+ if (DGAStealButtonEvent(device, idx, 6, 1)
+ DGAStealButtonEvent(device, idx, 6, 0))
+ stolen = 1;
+}
}
not quite correct, we can't guarantee that valuators 2/3 are the scrolling
axes on every device. you need to check if the
valuator-axes[axis].scroll.type is something other than SCROLL_TYPE_NONE.
emulate_scroll_button_events in dix/getevents.c is the blueprint here,
should be easy enough to follow (or possibly re-use)
Cheers,
Peter
+
+return stolen;
+}
+#else
+static int xf86CheckMotionEvent4DGA(DeviceIntPtr device, int is_absolute,
+const ValuatorMask *mask)
+{
+return 0;
+}
#endif
+void
+xf86PostMotionEventM(DeviceIntPtr device,
+ int is_absolute, const ValuatorMask *mask)
+{
+int flags = 0;
+
+if (valuator_mask_num_valuators(mask) 0) {
+if (is_absolute)
+flags = POINTER_ABSOLUTE;
+else
+flags = POINTER_RELATIVE | POINTER_ACCELERATE;
+}
+
+if (xf86CheckMotionEvent4DGA(device, is_absolute, mask))
+ return;
+
QueuePointerEvents(device, MotionNotify, 0, flags, mask);
}
--
1.7.8.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
New xf86-video-armsoc DDX driver
Hi All, For the last few months we (ARM MPD... The Mali guys) have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via KMS. The KMS driver also allocates both scan-out and pixmap/back buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. When returning buffers to DRI clients, the x-server uses flink to get a global handle to a buffer which it passes back to the DRI client (in our case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME ioctls to export the GEM buffer it received from the x-server to a dma_buf fd. This fd is then passed into the T6xx kernel driver via our own job dispatch user/kernel API (we're not using DRM for driving the GPU, only the display controller). Note: ARM doesn't generally provide the display controller IP block, so this is really for our customers/Linaro to develop, though we do have something hacked up for ARM's own PL111 display controller on our Versatile Express development platform which we'll be open sourcing/up-streaming asap via Linaro. We believe most ARM SoCs are likely to work the same way, at least those with 3rd-party GPU IP blocks/drivers (so everyone except Qualcomm nVidia). As mentioned, this is certainly how the OMAP integration works. As such, we've taken the OMAP DDX driver Rob Clark wrote and hacked on it to make it work for Mali. The patch is actually relatively small, which is not really too surprising as all the driver is doing is allocating buffers and managing a display controller via a device-agnostic interface (KMS). All the device-specific code is kept in the DRM driver and the client GLES/EGL library. Given that the DDX driver doesn't contain any device-specific code, we're going to take the OMAP DDX as a baseline and try and make it more generic. Our immediate goals are to make it work on our own Versatile Express development platform and on Samsung's Exynos 5250 SoC, however our hope is to have a single DDX driver which can cover OMAP, Exynos, ST-E's Nova/Thor platforms and probably others too. It's even been suggested it could work with Mesa's sw backend(?). Anyway, the DDX is very much a work-in-progress and is still heavily branded OMAP, even though it's working (almost) perfectly on VExpress Exynos too (re-branding isn't too high-up our priority list at the moment). We are actively developing this driver and will be doing so in a public git repository hosted by Linaro. We will not be maintaining any private repository behind ARM's firewall or anything like that - you'll see what we see. The first patches have now been pushed, so if anyone's interested in seeing what we have so far or wants to track development, the tree is here: http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa ry Note: When we originally spoke to Rob Clark about this, he suggested we take the already-generic xf86-video-modesetting and just add the dri2 code to it. This is indeed how we started out, however as we progressed it became clear that the majority of the code we wanted was in the omap driver and were having to work fairly hard to keep some of the original modesetting code. This is why we've now changed tactic and just forked the OMAP driver, something Rob is more than happy for us to do. One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In the short-term, we will simply create a branch off of the generic master for each SoC and add 2D hardware support there. We do however want a more permanent solution which doesn't need a separate branch per SoC. Some of the suggested solutions are: * Add a new generic DRM ioctl API for larger 2D operations (I would imagine small blits/blends would be done in SW). * Use SW rendering for everything other than solid blits and use v4l2's blitting API for those (importing/exporting buffers to be blitted using dma_buf). The theory here is that most UIs are rendered with GLES and so you only need 2D hardware for blits. I think we'll prototype this approach on Exynos. * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). We are hoping someone might have some advice suggestions on how to proceed with regards to 2D. We're also very interested in any feedback, both on the DDX driver specifically and on the approach we're taking in general. Cheers, Tom ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: New xf86-video-armsoc DDX driver
For the last few months we (ARM MPD... The Mali guys) have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via KMS. The KMS driver also allocates both scan-out and pixmap/back buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. When returning buffers to DRI clients, the x-server uses flink to get a global handle to a buffer which it passes back to the DRI client (in our case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME ioctls to export the GEM buffer it received from the x-server to a dma_buf fd. This fd is then passed into the T6xx kernel driver via our own job dispatch user/kernel API (we're not using DRM for driving the GPU, only the display controller). So using dumb in this was is probably a bit of an abuse, since dumb is defined to provide buffers not to be used for acceleration hw. Since when we allocate dumb buffers, we can't know what special hw layouts are required (tiling etc) for optimal performance for accel. The logic to work that out is rarely generic. http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa ry Note: When we originally spoke to Rob Clark about this, he suggested we take the already-generic xf86-video-modesetting and just add the dri2 code to it. This is indeed how we started out, however as we progressed it became clear that the majority of the code we wanted was in the omap driver and were having to work fairly hard to keep some of the original modesetting code. This is why we've now changed tactic and just forked the OMAP driver, something Rob is more than happy for us to do. It does seem like porting to -modesetting, and maybe cleaning up modesetting if its needs it. The modesetting driver is pretty much just a make it work port of the radeon/nouveau/intel code shared code. One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In the short-term, we will simply create a branch off of the generic master for each SoC and add 2D hardware support there. We do however want a more permanent solution which doesn't need a separate branch per SoC. Some of the suggested solutions are: * Add a new generic DRM ioctl API for larger 2D operations (I would imagine small blits/blends would be done in SW). Not going to happen, again the hw isn't generic in this area, some hw requires 3D engines to do 2D ops etc. The limitations on some hw with overlaps etc, and finally it breaks the rule about generic ioctls for acceleration operations. * Use SW rendering for everything other than solid blits and use v4l2's blitting API for those (importing/exporting buffers to be blitted using dma_buf). The theory here is that most UIs are rendered with GLES and so you only need 2D hardware for blits. I think we'll prototype this approach on Exynos. Seems a bit over the top, * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. I haven't time this week to review the code, but I'll try and take a look when time permits. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: lack of reviewers
On 05/20/2012 08:42 AM, Simon Thum wrote: Hi all, I would like to tell another story, perhaps you follow me. I work on a project with a quite sharp gradient of competence in the development team. We do use gerrit and a build server which verifies our patches. The effect of gerrit - in our case! - is to encourage the less knowledgeable people to do more complicated changes because they can rely on the infrastructure to catch most errors for them. Also, we all sleep better knowing it's hard to break the thing. Gerrit discerns review from humans from validation e.g. from tinderbox. Every patch is validated independently, as far as is possible. You know pretty fast when and where you made a mistake. Also it will email you (configurable at the user level!) so you don't need to check it actively if you don't like. For us it pays. But it also costs: The build process and unit testing has to be handled more rigid. We have a lot of surrounding infrastructure just to nail the builds and tests. It regularly needs attention to maintain. Unfortunately, the X server really has near-zero test coverage. I would not rely on compilation and existing test coverage as confirmation that there will likely not be regressions in xserver. Not yet at least. All in all, I think this not really a social problem - it's a social problem with technological roots, meaning it can be relieved substantially. But it's not likely to be easy even if the tinderbox already exists. I think the larger issue to potentially resolving this issue is for someone to do something about it. If someone who believes in gerrit sets up an instance and goes through the trouble to make it work, then I and hopefully others would be glad to try it out. X.org doesn't have funded leadership that can tell people to do specific things, like create a gerrit instance. It is up to individual developers to make the effort. -- Chase ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[git pull] new apis and fixes
Hi Keith, Just the first set of reviewed changes, thanks for looking at the newer ones. The following changes since commit ba883a0f3435d5da82a8134e696c4905eea70f23: Merge remote-tracking branch 'jeremyhu/master' (2012-05-17 16:49:19 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/xserver for-keithp Dave Airlie (11): xfree86: add modesetting driver to fallback list on Linux config/udev: add pre_init stage to config and udev. xf86/pci: fix slot claiming counting. xf86: add helper functions to convert to from ScrnInfoPtr/ScreenPtr (v2) xf86: migrate to using xf86ScreenToScrn wrapper (v2) render: add GetGlyphPicture accessor. render/exa: use glyph picture accessors xf86/modes: drop two uses of screenInfo xaa: convert pScrn-pScreen to use accessor. xf86/modes: drop more pScrn-pScreen usages xf86: reimplement XF86SCRNINFO macro using new functions. config/config-backends.h |1 + config/config.c|9 config/udev.c | 16 ++--- exa/exa_glyphs.c |6 ++-- glx/glxdri.c |2 +- glx/glxdri2.c |2 +- hw/xfree86/common/xf86.h | 15 +--- hw/xfree86/common/xf86AutoConfig.c |4 +++ hw/xfree86/common/xf86Bus.c| 20 + hw/xfree86/common/xf86Cursor.c |9 --- hw/xfree86/common/xf86DGA.c|2 +- hw/xfree86/common/xf86DPMS.c |2 +- hw/xfree86/common/xf86Helper.c | 18 ++- hw/xfree86/common/xf86Init.c |2 + hw/xfree86/common/xf86Priv.h |1 + hw/xfree86/common/xf86RandR.c | 15 +++-- hw/xfree86/common/xf86VGAarbiter.c |8 ++ hw/xfree86/common/xf86VGAarbiterPriv.h |2 +- hw/xfree86/common/xf86cmap.c | 22 +- hw/xfree86/common/xf86fbman.c |4 +- hw/xfree86/common/xf86pciBus.c | 10 +--- hw/xfree86/common/xf86xv.c | 10 hw/xfree86/common/xf86xvmc.c | 12 +- hw/xfree86/doc/ddxDesign.xml |2 +- hw/xfree86/dri/dri.c | 10 hw/xfree86/exa/examodule.c |5 +-- hw/xfree86/fbdevhw/fbdevhw.c |2 +- hw/xfree86/modes/xf86Crtc.c| 16 +++--- hw/xfree86/modes/xf86Cursors.c | 10 hw/xfree86/modes/xf86DiDGA.c |6 ++-- hw/xfree86/modes/xf86RandR12.c | 36 hw/xfree86/modes/xf86Rotate.c | 14 +--- hw/xfree86/ramdac/xf86Cursor.c |4 +- hw/xfree86/ramdac/xf86HWCurs.c |2 +- hw/xfree86/ramdac/xf86RamDacCmap.c |2 +- hw/xfree86/shadowfb/shadow.c |4 +- hw/xfree86/vgahw/vgaCmap.c |5 +--- hw/xfree86/vgahw/vgaHW.c |4 +- hw/xfree86/xaa/xaaInit.c | 12 +- hw/xfree86/xaa/xaaInitAccel.c |2 +- hw/xfree86/xaa/xaaOverlayDF.c |2 +- hw/xfree86/xaa/xaaPCache.c |6 ++-- hw/xfree86/xaa/xaaStateChange.c|2 +- include/hotplug.h |1 + render/glyph.c | 30 + render/glyphstr.h |6 + render/render.c|4 +- 47 files changed, 229 insertions(+), 150 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2 xorg-gtest] Namespace xorg-gtest header filenames
On 05/20/2012 02:55 PM, Peter Hutterer wrote: On Fri, May 18, 2012 at 01:23:32PM -0700, Chase Douglas wrote: Due to the default automake compilation flags including -I. -I.., it is possible to pick up an xorg-gtest header like device.h instead of a project header. Namespacing the headers should resolve this issue. Users should be including xorg-gtest.h instead of individual headers, so this should not cause compilation failures. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- include/Makefile.am |8 +- include/xorg/gtest/environment.h | 184 -- include/xorg/gtest/evemu/device.h| 91 - include/xorg/gtest/evemu/xorg-gtest_device.h | 91 + include/xorg/gtest/process.h | 166 --- include/xorg/gtest/test.h| 104 --- include/xorg/gtest/xorg-gtest.h |8 +- include/xorg/gtest/xorg-gtest_environment.h | 184 ++ include/xorg/gtest/xorg-gtest_process.h | 166 +++ include/xorg/gtest/xorg-gtest_test.h | 104 +++ 10 files changed, 553 insertions(+), 553 deletions(-) delete mode 100644 include/xorg/gtest/environment.h delete mode 100644 include/xorg/gtest/evemu/device.h create mode 100644 include/xorg/gtest/evemu/xorg-gtest_device.h delete mode 100644 include/xorg/gtest/process.h delete mode 100644 include/xorg/gtest/test.h create mode 100644 include/xorg/gtest/xorg-gtest_environment.h create mode 100644 include/xorg/gtest/xorg-gtest_process.h create mode 100644 include/xorg/gtest/xorg-gtest_test.h tbh i'm not a big fan of a xorg-gtest_test naming. Can't we just use dashes? It's a bit too late for xorg-gtest_main.cpp, so I'd prefer to stick the the same semantics throughout xorg-gtest. It's not perfect, I probably would pick different semantics if I were to do it over again, but these header file names are just an implementation detail, so meh. -- Chase ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/2 xorg-gtest] Add comment to Makefile-xorg-gtest.am about compiling with -w
On 05/18/2012 01:23 PM, Chase Douglas wrote: Users of xorg-gtest will not want warnings or failed builds due to issues in gtest or xorg-gtest. Note that the internal build of the xorg-gtest example does not use the -w flag when building examples, so we will still see warnings when xorg-gtest itself is built. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/Makefile-xorg-gtest.am |3 +++ 1 file changed, 3 insertions(+) diff --git a/src/Makefile-xorg-gtest.am b/src/Makefile-xorg-gtest.am index 185381d..20983eb 100644 --- a/src/Makefile-xorg-gtest.am +++ b/src/Makefile-xorg-gtest.am @@ -26,6 +26,9 @@ XORG_GTEST_BUILD_LIBS = \ libxorg-gtest.a \ libxorg-gtest_main.a +# Here and below we compile without warnings (-w) because the projects using +# xorg-gtest will not want to see warnings or fail to build due to warnings in +# gtest or xorg-gtest. nodist_libgtest_a_SOURCES = $(GTEST_SOURCE)/src/gtest-all.cc libgtest_a_CPPFLAGS = $(GTEST_CPPFLAGS) $(AM_CPPFLAGS) -w libgtest_a_CXXFLAGS = $(GTEST_CXXFLAGS) $(AM_CXXFLAGS) Both patches have no been merged: ae1e069..e1c010f -- Chase ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Remove NO_LIBCWRAPPER define
I'll just refer to 1faba79 (Death to libcwrapper., 2007-12-03). Signed-off-by: Tomas Carnecky tomas.carne...@gmail.com --- configure.ac |2 -- 1 file changed, 2 deletions(-) diff --git a/configure.ac b/configure.ac index 97ceab1..d3881e4 100644 --- a/configure.ac +++ b/configure.ac @@ -1317,8 +1317,6 @@ AC_DEFINE_UNQUOTED(VENDOR_NAME_SHORT, [$VENDOR_NAME_SHORT], [Vendor name]) AC_DEFINE_UNQUOTED(VENDOR_RELEASE, [$VENDOR_RELEASE], [Vendor release]) AC_DEFINE_UNQUOTED(VENDOR_MAN_VERSION, [$VENDOR_MAN_VERSION], [Vendor man version]) -AC_DEFINE(NO_LIBCWRAPPER, 1, [Define to 1 if modules should avoid the libcwrapper]) - if test x$DEBUGGING = xyes; then AC_DEFINE(DEBUG, 1, [Enable debugging code]) fi -- 1.7.10.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL: xserver master] SPARC build fix, documentation fixes
The following changes since commit ba883a0f3435d5da82a8134e696c4905eea70f23: Merge remote-tracking branch 'jeremyhu/master' (2012-05-17 16:49:19 -0700) are available in the git repository at: git://people.freedesktop.org/~alanc/xserver.git master for you to fetch changes up to 5a3a98fcb799c2ac8fa7494645ad9030f1cac837: Undocument Font Module loading (2012-05-18 21:34:20 -0700) The SPARC compiler.h patch I'd sent with the review requests is purposely omitted while we investigate an internal bug report related to it. Jeremy: all of these should be suitable for the 1.12 branch - the important one for us is the sbusPaletteKey build fix, but bringing the docs a little closer to matching reality is nice to have too. Alan Coopersmith (4): Convert sbusPaletteKey to latest DevPrivate API cvt man page should use Hz, not kHz, for vertical refresh rate Undocument mandatory loadable modules Undocument Font Module loading hw/xfree86/common/xf86sbusBus.c |8 ++-- hw/xfree86/doc/ddxDesign.xml| 25 - hw/xfree86/utils/man/cvt.man|4 ++-- 3 files changed, 8 insertions(+), 29 deletions(-) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Non-recursive make
Many years ago I wrote a small patch to generate protocol bindings from XCB. Initially only for DPMS, it worked quite well. I've been running my xserver with that patch since then. A few weeks ago I decided to port another extension and that where the trouble started. I've run into big problems because the many small interdependent libraries that are used to link the server didn't want to correctly link together. I always had some unresolved symbols. So that made me thinking about how we build the server, and whether a non-recursive make wouldn't make everything easier. We could collect all the source files first and then link the server in one go. Well, at least in theory. But even if don't get to that state, there's still a lot of potential. For example, all servers link with libdix, libos, libXi, libxfixes, libmi, librandr and librender. Combining all those into a single libXserver will eliminate a lot of ugly code throughout configure.ac and the makefiles. You've maybe noticed that I sent a few patches during the last few days. Those are simple cleanups, stuff that I came across while trying out non-recursive make. I have successfully converted most of the server to non-recursive make now, even Xvfb and Xnest are built from the top-level Makefile! As a proof-of-concept, it's been useful (if somebody wants to see the code, I can share it on github). However, the code is ugly, and likely breaks tests, Xwin and XQuartz. And it's a *big* diff, hard to review etc. But I can make gradual changes over many smaller commits, so we can review at each step, and see how well it goes: 1. Cleanup, required to make `subdir-objects` automake option work. 2. Convert one library after another to build from the top-level makefile. This part will include large diffs because all paths have to be made relative to the root. 3. Start consolidating libraries (libdix, libos, libXi etc), cleaning up configure.ac, dependencies etc as we go. Eventually building the DDXes from the top-level makefile. What do you think? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL: xserver] dri2: Add DRI2GetParam request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following changes since commit ba883a0f3435d5da82a8134e696c4905eea70f23: Merge remote-tracking branch 'jeremyhu/master' (2012-05-17 16:49:19 -0700) are available in the git repository at: git://people.freedesktop.org/~chadversary/xorg.xserver.git dri2getparam for you to fetch changes up to fba43ee7700e8c321a4feab4129015804817be80: dri2: Add DRI2GetParam request (2012-05-21 14:38:05 -0700) - Chad Versace (1): dri2: Add DRI2GetParam request configure.ac |2 +- hw/xfree86/dri2/dri2.c| 37 + hw/xfree86/dri2/dri2.h| 26 +- hw/xfree86/dri2/dri2ext.c | 33 + 4 files changed, 96 insertions(+), 2 deletions(-) - Chad Versace chad.vers...@linux.intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPura6AAoJEAIvNt057x8iFfEP/iDIi/t8LUAd1AEAONEU8c59 grFR3q0EBt95O9eG+LOKg6d6mwMKgaQ/GGYyl87Dp++fiwH+98vG4yIBXXTjEMSg Msz5/OMmL40Tf7NhOiCUZkWrT9IgvBwG5UxKy/RV+lQxdLVANYfe8ousD65kivGV qUm4HH5pgG3oQG/v/7owmuq0CMMOLrcQwjZ6JqcB0xH5EaGNe9Bm2w+IBFRLzsEO /Feg6KVLUu5GE3JJMjbwoYXOwCCT1XJDIhkRsm43PV2Cula63jqU/mxGXtzzzjLr OLS/ZfQo74nL5g7sKcH83SCC2NMYqlGSohTO3flfYX+8/ph6x4P+JlLbTksGXEY1 9Hz51HtCAv9znpUCVr5sxP0gCfoB9IvvyPRxb+WOjx9QEez6ALfpjtUzPmHWUP3o 4CdrmEE9VWw64rY8Ws8hJPWMlseAnazqbkdOkql7BQUvdBr9HkODq3wx7s5uArdB beOSlP3LFZe1n41005xU2QdcFSkQKXdwz74Y4qg1rnjq+dkjYGqdRDFj6jSVL8jF bI9NxhJ6rMYxOqYqz/4oNLUouBYCS6HbInU+CSo2PsQiM/VfxCbkriAXZJFjMlUR 36smG+jUh+uLSrTF5JdSWT9eHCjIeAY40vvOO9VShq90WAlSprXWF8t/7vfB4eB4 srAPhVobdgm5cSsrs0R9 =eLUN -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] ephyrGLXQueryServerString: Send padded copy of server_string to client
ephyrGLXQueryServerString() carefully allocated a buffer padded to the word-aligned string length for sending to the client, copied the string to it, and then forgot to use it, potentially reading a few bytes of garbage past the end of the server_string buffer. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- I'm not even sure why it copies to a padded buffer since WriteToClient will also pad it for you, but as long as it does, might as well use it instead of going to all that work to ignore it. hw/kdrive/ephyr/ephyrglxext.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/kdrive/ephyr/ephyrglxext.c b/hw/kdrive/ephyr/ephyrglxext.c index 1287e04..5b37329 100644 --- a/hw/kdrive/ephyr/ephyrglxext.c +++ b/hw/kdrive/ephyr/ephyrglxext.c @@ -376,7 +376,7 @@ ephyrGLXQueryServerString(__GLXclientState * a_cl, GLbyte * a_pc) memcpy(buf, server_string, length); WriteToClient(client, sz_xGLXQueryServerStringReply, reply); -WriteToClient(client, (int) (reply.length 2), server_string); +WriteToClient(client, (int) (reply.length 2), buf); res = Success; -- 1.7.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Fix statement not reached warning in _DMXXineramaActive
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
hw/dmx/dmx.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/dmx/dmx.c b/hw/dmx/dmx.c
index 5c59d05..5ea133e 100644
--- a/hw/dmx/dmx.c
+++ b/hw/dmx/dmx.c
@@ -74,8 +74,9 @@ _DMXXineramaActive(void)
{
#ifdef PANORAMIX
return !noPanoramiXExtension;
-#endif
+#else
return 0;
+#endif
}
static void
--
1.7.9.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Actually send the reply in SProcDRI2Connect()
No point faking up a reply for remote clients if we never send it to them. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- hw/xfree86/dri2/dri2ext.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c index 2579a5c..c1130e3 100644 --- a/hw/xfree86/dri2/dri2ext.c +++ b/hw/xfree86/dri2/dri2ext.c @@ -589,11 +589,13 @@ SProcDRI2Connect(ClientPtr client) if (sizeof(*stuff) / 4 != client-req_len) return BadLength; +rep.type = X_Reply; rep.sequenceNumber = client-sequence; swaps(rep.sequenceNumber); rep.length = 0; rep.driverNameLength = 0; rep.deviceNameLength = 0; +WriteToClient(client, sizeof(xDRI2ConnectReply), rep); return Success; } -- 1.7.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
