xf86-video-nested
Is this driver working with nvidia gpu? I cannot get it working on nvidia and ubuntu 12.10 It seems to load, but no login screen: 4.834] (II) LoadModule: nested [ 4.834] (II) Loading /usr/lib/xorg/modules/drivers/nested_drv.so [ 4.835] (II) Module nested: vendor=X.Org Foundation [ 4.835]compiled for 1.13.0, module version = 0.1.0 [ 4.835]Module class: X.Org Video Driver [ 4.835]ABI class: X.Org Video Driver, version 13.0 [ 4.835] (II) NESTED: Driver for nested servers: nested [ 4.835] (II) NestedDriverFunc [ 4.835] (II) NestedDriverFunc [ 4.835] (WW) Falling back to old probe method for nested [ 4.835] (II) NESTED(0): NestedPreInit [ 4.835] (**) NESTED(0): Depth 24, (--) framebuffer bpp 32 [ 4.835] (==) NESTED(0): RGB weight 888 [ 4.835] (==) NESTED(0): Default visual is TrueColor [ 4.835] (WW) NESTED(0): Option DPMS is not used ___ 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: xf86-video-nested
On Thu, Nov 22, 2012 at 11:24:39AM +0100, linux-service.be bvba wrote: Is this driver working with nvidia gpu? No, it's meant to nest an X-Server within/on top of an already running X-Server. ___ 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: xf86-video-nested
That is how I configure it: -Dual head nvidia gpu,two screens,keybaords and mices -xorg.conf generate with nvidia-settings -replace driver nvidia with nested -gdm 2.20, start underlaying,non-handled server :0 -start two xservers :0.0 and 0.1 in gdm just like I do it now with Xgl or xephyr. no go. Or do i need twe separate xorg.conf's? On Thu, Nov 22, 2012 at 11:24:39AM +0100, linux-service.be bvba wrote: Is this driver working with nvidia gpu? No, it's meant to nest an X-Server within/on top of an already running X-Server. ___ 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
Re: xf86-video-nested
On Thu, Nov 22, 2012 at 01:05:57PM +0100, linux-service.be bvba wrote: Or do i need twe separate xorg.conf's? Yes, you'll need a separate config. The README contains 2 examples. Don't expect to much of xf86-video-nested, i.e. modifiers don't work. I've fixed that and various other things. But, I didn't had the time to bring it into a publishable state, yet. ___ 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: xf86-video-nested
Ok, thanks. So for the underlaying non-handled server a xorg.conf(nvidia driver or nested driver?) and for the two nested servers also each a seperate xorg.conf? The xorg.conf for a nested server only has one screen and display? No problem for the expectations, but I want to test it anyway. guy On Thu, Nov 22, 2012 at 01:05:57PM +0100, linux-service.be bvba wrote: Or do i need twe separate xorg.conf's? Yes, you'll need a separate config. The README contains 2 examples. Don't expect to much of xf86-video-nested, i.e. modifiers don't work. I've fixed that and various other things. But, I didn't had the time to bring it into a publishable state, yet. ___ 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] [xorg-dev][xserver] Full support of sRGB capable fbconfigs.
From: Tomasz Lis tomasz@intel.com
Changes to correctly initialize the sRGB capability attribute and transfer it
between XServer and the client.
Modifications include extension string, transferring visual config attribs and
fbconfig attribs.
Also, attribute is initialized in the modules which do not really use it
(xquartz and xwin).
Signed-off-by: Tomasz Lis tomasz@intel.com
---
glx/extension_string.c|1 +
glx/extension_string.h|1 +
glx/glxcmds.c |7 +--
glx/glxdri2.c |7 +++
glx/glxdricommon.c|4 +++-
glx/glxscreens.c |2 ++
glx/glxscreens.h |3 +++
hw/xquartz/GL/visualConfigs.c |3 +++
hw/xwin/glx/indirect.c|2 ++
9 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/glx/extension_string.c b/glx/extension_string.c
index 544ca1f..47a9746 100644
--- a/glx/extension_string.c
+++ b/glx/extension_string.c
@@ -74,6 +74,7 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(ARB_multisample), VER(1,4), Y, },
{ GLX(EXT_create_context_es2_profile), VER(0,0), N, },
+{ GLX(EXT_framebuffer_sRGB),VER(1,1), N, },
{ GLX(EXT_import_context), VER(0,0), Y, },
{ GLX(EXT_texture_from_pixmap), VER(0,0), Y, },
{ GLX(EXT_visual_info), VER(0,0), Y, },
diff --git a/glx/extension_string.h b/glx/extension_string.h
index 7a4a8b1..a91385f 100644
--- a/glx/extension_string.h
+++ b/glx/extension_string.h
@@ -41,6 +41,7 @@ enum {
ARB_create_context_robustness_bit,
ARB_multisample_bit,
EXT_create_context_es2_profile_bit,
+EXT_framebuffer_sRGB_bit,
EXT_import_context_bit,
EXT_texture_from_pixmap_bit,
EXT_visual_info_bit,
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index c1f4e22..720a1a8 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -913,7 +913,7 @@ __glXDisp_CopyContext(__GLXclientState * cl, GLbyte * pc)
enum {
GLX_VIS_CONFIG_UNPAIRED = 18,
-GLX_VIS_CONFIG_PAIRED = 20
+GLX_VIS_CONFIG_PAIRED = 22
};
enum {
@@ -1005,6 +1005,8 @@ __glXDisp_GetVisualConfigs(__GLXclientState * cl, GLbyte
* pc)
buf[p++] = modes-samples;
buf[p++] = GLX_SAMPLE_BUFFERS_SGIS;
buf[p++] = modes-sampleBuffers;
+buf[p++] = GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT;
+buf[p++] = modes-sRGBCapable;
buf[p++] = 0; /* copy over visualSelectGroup
(GLX_VISUAL_SELECT_GROUP_SGIX)? */
buf[p++] = 0;
@@ -1017,7 +1019,7 @@ __glXDisp_GetVisualConfigs(__GLXclientState * cl, GLbyte
* pc)
return Success;
}
-#define __GLX_TOTAL_FBCONFIG_ATTRIBS (36)
+#define __GLX_TOTAL_FBCONFIG_ATTRIBS (37)
#define __GLX_FBCONFIG_ATTRIBS_LENGTH (__GLX_TOTAL_FBCONFIG_ATTRIBS * 2)
/**
* Send the set of GLXFBConfigs to the client. There is not currently
@@ -1109,6 +,7 @@ DoGetFBConfigs(__GLXclientState * cl, unsigned screen)
WRITE_PAIR(GLX_BIND_TO_MIPMAP_TEXTURE_EXT, modes-bindToMipmapTexture);
WRITE_PAIR(GLX_BIND_TO_TEXTURE_TARGETS_EXT,
modes-bindToTextureTargets);
+WRITE_PAIR(GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, modes-sRGBCapable);
if (client-swapped) {
__GLX_SWAP_INT_ARRAY(buf, __GLX_FBCONFIG_ATTRIBS_LENGTH);
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index bce1bfa..ef7afb4 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -882,6 +882,13 @@ initializeExtensions(__GLXDRIscreen * screen)
AIGLX: enabled GLX_SGI_swap_control and
GLX_MESA_swap_control\n);
}
+/* enable EXT_framebuffer_sRGB extension (even if there are no sRGB
capable fbconfigs) */
+{
+__glXEnableExtension(screen-glx_enable_bits,
+ GLX_EXT_framebuffer_sRGB);
+LogMessage(X_INFO, AIGLX: enabled GLX_EXT_framebuffer_sRGB\n);
+}
+
for (i = 0; extensions[i]; i++) {
#ifdef __DRI_READ_DRAWABLE
if (strcmp(extensions[i]-name, __DRI_READ_DRAWABLE) == 0) {
diff --git a/glx/glxdricommon.c b/glx/glxdricommon.c
index c90f380..b027f24 100644
--- a/glx/glxdricommon.c
+++ b/glx/glxdricommon.c
@@ -105,7 +105,9 @@ __ATTRIB(__DRI_ATTRIB_BUFFER_SIZE, rgbBits),
__ATTRIB(__DRI_ATTRIB_BIND_TO_TEXTURE_RGB, bindToTextureRgb),
__ATTRIB(__DRI_ATTRIB_BIND_TO_TEXTURE_RGBA, bindToTextureRgba),
__ATTRIB(__DRI_ATTRIB_BIND_TO_MIPMAP_TEXTURE, bindToMipmapTexture),
-__ATTRIB(__DRI_ATTRIB_YINVERTED, yInverted),};
+__ATTRIB(__DRI_ATTRIB_YINVERTED, yInverted),
+__ATTRIB(__DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE, sRGBCapable),
+};
static void
setScalar(__GLXconfig * config, unsigned int attrib, unsigned int value)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 61d590c..e87256d 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -164,7 +164,9 @@ static char GLXServerVendorName[] = SGI;
unsigned glxMajorVersion = SERVER_GLX_MAJOR_VERSION;
unsigned glxMinorVersion =
Re: drm_gem_create_mmap_offset / intel_uxa_prepare_access bo problems
On Thu, 22 Nov 2012 16:29:08 +0100, Knut Petersen knut_peter...@t-online.de wrote: Hi Chris! Problem: === Slowdown of system, missing icons after 16 days kernel uptime and 12 days Xserver uptime. Xorg log: flooded with (WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1, access 1) failed: No space left on device lines dmesg: flooded with [drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0 entries Hardware === AOpen i915GMm-hfs, Pentium-M Dothan Software: === linux kernel 3.6.6 full Xorg git master, fetch/build 10 November 2012, video-intel: git f5d79b202dd448e61ab6ffce26fe9cbf9051d770 xserver: git 011f8458805e443ac9130865d2840a929a00cabf rest of system openSuSE 12.1 Any idea? Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh That will undoubtably reveal a large number of objects being held by the X server... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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
drm_gem_create_mmap_offset / intel_uxa_prepare_access bo problems
Hi Chris! Problem: === Slowdown of system, missing icons after 16 days kernel uptime and 12 days Xserver uptime. Xorg log: flooded with (WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1, access 1) failed: No space left on device lines dmesg: flooded with [drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0 entries Hardware === AOpen i915GMm-hfs, Pentium-M Dothan Software: === linux kernel 3.6.6 full Xorg git master, fetch/build 10 November 2012, video-intel: git f5d79b202dd448e61ab6ffce26fe9cbf9051d770 xserver: git 011f8458805e443ac9130865d2840a929a00cabf rest of system openSuSE 12.1 Any idea? cu, Knut ___ 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: Implement pressure barriers and releases (server, try 1)
On Tue, Nov 20, 2012 at 02:50:40PM -0500, Jasper St. Pierre wrote: This is a heavy modification of RAOF's patch set that's used in Ubuntu for Unity and was was once proposed here. This implements the server side: xiproto [1] and libXi [2] patches are boring and bland, and read as you pretty much expect. If there isn't too much turbulence with this current patch set, I'll go and attach them here for a more formal review of those. I'd like to get this in for 1.14, and I understand this is sort of a tight schedule. I don't want to make any promises here, but I suspect this is more likely to land for 1.15. Over the last couple of releases we've merged features that were decidedly incomplete (touch, smooth scrolling, as two examples) and fixing them up under time pressure has not been useful. So this one I want to actually get done and tested before we merge it. 1.14 may still be possible if it turns out to be easier and we have enough test cases to assume that it's not broken out of the box (like touch pointer emulation for example). but if you set your mind to 1.15 now, you get spared the disappointment later :) There are a few limitations and issues with the current patch set, but hopefully these can live as-is for now, fixing up the implementation later. Limitations: 1. Barriers on screen edges will not get events, due to unintended interactions between RANDR and barriers. Multiple solutions have been discussed on #xorg-devel, but none of them are easy and convenient to fix. This is an extension of bug #48008 [3] in some ways. this is something that we should consider fixing, as it makes the corner hotspot use-case easier to clients. 2. Overlapping barriers will not work: only one will receive events. This is an extreme edge case, considering that window managers are supposed to be the intended user of barriers, and that they control their own destiny. this should be explicitly clarified in the protocol. something along these lines: pointer motion is blocked at the closest barrier blocking in the given direction. If two or more barriers block on the same coordinates, the first barrier is considered blocking. Barrier events are only sent to the one blocking barrier (if applicable) for the current direction Bonus points for making it really predictable, e.g. oldest barrier wins (which, given that we have a list of barriers, should be easy enough) which brings the next point - should barriers be assigned to windows, where useful? 3. Releasing a barrier will lose pointer acceleration across the barrier. Unity's current use case includes releasing a barrier when the pointer is at high velocity, so it may be worth re-introducing a velocity barrier, which is only solid at speeds less than some threshold. this is honestly something that I'd like to have tested reasonably well in real-world situations before merging. it's all nice if we can push through, but if the end result is confusing pointer motion, we need to find a better solution. 4. The interaction with grabs hasn't been decided yet; as with existing barriers, a pointer grab will still allow barriers to constrain the cursor. Currently, an event is sent to the appropriate client when a barrier is hit, always, even when a different client has a grab on the pointer. Semantics can and probably should be tweaked here. this is a can of worms that we really need to sort out before we merge anything because I suspect this can make or break the whole approach. - if you're sending events while a grab is active, can the non-grabbing client release the pointer from the barrier? - if not, what's the point of sending the event in the first place? is there one? (honestly not sure here, we don't send enter/leave events either during grabs iirc) - if you're sending events during grabs but the client cannot release, how will the client know that the device is grabbed? destroying the barrier may be a use-case in response to hitting it but the client needs to know if a grab is active here. - if you're _not_ sending events while a grab is active, the UI experience is inconsistent. a grab is always activated on button press, so if you're planning to drag and drop something but you hit a barrier on the way - what's the behaviour there? the last point also feeds in with point 1, where we could and should use barriers for corner hotspot. one more thing I found when testing the first patch you sent (the wobbly cursor one): how likely is it that a user sticks to the barrier until a release request arrives? I find that even when I try really hard to move right only along the barrier, I tend to get the odd x-1 event. which would generate a new event_id, thus trigger a new block/release cycle. do you have any data on that yet? Cheers, Peter
Re: [PATCH 3/5] Add support for XI2.3: Pointer barrier notify events
On Tue, Nov 20, 2012 at 02:50:43PM -0500, Jasper St. Pierre wrote:
From: Jasper St. Pierre jstpie...@mecheye.net
This adds support for clients that would like to get a notification
every time a barrier is released, along with a way to temporarily
release a barrier after it has been hit.
This adds two new events to XI: BarrierHitNotify and
BarrierPointerReleasedNotify.
Based on work by Chris Halse Rogers chris.halse.rog...@canonical.com
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
Xi/exevents.c | 43 ++
Xi/extinit.c | 32 ++
Xi/xibarriers.c| 98
++
Xi/xibarriers.h| 1 +
dix/getevents.c| 4 +-
hw/xfree86/modes/xf86RandR12.c | 4 +-
include/events.h | 1 +
include/eventstr.h | 22 ++
include/inputstr.h | 2 +-
include/protocol-versions.h| 2 +-
include/scrnintstr.h | 2 +-
mi/mieq.c | 3 ++
mi/mipointer.c | 12 --
mi/mipointer.h | 4 +-
randr/randrstr.h | 2 +-
randr/rrcrtc.c | 4 +-
16 files changed, 204 insertions(+), 32 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 4248b9a..98a2cee 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1649,6 +1649,46 @@ ProcessTouchEvent(InternalEvent *ev, DeviceIntPtr dev)
UpdateDeviceState(dev, ev-device_event);
}
+#define INT_TO_FP3232(x) ((FP3232) { (x), 0 })
+
+static void
+ProcessBarrierEvent(InternalEvent *e, DeviceIntPtr dev)
+{
+Mask filter;
+WindowPtr pWin;
+BarrierEvent *be = e-barrier_event;
+xXIBarrierNotifyEvent ev = {
+.type = GenericEvent,
+.extension = IReqCode,
+.sequenceNumber = 0,
+.length = 9,
+.evtype = be-event_type,
+.window = be-window,
+.deviceid = dev-id,
+.time = be-time,
+.x = be-x,
+.y = be-y,
+.dx = INT_TO_FP3232(be-dx),
+.dy = INT_TO_FP3232(be-dy),
+.raw_dx = INT_TO_FP3232(be-raw_dx),
+.raw_dy = INT_TO_FP3232(be-raw_dy),
+.dt = be-dt,
+.event_id = be-event_id,
+.barrier = be-barrierid,
+};
+
+if (!IsMaster(dev))
+return;
+
+if (dixLookupWindow(pWin, be-window, serverClient, DixReadAccess) !=
Success)
+return;
+
+filter = GetEventFilter(dev, (xEvent *) ev);
+
+DeliverEventsToWindow(dev, pWin, (xEvent *) ev, 1,
+ filter, NullGrab);
+}
+
/**
* Process DeviceEvents and DeviceChangedEvents.
*/
@@ -1798,6 +1838,9 @@ ProcessOtherEvent(InternalEvent *ev, DeviceIntPtr
device)
case ET_TouchEnd:
ProcessTouchEvent(ev, device);
break;
+case ET_BarrierNotify:
+ProcessBarrierEvent(ev, device);
+break;
default:
ProcessDeviceEvent(ev, device);
break;
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 1074b23..6571943 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -840,6 +840,33 @@ STouchOwnershipEvent(xXITouchOwnershipEvent * from,
xXITouchOwnershipEvent * to)
swapl(to-child);
}
+static void
+SBarrierNotifyEvent(xXIBarrierNotifyEvent * from,
+xXIBarrierNotifyEvent * to) {
+to-type = from-type;
+
+cpswaps(from-x, to-x);
+cpswaps(from-y, to-y);
+cpswaps(from-dt, to-dt);
+cpswapl(from-length, to-length);
+cpswapl(from-time, to-time);
+
+cpswaps(from-event_id, to-event_id);
+cpswapl(from-barrier, to-barrier);
+cpswapl(from-window, to-window);
+
+#define SWAP_FP3232(x, y) \
+do {\
+cpswapl((x).integral, (y).integral);\
+cpswapl((x).frac, (y).frac);\
+} while(0)
+
+SWAP_FP3232(from-dx, to-dx);
+SWAP_FP3232(from-dy, to-dy);
+SWAP_FP3232(from-raw_dx, to-raw_dx);
+SWAP_FP3232(from-raw_dy, to-raw_dy);
+}
+
/** Event swapping function for XI2 events. */
void
XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
@@ -886,6 +913,11 @@ XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
case XI_RawTouchEnd:
SRawEvent((xXIRawEvent *) from, (xXIRawEvent *) to);
break;
+case XI_BarrierHitNotify:
+case XI_BarrierPointerReleasedNotify:
+SBarrierNotifyEvent((xXIBarrierNotifyEvent *) from,
+(xXIBarrierNotifyEvent *) to);
+break;
default:
ErrorF([Xi] Unknown event type to swap. This is a bug.\n);
break;
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index a97db56..9b5f657 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -56,6 +56,8 @@
#include xace.h
#include list.h
#include exglobals.h
+#include eventstr.h
[ANNOUNCE] xorg-server 1.13.0.901 (1.13.1-rc1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carlos Garnacho (3): Sync TouchListener memory allocation with population in TouchSetupListeners() Xi: Update the device after delivering the emulated pointer event(#56558) Xi: Set modifier mask on touch events Chase Douglas (1): End physically active touches when device is disabled Daniel Drake (1): Xi: Don't check for TOUCH_END, it's never set Daniel Stone (1): Touch: Fix duplicate TouchBegin selection with virtual devices Dave Airlie (4): dri2: invalidate drawable after sharing pixmap xf86/platform: scan pci after probing devices config/udev: ignore change on drm devices xf86: fix multi-seat video device support. (v2) Jon TURNEY (4): Correct description of -displayfd option in man page. hw/xwin: Only add GLX extension once. Fix compilation of Xorg DDX without XF86VIDMODE Fix 'make distcheck' for hw/xwin Matt Dew (1): Bump release info for this RC1. Michel Dänzer (1): EXA: Track source/mask pixmaps more explicitly for Composite fallback regions. Peter Hutterer (7): dix: set the device transformation matrix dix: fix crash on XI 1.x grabs on disabled devices. (#54934) xfree86: add xf86UpdateDesktopDimensions() dix: fix crash on shutdown if a disabled device is still grabbed (XI1 grab) xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP Xi: don't deliver TouchEnd to a client waiting for TouchBegin (#55738) dix: fix zaphod screen scrossing (#54654) Yufeng Shen (1): dix: fix scale_to_desktop for edge ABS events git tag: xorg-server-1.13.0.901 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.13.0.901.tar.bz2 MD5: 8da850ca5d6f6aab8c620abb0ad21675 xorg-server-1.13.0.901.tar.bz2 SHA1: e863eed21cd75dfb3b6cfab5cdede72ac2057e13 xorg-server-1.13.0.901.tar.bz2 SHA256: 64a50d6ca8264d8e32db4ebeeaf4df3b37ef447c7eef37e9a377c983733596f5 xorg-server-1.13.0.901.tar.bz2 xorg-server-1.13.0.901.tar.gz MD5: ac4084faf06e46ecfc83be76f050e3cd xorg-server-1.13.0.901.tar.gz SHA1: 812c5b0ecc4aa8d60b87b33b2b93cfe6cb1d72c1 xorg-server-1.13.0.901.tar.gz SHA256: 323768f8309e99e92cd4c30a89bdabfe244ae1c873e79ad62eb18eb35346ee71 xorg-server-1.13.0.901.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQrw32AAoJEKa/N3H3w77DwSwH/j1OE9zWHPdYvTteRV3K/R5i 0Z/y9aNDPRh1LzLDGb6mgQ7et70BEn7J3jNkmCFlMPS2QqUsWlNKDQ6mSXrTH2J1 9ho3D2RVoZ6PEjpNKqZj1z54ZTWY3ATaKu8Dhbn362FzV47a4uqH9NA1tTlbuo9p yg2uNDZX+ZnAPlUPW/C+ncROHnWRQIYjLKVsz2v/WSTZe1TV41Zjf34Qy1El2DB1 TWDox9k+Uu0R0gqpvT7bmanqdtyYLSSXod8Mt/td4Ww5tAHvZ+mUzvapvUaW/tV/ AfC/SQCwGakTXuDyjWz60Xdh80ehi0zyjzMX9Oaah4zT2gL2KQIqNRJL9r8lk3M= =zMZE -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
