On Mon, 29 Mar 2010 16:08:06 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
Watching the other replies from Keith, I've seen he's not so enthusiastic with
the idea of not use stdint.h. Anyway, if this patch arrives on xserver, I'll
be pushing to my libx86 tree either.
Right, I think
On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
But the major point of the InputClass work is that you no longer have
to differentiate between the config backend. The .conf snippet works
for hal or udev. Now you can just install your driver and .conf file
and not
On Wed, 31 Mar 2010 08:31:16 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
They need to build and install a new evdev driver anyway for 1.8 since
the ABI bumped. And this rule will fail if they haven't installed the
evdev driver. I really think these would be better to stay with the
On Wed, 31 Mar 2010 09:49:24 -0700, Alan Coopersmith alan.coopersm...@sun.com
wrote:
So the same patch should remove config/x11-input.fdi since it's no longer
needed in the xorg.conf.d world, right?
Argh. I'm pretty sure we shouldn't be removing files in our 'make
install' phase. I haven't
On Thu, 1 Apr 2010 18:13:41 +1100, Daniel Stone dan...@fooishbar.org wrote:
If you're happy moving the config file to the server, then I think we're
fine to release the server, as the current release of evdev works fine
with 1.8. I think Peter had a few more things he wanted to do before
On Tue, 6 Apr 2010 11:51:53 +0200, Julien Cristau jcris...@debian.org wrote:
The GenericEvent is a core event, we never send an extension event, so
don't reserve an id for one.
The protocol header still defines one event coming from this extension.
--
keith.pack...@intel.com
First off, thanks to everyone involved in the 1.8 release; it was a
pleasure to work with you. I'm hoping everyone else is as happy as I am
about our new release process, it seemed to me that we saw a lot more
active review and discussion about proposed patches this time around.
For version 1.9,
On Wed, 7 Apr 2010 04:47:13 +1000, Daniel Stone dan...@fooishbar.org wrote:
Er, is there no reason hardware enable (even if it's not entirely
fully-featured) can't be done in point releases?
Nope, and perhaps that's what 'ABI/API stable odd releases' should mean?
Does mean more non-trivial
On Tue, 06 Apr 2010 14:43:01 -0700, Jeremy Huddleston
jerem...@freedesktop.org wrote:
I think a 3-month major-release cycle will be very taxing, especially
considering the increased codebase with drivers.
We're doing 3 month releases with the intel drivers today; it's working
out pretty
On Wed, 7 Apr 2010 04:47:13 +1000, Daniel Stone dan...@fooishbar.org wrote:
Er, is there no reason hardware enable (even if it's not entirely
fully-featured) can't be done in point releases?
On second thought, this would require additional work for driver
developers who would also need to
On Tue, 06 Apr 2010 14:32:53 -0700, Jeremy Huddleston
jerem...@freedesktop.org wrote:
Keith? Peter? I haven't seen a response to Alan's question, and I'm
curious too... Is master to be 1.8.1, or is it to be 1.9? What is the
1.8 branch-point? Are we delaying branching from master until
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get merged in.
Here's the merged package:
git clone git://people.freedesktop.org/home/keithp/proto.git
And
On Tue, 06 Apr 2010 15:46:28 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
So this still has each proto get released as individual tarballs, just merges
the git repo? What's the difference between this and the git super-module
Peter made?
No, the plan is to release a single
On Tue, 06 Apr 2010 16:32:18 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
How would updating different protocols work - if xrandr dri2 updates were
both in progress, then we couldn't have a stable version of either until both
were ready? Or would we just force protocol
On Wed, 7 Apr 2010 16:29:13 +1000, Peter Hutterer peter.hutte...@who-t.net
wrote:
From the input drivers POV merging them in provides little benefit as of yet
and would probably be even detrimental to testing.
Yeah, we keep comparing the X server to the kernel and we really need to
understand
On Wed, 07 Apr 2010 10:02:54 -0400, Gaetan Nadon mems...@videotron.ca wrote:
It may provide the best of both worlds, retaining the desired level of
granularity while distributing a small number of packages.
I don't want to deliver multiple small packages. I want to deliver the
protocol headers
On Wed, 07 Apr 2010 10:56:50 -0400, Adam Jackson a...@nwnk.net wrote:
Implementation seems a little immature. fontsproto, for example, is a
mess. About half the headers are actually function prototypes for
libXfont, which absolutely does not belong there. I'd really like to
see that
On Wed, 7 Apr 2010 13:24:38 +1000, Peter Hutterer peter.hutte...@who-t.net
wrote:
Having a generic catchall also adds devices like accelerometers. These
devices make X unusable, hence restrict matching to known sane devices
like pointers, touchpads, keyboards, tablets and touchscreens.
On Wed, 7 Apr 2010 17:26:46 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
The rationale behind is because no sane application will use this when we have
modern APIs such DRI2. Besides, as a fact, xfree86 server has already
deprecated this extension in 1998:
I'd like to know what the
On Wed, 07 Apr 2010 15:40:29 -0400, Adam Jackson a...@redhat.com wrote:
Not that we have any driver that supports it, but typically people use
GL for that.
Yeah, I was talking to someone a few years ago where their GL stereo
implementation depended on Multibuffer though.
I mostly wanted to
On Thu, 8 Apr 2010 08:19:05 +1000, Peter Hutterer peter.hutte...@who-t.net
wrote:
I agree with Julien here, the special-case drivers are better off to keep
their own snippets around. I'll add that once we have Dan's changes in to
export the location from the pkgconfig file.
Sounds good then.
Ok, I've cleaned up the build process and removed the spurious
configure.ac/autogen.sh files. It now passes 'make distcheck' and I've
stuck a .tar.gz file in:
http://people.freedesktop.org/~keithp/proto-0.0.99.1.tar.gz
At this point, I'd like people to nominate subdirectories that should be
On Wed, 7 Apr 2010 19:32:32 -0400, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
It's a numbers game. How many contributors and testers will I lose or gain
compared to the hours of work spent? Until the server is a
On Wed, 07 Apr 2010 17:09:18 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
- calibrateproto
- lg3dproto
- pmproto
- printproto
- trapproto
- xf86miscproto
- xf86rushproto
Doesn't appear to have broken my X server build at least :-)
I've pushed the tree with these removed.
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
1) Keeping per-extension proto .pc files makes sense wrt to
compatibility, but perhaps keeping all the old version number schemes
does not. For example, in the future, if a package requires
On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
6) Please tell me you're not planning
On Thu, 8 Apr 2010 11:33:31 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
Thanks. Don't know what I was thinking.
--
keith.pack...@intel.com
pgpCPyDJNdGMI.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos cl...@jhcloos.com wrote:
I see that there are no tags in the combined proto repo. Retaining
history should require retaining the tags, too.
Almost all of the tags were from CVS days; are those really interesting?
I hope the goal is to
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos cl...@jhcloos.com wrote:
I see that there are no tags in the combined proto repo. Retaining
history should require retaining the tags, too.
Almost all of the tags in the proto modules are old CVS tags, and
they're all the same names, so we can't
On Thu, 08 Apr 2010 14:24:29 -0400, Gaetan Nadon mems...@videotron.ca wrote:
I like that. I am not sure, but are the old *.pc realy needed? It adds a
little bit to existing complexity:
Just for compatibility with existing users.
For backward compatibility, if config file ask for old package,
On Thu, 8 Apr 2010 14:47:33 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
Trying to keep individual versions of all protos which don't match the
version of the package with which they are shipped will just cause
On Thu, 8 Apr 2010 14:47:29 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
These patches have also been uploaded to annarchy:
http://cgit.freedesktop.org/~yselkowitz/xproto/
Thanks. I've merged everything but the
On Thu, 8 Apr 2010 12:24:41 -0700, Aaron Plattner aplatt...@nvidia.com wrote:
Since you're breaking the ABI already, could we move this sort of
dynamically-allocated global array into the pScreen or pScrnInfo instead,
either as just a plain old struct member or as a DevPrivate hook? That
On Wed, 7 Apr 2010 17:26:46 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
I sent last week and no one object that, but even no one put his stamp of
review. So please...
This looks good to me, with a few comments included below
/*
*** Server Block Handler
-*** code inspired by
On Thu, 8 Apr 2010 19:10:52 -0400, Matt Turner matts...@gmail.com wrote:
-#define GET_HIGH_BASE(x) (((V_BIOS + (x) + getpagesize() - 1)/getpagesize())
\
- * getpagesize())
+#define GET_HIGH_BASE(x) (ALIGN(V_BIOS + (x), getpagesize()))
#endif
Note that this
On Thu, 8 Apr 2010 20:06:40 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
+static int glxWindowPrivateKeyIndex;
+static DevPrivateKey glxWindowPrivateKey = glxWindowPrivateKeyIndex;
Because there doesn't appear to be any performance critical use for this
object, it should be in the
On Fri, 9 Apr 2010 11:20:10 +1000, Daniel Stone dan...@fooishbar.org wrote:
Well, for a start, you'd have to start only storing screen IDs instead
of ScreenPtrs everywhere.
No, the ScreenRecs are allocated in AddScreen and the pointer stored in the
(currently static) array in screenInfo. Just
On Thu, 8 Apr 2010 21:48:11 -0400, Kristian Høgsberg k...@bitplanet.net wrote:
Do you have a better suggestion?
You create another resource type and *always* index that by the window
id. Destruction order would not be guaranteed, of course.
--
keith.pack...@intel.com
pgpO8Pw290ycc.pgp
On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer mic...@daenzer.net wrote:
There were a number of cases where breakage wasn't fixed for days
because nobody else was allowed to push the fixes.
This is good feedback, thanks. Can you point out specific cases and we
can figure out what went
On Mon, 12 Apr 2010 07:02:27 +1000, Dave Airlie airl...@gmail.com wrote:
I'd have to agree here, I think we need to do 1.9 following the same
process again and refine it a lot more.
Yeah, developing the release process is almost as hard as developing the
code.
Keith there were large stages
:
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpYibwJxXQhf.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
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current bits.
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros
On Tue, 13 Apr 2010 10:16:20 +0530, Arvind Umrao arvind.um...@sun.com wrote:
CARD32 maxSecs = (CARD32)(~0) / (CARD32)MILLI_PER_SECOND;
+CARD32 nowSec = GetTimeInMillis()/ (CARD32)MILLI_PER_SECOND;
-if (seconds maxSecs)
-{ /* only come here if we want to wait more than 49
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard kei...@keithp.com wrote:
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros and/or util/modular into this package at
some point? Again, with the goal of making it easier to build the server
On Tue, 13 Apr 2010 11:45:41 +0200, Julien Cristau jcris...@debian.org wrote:
It's been over a week since 1.8.0...
Oops. Pushed.
--
keith.pack...@intel.com
pgpTmQbpBrPo5.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
On Tue, 13 Apr 2010 16:50:30 +0530, Arvind Umrao arvind.um...@sun.com wrote:
On 04/13/10 10:57, Keith Packard wrote:
On Tue, 13 Apr 2010 10:16:20 +0530, Arvind Umraoarvind.um...@sun.com
wrote:
CARD32 maxSecs = (CARD32)(~0) / (CARD32)MILLI_PER_SECOND;
+CARD32 nowSec
On Tue, 13 Apr 2010 03:40:40 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
1) Right now we have a bunch of COPYING files in each proto subdirectory
and there is no top-level COPYING. Unfortunately each proto is under a
slightly different license, so consolidating them
On Wed, 14 Apr 2010 07:22:24 +0530, Arvind Umrao arvind.um...@sun.com wrote:
Keith Packard wrote:
On Tue, 13 Apr 2010 16:50:30 +0530, Arvind Umrao arvind.um...@sun.com
wrote:
On 04/13/10 10:57, Keith Packard wrote:
On Tue, 13 Apr 2010 10:16:20 +0530, Arvind Umraoarvind.um
On Wed, 14 Apr 2010 10:25:49 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Keith, have you had time to look at this respun fix for 26394?
Oh. I just had a bad thought -- pixmaps don't follow the same rule as
windows, they aren't always in the resource database and don't always
have
) ==
- CLIENT_BITS(dev-deviceGrab.sync.other-resource)))
+ CLIENT_BITS(dev-deviceGrab.grab-resource)))
dev-deviceGrab.sync.state = FROZEN_NO_EVENT;
else
dev-deviceGrab.sync.other = grab;
Reviewed-by: Keith Packard kei
On Wed, 14 Apr 2010 14:22:05 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Right, true. But we always create DRI2 drawable for client created
drawables, except in the case of an AIGLX pbuffer. There we create a
pixmap behind the scenes and then create a DRI2 drawable for that. I
On Wed, 14 Apr 2010 20:30:55 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Oh, I was thinking I could just allocate the ID, but not actually add
the Pixmap as a resource. Is that bad form?
It wouldn't help -- you need FreeResource to be invoked on that XID to
get the other resources with
On Thu, 15 Apr 2010 12:13:19 +0530, Arvind Umrao arvind.um...@sun.com wrote:
Second thought, after some more testing. It seems your fixes are not
better than mine. When epoch time is GetTimeInMillis() -
(CARD32)(MAXINT), ie Sun Jan 10 2038 11:09:28 GMT+0530 (IST), security
authorization
such problem.
Signed-off-by: Philippe Ribet ri...@cena.fr
Signed-off-by: Benjamin Tissoires tisso...@cena.fr
Reviewed-by: Keith Packard kei...@keithp.com
int X;
-int dSx = Sxhigh - Sxlow;
-int dRx = Rxhigh - Rxlow;
+int64_t dSx = Sxhigh - Sxlow;
+int64_t dRx = Rxhigh
On Thu, 15 Apr 2010 14:47:51 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Right, it would linger until the client exits. So I guess I'll have
to actually AddResource the pixmap with the FakeClientID and then use
FreeResource to destroy it instead of pScreen-DestroyPixmap.
I think that
On Thu, 15 Apr 2010 16:35:02 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Ah, we can just assign the pixmap the XID of the pbuffer and
AddResource it using that XID. That way both the hidden pixmap and
the DRI2 drawable will automatically be reclaimed when the client
destroys the
On Fri, 16 Apr 2010 18:42:19 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
- if (!name || name[0] == '.' || len = suflen)
+ if (!name)
+ return 0;
+
+ name = de-d_name;
You might want to assign name before testing it.
--
keith.pack...@intel.com
This patch was created with:
git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done
Signed-off-by: Keith Packard kei...@keithp.com
---
Xext/panoramiX.c |6 --
Xext/panoramiX.h |2 --
exa/exa.c
On Mon, 19 Apr 2010 09:53:32 -0700, Keith Packard kei...@keithp.com wrote:
This patch was created with:
git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f;
done
This is not an actual proposal to apply this patch, I just wanted to
start discussion on what we could do
On Tue, 20 Apr 2010 00:00:39 +0300, Tiago Vignatti vigna...@freedesktop.org
wrote:
But if we go for it, we're going have an implementation that exceeds
the protocol. Is that valid?
Sure, there's nothing saying that we have to be able to not provide
certain extensions in the sample
On Mon, 19 Apr 2010 14:27:11 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Not really part of the unifdef patch, but a second patch to do s/of/off/ in
that
message would be good.
Yeah, as you can imagine, any patch that changes as much as the RENDER
stuff should be entirely
the tuner locks or gives up, recording the result in
last_afc_hint, so it seems correct to simply return the most recently
received value.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgp8qA0TesKHm.pgp
Description: PGP signature
On Wed, 21 Apr 2010 16:51:17 -0700, Pierre-Loup A. Griffais
pgriff...@nvidia.com wrote:
Since the revert is already pushed, here's a new version of the change as
Peter
pushed it including the teardown crash fix.
Is this fixing some known issue? Or is it just that it seems sub-optimal
to
a...@redhat.com
Seems reasonable to me.
Reviewed-by: Keith Packard kei...@keithp.com
---
dix/main.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/dix/main.c b/dix/main.c
index f023536..b500ad7 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -161,9 +161,7 @@ int
On Fri, 23 Apr 2010 15:25:26 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index c42119d..5a7c57d 100644
--- a/include/scrnintstr.h
+++ b/include/scrnintstr.h
@@ -615,7 +615,7 @@ typedef struct _ScreenInfo {
int
it a try.
Reviewed-by: Keith Packard kei...@keithp.com
Signed-off-by: Jamey Sharp ja...@minilop.net
---
What's up with the REGION_* macros anyway? AFAICT they've never cared
about their screen argument for as long as we have history in git.
The region functions used to be per-screen
On Fri, 23 Apr 2010 18:22:58 -0700, Jamey Sharp ja...@minilop.net wrote:
Advantages:
- Spares callers from allocating a MAXSCREENS-sized temporary array.
A simpler change would be to have callers allocate a PanoramXNumScreens
temporary array for the drawable pointers. Just xalloc and xfree it;
On Fri, 23 Apr 2010 21:51:08 -0700, Jamey Sharp ja...@minilop.net wrote:
I'd appreciate that too. I'd prefer testing on this version of the patch
since it's more comprehensive.
This stuff also looks good, if untested :-)
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack
On Mon, 26 Apr 2010 15:29:16 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
This patch series is a preparation to remove MAXSCREENS from the server. It
shouldn't affect nothing so in depth, really. Just a preparation.
Yeah, it's looking pretty good. I'll give it a bit of review and
On Mon, 26 Apr 2010 09:27:56 -0700, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Apr 26, 2010 at 05:29:16AM -0700, Tiago Vignatti wrote:
Keith,
This patch series is a preparation to remove MAXSCREENS from the server. It
shouldn't affect nothing so in depth, really. Just a
On Mon, 26 Apr 2010 13:06:34 -0700, Jamey Sharp ja...@minilop.net wrote:
Sure, if Keith agrees. I just figured it's something you could do
quickly while waiting for him to pull.
I'd rather pull a clean history as that makes bisecting easier in the
future. And, I've been busy all day poking at
On Mon, 26 Apr 2010 11:48:42 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
Keith,
Please note that the dmx: Ignore linuxdoc generated docs patch will
force those running 'make dist' (primarily you and whot) to have a
working linuxdoc installation. If that requirement
On Tue, 5 Jan 2010 13:32:28 -0500, Adam Jackson a...@redhat.com wrote:
Banked framebuffers are so 1990. As of 7.4 the only drivers remaining
that used this were chips, neomagic, trident, and vesa. vesa only used
it when not using shadowfb, which is broadly undesirable anyway, and no
longer
I've been wanting to do this for a while, but the recent work to
eliminate MAXSCREENS has pushed me to get it done sooner rather than
later.
What's the problem with devPrivates?
The biggest issue is that the index space is global. Which is to say
that anyone allocating a private index for any
On Thu, 29 Apr 2010 14:06:19 +0200, Matthias Hopf mh...@suse.de wrote:
On Apr 28, 10 23:59:06 -0700, Keith Packard wrote:
It's possible to adapt to this change with some very small adjustments
in your code; simply replace 'int' in the index variable declaration
with 'DevPrivateKeyRec
On Thu, 29 Apr 2010 17:34:47 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
Reviewing your proposal made me think if we really need devPrivates mechanism
at all.
Yeah, some of my patch was actually to remove devPrivate usage in DIX.
It only exists to not change ABI all the time on
On Thu, 29 Apr 2010 07:43:47 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Given that each devPrivate key increased in size from a single int to a larger
structure, it's not that surprising. I'd not expect savings until you've got
a whole bunch of windows, pixmaps, gc's, etc.
On Thu, 29 Apr 2010 18:04:35 +0300, tiago.vigna...@nokia.com wrote:
And when extensions are not used then would be just nil pointers in those
structures, which doesn't cost much.
Right now, we can preserve ABI even across differently built X servers
because the data structures aren't supposed
On Thu, 29 Apr 2010 12:24:46 -0700, Jamey Sharp ja...@minilop.net wrote:
Hi Keith!
I think the important parts of your devPrivates patches will be easier
to review if you rebase on these patches first. I stuck your
signed-off-by on them since they're all extracted from your patch-set,
On Thu, 29 Apr 2010 16:42:41 -0400, Eamon Walsh ewa...@tycho.nsa.gov wrote:
So a new rev of devPrivates would involve adding another clause to these
ifdefs.
Right, fortunately the API change is much smaller this time -- it only
affects the initialization of the key and not the usage. Turns out
Here are a few comments about how I see the new devPrivates scheme
working with XSELinux. Note that the current implementation is
sub-optimal when XSELinux is enabled -- the XSELinux private keys get
initialized late in the game and end up increasing the size of all of
the private records with
On Thu, 29 Apr 2010 21:37:18 -0400, Eamon Walsh ewa...@tycho.nsa.gov wrote:
Our mails crossed! I sent a lengthy reply to the original post.
Perfect!
SELinux does use the picture and glyphset privates. Any resource type
with a devPrivates field and a registered offset (returned by
On Thu, 29 Apr 2010 20:39:24 -0400, Eamon Walsh ewa...@tycho.nsa.gov wrote:
On 04/29/2010 02:59 AM, Keith Packard wrote:
I've been wanting to do this for a while, but the recent work to
eliminate MAXSCREENS has pushed me to get it done sooner rather than
later.
What's the problem
On Fri, 30 Apr 2010 04:45:43 +0200, Tomas Carnecky t...@dbservice.com wrote:
Is there any other reason you chose to allocated the array only once
when the object is created?
For almost all of the objects, the privates are allocated along with the
underlying object itself, saving an allocation
On Fri, 30 Apr 2010 11:31:48 +0200, Matthias Hopf mh...@suse.de wrote:
Hm, right, forgot about the ABI version. That would be enough,
especially for rarely externally used APIs like this.
Seems like adding:
/*
* Let drivers know how to initialize private keys
*/
#define
On Fri, 30 Apr 2010 15:01:40 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
this shut up some warnings.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
dix/events.c |2 ++
dix/window.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git
On Tue, 27 Apr 2010 13:23:26 -0700, Jeremy Huddleston jerem...@apple.com
wrote:
This pull request includes an unreviewed patch outside of XQuartz
which has been submitted to the list twice. It is small and just adds
some sanity checking to miPaintWindow. These checks used to be in
XQuartz'
On Wed, 28 Apr 2010 20:58:58 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
Unfortunately no commits here got a review tag. Even so, I'm keeping this work
openly for months already and I'd like to work on it to integrate now. So
please, tell me your thoughts.
Deleting this much code
On Fri, 30 Apr 2010 13:13:16 -0700, Jeremy Huddleston jerem...@apple.com
wrote:
what about the early return if it's an UNDRAWABLE_WINDOW?
pWin-drawable cannot ever be NULL unless pWin is NULL, and that 'can't
happen'.
--
keith.pack...@intel.com
pgpGzgN6px40K.pgp
Description: PGP signature
A few cursor value assignments weren't getting correctly ref counted,
causing leaks of cursor objects.
Signed-off-by: Keith Packard kei...@keithp.com
---
dix/devices.c |2 ++
dix/events.c | 20 +++-
hw/xfree86/ramdac/xf86Cursor.c |2
generations.
Signed-off-by: Keith Packard kei...@keithp.com
---
xfixes/cursor.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 1471a58..2aba0ce 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1054,11
Ok, I've gone ahead and changed the implementation so that it exposes an
explicit PRIVATE_XSELINUX which can be used on the following objects:
client, window, pixmap, gc, cursor, colormap, device, extension,
selection, property, picture, glyphset
(pixmap includes dbe buffers, btw)
I've also
On Thu, 29 Apr 2010 17:34:47 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
I started one standalone Xorg and here are the results:
- with current devPrivates: 5008 kB
- with new proposed devPrivates: 5032 kB
I promised to get some actual numbers. I did before/after comparisons
with
On Fri, 30 Apr 2010 16:22:07 -0700, Jeremy Huddleston jerem...@apple.com
wrote:
if (pWin-drawable-type == UNDRAWABLE_WINDOW)
return;
Ok, now I'm confused. The patch I see in your tree looks like this:
@@ -552,6 +552,9 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what)
On Sat, 01 May 2010 11:07:20 -0700, Jeremy Huddleston jerem...@apple.com
wrote:
drawable *is* pWin-drawable.
i put the hunk insid ifdef ROOTLESS per your comment, but I wonder if
miPaintwindow should return early in the general case if if is called
with an UNDRAWABLE_WINDOW
Ah, ok. I don't
On Fri, 30 Apr 2010 22:26:50 -0700, Jamey Sharp ja...@minilop.net wrote:
To what extent do people care if error paths like this leak memory?
Should the AddResource failure free pCursor?
AddResource frees the cursor if it fails. It's fancy.
--
keith.pack...@intel.com
pgpUMNt9YYUu5.pgp
On Sun, 2 May 2010 09:11:53 -0700, Jamey Sharp ja...@minilop.net wrote:
Would you agree to revert the ptrveloc.* part of the patch? I'd rather
fix this when fixing the accel setup. The scheme stuff isn't fully
worked out, but the props really belong there.
Feel free to use a union or some
On Sun, 2 May 2010 18:33:40 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
-AC_CHECK_LIB([sha1], [sha1_begin], [HAVE_LIBSHA1=yes])
+PKG_CHECK_MODULES([LIBSHA1], [sha1], [HAVE_LIBSHA1=yes])
If the sha1.pc file isn't available, this causes an error and the build
fails:
checking for
On Sat, 1 May 2010 13:31:57 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
All resource functions keep clientTable[cid].elements up to date with the
number of resources allocated to the client. Except
FreeResourceByType().
How about FreeClientNeverRetainResources and
On Sun, 2 May 2010 17:26:58 -0400, Kristian Høgsberg k...@bitplanet.net wrote:
On Sun, May 2, 2010 at 5:02 PM, Keith Packard kei...@keithp.com wrote:
On Sat, 1 May 2010 13:31:57 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
All resource functions keep clientTable[cid].elements up
501 - 600 of 4633 matches
Mail list logo
