This part of work will enable Xephyr to run xcompmgr.
The logic is when an X clients wants to get a DRI2Drawable, we create a host
peer invisible window, and give the client the peer DRI2Drawable. When
glXSwapbuffer happens, we copy the peer window content into Xpehyr managed
window and damage tha
This part of work will enable Xephyr to run mutter.
The logic is that I disabled the GLX_texture_from_pixmap extension in Xephyr so
that mutter will have to copy the pixmap into texture and draw the texture with
glTexImage2D.
To support GLX_texture_from_pixmap, we have to support the general GLX
This part of work fixes the Xephyr host cursor issue. Ohterwise when we close
pointer device in dix, it will cause a signal fault as the callback is NULL.
>From 06f30919ed2e2624c743ef59c6b7f21d0fef424c Mon Sep 17 00:00:00 2001
From: Haitao Feng
Date: Fri, 14 May 2010 13:03:55 +0800
Subject: Fix
Morton,
I want to know if the black region after SRC is the CLEAR operation?
If that is so, I want to modify the driver to do the CLEAR outside the
20x20 mask region to make the driver does the right SRC operation.
Thanks,
Frank
-Original Message-
From: Jonathan Morton
On Mit, 2010-05-19 at 02:01 +0700, Mikhail Gusarov wrote:
> This changes ABI of server as Xalloc/Xfree/Xrealloc/Xstrdup are
> no longer exported. OTOH, API is not changed.
I'm not sure there's much point keeping the API around when the ABI is
removed. Warning-conscious drivers will need to be fix
This should go away in 0b45ba48.
Signed-off-by: Tiago Vignatti
---
Xext/Makefile.am |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Xext/Makefile.am b/Xext/Makefile.am
index fa007aa..e444fd0 100644
--- a/Xext/Makefile.am
+++ b/Xext/Makefile.am
@@ -133,7 +133,6 @@ EXTRA_D
Hi, Jackson,
First thanks for your explanation, through the debugging, I found when
I start the "fade to black", the gamma values will be setup to the default
value (1.0), it will be transferred to the XServer. And in XServer, the value
will be write into the VidModeSetGamma -> xf86Chang
On Tue, 2010-05-18 at 17:50 -0700, Alan Coopersmith wrote:
> Gaetan Nadon wrote:
> > Just moving into a subdir won't fix anything. I was referring to
> > replacing the cpp method with the sed method used in 155 modules. If
> > there is a quick fix in the mean time, perfect.
>
> I assume a sed con
Gamma ramps vary from card to driver. 8,10,12-bit Who knows? A correct
implementation has to check the gamma ramp size. I thought to have read
somewhere in the adverticing material that ATI has more then 8-bit ramps.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrman
Twas brillig at 11:38:58 19.05.2010 UTC+02 when mic...@daenzer.net did gyre and
gimble:
>> This changes ABI of server as Xalloc/Xfree/Xrealloc/Xstrdup are no
>> longer exported. OTOH, API is not changed.
MD> I'm not sure there's much point keeping the API around when the ABI
MD> is removed.
On Tue, May 18, 2010 at 04:50:25PM -0700, Jamey Sharp wrote:
> Nobody wraps the mi software-cursor sprite rendering implementations.
>
> Signed-off-by: Jamey Sharp
makes sense to me, I just have a few minor comments on style.
> ---
> mi/midispcur.c | 58 ++--
>
On Tue, May 18, 2010 at 04:50:26PM -0700, Jamey Sharp wrote:
> Signed-off-by: Jamey Sharp
Reviewed-by: Peter Hutterer
though I think this one might as well be squashed in with the previous one.
Cheers,
Peter
> ---
> mi/misprite.c | 18 --
> 1 files changed, 0 insertions(+)
Behrmann,
You said the Gamma ramps have 8, 10, 12-bit, but each of the entries
are made up of corrections for R/G/B. Within the DWORD, the red correction is
in b[23:16], green in b[15:8] and blue in b[7:0]. For 24 bit graphics, each
color (R, G, and B) are comprised of one byte. The Gamm
hi,
created a patch to cure xorg-xinput-fpit from wired behavoir.
--
Philip
>From c40f057f21af7a52cb15beed61beead45b4c4b40 Mon Sep 17 00:00:00 2001
From: philip
Date: Wed, 19 May 2010 12:37:05 +0200
Subject: [PATCH] fpit: minX/ maxX get wrongly initialized
maxX/ minX get values from maxY/ min
On Wed, 2010-05-19 at 17:19 +0800, Huang, FrankR wrote:
> I want to know if the black region after SRC is the CLEAR operation?
> If that is so, I want to modify the driver to do the CLEAR outside the
> 20x20 mask region to make the driver does the right SRC operation.
It's not quite the same - it
On Tue, May 18, 2010 at 3:51 PM, Alan Coopersmith
wrote:
> Uses a catalog file to provide the path to an entity file in a
> different directory than the xml sources.
This commit message isn't really accurate anymore since the entity
file is used directly from the xml sources.
>
> Signed-off-by:
Since _X_NORETURN is used in the os.h header that gets installed as
part of the SDK, shouldn't the xorg-server.pc also list a Requires:
on the new version? (Hopefully packagers would enforce the requirement
in their packaging system, but it may still help catch people who have
installed a newer x
On Wed, 2010-05-19 at 19:01 +0800, Cui, Hunk wrote:
> Hi, Jackson,
> First thanks for your explanation, through the debugging, I found
> when I start the "fade to black", the gamma values will be setup to
> the default value (1.0), it will be transferred to the XServer. And in
> XServer, the
I know more the client side of the API.
DisplayPort can serve up to 16-bit per channel.
Three one dimensional look up tables (LUT) each of 8-bit resolution would
not make much sense in this scenario.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyra
Hi Pierre,
On Tue, May 04, 2010 at 10:21:55PM +0200, ext Pierre-Loup A. Griffais wrote:
>
> I just reproduced something that sounds like what you're describing with two
> R520 cards (one X screen per card) and the 'radeon' driver. However, it seems
> unrelated to my change; that's what the hang
Dan Nicholson wrote:
> On Tue, May 18, 2010 at 3:51 PM, Alan Coopersmith
>> + %defs;
>
> Just FYI because I toyed around with this a little more. The file://
> prefix seems to be redundant and just a normal absolute path is fine.
> Also, any directory prefix is fine since the tools will strip dow
Thanks for all the suggestions & review so far. I've reset my fd.o
git repo with the latest versions:
The following changes since commit 673eb707ce6737284c4886265ba149c5587a74e2:
Jamey Sharp (1):
SyncSendAlarmNotifyEvents: check the correct client's clientGone flag.
are available in t
On Wed, May 19, 2010 at 1:31 AM, Keith Packard wrote:
> On Tue, 18 May 2010 16:20:14 -0700, Jamey Sharp wrote:
>> On Tue, May 18, 2010 at 3:38 PM, Keith Packard wrote:
>> > On Sat, 15 May 2010 14:37:22 -0700, Keith Packard
>> > wrote:
>> >> Does __glXdriSwapEvent also need to be fixed? Or shou
On Tue, 2010-05-18 at 15:27 -0700, Keith Packard wrote:
> On Tue, 18 May 2010 17:57:31 -0400, Adam Jackson wrote:
> > Since we're breaking ScreenRec, might as well break it good and hard.
>
> Looking good to me. Should change backStorage into a boolean instead of
> a pointer now too -- it's only
On Tue, 2010-05-18 at 15:17 -0700, David James wrote:
> When xorg-xserver is being cross-compiled, there is currently no way
> for us to detect whether the monotonic clock is available on the
> target system. Currently, in this situation, we default to not use the
> monotonic clock. One problem wit
On Tue, 2010-05-18 at 20:31 -0700, Alan Coopersmith wrote:
> As explained in https://bugs.freedesktop.org/show_bug.cgi?id=26943
> since libXt callers need the SM headers but don't necessarily need to
> link directly to libSM, it should be in Requires.private, not Requires.
>
> Signed-off-by: Alan
Twas brillig at 11:47:08 19.05.2010 UTC-04 when a...@nwnk.net did gyre and
gimble:
>> To fix this situation, this patch creates a new variable called
>> xorg_cv_MONOTONIC_CLOCK. If packagers who cross-compile setup this
>> variable appropriately, then we can enable usage of the
>> MONOTONIC_
> Date: Wed, 19 May 2010 08:21:03 -0700
> From: Alan Coopersmith
>
> Dan Nicholson wrote:
> > On Tue, May 18, 2010 at 3:51 PM, Alan Coopersmith
> >> + %defs;
> >
> > Just FYI because I toyed around with this a little more. The file://
> > prefix seems to be redundant and just a normal absolute
On Tue, May 18, 2010 at 11:37:26PM +0200, ext Adam Jackson wrote:
> On Tue, 2010-05-18 at 13:21 -0700, Keith Packard wrote:
> >
> > Do you have a suggestion as to who should review this? Ajax? We can prod
> > an appropriate person, but I'd like to see it get a Reviewed-by: line
> > before merging
On Tue, 2010-05-18 at 20:30 -0700, Randy Turner wrote:
> Hi All,
>
> I am developing an application that processes the output of the X
> Windows Dump (xwd) application. I'm assembling use-case scenarios for
> testing this app and was wondering about how xwd actually works.
In brief: It gets the
The following changes since commit ff3026a02dfdcc3efeb4b8070f37ec4f0418d5dc:
ext Jamey Sharp (1):
Device init: Don't crash when CreateGC fails.
are available in the git repository at:
git://people.freedesktop.org/~vignatti/xserver.git bus-cleanup
Jamey Sharp (1):
SyncSendAlarmN
The following changes since commit ff3026a02dfdcc3efeb4b8070f37ec4f0418d5dc:
ext Jamey Sharp (1):
Device init: Don't crash when CreateGC fails.
are available in the git repository at:
git://people.freedesktop.org/~vignatti/xserver.git animcursor-state-fix
Tiago Vignatti (3):
re
On Wed, May 19, 2010 at 8:47 AM, Adam Jackson wrote:
> On Tue, 2010-05-18 at 15:17 -0700, David James wrote:
>> When xorg-xserver is being cross-compiled, there is currently no way
>> for us to detect whether the monotonic clock is available on the
>> target system. Currently, in this situation, w
Twas brillig at 09:12:59 19.05.2010 UTC-07 when davidja...@google.com did gyre
and gimble:
DJ> [PATCH] Discover monotonic clock using compile-time check.
Reviewed-by: Mikhail Gusarov
--
http://fossarchy.blogspot.com/
pgpQQHWM1RbHJ.pgp
Description: PGP signature
_
On Wed, May 19, 2010 at 5:06 AM, Peter Hutterer
wrote:
>> @@ -861,7 +850,7 @@ miSpriteSetCursor (DeviceIntPtr pDev, ScreenPtr pScreen,
>> pointer->saved.y1 -= dy;
>> pointer->saved.x2 -= dx;
>> pointer->saved.y2 -= dy;
>> - (void) (*pScreenPriv
Mark Kettenis wrote:
>> From: Alan Coopersmith
>> Dan Nicholson wrote:
>>> On Tue, May 18, 2010 at 3:51 PM, Alan Coopersmith
+ (cd $(XML_ENT_DIR) && $(MAKE) $(AM_MAKEFLAGS) $(@F))
>>> Is $(@F) a gnu makeism? I can't tell, but I don't think so.
>> I first learned about it when using Sol
The following changes since commit 673eb707ce6737284c4886265ba149c5587a74e2:
Jamey Sharp (1):
SyncSendAlarmNotifyEvents: check the correct client's clientGone flag.
are available in the git repository at:
git://people.freedesktop.org/~jamey/xserver for-keith
Jamey Sharp (2):
Re
ActivateDevice was ignoring errors from DeviceCursorInitialize, so
cursor-related calls failed later. Jeremy Huddleston saw that crash in
miPointerConstrainCursor, while with Xvfb I saw it in
miSpriteRealizeCursor.
miDCDeviceCleanup frees any non-NULL GCs. miDCDeviceInitialize calls
Cleanup on any
Setting 'Option "DefaultModes" "No"' in an output will guarantee that
X will omit the default modes, just picking up modes from the
configuration file and modes provided by the output.
Signed-off-by: Simon Farnsworth
---
hw/xfree86/modes/xf86Crtc.c |4 +++-
1 files changed, 3 insertions(+),
I've been submitting a lot of xserver patches lately, and I gotta say,
I'm really glad there's a review process in place. There's too much
cruft here for any one person to have a hope of predicting whether a
patch will work in all circumstances.
Reviewer bandwidth continues to be an issue though.
This patch is part of our attempt to move EDID handling out of our
embedded product's code and into the stack we depend on anyway.
Our goal is to divide modes into two classes; modes supplied by us,
and modes we've learnt about from EDID. We supply a set of "default"
modes in the configuration fi
This eliminates the unused 'id' field (what the eff), and reorders the
other data fields to fit packed on both ILP32 and LP64. ScreenRec
shrinks by 64 bytes on LP64 (less on ILP32), and devPrivate just
barely squeaks into the first cacheline on LP64 as a bonus.
This also marks a flags field for f
On Wed, 2010-05-19 at 17:07 +0200, Kai-Uwe Behrmann wrote:
> I know more the client side of the API.
> DisplayPort can serve up to 16-bit per channel.
> Three one dimensional look up tables (LUT) each of 8-bit resolution would
> not make much sense in this scenario.
Strictly, so can DVI and HDMI.
On Wed, 2010-05-19 at 18:19 +0100, Simon Farnsworth wrote:
> Setting 'Option "DefaultModes" "No"' in an output will guarantee that
> X will omit the default modes, just picking up modes from the
> configuration file and modes provided by the output.
>
> Signed-off-by: Simon Farnsworth
This is mi
On Wed, 2010-05-19 at 08:34 -0700, Alan Coopersmith wrote:
> Thanks for all the suggestions & review so far. I've reset my fd.o
> git repo with the latest versions:
>
> The following changes since commit 673eb707ce6737284c4886265ba149c5587a74e2:
> Jamey Sharp (1):
> SyncSendAlarmNotif
On Wed, May 19, 2010 at 11:07:58 -0700, Jamey Sharp wrote:
> The following changes since commit 673eb707ce6737284c4886265ba149c5587a74e2:
> Jamey Sharp (1):
> SyncSendAlarmNotifyEvents: check the correct client's clientGone flag.
>
> are available in the git repository at:
>
> git://
On Wed, 2010-05-19 at 11:07 -0700, Jamey Sharp wrote:
> Jamey Sharp (4):
> xv: TryClientEvents already checks client and sets sequenceNumber.
> Make WriteEventsToClient/WriteToClient no-op on fake or dead clients.
> Set event sequence number in WriteEventsToClient instead of at c
> Date: Wed, 19 May 2010 09:12:59 -0700
> From: David James
>
> On Wed, May 19, 2010 at 8:47 AM, Adam Jackson wrote:
> > On Tue, 2010-05-18 at 15:17 -0700, David James wrote:
> >> When xorg-xserver is being cross-compiled, there is currently no way
> >> for us to detect whether the monotonic clo
> Date: Wed, 19 May 2010 09:56:29 -0700
> From: Alan Coopersmith
>
> Mark Kettenis wrote:
> >> From: Alan Coopersmith
> >> Dan Nicholson wrote:
> >>> On Tue, May 18, 2010 at 3:51 PM, Alan Coopersmith
> + (cd $(XML_ENT_DIR) && $(MAKE) $(AM_MAKEFLAGS) $(@F))
> >>> Is $(@F) a gnu makeism
On Wed, 19 May 2010 11:42:10 -0400, Adam Jackson wrote:
> Just a bit in the long bitfield list in WindowRec? No reason to burn a
> whole int on it. Although we're remarkably close to running over an int
> there too.
We can make more :-)
> I bet we can macro it away in the autoconf for the dri
On Wed, 19 May 2010 11:40:24 -0400, Kristian Høgsberg
wrote:
> How can we be sure another client hasn't connected in the meantime
> getting the id of the client who schedules the swap?
I thought the whole point of creating a resource was that it would be
deleted when the client exited. If the e
Thanks to Julien and ajax for reviewing these! I've added my remaining
branches to my for-keith branch for merge, so this request subsumes the
one I sent earlier.
Keith, lest you grumble about the scope of these patches: I believe they
don't conflict with your fix-private-usage branch at *all*. :-
On Wed, May 19, 2010 at 11:31 AM, Adam Jackson wrote:
> This eliminates the unused 'id' field (what the eff), and reorders the
> other data fields to fit packed on both ILP32 and LP64. ScreenRec
> shrinks by 64 bytes on LP64 (less on ILP32), and devPrivate just
> barely squeaks into the first cac
On Wed, 2010-05-19 at 12:56 +0200, Philip wrote:
> hi,
> created a patch to cure xorg-xinput-fpit from wired behavoir.
>
The bug was trivial to verify, so I took the liberty of pushing the
patch.
> ___
> xorg-devel@lists.x.org: X.Org development
> Arc
On Wed, 19 May 2010 14:31:19 -0400, Adam Jackson wrote:
> This eliminates the unused 'id' field (what the eff), and reorders the
> other data fields to fit packed on both ILP32 and LP64. ScreenRec
> shrinks by 64 bytes on LP64 (less on ILP32), and devPrivate just
> barely squeaks into the first c
On Wed, 19 May 2010 12:47:27 -0700, Jamey Sharp wrote:
> Keith, lest you grumble about the scope of these patches: I believe they
> don't conflict with your fix-private-usage branch at *all*. :-) Or at
> least, nothing that can't be auto-merged.
No grumbling, just whinging that people love your
On Wed, 2010-05-19 at 12:23 -0700, Jamey Sharp wrote:
> On Wed, May 19, 2010 at 11:31 AM, Adam Jackson wrote:
> > typedef struct _Screen {
> > intmyNum; /* index of this instance in
> > Screens[] */
> > -ATOM id;
> > +unsigned int rgf;
I got this wrong in e2929db7b737413cf93fbebdf4d15abdfebff05c.
Signed-off-by: Jamey Sharp
---
glx/glxdriswrast.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index ac8fd47..54f4440 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdr
On Wed, 19 May 2010 16:04:14 -0400, Adam Jackson wrote:
> It's really just an optimization to store it in the ScreenRec, you could
> equivalently do:
Other than the whole 'what depth does the root window get' issue...
--
keith.pack...@intel.com
pgp2sxgcoGv9O.pgp
Description: PGP signature
__
On Wed, 2010-05-19 at 12:56 -0700, Keith Packard wrote:
> On Wed, 19 May 2010 14:31:19 -0400, Adam Jackson wrote:
> > This eliminates the unused 'id' field (what the eff), and reorders the
> > other data fields to fit packed on both ILP32 and LP64. ScreenRec
> > shrinks by 64 bytes on LP64 (less
On Wed, 19 May 2010 17:30:01 -0400, Adam Jackson wrote:
> Don't commit this yet, I want to pull some of Jamey's suggestions in.
I'm a' waitin'.
--
keith.pack...@intel.com
pgpM5TgqQlzcY.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Or
On Wed, May 19, 2010 at 12:04 PM, Mark Kettenis wrote:
>> Date: Wed, 19 May 2010 09:12:59 -0700
>> From: David James
>>
>> On Wed, May 19, 2010 at 8:47 AM, Adam Jackson wrote:
>> > On Tue, 2010-05-18 at 15:17 -0700, David James wrote:
>> >> When xorg-xserver is being cross-compiled, there is cur
On Wed, 2010-05-19 at 16:04 -0400, Adam Jackson wrote:
> I dunno, the whole blackPixel/whitePixel thing is an anachronism. The
> idea is that on monochrome framebuffers it's not especially obvious
> whether 1 or 0 is black. But, anymore, I really can't justify giving a
> damn. 0 is black, move
Tiago,
On 05/19/2010 08:09 AM, Vignatti Tiago (Nokia-D/Helsinki) wrote:
Hi Pierre,
On Tue, May 04, 2010 at 10:21:55PM +0200, ext Pierre-Loup A. Griffais wrote:
I just reproduced something that sounds like what you're describing with
two R520 cards (one X screen per card) and the 'radeon' driv
On Wed, May 19, 2010 at 09:45:23AM -0700, Jamey Sharp wrote:
> On Wed, May 19, 2010 at 5:06 AM, Peter Hutterer
> wrote:
> >> @@ -861,7 +850,7 @@ miSpriteSetCursor (DeviceIntPtr pDev, ScreenPtr
> >> pScreen,
> >> pointer->saved.y1 -= dy;
> >> pointer->saved.x2 -= dx;
>
Since this code was using CreateScratchGC and not GetScratchGC,
FreeScratchGC would always call FreeGC, so just call it directly.
As long as the drawable provided to CreateGC has the same screen and
depth as were passed to CreateScratchGC, these functions are basically
identical. There are two dif
The server and drivers sometimes use GetScratchGC, but never
CreateScratchGC.
Signed-off-by: Jamey Sharp
---
dix/gc.c |2 +-
include/gc.h |4
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/dix/gc.c b/dix/gc.c
index 65d05eb..56d5cda 100644
--- a/dix/gc.c
+++ b/dix
This eliminates a poorly-named, poorly-documented field from the
ScreenRec, using a previously-unused flag bit in each GC instead.
Signed-off-by: Jamey Sharp
Cc: Adam Jackson
---
On Wed, May 19, 2010 at 1:04 PM, Adam Jackson wrote:
> On Wed, 2010-05-19 at 12:23 -0700, Jamey Sharp wrote:
>> Alte
On Wed, 19 May 2010 17:58:15 -0400, Adam Jackson wrote:
> On Wed, 2010-05-19 at 16:04 -0400, Adam Jackson wrote:
>
> > I dunno, the whole blackPixel/whitePixel thing is an anachronism. The
> > idea is that on monochrome framebuffers it's not especially obvious
> > whether 1 or 0 is black. But,
On Wed, 19 May 2010 16:09:58 -0700, Jamey Sharp wrote:
> Like this? It's more clear that it's correct after the patches I posted
> earlier, to make CreateScratchGC static, but I believe it's correct
> regardless.
'reusable' seems a bit vague; perhaps something more like 'scratch_busy'
or 'scratc
On Wed, 19 May 2010 15:25:43 -0700, Jamey Sharp wrote:
> Since this code was using CreateScratchGC and not GetScratchGC,
> FreeScratchGC would always call FreeGC, so just call it directly.
I'm having a hard time caring; drivers don't call CreateGC either, so it
seems like we can pick one of these
On Wed, May 19, 2010 at 4:40 PM, Keith Packard wrote:
> On Wed, 19 May 2010 15:25:43 -0700, Jamey Sharp wrote:
>> As long as the drawable provided to CreateGC has the same screen and
>> depth as were passed to CreateScratchGC, these functions are basically
>> identical.
>
> One would think that g
This eliminates a poorly-named, poorly-documented field from the
ScreenRec, using a previously-unused flag bit in each GC instead.
Signed-off-by: Jamey Sharp
Cc: Adam Jackson
Cc: Keith Packard
---
PURPLE!
dix/dispatch.c |1 -
dix/gc.c | 20
hw/xnes
Hi, Jackson & Behrmann,
What is mean about the server's internal representation is abstracted
away from the driver's representation? I don't understand it. Can you
particular explain it. I know the R,G,B originality values are 16 bits per
channel. When the values are transfered to the d
Am 20.05.10, 12:03 +0800 schrieb Cui, Hunk:
BTW: Behrmann, "Three one dimensional look up tables (LUT) each of 8-bit resolution
would not make much sense in this scenario." Please particular explain it. Thank you
for your earnest reply.
LUTs look up a resulting value for each input value. If
On Thu, May 20, 2010 at 12:03 AM, Cui, Hunk wrote:
> Hi, Jackson & Behrmann,
>
> What is mean about the server's internal representation is abstracted
> away from the driver's representation? I don't understand it. Can you
> particular explain it. I know the R,G,B originality values are 1
On 19 May 2010 21:03, Cui, Hunk wrote:
> What is mean about the server's internal representation is abstracted
> away from the driver's representation? I don't understand it. Can you
> particular explain it. I know the R,G,B originality values are 16 bits per
> channel. When the values a
On Wed, 19 May 2010 17:25:18 -0700, Jamey Sharp wrote:
> This eliminates a poorly-named, poorly-documented field from the
> ScreenRec, using a previously-unused flag bit in each GC instead.
>
> Signed-off-by: Jamey Sharp
> Cc: Adam Jackson
> Cc: Keith Packard
> ---
> PURPLE!
A fine bikeshed c
On Wed, 19 May 2010 02:01:18 +0700, Mikhail Gusarov
wrote:
> This changes ABI of server as Xalloc/Xfree/Xrealloc/Xstrdup are
> no longer exported. OTOH, API is not changed.
Thanks for fixing libXdmcp as well, but we'll need to get that library
released and the package version check in the X ser
We're closing in on the scheduled date for the merge window closure and
I thought it would be a good idea to update people on what's going on.
Here's some patches that I know are outstanding:
* mi: removed the invisible cursor sprite; use NullCursor instead.
Oliver was trying to check with
On Wed, May 19, 2010 at 11:42:50PM -0700, Keith Packard wrote:
>
> We're closing in on the scheduled date for the merge window closure and
> I thought it would be a good idea to update people on what's going on.
>
> Here's some patches that I know are outstanding:
>
> * mi: removed the invisibl
81 matches
Mail list logo
