date:20110510

threads and X.org/AIGLX drivers

2011-05-10 Thread Dave Airlie

Hey,

So we got a bug reported against F15 where we were getting an illegal
input event type 0, after passing it around the RH X team I eventually
came to look at it.

The problem appears to be that we are using llvmpipe as our swrast
renderer and on systems that fallback to that we end up with threads
inside the X server, that we didn't spawn. It appears SIGIO gets
delivered to one of these threads while the main thread keeps on
trucking and fail ensues.

So I'm crossposting this as there are two fixes we can do that aren't
exclusive but could act as belt and braces on Linux at least (other
OSes get the belt only).

Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging
up this nugget, "From  Linux  2.6.32 onwards, use F_SETOWN_EX to
target SIGIO
and SIGURG signals at a particular thread.". So on
Linux we would use that instead of F_SETOWN to make sure SIGIO only
goes to the main X process/thread. Though I'm not sure how to get the
defintion for gettid which we need, though I'll look into this a bit
more.

Fix 2: block all signals in the gallium thread spawning code, this
involves using pthread_sigmask around the pthread_create function.
Calling it once with a full set of signals to block, and get a copy of
the current signals, then calling it again to put back the current
signals. I think this might be a good plan for some other things, as I
can't see a good reason for a DRI driver to ever get SIGIO, esp as it
may interfere with the parent app.

I've built a test package with 2 in it for Fedora and am awaiting
feedback from the tester, but just though I'd raise the subject here
for some discussion/feedback.

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: [PATCH libpciaccess 1/2] Add map_legacy interface

2011-05-10 Thread Mark Kettenis

> From: Adam Jackson 
> Date: Tue, 10 May 2011 17:56:34 -0400
> 
> This allows platforms to hand back mmaps of the low 1M (ISA) address
> space on a per-domain basis.

Any reason why you chose to have an explicit "write_enable" flag
instead of using the standard "map_flags" used in the non-legacy
pci_device_map_range() interface?

> Signed-off-by: Adam Jackson 
> ---
>  include/pciaccess.h |8 
>  src/common_interface.c  |   43 +++
>  src/pciaccess_private.h |3 +++
>  3 files changed, 54 insertions(+), 0 deletions(-)
> 
> diff --git a/include/pciaccess.h b/include/pciaccess.h
> index 88515e2..b7795b9 100644
> --- a/include/pciaccess.h
> +++ b/include/pciaccess.h
> @@ -526,4 +526,12 @@ void pci_io_write32(struct pci_io_handle *handle, 
> uint32_t reg, uint32_t data);
>  void pci_io_write16(struct pci_io_handle *handle, uint32_t reg, uint16_t 
> data);
>  void pci_io_write8(struct pci_io_handle *handle, uint32_t reg, uint8_t data);
>  
> +/*
> + * Legacy memory access
> + */
> +
> +int pci_device_map_legacy(struct pci_device *dev, pciaddr_t base,
> +   pciaddr_t size, int write_enable, void **addr);
> +int pci_device_unmap_legacy(struct pci_device *dev, void *addr, pciaddr_t 
> size);
> +
>  #endif /* PCIACCESS_H */
> diff --git a/src/common_interface.c b/src/common_interface.c
> index 4af772a..fe3c1af 100644
> --- a/src/common_interface.c
> +++ b/src/common_interface.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pciaccess.h"
>  #include "pciaccess_private.h"
> @@ -654,3 +655,45 @@ pci_device_enable(struct pci_device *dev)
>  if (pci_sys->methods->enable)
>   pci_sys->methods->enable(dev);
>  }
> +
> +/**
> + * Map the legacy memory space for the PCI domain containing \c dev.
> + *
> + * \param dev  Device whose memory region is to be mapped.
> + * \param base Base address of the range to be mapped.
> + * \param size Size of the range to be mapped.
> + * \param write_enable Map for writing (non-zero).
> + * \param addr Location to store the mapped address.
> + *
> + * \returns
> + * Zero on success or an \c errno value on failure.
> + */
> +int
> +pci_device_map_legacy(struct pci_device *dev, pciaddr_t base, pciaddr_t size,
> +   int write_enable, void **addr)
> +{
> +if (base > 1048576 || base + size > 1048576)
> + return EINVAL;
> +
> +if (!pci_sys->methods->map_legacy)
> + return ENOSYS;
> +
> +return pci_sys->methods->map_legacy(dev, base, size, write_enable, addr);
> +}
> +
> +/**
> + * Unmap the legacy memory space for the PCI domain containing \c dev.
> + *
> + * \param dev  Device whose memory region is to be unmapped.
> + * \param addr Location of the mapped address.
> + * \param size Size of the range to be unmapped.
> + *
> + * \returns
> + * Zero on success or an \c errno value on failure.
> + */
> +int
> +pci_device_unmap_legacy(struct pci_device *dev, void *addr, pciaddr_t size)
> +{
> +/* Maybe vtable this?  Meh. */
> +return munmap(addr, size);
> +}
> diff --git a/src/pciaccess_private.h b/src/pciaccess_private.h
> index ef0..7870395 100644
> --- a/src/pciaccess_private.h
> +++ b/src/pciaccess_private.h
> @@ -77,6 +77,9 @@ struct pci_system_methods {
>  void (*write16)( struct pci_io_handle *handle, uint32_t reg,
>uint16_t data );
>  void (*write8)( struct pci_io_handle *handle, uint32_t reg, uint8_t data 
> );
> +
> +int (*map_legacy)(struct pci_device *dev, pciaddr_t base, pciaddr_t size,
> +   int write_enable, void **addr);
>  };
>  
>  struct pci_device_mapping {
> -- 
> 1.7.5
> 
> ___
> 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
> 
___
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 inputproto] XI2.1: send RawEvents at all times.

2011-05-10 Thread Peter Hutterer

When a client grabbed a device, XI 2.0 only sends RawEvents to that client.
This behaviour is problematic and cannot be worked around for many
applications that need to continue receiving events.

On the other hand, no client seems to rely on this behaviour or use it to
its advantage. For XI 2.1, disable this behaviour and continue to send raw
events regardless of the grab state of the device.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 1e3adbe..5abf9d4 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -34,6 +34,12 @@ used on applications employing the core protocol. XI2 
addresses both of these
 issues by enabling devices to be both extended and core devices and providing
 device information in each event (with the exception of core events).
 
+2.1 Changes
+---
+Changes introduced by version 2.1
+
+- RawEvents are sent regardless of the grab state.
+
 //❧❧❧
 
 2. Notations used in this document
@@ -1598,8 +1604,12 @@ transformed data as used in the server. Transformations 
include, but are
 not limited to, axis clipping and acceleration.
 Transformed valuator data may be equivalent to raw data. In this case,
 both raw and transformed valuator data is provided.
-RawEvents are sent exclusively to all root windows or to the client
-that grabbed the device only.
+RawEvents are sent exclusively to all root windows.
+Clients supporting XI 2.0 receive raw events when the device is not grabbed,
+or when the device is grabbed by the client but not when the device is
+grabbed by another client.
+Clients supporting XI 2.1 or later receive raw events at all times, even
+when the device is grabbed by another client.
 
 eventtype
 The type of event that occured on the device.
-- 
1.7.4.4

___
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] input: deliver raw events unconditionally for XI 2.1 clients.

2011-05-10 Thread Peter Hutterer

Deliver raw events regardless whether there is a grab on or not for clients
supporting 2.1 or later.

Signed-off-by: Peter Hutterer 
---
 Xi/exevents.c |   42 --
 dix/events.c  |   49 -
 2 files changed, 72 insertions(+), 19 deletions(-)

diff --git a/Xi/exevents.c b/Xi/exevents.c
index c6f9d46..2392ff1 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -876,30 +876,36 @@ UpdateDeviceState(DeviceIntPtr device, DeviceEvent* event)
 return DEFAULT;
 }
 
