Re: [PULL v2] XResource extension v1.2
On 17.04.2012 18:20, Alan Coopersmith wrote: They seem to apply fine, and there haven't been updated, so yes. However, I'm wondering on which tree the server side is integrated into, not on fdo/xorg/xserver master surely? Or then my git-fu is too poor :). Oh, erm, I could have sworn they were. So really only the resourceproto stuff made it into git? How inconsistent of us. Am I forgetting some Hey, at least it got into the release notes! reason the rest of the bits didn't go forward once that landed, or did we all just drop the ball? Probably the ball was just misplaced at some point. However, I've now rebased my xserver patches against master successfully. I'll still check that they applycompile patch-by-patch and that I haven't messed up with the rebase. ___ 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: [PULL v2] XResource extension v1.2
On 04/17/12 08:15 AM, Erkki Seppala wrote: On 17.04.2012 08:07, Alan Coopersmith wrote: BTW, I was just looking at libXRes, and unless I'm missing something, it appears these changes never got pulled/pushed to it, nor did the xcb-proto ones. We seem to have the resourceproto changes and the server changes, but I don't see any way for clients to use. Oops? Is the below pull request still the best source to use for libXRes xcb-proto? They seem to apply fine, and there haven't been updated, so yes. However, I'm wondering on which tree the server side is integrated into, not on fdo/xorg/xserver master surely? Or then my git-fu is too poor :). In any case I can put a merged-against-current-HEAD version of the X server changes available, if they are needed. Oh, erm, I could have sworn they were. So really only the resourceproto stuff made it into git? How inconsistent of us. Am I forgetting some reason the rest of the bits didn't go forward once that landed, or did we all just drop the ball? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL v2] XResource extension v1.2
On 17.04.2012 08:07, Alan Coopersmith wrote: BTW, I was just looking at libXRes, and unless I'm missing something, it appears these changes never got pulled/pushed to it, nor did the xcb-proto ones. We seem to have the resourceproto changes and the server changes, but I don't see any way for clients to use. Oops? Is the below pull request still the best source to use for libXRes xcb-proto? They seem to apply fine, and there haven't been updated, so yes. However, I'm wondering on which tree the server side is integrated into, not on fdo/xorg/xserver master surely? Or then my git-fu is too poor :). In any case I can put a merged-against-current-HEAD version of the X server changes available, if they are needed. ___ 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: [PULL v2] XResource extension v1.2
BTW, I was just looking at libXRes, and unless I'm missing something, it appears these changes never got pulled/pushed to it, nor did the xcb-proto ones. We seem to have the resourceproto changes and the server changes, but I don't see any way for clients to use. Oops? Is the below pull request still the best source to use for libXRes xcb-proto? -alan- On 03/11/11 06:38 AM, Erkki Seppala wrote: Hello, Here is the pull request for introducing and implementing XResource extension v1.2. The previous pull request with some more information about this extension, that didn't make it to 1.10, can be viewed at http://www.mail-archive.com/xorg-devel@lists.x.org/msg18418.html . These branches have been rebased against the corresponding master branches. This version has been tested on 64-bit platforms as well and libXRes has been slightly amended to fix an issue (hi, Tiago!). Cc'd to interested parties. xorg/xserver: The following changes since commit a19771e4337d1c4600550314bbc42a1495a023ff: Erkki Seppälä (1): xfree86/common: Remove a configScreen leak when conf_screen is NULL are available in the git repository at: git://gitorious.org/erkkise/fdo-xserver.git client-tracking Erkki Seppälä (6): Implemented first part of XResource extension v1.2: X_XResQueryClientIds dix: add a mechanism for iterating through all subresources dix: add hashing functions to resource.h for others to use. dix: add a generic hashtable implementation dix: add reference count of the resource to ResourceSizeRec Xext: add support for X_XResQueryResourceBytes Rami Ylimäki (3): render: Report pixmap usage of pictures to resource extension. composite: Report pixmap usage of client windows to resource extension. dix: Add reverse resource name lookup function to registry. Xext/xres.c | 830 +- composite/compext.c | 24 ++ dix/Makefile.am |1 + dix/hashtable.c | 240 dix/registry.c | 10 + dix/resource.c | 375 ++- hw/xfree86/loader/sdksyms.sh |1 + include/Makefile.am |1 + include/hashtable.h | 113 ++ include/protocol-versions.h |2 +- include/registry.h |6 + include/resource.h | 59 +++ render/picture.c | 24 ++ test/Makefile.am |3 +- test/hashtabletest.c | 143 15 files changed, 1813 insertions(+), 19 deletions(-) create mode 100644 dix/hashtable.c create mode 100644 include/hashtable.h create mode 100644 test/hashtabletest.c xorg/proto/resourceproto: The following changes since commit 386946098f97b9137af3265b5608fdcf22c7d49a: Alan Coopersmith (1): Add missing XFree86 copyright notice to COPYING are available in the git repository at: git://git.gitorious.org/erkkise/fdo-resourceproto.git client-tracking Erkki Seppälä (1): Protocol records for XRes v1.2 Rami Ylimäki (1): Added protocol description for XRes v1.2 XResproto.h | 100 +- resproto.txt | 462 ++ 2 files changed, 561 insertions(+), 1 deletions(-) create mode 100644 resproto.txt xcb/proto: The following changes since commit c4497cdbf0640c376cdebb0a9e5ea62458e6ba51: Peter Harris (1): Merge branch 'master' of git://anongit.freedesktop.org/~peterh/xcbproto are available in the git repository at: git://gitorious.org/erkkise/fdo-xcb-proto.git client-tracking Erkki Seppälä (1): Prototype for XRes v1.2 src/res.xml | 70 ++- 1 files changed, 69 insertions(+), 1 deletions(-) xorg/lib/libXRes: The following changes since commit 455c02ee9143b2bfbfd99b6481a1b22a0ce2a2bf: Gaetan Nadon (1): config: comment, minor upgrade, quote and layout configure.ac are available in the git repository at: git://gitorious.org/erkkise/fdo-libXRes.git client-tracking Erkki Seppälä (2): Implemented first part of XResource extension v1.2: XResQueryClientIds Implemented second part of XResource extension v1.2: XResQueryResourceBytes include/X11/extensions/XRes.h | 79 ++ src/XRes.c| 230 - 2 files changed, 306 insertions(+), 3 deletions(-) end of pull requests :). --
Re: [PULL v2] XResource extension v1.2
Hello,
On 14.03.2011 22:35, Keith Packard wrote:
We've already got half a dozen hash table implementations in the X
server, most of which are heavily tuned for a particular task.
Yes, there are some hash implementations which are intertwined with the
implementation of the code using it, such as with resources (which is
what I wanted to avoid, to make the actual implementation more clear),
and then there is x-hash.{c,h} in hw/xquartz/xpr, which seemed quite
un-Xish, given its dependency on a a separate linked list implementation
in x-list (which features thread-safe freelists).
I quite hope that there will be more standard data structures in X,
because not having them leads to having ad-hoc data structures that are
possibly suboptimal for the task at hand - not only performance-wise but
from code clarity point of view as well. I think that having this
implementation doesn't at least make the situation worse ;).
Glib appears to be somewhat popular and have a decent set of data
structures, but I imagine not everyone would be happy with a new
dependency. (Disclaimer: I haven't actually used Glib.)
While the current implementation of the hash table in the patch is far
from optimal, it can be enhanced should there be more high-profile uses
for it. For example it allocates multiple blocks when one could do (with
some alignment etc related calculations).
dix: add reference count of the resource to ResourceSizeRec
This seems to be used (at present) only for pixmaps. And, pixmaps
can be referenced by many things. Is there some specification for
which references are included in this count?
The specification is that the best effort is made to find as many
references as possible.
Rami Ylimäki (3):
render: Report pixmap usage of pictures to resource extension.
composite: Report pixmap usage of client windows to resource
extension.
This patch is out-of-sequence -- it uses LookupResourceType which
isn't defined at this point.
Oops, I have quite likely messed up the order while updating the patches
in my tree.
dix: Add reverse resource name lookup function to registry.
Ick. The names are purely informative, if you need the resource type,
then export the necessary variable.
I discussed this with Rami and that solution is fine. I shall update the
code.
___
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: [PULL v2] XResource extension v1.2
On Tue, 15 Mar 2011 10:42:32 +0200, Erkki Seppala erkki.sepp...@vincit.fi wrote: I quite hope that there will be more standard data structures in X, because not having them leads to having ad-hoc data structures that are possibly suboptimal for the task at hand - not only performance-wise but from code clarity point of view as well. I think that having this implementation doesn't at least make the situation worse ;). I'd say it would be better to separate out the tasks of adding this new code from that of standardizing on one hash API. I don't expect you to work on fixing the rest of the server, but until we've got at least two existing hash users sharing the same implementation, let's leave your hash code out of DIX and hope that someday someone merges all of these implementations together. Glib appears to be somewhat popular and have a decent set of data structures, but I imagine not everyone would be happy with a new dependency. (Disclaimer: I haven't actually used Glib.) Glib has an incompatible license, and so isn't a good candidate here. While the current implementation of the hash table in the patch is far from optimal, it can be enhanced should there be more high-profile uses for it. For example it allocates multiple blocks when one could do (with some alignment etc related calculations). You might take a look at the hash implementation in the Render glyph code; it's one of my favorites as it avoids the overhead of per-bucket linked lists. dix: add reference count of the resource to ResourceSizeRec This seems to be used (at present) only for pixmaps. And, pixmaps can be referenced by many things. Is there some specification for which references are included in this count? The specification is that the best effort is made to find as many references as possible. Ok, it should at least be bigger when you have a pile of pictures or GCs pointing at a single pixmap. I discussed this with Rami and that solution is fine. I shall update the code. Less code is good code :-) -- keith.pack...@intel.com pgpqYhT515cUo.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: [PULL v2] XResource extension v1.2
On Fri, 11 Mar 2011 16:38:54 +0200 (EET), Erkki Seppala erkki.sepp...@vincit.fi wrote: Implemented first part of XResource extension v1.2: X_XResQueryClientIds dix: add a mechanism for iterating through all subresources These look fine. dix: add a generic hashtable implementation We've already got half a dozen hash table implementations in the X server, most of which are heavily tuned for a particular task. I raise this solely to ask whether we should be trying to reduce that number at some point by creating some shared version, and if so, whether we need significant additional review of the API and implementation to see which existing hash implementations could be replaced by a shared version. I don't know the right answer here; the server has frequently grown essentially duplicate code and we haven't been good about merging it later on. dix: add reference count of the resource to ResourceSizeRec This seems to be used (at present) only for pixmaps. And, pixmaps can be referenced by many things. Is there some specification for which references are included in this count? Xext: add support for X_XResQueryResourceBytes Rami Ylimäki (3): render: Report pixmap usage of pictures to resource extension. composite: Report pixmap usage of client windows to resource extension. This patch is out-of-sequence -- it uses LookupResourceType which isn't defined at this point. dix: Add reverse resource name lookup function to registry. Ick. The names are purely informative, if you need the resource type, then export the necessary variable. -- keith.pack...@intel.com pgpLi0MBKzSM3.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