+
+/**
+ * Raw event delivery differs between XI 2.0 and XI 2.1.
+ * XI 2.0: events delivered to the grabbing client only (if any) OR to all
+ * root windows
+ * XI 2.1: events delivered to all root windows, regardless of grabbing
+ * state
+ *
+ */
 static void
 ProcessRawEvent(RawDeviceEvent *ev, DeviceIntPtr device)
 {
 GrabPtr grab = device->deviceGrab.grab;
+xEvent *xi;
+int i;
 
-if (grab)
-DeliverGrabbedEvent((InternalEvent*)ev, device, FALSE);
-else { /* deliver to all root windows */
-xEvent *xi;
-int i;
-
-i = EventToXI2((InternalEvent*)ev, (xEvent**)&xi);
-if (i != Success)
-{
-ErrorF("[Xi] %s: XI2 conversion failed in ProcessRawEvent (%d)\n",
-device->name, i);
-return;
-}
-
-for (i = 0; i < screenInfo.numScreens; i++)
-DeliverEventsToWindow(device, screenInfo.screens[i]->root, xi, 1,
-  GetEventFilter(device, xi), NULL);
-free(xi);
+/* deliver to all root windows. For XI 2.0 clients,
+ * grabbed raw events will be filtered later */
+i = EventToXI2((InternalEvent*)ev, (xEvent**)&xi);
+if (i != Success)
+{
+ErrorF("[Xi] %s: XI2 conversion failed in ProcessRawEvent (%d)\n",
+device->name, i);
+return;
 }
+
+for (i = 0; i < screenInfo.numScreens; i++)
+DeliverEventsToWindow(device, screenInfo.screens[i]->root, xi, 1,
+GetEventFilter(device, xi), NULL);
+free(xi);
 }
 
 /**
diff --git a/dix/events.c b/dix/events.c
index f3af5ee..ee05be3 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -1992,6 +1992,52 @@ out:
 }
 
 /**
+ * Filter out raw events for XI 2.0 clients.
+ *
+ * If there is a grab on the device, 2.0 clients only get raw events if they
+ * have the grab. 2.1+ clients get raw events in all cases.
+ *
+ * For raw events, this function may be called from DeliverEventsToWindow()
+ * or through DeliverGrabbedEvent(). For 2.0 we need to filter when a grab
+ * is on and we're coming from DeliverEventsToWindow(), for 2.1 we need to
+ * filter whenever we come from DeliverGrabbedEvent().
+ *
+ * grab is non-NULL when coming from DeliverGrabbedEvent(), otherwise NULL.
+ *
+ * @return TRUE if the event should be discarded, FALSE otherwise.
+ */
+static BOOL
+FilterRawEvents(const DeviceIntPtr dev, const xEvent *event,
+const GrabPtr grab, const ClientPtr client)
+{
+int rc = FALSE;
+XIClientPtr client_xi_version;
+
+if (!is_xi2_event_of_type(event, XI_RawMotion) &&
+!is_xi2_event_of_type(event, XI_RawButtonPress)&&
+!is_xi2_event_of_type(event, XI_RawButtonRelease)  &&
+!is_xi2_event_of_type(event, XI_RawKeyPress)   &&
+!is_xi2_event_of_type(event, XI_RawKeyRelease))
+goto out;
+
+client_xi_version = dixLookupPrivate(&client->devPrivates, 
XIClientPrivateKey);
+
+/* If the client is XI 2.0, there is a grab on the device and it's not
+ * our grab, filter the raw event. */
+if (version_compare(client_xi_version->major_version,
+   client_xi_version->minor_version, 2, 0) == 0)
+{
+GrabPtr devgrab = dev->deviceGrab.grab;
+
+if (devgrab && rClient(devgrab) != client)
+rc = TRUE;
+}
+
+out:
+return rc;
+}
+
+/**
  * Deliver events to clients registered on the window.
  *
  * @param client_return On successful delivery, set to the recipient.
@@ -2039,7 +2085,8 @@ DeliverEventToClients(DeviceIntPtr dev, WindowPtr win, 
xEvent *events,
 mask = GetEventMask(dev, events, other);
 
 if (XaceHook(XACE_RECEIVE_ACCESS, client, win,
-events, count))
+events, count) ||
+FilterRawEvents(dev, events, grab, client))
 /* do nothing */;
 else if ( (attempt = TryClientEvents(client, dev,
 events, count,
-- 
1.7.4.4

___
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 RFC] New raw event behaviour for XI 2.1

2011-05-10 Thread Peter Hutterer


The current raw event behaviour is pretty useless. RawEvents are sent to all
root windows but only if the device is not grabbed. Clients that need to
monitor devices can only do so by grabbing the device - rendering it
unusable to other clients. Real device monitoring (like we want for 2.1
touch support for example) is not possible.
I have yet to hear of someone who actually needs the current behaviour and I
can't imagine a use-case that does either.

Change the behaviour for clients supporting 2.1 so that raw events are
delivered regardless whether a grab is active on the device. Behaviour for
2.0 clients stays the same. Clients that grabbed devices to get raw events
will still get raw events, so that part of the 2.0 behaviour is preserved
even with 2.1.

No protocol additions, only documentation update necessary. No libXi patch
needed. Note that if you just apply the patch as-is, testing will fail since
XIQueryVersion still limits the server to 2.0. You need to manually bump the
server to 2.1 for the changes to take effect.

The X server patch builds onto the patchset I just sent out before.

Cheers,
  Peter

___
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 11/11] dix: add is_xi2_event_of_type helper function.

2011-05-10 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   23 ++-
 1 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 7885e86..f3af5ee 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -190,6 +190,11 @@ is_xi2_event(const xEvent *event)
((xGenericEvent*)event)->extension == IReqCode;
 }
 
+static inline BOOL
+is_xi2_event_of_type(const xEvent *event, int type)
+{
+return is_xi2_event(event) && ((xGenericEvent*)event)->evtype == type;
+}
 
 /**
  * Used to indicate a implicit passive grab created by a ButtonPress event.
@@ -2105,7 +2110,7 @@ IsButtonPressEvent(xEvent *pEvents)
 {
 int type = pEvents->u.u.type;
 
-if (((is_xi2_event(pEvents) && ((xGenericEvent*)pEvents)->evtype == 
XI_ButtonPress)) ||
+if (is_xi2_event_of_type(pEvents, XI_ButtonPress) ||
 type == DeviceButtonPress || type == ButtonPress)
 return TRUE;
 else
@@ -2340,14 +2345,14 @@ FixUpEventFromWindow(
 {
 xXIDeviceEvent* event = (xXIDeviceEvent*)xE;
 
-if (event->evtype == XI_RawKeyPress ||
-event->evtype == XI_RawKeyRelease ||
-event->evtype == XI_RawButtonPress ||
-event->evtype == XI_RawButtonRelease ||
-event->evtype == XI_RawMotion ||
-event->evtype == XI_DeviceChanged ||
-event->evtype == XI_HierarchyChanged ||
-event->evtype == XI_PropertyEvent)
+if (is_xi2_event_of_type(xE, XI_RawKeyRelease)||
+is_xi2_event_of_type(xE, XI_RawKeyRelease)||
+is_xi2_event_of_type(xE, XI_RawButtonPress)   ||
+is_xi2_event_of_type(xE, XI_RawButtonRelease) ||
+is_xi2_event_of_type(xE, XI_RawMotion)||
+is_xi2_event_of_type(xE, XI_DeviceChanged)||
+is_xi2_event_of_type(xE, XI_HierarchyChanged) ||
+is_xi2_event_of_type(xE, XI_PropertyEvent))
 return;
 
 event->root = RootWindow(pSprite)->drawable.id;
-- 
1.7.4.4

___
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 10/11] dix: replace CORE_EVENT and XI2_EVENT macros with inline functions.

2011-05-10 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   38 +++---
 1 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 3f7cc6f..7885e86 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -176,12 +176,20 @@ typedef const char *string;
 #define AllEventMasks (LastEventMask|(LastEventMask-1))
 
 
-#define CORE_EVENT(event) \
-(!((event)->u.u.type & EXTENSION_EVENT_BASE) && \
-  (event)->u.u.type != GenericEvent)
-#define XI2_EVENT(event) \
-(((event)->u.u.type == GenericEvent) && \
-((xGenericEvent*)(event))->extension == IReqCode)
+static inline BOOL
+is_core_event(const xEvent *event)
+{
+return !(event->u.u.type & EXTENSION_EVENT_BASE) &&
+   event->u.u.type != GenericEvent;
+}
+
+static inline BOOL
+is_xi2_event(const xEvent *event)
+{
+return (event->u.u.type == GenericEvent) &&
+   ((xGenericEvent*)event)->extension == IReqCode;
+}
+
 
 /**
  * Used to indicate a implicit passive grab created by a ButtonPress event.
@@ -416,7 +424,7 @@ GetEventFilter(DeviceIntPtr dev, xEvent *event)
 {
 if (event->u.u.type != GenericEvent)
 return filters[dev ? dev->id : 0][event->u.u.type];
-else if (XI2_EVENT(event))
+else if (is_xi2_event(event))
 return (1 << (((xXIDeviceEvent*)event)->evtype % 8));
 ErrorF("[dix] Unknown device type %d. No filter\n", event->u.u.type);
 return 0;
@@ -432,7 +440,7 @@ GetWindowXI2Mask(DeviceIntPtr dev, WindowPtr win, xEvent* 
ev)
 int filter;
 int evtype;
 
-if (!inputMasks || !XI2_EVENT(ev))
+if (!inputMasks || !is_xi2_event(ev))
 return 0;
 
 evtype = ((xGenericEvent*)ev)->evtype;
@@ -447,13 +455,13 @@ Mask
 GetEventMask(DeviceIntPtr dev, xEvent *event, InputClients* other)
 {
 /* XI2 filters are only ever 8 bit, so let's return a 8 bit mask */
-if (XI2_EVENT(event))
+if (is_xi2_event(event))
 {
 int byte = ((xGenericEvent*)event)->evtype / 8;
 return (other->xi2mask[dev->id][byte] |
 other->xi2mask[XIAllDevices][byte] |
 (IsMaster(dev)? other->xi2mask[XIAllMasterDevices][byte] : 0));
-} else if (CORE_EVENT(event))
+} else if (is_core_event(event))
 return other->mask[XIAllDevices];
 else
 return other->mask[dev->id];
@@ -1994,9 +2002,9 @@ DeliverEventToClients(DeviceIntPtr dev, WindowPtr win, 
xEvent *events,
 enum EventDeliveryState rc = EVENT_SKIP;
 InputClients *other;
 
-if (CORE_EVENT(events))
+if (is_core_event(events))
 other = (InputClients *)wOtherClients(win);
-else if (XI2_EVENT(events))
+else if (is_xi2_event(events))
 {
 OtherInputMasks *inputMasks = wOtherInputMasks(win);
 /* Has any client selected for the event? */
@@ -2097,7 +2105,7 @@ IsButtonPressEvent(xEvent *pEvents)
 {
 int type = pEvents->u.u.type;
 
-if (((XI2_EVENT(pEvents) && ((xGenericEvent*)pEvents)->evtype == 
XI_ButtonPress)) ||
+if (((is_xi2_event(pEvents) && ((xGenericEvent*)pEvents)->evtype == 
XI_ButtonPress)) ||
 type == DeviceButtonPress || type == ButtonPress)
 return TRUE;
 else
@@ -2135,7 +2143,7 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr pWin, 
xEvent
 int type = pEvents->u.u.type;
 
 /* Deliver to window owner */
-if ((filter == CantBeFiltered) || CORE_EVENT(pEvents))
+if ((filter == CantBeFiltered) || is_core_event(pEvents))
 {
 enum EventDeliveryState rc;
 
@@ -2328,7 +2336,7 @@ FixUpEventFromWindow(
 if (calcChild)
 child = FindChildForEvent(pSprite, pWin);
 
-if (XI2_EVENT(xE))
+if (is_xi2_event(xE))
 {
 xXIDeviceEvent* event = (xXIDeviceEvent*)xE;
 
-- 
1.7.4.4

___
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 09/11] include: add version_compare helper function

2011-05-10 Thread Peter Hutterer

Compare two version numbers in the major.minor form.
Switch the few users of manual version switching over to the new function.

Signed-off-by: Peter Hutterer 
---
 Xi/xiqueryversion.c |7 ++-
 include/misc.h  |   18 ++
 randr/rrdispatch.c  |8 
 xfixes/xfixes.c |   12 ++--
 4 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/Xi/xiqueryversion.c b/Xi/xiqueryversion.c
index ae63297..1aaadb6 100644
--- a/Xi/xiqueryversion.c
+++ b/Xi/xiqueryversion.c
@@ -58,7 +58,6 @@ ProcXIQueryVersion(ClientPtr client)
 xXIQueryVersionReply rep;
 XIClientPtr pXIClient;
 int major, minor;
-unsigned int sversion, cversion;
 
 REQUEST(xXIQueryVersionReq);
 REQUEST_SIZE_MATCH(xXIQueryVersionReq);
@@ -72,10 +71,8 @@ ProcXIQueryVersion(ClientPtr client)
 
 pXIClient = dixLookupPrivate(&client->devPrivates, XIClientPrivateKey);
 
-sversion = XIVersion.major_version * 1000 + XIVersion.minor_version;
-cversion = stuff->major_version * 1000 + stuff->minor_version;
-
-if (sversion > cversion)
+if (version_compare(XIVersion.major_version, XIVersion.minor_version,
+stuff->major_version, stuff->minor_version) == 1)
 {
 major = stuff->major_version;
 minor = stuff->minor_version;
diff --git a/include/misc.h b/include/misc.h
index 803f5ba..604c893 100644
--- a/include/misc.h
+++ b/include/misc.h
@@ -223,6 +223,24 @@ pad_to_int32(const int bytes) {
 extern char**
 xstrtokenize(const char *str, const char* separators);
 
+/**
+ * Compare the two version numbers comprising of major.minor.
+ *
+ * @retval -1 if a is less than b
+ * @retval 0 if a is equal to b
+ * @retval 1 if a is greater than b
+ */
+static inline int
+version_compare(int a_major, int a_minor, int b_major, int b_minor)
+{
+int a, b;
+
+a = a_major * 1000 + a_minor;
+b = b_major * 1000 + b_minor;
+
+return (a == b) ? 0 : (a < b) ? -1 : 1;
+}
+
 /* some macros to help swap requests, replies, and events */
 
 #define LengthRestB(stuff) \
diff --git a/randr/rrdispatch.c b/randr/rrdispatch.c
index 2135504..57d 100644
--- a/randr/rrdispatch.c
+++ b/randr/rrdispatch.c
@@ -28,8 +28,8 @@ RRClientKnowsRates (ClientPtr pClient)
 {
 rrClientPriv(pClient);
 
-return (pRRClient->major_version > 1 ||
-   (pRRClient->major_version == 1 && pRRClient->minor_version >= 1));
+return version_compare(pRRClient->major_version, pRRClient->minor_version,
+   1, 1) >= 0;
 }
 
 static int
@@ -47,8 +47,8 @@ ProcRRQueryVersion (ClientPtr client)
 rep.length = 0;
 rep.sequenceNumber = client->sequence;
 
-if ((stuff->majorVersion * 1000 + stuff->minorVersion) <
-(SERVER_RANDR_MAJOR_VERSION * 1000 + SERVER_RANDR_MINOR_VERSION))
+if (version_compare(stuff->majorVersion, stuff->minorVersion,
+SERVER_RANDR_MAJOR_VERSION, 
SERVER_RANDR_MINOR_VERSION) == -1)
 {
rep.majorVersion = stuff->majorVersion;
rep.minorVersion = stuff->minorVersion;
diff --git a/xfixes/xfixes.c b/xfixes/xfixes.c
index e8c7bf1..8563b22 100644
--- a/xfixes/xfixes.c
+++ b/xfixes/xfixes.c
@@ -72,17 +72,17 @@ ProcXFixesQueryVersion(ClientPtr client)
 rep.type = X_Reply;
 rep.length = 0;
 rep.sequenceNumber = client->sequence;
-if (stuff->majorVersion < SERVER_XFIXES_MAJOR_VERSION) {
+
+if (version_compare(stuff->majorVersion, stuff->minorVersion,
+SERVER_XFIXES_MAJOR_VERSION, 
SERVER_XFIXES_MAJOR_VERSION) == -1)
+{
rep.majorVersion = stuff->majorVersion;
rep.minorVersion = stuff->minorVersion;
 } else {
rep.majorVersion = SERVER_XFIXES_MAJOR_VERSION;
-   if (stuff->majorVersion == SERVER_XFIXES_MAJOR_VERSION &&
-   stuff->minorVersion < SERVER_XFIXES_MINOR_VERSION)
-   rep.minorVersion = stuff->minorVersion;
-   else
-   rep.minorVersion = SERVER_XFIXES_MINOR_VERSION;
+rep.minorVersion = SERVER_XFIXES_MINOR_VERSION;
 }
+
 pXFixesClient->major_version = rep.majorVersion;
 pXFixesClient->minor_version = rep.minorVersion;
 if (client->swapped) {
-- 
1.7.4.4

___
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 08/11] dix: use a tmp variable instead of multiple rClient(other).

2011-05-10 Thread Peter Hutterer

no functional changes.

Signed-off-by: Peter Hutterer 
---
 dix/events.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 4721f40..3f7cc6f 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2018,23 +2018,24 @@ DeliverEventToClients(DeviceIntPtr dev, WindowPtr win, 
xEvent *events,
 for (; other; other = other->next)
 {
 Mask mask;
+ClientPtr client = rClient(other);
 
-if (IsInterferingGrab(rClient(other), dev, events))
+if (IsInterferingGrab(client, dev, events))
 continue;
 
 mask = GetEventMask(dev, events, other);
 
-if (XaceHook(XACE_RECEIVE_ACCESS, rClient(other), win,
+if (XaceHook(XACE_RECEIVE_ACCESS, client, win,
 events, count))
 /* do nothing */;
-else if ( (attempt = TryClientEvents(rClient(other), dev,
+else if ( (attempt = TryClientEvents(client, dev,
 events, count,
 mask, filter, grab)) )
 {
 if (attempt > 0)
 {
 rc = EVENT_DELIVERED;
-*client_return = rClient(other);
+*client_return = client;
 *mask_return = mask;
 } else
 rc = EVENT_REJECTED;
-- 
1.7.4.4

___
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 07/11] Xi: split DeviceStateNotify delivery into a separate function

2011-05-10 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 Xi/exevents.c |  202 +
 1 files changed, 104 insertions(+), 98 deletions(-)

diff --git a/Xi/exevents.c b/Xi/exevents.c
index d48d397..c6f9d46 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1189,6 +1189,108 @@ FixDeviceValuator(DeviceIntPtr dev, deviceValuator * 
ev, ValuatorClassPtr v,
 first += ev->num_valuators;
 }
 
+static void
+DeliverStateNotifyEvent(DeviceIntPtr dev, WindowPtr win)
+{
+int evcount = 1;
+deviceStateNotify *ev, *sev;
+deviceKeyStateNotify *kev;
+deviceButtonStateNotify *bev;
+
+KeyClassPtr k;
+ButtonClassPtr b;
+ValuatorClassPtr v;
+int nval = 0, nkeys = 0, nbuttons = 0, first = 0;
+
+if (!(wOtherInputMasks(win)) ||
+!(wOtherInputMasks(win)->inputEvents[dev->id] & DeviceStateNotifyMask))
+return;
+
+if ((b = dev->button) != NULL) {
+nbuttons = b->numButtons;
+if (nbuttons > 32)
+evcount++;
+}
+if ((k = dev->key) != NULL) {
+nkeys = k->xkbInfo->desc->max_key_code -
+k->xkbInfo->desc->min_key_code;
+if (nkeys > 32)
+evcount++;
+if (nbuttons > 0) {
+evcount++;
+}
+}
+if ((v = dev->valuator) != NULL) {
+nval = v->numAxes;
+
+if (nval > 3)
+evcount++;
+if (nval > 6) {
+if (!(k && b))
+evcount++;
+if (nval > 9)
+evcount += ((nval - 7) / 3);
+}
+}
+
+sev = ev = (deviceStateNotify *) malloc(evcount * sizeof(xEvent));
+FixDeviceStateNotify(dev, ev, NULL, NULL, NULL, first);
+
+if (b != NULL) {
+FixDeviceStateNotify(dev, ev++, NULL, b, v, first);
+first += 3;
+nval -= 3;
+if (nbuttons > 32) {
+(ev - 1)->deviceid |= MORE_EVENTS;
+bev = (deviceButtonStateNotify *) ev++;
+bev->type = DeviceButtonStateNotify;
+bev->deviceid = dev->id;
+memcpy((char*)&bev->buttons[4], (char*)&b->down[4], DOWN_LENGTH - 
4);
+}
+if (nval > 0) {
+(ev - 1)->deviceid |= MORE_EVENTS;
+FixDeviceValuator(dev, (deviceValuator *) ev++, v, first);
+first += 3;
+nval -= 3;
+}
+}
+
+if (k != NULL) {
+FixDeviceStateNotify(dev, ev++, k, NULL, v, first);
+first += 3;
+nval -= 3;
+if (nkeys > 32) {
+(ev - 1)->deviceid |= MORE_EVENTS;
+kev = (deviceKeyStateNotify *) ev++;
+kev->type = DeviceKeyStateNotify;
+kev->deviceid = dev->id;
+memmove((char *)&kev->keys[0], (char *)&k->down[4], 28);
+}
+if (nval > 0) {
+(ev - 1)->deviceid |= MORE_EVENTS;
+FixDeviceValuator(dev, (deviceValuator *) ev++, v, first);
+first += 3;
+nval -= 3;
+}
+}
+
+while (nval > 0) {
+FixDeviceStateNotify(dev, ev++, NULL, NULL, v, first);
+first += 3;
+nval -= 3;
+if (nval > 0) {
+(ev - 1)->deviceid |= MORE_EVENTS;
+FixDeviceValuator(dev, (deviceValuator *) ev++, v, first);
+first += 3;
+nval -= 3;
+}
+}
+
+DeliverEventsToWindow(dev, win, (xEvent *) sev, evcount,
+  DeviceStateNotifyMask, NullGrab);
+free(sev);
+}
+
 void
 DeviceFocusEvent(DeviceIntPtr dev, int type, int mode, int detail,
 WindowPtr pWin)
@@ -1255,104 +1357,8 @@ DeviceFocusEvent(DeviceIntPtr dev, int type, int mode, 
int detail,
 DeliverEventsToWindow(dev, pWin, (xEvent *) & event, 1,
DeviceFocusChangeMask, NullGrab);
 
-if ((event.type == DeviceFocusIn) &&
-   (wOtherInputMasks(pWin)) &&
-   (wOtherInputMasks(pWin)->inputEvents[dev->id] & DeviceStateNotifyMask))
-{
-   int evcount = 1;
-   deviceStateNotify *ev, *sev;
-   deviceKeyStateNotify *kev;
-   deviceButtonStateNotify *bev;
-
-   KeyClassPtr k;
-   ButtonClassPtr b;
-   ValuatorClassPtr v;
-   int nval = 0, nkeys = 0, nbuttons = 0, first = 0;
-
-   if ((b = dev->button) != NULL) {
-   nbuttons = b->numButtons;
-   if (nbuttons > 32)
-   evcount++;
-   }
-   if ((k = dev->key) != NULL) {
-   nkeys = k->xkbInfo->desc->max_key_code -
-k->xkbInfo->desc->min_key_code;
-   if (nkeys > 32)
-   evcount++;
-   if (nbuttons > 0) {
-   evcount++;
-   }
-   }
-   if ((v = dev->valuator) != NULL) {
-   nval = v->numAxes;
-
-   if (nval > 3)
-   evcount++;
-   if (nval > 6) {
-   if (!(k && b))
-   evcount++;
-   if (nval > 9)
-   evcount += ((nval - 7) / 3);
-   }
-   }
-
-   sev = ev = (

[PATCH 06/11] dix: return deliveries from DeliverGrabbedEvent

2011-05-10 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 dix/events.c  |6 +-
 include/dix.h |2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index a8bfa72..4721f40 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3896,8 +3896,10 @@ unwind:
  * grab. If not, TryClientEvents() is used.
  *
  * @param deactivateGrab True if the device's grab should be deactivated.
+ *
+ * @return The number of events delivered.
  */
-void
+int
 DeliverGrabbedEvent(InternalEvent *event, DeviceIntPtr thisDev,
 Bool deactivateGrab)
 {
@@ -4065,6 +4067,8 @@ DeliverGrabbedEvent(InternalEvent *event, DeviceIntPtr 
thisDev,
 free(core);
 free(xi);
 free(xi2);
+
+return deliveries;
 }
 
 /* This function is used to set the key pressed or key released state -
diff --git a/include/dix.h b/include/dix.h
index fb9be43..9a111e8 100644
--- a/include/dix.h
+++ b/include/dix.h
@@ -415,7 +415,7 @@ extern void DeliverFocusedEvent(
 InternalEvent* /* event */,
 WindowPtr /* window */);
 
-extern void DeliverGrabbedEvent(
+extern int DeliverGrabbedEvent(
 InternalEvent* /* event */,
 DeviceIntPtr /* thisDev */,
 Bool /* deactivateGrab */);
-- 
1.7.4.4

___
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 05/11] dix: move the grab activation condition into a if block.

2011-05-10 Thread Peter Hutterer

Rather than 3 conditions with if (deliveries && ...), have one block with
the three in them.
No functional changes.

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   34 ++
 1 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 35548ea..a8bfa72 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2181,24 +2181,26 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr 
pWin, xEvent
 }
 }
 
-/*
- * Note that since core events are delivered first, an implicit grab may
- * be activated on a core grab, stopping the XI events.
- */
-if (IsButtonPressEvent(pEvents) && deliveries && (!grab))
-ActivateImplicitGrab(pDev, client, pWin, pEvents, deliveryMask);
-else if ((type == MotionNotify) && deliveries)
-   pDev->valuator->motionHintWindow = pWin;
-else
-{
-   if ((type == DeviceMotionNotify || type == DeviceButtonPress) &&
-   deliveries)
-   CheckDeviceGrabAndHintWindow (pWin, type,
- (deviceKeyButtonPointer*) pEvents,
- grab, client, deliveryMask);
-}
 if (deliveries)
+{
+/*
+ * Note that since core events are delivered first, an implicit grab 
may
+ * be activated on a core grab, stopping the XI events.
+ */
+if (IsButtonPressEvent(pEvents) && (!grab))
+ActivateImplicitGrab(pDev, client, pWin, pEvents, deliveryMask);
+else if ((type == MotionNotify))
+pDev->valuator->motionHintWindow = pWin;
+else
+{
+if (type == DeviceMotionNotify || type == DeviceButtonPress)
+CheckDeviceGrabAndHintWindow (pWin, type,
+  (deviceKeyButtonPointer*) 
pEvents,
+  grab, client, deliveryMask);
+}
+
return deliveries;
+}
 return nondeliveries;
 }
 
-- 
1.7.4.4

___
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 04/11] dix: split implicit grab activation into a separate function.

2011-05-10 Thread Peter Hutterer

No functional changes, just for readability.

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   79 ++---
 1 files changed, 42 insertions(+), 37 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index bc981a2..35548ea 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2045,6 +2045,47 @@ out:
 return rc;
 }
 
+static void
+ActivateImplicitGrab(DeviceIntPtr dev, ClientPtr client, WindowPtr win,
+ xEvent *event, Mask deliveryMask)
+{
+GrabRec tempGrab;
+OtherInputMasks *inputMasks;
+int type = event->u.u.type;
+
+memset(&tempGrab, 0, sizeof(GrabRec));
+tempGrab.next = NULL;
+tempGrab.device = dev;
+tempGrab.resource = client->clientAsMask;
+tempGrab.window = win;
+tempGrab.ownerEvents = (deliveryMask & OwnerGrabButtonMask) ? TRUE : FALSE;
+tempGrab.eventMask = deliveryMask;
+tempGrab.keyboardMode = GrabModeAsync;
+tempGrab.pointerMode = GrabModeAsync;
+tempGrab.confineTo = NullWindow;
+tempGrab.cursor = NullCursor;
+tempGrab.type = type;
+if (type == ButtonPress)
+tempGrab.grabtype = GRABTYPE_CORE;
+else if (type == DeviceButtonPress)
+tempGrab.grabtype = GRABTYPE_XI;
+else
+{
+tempGrab.type = ((xGenericEvent*)event)->evtype;
+tempGrab.grabtype = GRABTYPE_XI2;
+}
+
+/* get the XI and XI2 device mask */
+inputMasks = wOtherInputMasks(win);
+tempGrab.deviceMask = (inputMasks) ? inputMasks->inputEvents[dev->id]: 0;
+
+if (inputMasks)
+memcpy(tempGrab.xi2mask, inputMasks->xi2mask,
+sizeof(tempGrab.xi2mask));
+
+(*dev->deviceGrab.ActivateGrab)(dev, &tempGrab,
+currentTime, TRUE | ImplicitGrabMask);
+}
 
 /**
  * @return TRUE if the event provided is any of core, XI or XI2 button
@@ -2145,43 +2186,7 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr pWin, 
xEvent
  * be activated on a core grab, stopping the XI events.
  */
 if (IsButtonPressEvent(pEvents) && deliveries && (!grab))
-{
-   GrabRec tempGrab;
-OtherInputMasks *inputMasks;
-
-memset(&tempGrab, 0, sizeof(GrabRec));
-tempGrab.next = NULL;
-   tempGrab.device = pDev;
-   tempGrab.resource = client->clientAsMask;
-   tempGrab.window = pWin;
-   tempGrab.ownerEvents = (deliveryMask & OwnerGrabButtonMask) ? TRUE : 
FALSE;
-   tempGrab.eventMask = deliveryMask;
-   tempGrab.keyboardMode = GrabModeAsync;
-   tempGrab.pointerMode = GrabModeAsync;
-   tempGrab.confineTo = NullWindow;
-   tempGrab.cursor = NullCursor;
-tempGrab.type = type;
-if (type == ButtonPress)
-tempGrab.grabtype = GRABTYPE_CORE;
-else if (type == DeviceButtonPress)
-tempGrab.grabtype = GRABTYPE_XI;
-else
-{
-tempGrab.type = ((xGenericEvent*)pEvents)->evtype;
-tempGrab.grabtype = GRABTYPE_XI2;
-}
-
-/* get the XI and XI2 device mask */
-inputMasks = wOtherInputMasks(pWin);
-tempGrab.deviceMask = (inputMasks) ? 
inputMasks->inputEvents[pDev->id]: 0;
-
-if (inputMasks)
-memcpy(tempGrab.xi2mask, inputMasks->xi2mask,
-sizeof(tempGrab.xi2mask));
-
-   (*pDev->deviceGrab.ActivateGrab)(pDev, &tempGrab,
-currentTime, TRUE | ImplicitGrabMask);
-}
+ActivateImplicitGrab(pDev, client, pWin, pEvents, deliveryMask);
 else if ((type == MotionNotify) && deliveries)
pDev->valuator->motionHintWindow = pWin;
 else
-- 
1.7.4.4

___
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 03/11] dix: simplify button press check for passive grabs

2011-05-10 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index efe596b..bc981a2 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2046,6 +2046,21 @@ out:
 }
 
 
+/**
+ * @return TRUE if the event provided is any of core, XI or XI2 button
+ * press.
+ */
+static BOOL
+IsButtonPressEvent(xEvent *pEvents)
+{
+int type = pEvents->u.u.type;
+
+if (((XI2_EVENT(pEvents) && ((xGenericEvent*)pEvents)->evtype == 
XI_ButtonPress)) ||
+type == DeviceButtonPress || type == ButtonPress)
+return TRUE;
+else
+return FALSE;
+}
 
 /**
  * Deliver events to a window. At this point, we do not yet know if the event
@@ -2129,10 +2144,7 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr pWin, 
xEvent
  * Note that since core events are delivered first, an implicit grab may
  * be activated on a core grab, stopping the XI events.
  */
-if ((type == DeviceButtonPress || type == ButtonPress ||
-((XI2_EVENT(pEvents) && ((xGenericEvent*)pEvents)->evtype == 
XI_ButtonPress)))
-&& deliveries
-&& (!grab))
+if (IsButtonPressEvent(pEvents) && deliveries && (!grab))
 {
GrabRec tempGrab;
 OtherInputMasks *inputMasks;
-- 
1.7.4.4

___
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 02/11] dix: split out client delivery from DeliverEventsToWindow

2011-05-10 Thread Peter Hutterer

No functional changes, just for readability.

Signed-off-by: Peter Hutterer 
---
 dix/events.c |  125 ++---
 1 files changed, 83 insertions(+), 42 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 92fd41d..efe596b 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -1978,6 +1978,74 @@ out:
 return rc;
 }
 
+/**
+ * Deliver events to clients registered on the window.
+ *
+ * @param client_return On successful delivery, set to the recipient.
+ * @param mask_return On successful delivery, set to the recipient's event
+ * mask for this event.
+ */
+static enum EventDeliveryState
+DeliverEventToClients(DeviceIntPtr dev, WindowPtr win, xEvent *events,
+  int count, Mask filter, GrabPtr grab,
+  ClientPtr *client_return, Mask *mask_return)
+{
+int attempt;
+enum EventDeliveryState rc = EVENT_SKIP;
+InputClients *other;
+
+if (CORE_EVENT(events))
+other = (InputClients *)wOtherClients(win);
+else if (XI2_EVENT(events))
+{
+OtherInputMasks *inputMasks = wOtherInputMasks(win);
+/* Has any client selected for the event? */
+if (!GetWindowXI2Mask(dev, win, events))
+goto out;
+other = inputMasks->inputClients;
+} else {
+OtherInputMasks *inputMasks = wOtherInputMasks(win);
+/* Has any client selected for the event? */
+if (!inputMasks ||
+!(inputMasks->inputEvents[dev->id] & filter))
+goto out;
+
+other = inputMasks->inputClients;
+}
+
+rc = EVENT_NOT_DELIVERED;
+
+for (; other; other = other->next)
+{
+Mask mask;
+
+if (IsInterferingGrab(rClient(other), dev, events))
+continue;
+
+mask = GetEventMask(dev, events, other);
+
+if (XaceHook(XACE_RECEIVE_ACCESS, rClient(other), win,
+events, count))
+/* do nothing */;
+else if ( (attempt = TryClientEvents(rClient(other), dev,
+events, count,
+mask, filter, grab)) )
+{
+if (attempt > 0)
+{
+rc = EVENT_DELIVERED;
+*client_return = rClient(other);
+*mask_return = mask;
+} else
+rc = EVENT_REJECTED;
+}
+}
+
+out:
+return rc;
+}
+
+
 
 /**
  * Deliver events to a window. At this point, we do not yet know if the event
@@ -2004,14 +2072,11 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr 
pWin, xEvent
 *pEvents, int count, Mask filter, GrabPtr grab)
 {
 int deliveries = 0, nondeliveries = 0;
-int attempt;
-InputClients *other;
 ClientPtr client = NullClient;
 Mask deliveryMask = 0; /* If a grab occurs due to a button press, then
  this mask is the mask of the grab. */
 int type = pEvents->u.u.type;
 
-
 /* Deliver to window owner */
 if ((filter == CantBeFiltered) || CORE_EVENT(pEvents))
 {
@@ -2040,50 +2105,26 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr 
pWin, xEvent
 /* CantBeFiltered means only window owner gets the event */
 if (filter != CantBeFiltered)
 {
-if (CORE_EVENT(pEvents))
-other = (InputClients *)wOtherClients(pWin);
-else if (XI2_EVENT(pEvents))
-{
-OtherInputMasks *inputMasks = wOtherInputMasks(pWin);
-/* Has any client selected for the event? */
-if (!GetWindowXI2Mask(pDev, pWin, pEvents))
-return 0;
-other = inputMasks->inputClients;
-} else {
-OtherInputMasks *inputMasks = wOtherInputMasks(pWin);
-/* Has any client selected for the event? */
-if (!inputMasks ||
-!(inputMasks->inputEvents[pDev->id] & filter))
-return 0;
+enum EventDeliveryState rc;
 
-other = inputMasks->inputClients;
-}
+rc = DeliverEventToClients(pDev, pWin, pEvents, count, filter, grab,
+   &client, &deliveryMask);
 
-for (; other; other = other->next)
+switch(rc)
 {
-Mask mask;
-if (IsInterferingGrab(rClient(other), pDev, pEvents))
-continue;
-
-mask = GetEventMask(pDev, pEvents, other);
-
-if (XaceHook(XACE_RECEIVE_ACCESS, rClient(other), pWin,
-pEvents, count))
-/* do nothing */;
-else if ( (attempt = TryClientEvents(rClient(other), pDev,
-pEvents, count,
-mask, filter, grab)) )
-{
-if (attempt > 0)
-{
-deliveries++;
-client = rClient(other);
-deliveryMask = mask;
-} else
-nondeliveries--;
-}
+cas

[PATCH 01/11] dix: split out window owner event delivery from DeliverEventsToWindow

2011-05-10 Thread Peter Hutterer

No functional changes, just for readability.

Signed-off-by: Peter Hutterer 
---
 dix/events.c |   78 +++---
 1 files changed, 58 insertions(+), 20 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 276bc75..92fd41d 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -1939,6 +1939,46 @@ TryClientEvents (ClientPtr client, DeviceIntPtr dev, 
xEvent *pEvents,
 return 1;
 }
 
+enum EventDeliveryState {
+EVENT_DELIVERED, /**< Event has been delivered to a client  */
+EVENT_NOT_DELIVERED, /**< Event was not delivered to any client */
+EVENT_SKIP,  /**< Event can be discarded by the caller  */
+EVENT_REJECTED,  /**< Event was rejected for delivery to the client */
+};
+
+/**
+ * Attempt event delivery to the client owning the window.
+ */
+static enum EventDeliveryState
+DeliverToWindowOwner(DeviceIntPtr dev, WindowPtr win,
+ xEvent *events, int count, Mask filter,
+ GrabPtr grab)
+{
+int attempt;
+enum EventDeliveryState rc = EVENT_SKIP;
+
+/* if nobody ever wants to see this event, skip some work */
+if (filter != CantBeFiltered &&
+!((wOtherEventMasks(win)|win->eventMask) & filter))
+goto out;
+
+if (IsInterferingGrab(wClient(win), dev, events))
+goto out;
+
+rc = EVENT_NOT_DELIVERED;
+
+if (XaceHook(XACE_RECEIVE_ACCESS, wClient(win), win, events, count))
+/* do nothing */;
+else if ((attempt = TryClientEvents(wClient(win), dev, events,
+count, win->eventMask,
+filter, grab)))
+rc = (attempt > 0) ? EVENT_DELIVERED : EVENT_REJECTED;
+
+out:
+return rc;
+}
+
+
 /**
  * Deliver events to a window. At this point, we do not yet know if the event
  * actually needs to be delivered. May activate a grab if the event is a
@@ -1975,28 +2015,26 @@ DeliverEventsToWindow(DeviceIntPtr pDev, WindowPtr 
pWin, xEvent
 /* Deliver to window owner */
 if ((filter == CantBeFiltered) || CORE_EVENT(pEvents))
 {
-   /* if nobody ever wants to see this event, skip some work */
-   if (filter != CantBeFiltered &&
-   !((wOtherEventMasks(pWin)|pWin->eventMask) & filter))
-   return 0;
+enum EventDeliveryState rc;
 
-if (IsInterferingGrab(wClient(pWin), pDev, pEvents))
-return 0;
+rc = DeliverToWindowOwner(pDev, pWin, pEvents, count, filter, grab);
 
-   if (XaceHook(XACE_RECEIVE_ACCESS, wClient(pWin), pWin, pEvents, count))
-   /* do nothing */;
-else if ( (attempt = TryClientEvents(wClient(pWin), pDev, pEvents,
- count, pWin->eventMask,
- filter, grab)) )
-   {
-   if (attempt > 0)
-   {
-   deliveries++;
-   client = wClient(pWin);
-   deliveryMask = pWin->eventMask;
-   } else
-   nondeliveries--;
-   }
+switch(rc)
+{
+case EVENT_SKIP:
+return 0;
+case EVENT_REJECTED:
+nondeliveries--;
+break;
+case EVENT_DELIVERED:
+/* We delivered to the owner, with our event mask */
+deliveries++;
+client = wClient(pWin);
+deliveryMask = pWin->eventMask;
+break;
+case EVENT_NOT_DELIVERED:
+break;
+}
 }
 
 /* CantBeFiltered means only window owner gets the event */
-- 
1.7.4.4

___
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 00/11] Misc input cleanup patches

2011-05-10 Thread Peter Hutterer


Nothing overly exciting here, just the usual cleanups of mainly splitting
functions into more bite-sized pieces. There are no (well, shouldn't be)
real functionality changes, just making everything a tad more readable.

Cheers,
  Peter

___
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: IR remote control autorepeat / evdev

2011-05-10 Thread Mauro Carvalho Chehab

Hi Anssi/Peter,

Em 10-05-2011 15:43, Anssi Hannula escreveu:
> On 10.05.2011 08:30, Peter Hutterer wrote:
>> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote:
>>> On 10.05.2011 07:11, Peter Hutterer wrote:
 On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote:
> Hi all!
>
> Most IR/RF remotes differ from normal keyboards in that they don't
> provide release events. They do provide native repeat events, though.
>
> Currently the Linux kernel RC/input subsystems provide a simulated
> autorepeat for remote controls (default delay 500ms, period 33ms), and
> X.org server ignores these events and generates its own autorepeat for 
> them.
>
> The kernel RC subsystem provides a simulated release event when 250ms
> has passed since the last native event (repeat or non-repeat) was
> received from the device.
>
> This is problematic, since it causes lots of extra repeat events to be
> always sent (for up to 250ms) after the user has released the remote
> control button, which makes the remote quite uncomfortable to use.

 I got a bit confused reading this description. Does this mean that remotes
 usually send:
 key press - repeat - repeat - ... - repeat - 
 where the silence indicates that the key has been released? Which the 
 kernel
 after 250ms translates into a release event.
 And the kernel discards the repeats and generates it's own on 500/33?
 Do I get this right so far?
>>>
>>> Yes.
>>>
 If so, I'm not sure how to avoid the 250ms delay since we have no 
 indication
 from the hardware when the silence will stop, right?
>>>
>>> Yes.
>>> AFAICS what we need is to not use softrepeat for these devices and
>>> instead use the native repeats. The 250ms release delay could then be
>>> kept (as it wouldn't cause unwanted repeats anymore) or it could be made
>>> 0ms if that is deemed better.
>>>
>>> I listed some ways to do that below in my original post.
>>>
 Note that the repeat delay and ratio are configurable per-device using XKB,
 so you could set up the 500/33 in X too.

While 500/33 is good for keyboards, this is generally not good for remote 
controllers.
The bit rate for IR transmissions are slow. So, one keypress can last up to 
about
110 ms[1]. That means that the maximum repeat rate for IR devices with such
protocol should be bellow than 10 keystrokes/sec.

Also, the minimum initial delay for IR needs to be different on a few hardware 
that
have a broken IR implementation. We default it to 500ms, but a few drivers 
change it
to fit into some hardware constraits. So, a few kernel driver have some tweaks 
of 
repeat times, to be sure that the device will work properly.

[1] http://www.sbprojects.com/knowledge/ir/nec.htm

>>> It wouldn't make any difference with the actual issue which is
>>> "autorepeat happening after physical key released".
>>>
>>> I guess the reason this hasn't come up earlier is that the unified IR/RC
>>> subsystem in the linux kernel is still quite new. It definitely needs to
>>> be improved regarding this issue - just trying to figure out the best
>>> way to do it.

The repeat events always generated troubles, as it basically depends on how
the hardware actually handles it. Some hardware decoders and some protocols 
support repeat events, while others don't. There are even some remote 
controllers
that, instead of generating repeat codes, they just generate multiple 
keypresses.

With the rc-core, we've unified the repeat treatment (yet, there are some 
exceptions to the default way, for some devices where that uses broken hardware
decoders).

>> right. we used to have hardware repeats in X a few releases back. I think
>> 1.6 was the first one that shifted to pure software autorepeat. One of the
>> results we saw in the transition period was the clash of hw autorepeat (in
>> X's input system, anything that comes out of the kernel counts as "hw") and
>> software repeat. 
>>
>> Integrating them back in is going to be a bit iffy, especially since you
>> need the integration with XKB on each device, essentially disallowing the
>> clients from enabling autorepeat. Not 100% what's required there.
>> The evtev part is going to be the simplest part of all that.
> 
> I suspected it might be tricky. So maybe (at least for the time being)
> remote controls in X should simply get KeyRelease immediately after
> every KeyPress?

This will probably cause some hurt. Things like volume control only work
nice on userspace if repeat events are properly handled. I think we should
try to fix XKB/evdev to not use software events on remote controllers. It
is easy to detect that an input device is a remote controller on evdev.
I wrote a patch for it some time ago (unfortunately, hadn't time to finish
it, as I got some jobs with higher priority). Peter, is that a way to pass
a flag to XKB to say that a hw input device is not a keyboard, and need
a different tr

Re: [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Eric Anholt

On Tue, 10 May 2011 12:32:24 -0700, Jesse Barnes  
wrote:
> On Tue, 10 May 2011 11:59:56 -0700
> Eric Anholt  wrote:
> 
> > On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
> > wrote:
> > > Just add a new struct to remain compatible with existing code.
> > > 
> > > Signed-off-by: Jesse Barnes 
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index a3047e4..a6c301c 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -1,5 +1,5 @@
> > >  AC_PREREQ([2.60])
> > > -AC_INIT([GLProto], [1.4.13], 
> > > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > > +AC_INIT([GLProto], [1.4.14], 
> > > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > >  AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > >  AM_MAINTAINER_MODE
> > >  
> > > diff --git a/glxproto.h b/glxproto.h
> > > index dfa0647..3f9e837 100644
> > > --- a/glxproto.h
> > > +++ b/glxproto.h
> > > @@ -1375,6 +1375,20 @@ typedef struct {
> > >  BYTE pad;
> > >  CARD16 sequenceNumber B16;
> > >  CARD16 event_type B16;
> > 
> > While this is the compat structure, I'd still like to see the padding
> > explicit so I don't worry about it when reading the code ever again.
> 
> Ok, wanna push your existing patch for that or should I push it with
> this stuff?

Meh, just push it with your stuff.


pgpMtDZ9wbewi.pgp
Description: 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] xfree86: print the device ID to the log when adding a device.

2011-05-10 Thread Peter Hutterer

Sometimes the name isn't enough, it's handy to see the device IDs from the
log file.

Signed-off-by: Peter Hutterer 
---
 hw/xfree86/common/xf86Xinput.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 072c1ab..9844613 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -327,8 +327,8 @@ xf86ActivateDevice(InputInfoPtr pInfo)
 dev->config_info = xf86SetStrOption(pInfo->options, "config_info", NULL);
 
 if (serverGeneration == 1)
-xf86Msg(X_INFO, "XINPUT: Adding extended input device \"%s\" (type: 
%s)\n",
-pInfo->name, pInfo->type_name);
+xf86Msg(X_INFO, "XINPUT: Adding extended input device \"%s\" (type: 
%s, id %d)\n",
+pInfo->name, pInfo->type_name, dev->id);
 
 return dev;
 }
-- 
1.7.4.4

___
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] include: export GetProximityEvents and QueueProximityEvents

2011-05-10 Thread Jeremy Huddleston

Reviewed-by: Jeremy Huddleston 

On May 10, 2011, at 17:38, Peter Hutterer wrote:

> This is mainly needed for consistency with GetPointerEvents and friend.
> No-one seems to actually need this function from outside the usual DDXs.
> 
> Signed-off-by: Peter Hutterer 
> ---
> This obviously goes on top of the Queue***Events series in this thread.
> 
> include/input.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/input.h b/include/input.h
> index c1783f7..81c9dfb 100644
> --- a/include/input.h
> +++ b/include/input.h
> @@ -469,13 +469,13 @@ extern _X_EXPORT void QueueKeyboardEvents(
> int key_code,
> const ValuatorMask *mask);
> 
> -extern int GetProximityEvents(
> +extern _X_EXPORT int GetProximityEvents(
> InternalEvent *events,
> DeviceIntPtr pDev,
> int type,
> const ValuatorMask *mask);
> 
> -extern void QueueProximityEvents(
> +extern _X_EXPORT void QueueProximityEvents(
> DeviceIntPtr pDev,
> int type,
> const ValuatorMask *mask);
> -- 
> 1.7.4.4
> 

___
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] include: export GetProximityEvents and QueueProximityEvents

2011-05-10 Thread Peter Hutterer

This is mainly needed for consistency with GetPointerEvents and friend.
No-one seems to actually need this function from outside the usual DDXs.

Signed-off-by: Peter Hutterer 
---
This obviously goes on top of the Queue***Events series in this thread.

 include/input.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/input.h b/include/input.h
index c1783f7..81c9dfb 100644
--- a/include/input.h
+++ b/include/input.h
@@ -469,13 +469,13 @@ extern _X_EXPORT void QueueKeyboardEvents(
 int key_code,
 const ValuatorMask *mask);
 
-extern int GetProximityEvents(
+extern _X_EXPORT int GetProximityEvents(
 InternalEvent *events,
 DeviceIntPtr pDev,
 int type,
 const ValuatorMask *mask);
 
-extern void QueueProximityEvents(
+extern _X_EXPORT void QueueProximityEvents(
 DeviceIntPtr pDev,
 int type,
 const ValuatorMask *mask);
-- 
1.7.4.4

___
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: Not receiving XI_RawMotion events while mouse button is pressed.

2011-05-10 Thread Peter Hutterer

On Tue, May 10, 2011 at 01:56:19PM -0500, Roger Cruz wrote:
> I have integrated libxi2's capability to provide raw motion pointer values
> into my application which was originally using (and still uses) xinput
> events.  The application currently registers for the old xinput events
> using XSelectInput.  
> 
>   XSelectInput(xs->dpy, xs->w, event_mask);
> 
> where the event mask is
> 
>   event_mask = (OwnerGrabButtonMask << 1) - 1;/* all events */
> 
>   event_mask &= ~PointerMotionHintMask;
>   event_mask &= ~PropertyChangeMask;
>   event_mask &= ~ColormapChangeMask;
>   event_mask &= ~SubstructureNotifyMask;
> 
> 
> I added an additional xinput2 registration to only capture the raw motion 
> events which I needed.
> 
>   XISetMask(eventmask->mask, XI_RawMotion);
>   XISelectEvents(xs->dpy, DefaultRootWindow(xs->dpy), eventmask, 1);
> 
> This appears to be working fine.  I get raw motion and mouse button press
> and releases when done independently.  However, when I click to drag, I
> only get the button press event but not the raw motion events.  Is this
> expected behavior for the current implementation of libxi?  I need to be
> able to get raw motion events even when the button is pressed.  I don't
> believe anyone else is grabbing the pointer.

If the button press event is delivered somewhere, this activated an implicit
grab in the server and the device is now grabbed by that client that
received the button press event. I suspect this is the cause here too.

Furthermore, XI and XI2 grabs are handled separately, so if you get a XI1
grab, it does not carry the XI2 event mask. Your raw event is thus not
delivered once you have an XI grab.

Cheers,
  Peter
___
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:twm] Fix: menus.c:2374: warning: implicit declaration of function `putenv`

2011-05-10 Thread Julien Cristau

On Tue, May 10, 2011 at 15:40:46 -0700, Alan Coopersmith wrote:

> Ensure _GNU_SOURCE is defined on Linux builds before including 
> so the prototype is exposed in the header properly.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=32696
> 
> Signed-off-by: Alan Coopersmith 
> ---
>  configure.ac|1 +
>  src/Makefile.am |2 +-
>  src/menus.c |4 
>  src/twm.h   |4 
>  4 files changed, 10 insertions(+), 1 deletions(-)
> 
Reviewed-by: Julien Cristau 

Cheers,
Julien
___
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:twm] Fix: menus.c:2374: warning: implicit declaration of function `putenv`

2011-05-10 Thread Alan Coopersmith

Ensure _GNU_SOURCE is defined on Linux builds before including 
so the prototype is exposed in the header properly.

https://bugs.freedesktop.org/show_bug.cgi?id=32696

Signed-off-by: Alan Coopersmith 
---
 configure.ac|1 +
 src/Makefile.am |2 +-
 src/menus.c |4 
 src/twm.h   |4 
 4 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6f1cef7..fc63127 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,7 @@ AC_INIT([twm], [1.0.6],
 [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [twm])
 AC_CONFIG_SRCDIR([Makefile.am])
 AC_CONFIG_HEADERS([config.h])
+AC_USE_SYSTEM_EXTENSIONS
 
 # Initialize Automake
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
diff --git a/src/Makefile.am b/src/Makefile.am
index cb6f615..cfd0b44 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -27,7 +27,7 @@ bin_PROGRAMS = twm
 rcdir = ${datadir}/X11/twm
 dist_rc_DATA = system.twmrc
 
-AM_CFLAGS = $(TWM_CFLAGS) -DXVENDORNAME=\"The\ X.Org\ Foundation\" 
-DXORG_RELEASE=\"Release\ $(VERSION)\" -D_BSD_SOURCE
+AM_CFLAGS = $(TWM_CFLAGS) -DXVENDORNAME=\"The\ X.Org\ Foundation\" 
-DXORG_RELEASE=\"Release\ $(VERSION)\"
 AM_CFLAGS += -DSYSTEM_INIT_FILE=\"${datadir}/X11/twm/system.twmrc\"
 
 twm_LDADD = $(TWM_LIBS)
diff --git a/src/menus.c b/src/menus.c
index 8d21644..bc688e6 100644
--- a/src/menus.c
+++ b/src/menus.c
@@ -58,6 +58,10 @@ in this Software without prior written authorization from 
The Open Group.
  *
  ***/
 
+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
+
 #include 
 #include 
 #include "twm.h"
diff --git a/src/twm.h b/src/twm.h
index 420d6c8..6e2bb27 100644
--- a/src/twm.h
+++ b/src/twm.h
@@ -62,6 +62,10 @@ from The Open Group.
 #ifndef _TWM_
 #define _TWM_
 
+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
+
 #include 
 #include 
 #include 
-- 
1.7.3.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 libpciaccess 2/2] linux: Implement map_legacy

2011-05-10 Thread Adam Jackson

Signed-off-by: Adam Jackson 
---
 src/linux_sysfs.c |   46 ++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
index 1832ee7..850f92f 100644
--- a/src/linux_sysfs.c
+++ b/src/linux_sysfs.c
@@ -836,6 +836,50 @@ pci_device_linux_sysfs_write8(struct pci_io_handle 
*handle, uint32_t port,
 pwrite(handle->fd, &data, 1, port + handle->base);
 }
 
+static int
+pci_device_linux_sysfs_map_legacy(struct pci_device *dev, pciaddr_t base,
+ pciaddr_t size, int write_enable, void **addr)
+{
+char name[PATH_MAX];
+int flags = O_RDONLY;
+int prot = PROT_READ;
+int fd;
+
+if (write_enable) {
+   flags |= O_WRONLY;
+   prot |= PROT_WRITE;
+}
+
+/* First check if there's a legacy memory method for the device */
+while (dev) {
+   snprintf(name, PATH_MAX, "/sys/class/pci_bus/%04x:%02x/legacy_mem",
+dev->domain, dev->bus);
+
+   fd = open(name, O_RDWR);
+   if (fd >= 0)
+   break;
+
+   dev = pci_device_get_parent_bridge(dev);
+}
+
+/* If not, /dev/mem is the best we can do */
+if (!dev)
+   fd = open("/dev/mem", flags);
+
+if (fd < 0)
+   return errno;
+
+*addr = mmap(NULL, size, prot, MAP_SHARED, fd, base);
+if (*addr == MAP_FAILED) {
+   int ret = errno;
+   close(fd);
+   return ret;
+}
+
+close(fd);
+return 0;
+}
+
 static const struct pci_system_methods linux_sysfs_methods = {
 .destroy = NULL,
 .destroy_device = NULL,
@@ -861,4 +905,6 @@ static const struct pci_system_methods linux_sysfs_methods 
= {
 .write32 = pci_device_linux_sysfs_write32,
 .write16 = pci_device_linux_sysfs_write16,
 .write8 = pci_device_linux_sysfs_write8,
+
+.map_legacy = pci_device_linux_sysfs_map_legacy,
 };
-- 
1.7.5

___
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 libpciaccess 1/2] Add map_legacy interface

2011-05-10 Thread Adam Jackson

This allows platforms to hand back mmaps of the low 1M (ISA) address
space on a per-domain basis.

Signed-off-by: Adam Jackson 
---
 include/pciaccess.h |8 
 src/common_interface.c  |   43 +++
 src/pciaccess_private.h |3 +++
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/include/pciaccess.h b/include/pciaccess.h
index 88515e2..b7795b9 100644
--- a/include/pciaccess.h
+++ b/include/pciaccess.h
@@ -526,4 +526,12 @@ void pci_io_write32(struct pci_io_handle *handle, uint32_t 
reg, uint32_t data);
 void pci_io_write16(struct pci_io_handle *handle, uint32_t reg, uint16_t data);
 void pci_io_write8(struct pci_io_handle *handle, uint32_t reg, uint8_t data);
 
+/*
+ * Legacy memory access
+ */
+
+int pci_device_map_legacy(struct pci_device *dev, pciaddr_t base,
+ pciaddr_t size, int write_enable, void **addr);
+int pci_device_unmap_legacy(struct pci_device *dev, void *addr, pciaddr_t 
size);
+
 #endif /* PCIACCESS_H */
diff --git a/src/common_interface.c b/src/common_interface.c
index 4af772a..fe3c1af 100644
--- a/src/common_interface.c
+++ b/src/common_interface.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pciaccess.h"
 #include "pciaccess_private.h"
@@ -654,3 +655,45 @@ pci_device_enable(struct pci_device *dev)
 if (pci_sys->methods->enable)
pci_sys->methods->enable(dev);
 }
+
+/**
+ * Map the legacy memory space for the PCI domain containing \c dev.
+ *
+ * \param dev  Device whose memory region is to be mapped.
+ * \param base Base address of the range to be mapped.
+ * \param size Size of the range to be mapped.
+ * \param write_enable Map for writing (non-zero).
+ * \param addr Location to store the mapped address.
+ *
+ * \returns
+ * Zero on success or an \c errno value on failure.
+ */
+int
+pci_device_map_legacy(struct pci_device *dev, pciaddr_t base, pciaddr_t size,
+ int write_enable, void **addr)
+{
+if (base > 1048576 || base + size > 1048576)
+   return EINVAL;
+
+if (!pci_sys->methods->map_legacy)
+   return ENOSYS;
+
+return pci_sys->methods->map_legacy(dev, base, size, write_enable, addr);
+}
+
+/**
+ * Unmap the legacy memory space for the PCI domain containing \c dev.
+ *
+ * \param dev  Device whose memory region is to be unmapped.
+ * \param addr Location of the mapped address.
+ * \param size Size of the range to be unmapped.
+ *
+ * \returns
+ * Zero on success or an \c errno value on failure.
+ */
+int
+pci_device_unmap_legacy(struct pci_device *dev, void *addr, pciaddr_t size)
+{
+/* Maybe vtable this?  Meh. */
+return munmap(addr, size);
+}
diff --git a/src/pciaccess_private.h b/src/pciaccess_private.h
index ef0..7870395 100644
--- a/src/pciaccess_private.h
+++ b/src/pciaccess_private.h
@@ -77,6 +77,9 @@ struct pci_system_methods {
 void (*write16)( struct pci_io_handle *handle, uint32_t reg,
 uint16_t data );
 void (*write8)( struct pci_io_handle *handle, uint32_t reg, uint8_t data );
+
+int (*map_legacy)(struct pci_device *dev, pciaddr_t base, pciaddr_t size,
+ int write_enable, void **addr);
 };
 
 struct pci_device_mapping {
-- 
1.7.5

___
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] Add new compose maps for some graphical and mathematical symbols.

2011-05-10 Thread Daniel Kahn Gillmor

This includes the symbols SKULL AND CROSSBONES, ARROW UP, ARROW DOWN,
and UMBRELLA, and the mathematical symbols INFINITY and GREEK SMALL
LETTER PI, GREEK CAPITAL LETTER PI.

 (see also http://bugs.debian.org/607395)
---
 nls/en_US.UTF-8/Compose.pre |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index c3c45db..99e5788 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -218,6 +218,8 @@ XCOMM Other symbols
  : "☭"   U262D # HAMMER AND SICKLE
: "Ⓐ"   U24B6 # CIRCLED LATIN CAPITAL 
LETTER A
   <3>  : "♥"   U2665 # BLACK HEART SUIT
+   : "☠"   U2620 # SKULL AND 
CROSSBONES
+: "☂"   U2602 # UMBRELLA
 
   : "☺"   U263A # WHITE SMILING FACE
: "☹"   U2639 # WHITE FROWNING FACE
@@ -4162,6 +4164,10 @@ XCOMM Part 3
   : "↮"   U21AE # LEFT RIGHT ARROW WITH 
STROKE
: "←" U2190 # LEFTWARDS ARROW
 : "→" U2192 # RIGHTWARDS ARROW
+   : "↑" U2191 # ARROW UP
+   : "↑" U2191 # ARROW UP
+ : "↓" U2193 # ARROW DOWN
+ : "↓" U2193 # ARROW DOWN
   : "∄"   U2204 # THERE DOES NOT EXIST
   : "∉"   U2209 # NOT AN ELEMENT OF
   : "∌"   U220C # DOES NOT CONTAIN AS MEMBER
@@ -4209,6 +4215,9 @@ XCOMM Part 3
   : "⋫"   U22EB # DOES NOT CONTAIN AS NORMAL 
SUBGROUP
   : "⋬"   U22EC # NOT NORMAL SUBGROUP OF OR EQUAL 
TO
   : "⋭"   U22ED # DOES NOT CONTAIN AS NORMAL 
SUBGROUP OR EQUAL
+ <8> <8> : "∞"   U221E # INFINITY
+   : "π"   U03C0 # GREEK SMALL 
LETTER PI
+   : "Π"   U03A0 # GREEK CAPITAL 
LETTER PI
   <1>: "①"   U2460 # CIRCLED DIGIT 
ONE
: "①"   U2460 # CIRCLED DIGIT 
ONE
   <2>: "②"   U2461 # CIRCLED DIGIT 
TWO
-- 
1.7.4.4

___
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: Not receiving XI_RawMotion events while mouse button is pressed.

2011-05-10 Thread Roger Cruz


I have integrated libxi2's capability to provide raw motion pointer values into 
my application which was originally using (and still uses) xinput events.  The 
application currently registers for the old xinput events using XSelectInput.  

XSelectInput(xs->dpy, xs->w, event_mask);

where the event mask is

event_mask = (OwnerGrabButtonMask << 1) - 1;/* all events */

event_mask &= ~PointerMotionHintMask;
event_mask &= ~PropertyChangeMask;
event_mask &= ~ColormapChangeMask;
event_mask &= ~SubstructureNotifyMask;


I added an additional xinput2 registration to only capture the raw motion 
events which I needed.

XISetMask(eventmask->mask, XI_RawMotion);
XISelectEvents(xs->dpy, DefaultRootWindow(xs->dpy), eventmask, 1);

This appears to be working fine.  I get raw motion and mouse button press and 
releases when done independently.  However, when I click to drag, I only get 
the button press event but not the raw motion events.  Is this expected 
behavior for the current implementation of libxi?  I need to be able to get raw 
motion events even when the button is pressed.  I don't believe anyone else is 
grabbing the pointer.

Thanks
Roger R. Cruz

___
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] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Jesse Barnes

On Tue, 10 May 2011 11:59:56 -0700
Eric Anholt  wrote:

> On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
> wrote:
> > Just add a new struct to remain compatible with existing code.
> > 
> > Signed-off-by: Jesse Barnes 
> > 
> > diff --git a/configure.ac b/configure.ac
> > index a3047e4..a6c301c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1,5 +1,5 @@
> >  AC_PREREQ([2.60])
> > -AC_INIT([GLProto], [1.4.13], 
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > +AC_INIT([GLProto], [1.4.14], 
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> >  AM_INIT_AUTOMAKE([foreign dist-bzip2])
> >  AM_MAINTAINER_MODE
> >  
> > diff --git a/glxproto.h b/glxproto.h
> > index dfa0647..3f9e837 100644
> > --- a/glxproto.h
> > +++ b/glxproto.h
> > @@ -1375,6 +1375,20 @@ typedef struct {
> >  BYTE pad;
> >  CARD16 sequenceNumber B16;
> >  CARD16 event_type B16;
> 
> While this is the compat structure, I'd still like to see the padding
> explicit so I don't worry about it when reading the code ever again.

Ok, wanna push your existing patch for that or should I push it with
this stuff?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
___
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] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Eric Anholt

On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
wrote:
> Just add a new struct to remain compatible with existing code.
> 
> Signed-off-by: Jesse Barnes 
> 
> diff --git a/configure.ac b/configure.ac
> index a3047e4..a6c301c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,5 +1,5 @@
>  AC_PREREQ([2.60])
> -AC_INIT([GLProto], [1.4.13], 
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> +AC_INIT([GLProto], [1.4.14], 
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
>  AM_INIT_AUTOMAKE([foreign dist-bzip2])
>  AM_MAINTAINER_MODE
>  
> diff --git a/glxproto.h b/glxproto.h
> index dfa0647..3f9e837 100644
> --- a/glxproto.h
> +++ b/glxproto.h
> @@ -1375,6 +1375,20 @@ typedef struct {
>  BYTE pad;
>  CARD16 sequenceNumber B16;
>  CARD16 event_type B16;

While this is the compat structure, I'd still like to see the padding
explicit so I don't worry about it when reading the code ever again.

> +CARD32 drawable;
> +CARD32 ust_hi B32;
> +CARD32 ust_lo B32;
> +CARD32 msc_hi B32;
> +CARD32 msc_lo B32;
> +CARD32 sbc_hi B32;
> +CARD32 sbc_lo B32;
> +} xGLXBufferSwapComplete;


pgpGoE7Hp2AZA.pgp
Description: 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

Re: [PATCH] dri2proto: add new DRI2BufferSwapComplete struct to match spec

2011-05-10 Thread Eric Anholt

On Thu, 5 May 2011 12:42:43 -0700, Jesse Barnes  
wrote:
> Just add a new struct to remain compatible with existing code.

Reviewed-by: Eric Anholt 


pgpPWYDLhJdKT.pgp
Description: 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

Re: [PATCH:twm] Remove unused fallback implementation of putenv()

2011-05-10 Thread Alan Coopersmith

On 05/10/11 01:04 AM, Mark Kettenis wrote:
>> From: Alan Coopersmith 
>> Date: Mon,  9 May 2011 22:51:36 -0700
>>
>> NOPUTENV was never defined in a modular build, probably because putenv()
>> is a standard function in Unix98 / SUSv2.
> 
> Much older than that.  Looks like it first appeared in SVR2 and
> 4.3BSD-Reno.  That should mean that everything that's even remotely
> UNIX these days should have it.

Thanks - SUSv2 was the earliest standard I could find online quickly, though
I did find man pages referencing it appearing in older BSD versions & SVID,
they weren't specific about versions.

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
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 rendercheck] Report which test groups passed successfully

2011-05-10 Thread Eric Anholt

On Mon, 9 May 2011 18:31:34 -0700, Jeremy Huddleston  wrote:
> 
> This was previously computed but never passed on to the caller.
> 
> Found-by: clang static analyzer
> Signed-off-by: Jeremy Huddleston 

Bonus cleanup of the rest of the code.  Nice.

Looks like I don't get to complain about 4-space indents, because I've
got them all over the code.  Sigh.

> ---
>  configure.ac  |2 +-
>  main.c|   83 
> +++--
>  rendercheck.h |5 +++-
>  tests.c   |2 +
>  4 files changed, 58 insertions(+), 34 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4fa5a63..09b07bd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -22,7 +22,7 @@ XORG_DEFAULT_OPTIONS
>  AC_CHECK_HEADERS([err.h])
>  
>  # Checks for pkg-config packages
> -PKG_CHECK_MODULES(RC, [xrender x11])
> +PKG_CHECK_MODULES(RC, [xrender x11 xproto >= 7.0.17])

What's this about?  Seems like a separate commit kind of thing.

> +void print_tests(FILE *file, int tests) {
> +int i, j;
> +
> +for(i=0, j=0; available_tests[i].name; i++) {
> +if(!(available_tests[i].flag & tests))
> +continue;
> +if(j % 5 == 0) {
> +if(j != 0)
> +putc('\n', stderr);
> +putc('\t', stderr);
> +} else {
> +fprintf(stderr, ", ");
> +}
> +fprintf(stderr, "%s", available_tests[i].name);
> +j++;
> +}
> +if(j)
> +fprintf(file, "\n");
> +}

Spaces between "if(" and "for("


pgpm0RUtLruln.pgp
Description: 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

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

2011-05-10 Thread Jesse Barnes

On Tue, 10 May 2011 10:46:17 +0200
Michel Dänzer  wrote:

> On Fre, 2011-05-06 at 14:01 -0700, Jesse Barnes wrote: 
> > On Fri, 6 May 2011 13:00:19 -0700
> > Jeremy Huddleston  wrote:
> > 
> > > Yeah, that looks about right.
> > > 
> > > This in combination with the latest version of "xserver/glx/dri2: use new 
> > > GLX/DRI2 swap event types"
> > > 
> > > Reviewed-by: Jeremy Huddleston 
> > 
> > Ok here's a more complete patch.  It touches GLX and involves drawable
> > lifetimes, which I'm not that familiar with, so careful review
> > appreciated.  Note the X vs GLX drawable ID switching in the DRI2 event
> > handler (DRI2 just deals with X IDs).
> > 
> > Kristian and Jeremy, is this a good basis for moving the Apple stuff
> > over to a client GLX drawable type?
> > 
> > -- 
> > Jesse Barnes, Intel Open Source Technology Center
> > 
> > From fae63609dd4fd20ccd84d2211787136bb9a1da05 Mon Sep 17 00:00:00 2001
> > From: Jesse Barnes 
> > Date: Fri, 6 May 2011 10:31:24 -0700
> > Subject: [PATCH] GLX/DRI2: handle swap event swap count wrapping
> > 
> > Create a new GLX drawable struct to track client related info, and add a
> > wrap counter to it drawable and track it as we receive events.  This
> > allows us to support the full 64 bits of the event structure we pass to
> > the client even though the server only gives us a 32 bit count.
> > 
> > Signed-off-by: Jesse Barnes 
> 
> [...]
> 
> > @@ -582,6 +584,14 @@ struct glx_display
> >  #endif
> >  };
> >  
> > +struct glx_drawable {
> > +   XID xDrawable;
> > +   XID drawable;
> > +
> > +   uint32_t lastEventSbc;
> > +   int64_t eventSbcWrap;
> 
> Shouldn't eventSbcWrap be unsigned?

The aevent sbc field is signed, so I thought I'd match it.  Making it
unsigned should be fine though too; client already have to check for
wraparound on this value.

> > diff --git a/src/glx/glxext.c b/src/glx/glxext.c
> > index 02652cb..03c05a3 100644
> > --- a/src/glx/glxext.c
> > +++ b/src/glx/glxext.c
> > @@ -106,7 +106,7 @@ XEXT_GENERATE_ERROR_STRING(__glXErrorString, 
> > __glXExtensionName,
> >  static Bool
> >  __glXWireToEvent(Display *dpy, XEvent *event, xEvent *wire)
> >  {
> > - struct glx_display *glx_dpy = __glXInitialize(dpy);
> > +   struct glx_display *glx_dpy = __glXInitialize(dpy);
> >  
> > if (glx_dpy == NULL)
> >return False;
> 
> Superfluous whitespace-only change.

Yeah I couldn't resist.  I'll push that separately.

> Looks good to me otherwise, but I'm not really familiar with the
> client-side GLX drawable lifetime either.

Ok, I'll double check things; I think it's ok since the new struct
matches the DRI drawable lifetime, but I'll look at those paths again
and make sure I haven't missed something.

Now anyone care to test?

-- 
Jesse Barnes, Intel Open Source Technology Center
___
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: IR remote control autorepeat / evdev

2011-05-10 Thread Anssi Hannula

On 10.05.2011 08:30, Peter Hutterer wrote:
> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote:
>> On 10.05.2011 07:11, Peter Hutterer wrote:
>>> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote:
 Hi all!

 Most IR/RF remotes differ from normal keyboards in that they don't
 provide release events. They do provide native repeat events, though.

 Currently the Linux kernel RC/input subsystems provide a simulated
 autorepeat for remote controls (default delay 500ms, period 33ms), and
 X.org server ignores these events and generates its own autorepeat for 
 them.

 The kernel RC subsystem provides a simulated release event when 250ms
 has passed since the last native event (repeat or non-repeat) was
 received from the device.

 This is problematic, since it causes lots of extra repeat events to be
 always sent (for up to 250ms) after the user has released the remote
 control button, which makes the remote quite uncomfortable to use.
>>>
>>> I got a bit confused reading this description. Does this mean that remotes
>>> usually send:
>>> key press - repeat - repeat - ... - repeat - 
>>> where the silence indicates that the key has been released? Which the kernel
>>> after 250ms translates into a release event.
>>> And the kernel discards the repeats and generates it's own on 500/33?
>>> Do I get this right so far?
>>
>> Yes.
>>
>>> If so, I'm not sure how to avoid the 250ms delay since we have no indication
>>> from the hardware when the silence will stop, right?
>>
>> Yes.
>> AFAICS what we need is to not use softrepeat for these devices and
>> instead use the native repeats. The 250ms release delay could then be
>> kept (as it wouldn't cause unwanted repeats anymore) or it could be made
>> 0ms if that is deemed better.
>>
>> I listed some ways to do that below in my original post.
>>
>>> Note that the repeat delay and ratio are configurable per-device using XKB,
>>> so you could set up the 500/33 in X too.
>>
>> It wouldn't make any difference with the actual issue which is
>> "autorepeat happening after physical key released".
>>
>> I guess the reason this hasn't come up earlier is that the unified IR/RC
>> subsystem in the linux kernel is still quite new. It definitely needs to
>> be improved regarding this issue - just trying to figure out the best
>> way to do it.
> 
> right. we used to have hardware repeats in X a few releases back. I think
> 1.6 was the first one that shifted to pure software autorepeat. One of the
> results we saw in the transition period was the clash of hw autorepeat (in
> X's input system, anything that comes out of the kernel counts as "hw") and
> software repeat. 
> 
> Integrating them back in is going to be a bit iffy, especially since you
> need the integration with XKB on each device, essentially disallowing the
> clients from enabling autorepeat. Not 100% what's required there.
> The evtev part is going to be the simplest part of all that.

I suspected it might be tricky. So maybe (at least for the time being)
remote controls in X should simply get KeyRelease immediately after
every KeyPress?

Meaning that either a) kernel does it (while maybe providing some new
extra info for those evdev users that want to distinguish repeats from
new keypresses - original suggestion 4), or b) kernel provides a flag
which causes the X evdev driver to follow-up every keydown/repeat event
with an immediate release event. (both of these include kernel changed
to use native repeats instead of softrepeats, which is trivial)


 Now, IMO something should be done to fix this. But what exactly?

 Here are two ideas that would remove these ghost repeats:

 1. Do not provide any repeat/release simulation in the kernel for RC
 devices (by default?), just provide both keydown and immediate release
 events for every native keypress or repeat received from the device.
 + Very simple to implement
 - We lose the ability to track repeats, i.e. if a new event was a repeat
   or a new keypress; "holding down" a key becomes impossible

 or
 2. Replace kernel autorepeat simulation by passing through the native
 repeat events (probably filtering them according to REP_DELAY and
 REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP)
 indicating that the keyrelease is simulated, and have the X server use
 the native repeats instead of softrepeats for such a device.
 + The userspace correctly gets repeat events tagged as repeats and
   release events when appropriate (albeit a little late)
 - Adds complexity. Also, while the kernel part is quite easy to
   implement, I'm not sure if the X server part is.

 or
 3. Same as 1., but indicate the repeatness of an event with a new
additional special event before EV_SYN (sync event).
 + Simple to implement
 - Quite hacky, and userspace still can't guess f

Re: [PATCH 2/6] XKB: Simplify a loop in ProcXkbGetKbdByName

2011-05-10 Thread Cyril Brulebois

Hi,

Daniel Stone  (10/05/2011):
> Yes.  I could probably call it out in the commit message if that
> would help?

for a random passerby like I am, that'd be nice; but I'm also happy as
it is if everything is like intended. :)

Mraw,
KiBi.


signature.asc
Description: Digital 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

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

2011-05-10 Thread Michel Dänzer

On Fre, 2011-05-06 at 14:01 -0700, Jesse Barnes wrote: 
> On Fri, 6 May 2011 13:00:19 -0700
> Jeremy Huddleston  wrote:
> 
> > Yeah, that looks about right.
> > 
> > This in combination with the latest version of "xserver/glx/dri2: use new 
> > GLX/DRI2 swap event types"
> > 
> > Reviewed-by: Jeremy Huddleston 
> 
> Ok here's a more complete patch.  It touches GLX and involves drawable
> lifetimes, which I'm not that familiar with, so careful review
> appreciated.  Note the X vs GLX drawable ID switching in the DRI2 event
> handler (DRI2 just deals with X IDs).
> 
> Kristian and Jeremy, is this a good basis for moving the Apple stuff
> over to a client GLX drawable type?
> 
> -- 
> Jesse Barnes, Intel Open Source Technology Center
> 
> From fae63609dd4fd20ccd84d2211787136bb9a1da05 Mon Sep 17 00:00:00 2001
> From: Jesse Barnes 
> Date: Fri, 6 May 2011 10:31:24 -0700
> Subject: [PATCH] GLX/DRI2: handle swap event swap count wrapping
> 
> Create a new GLX drawable struct to track client related info, and add a
> wrap counter to it drawable and track it as we receive events.  This
> allows us to support the full 64 bits of the event structure we pass to
> the client even though the server only gives us a 32 bit count.
> 
> Signed-off-by: Jesse Barnes 

[...]

> @@ -582,6 +584,14 @@ struct glx_display
>  #endif
>  };
>  
> +struct glx_drawable {
> +   XID xDrawable;
> +   XID drawable;
> +
> +   uint32_t lastEventSbc;
> +   int64_t eventSbcWrap;

Shouldn't eventSbcWrap be unsigned?


> diff --git a/src/glx/glxext.c b/src/glx/glxext.c
> index 02652cb..03c05a3 100644
> --- a/src/glx/glxext.c
> +++ b/src/glx/glxext.c
> @@ -106,7 +106,7 @@ XEXT_GENERATE_ERROR_STRING(__glXErrorString, 
> __glXExtensionName,
>  static Bool
>  __glXWireToEvent(Display *dpy, XEvent *event, xEvent *wire)
>  {
> - struct glx_display *glx_dpy = __glXInitialize(dpy);
> +   struct glx_display *glx_dpy = __glXInitialize(dpy);
>  
> if (glx_dpy == NULL)
>return False;

Superfluous whitespace-only change.


Looks good to me otherwise, but I'm not really familiar with the
client-side GLX drawable lifetime either.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
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:twm] Remove unused fallback implementation of putenv()

2011-05-10 Thread Mark Kettenis

> From: Alan Coopersmith 
> Date: Mon,  9 May 2011 22:51:36 -0700
> 
> NOPUTENV was never defined in a modular build, probably because putenv()
> is a standard function in Unix98 / SUSv2.

Much older than that.  Looks like it first appeared in SVR2 and
4.3BSD-Reno.  That should mean that everything that's even remotely
UNIX these days should have it.

Reviewed-by: Mark Kettenis 

> Signed-off-by: Alan Coopersmith 
> ---
>  src/util.c |   66 
> 
>  1 files changed, 0 insertions(+), 66 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

39 matches

Mail list logo