On 24.04.2012 15:57, Peter Harris wrote:
On Tue, Apr 24, 2012 at 6:35 AM, Erkki Seppala wrote:
list type=CARD32 name=client_ids
op//op
op+/op
fieldreflength/fieldref
value3/value
/op
value4/value
/op
/list
or not, hopefully someone can chime
On 24.04.2012 05:07, Alan Coopersmith wrote:
I've gone ahead and pushed this to git, along with changes to handle versioning,
however, before this would be ready for release, the man pages still need to be
updated to tell developers about the new API's and how to call them.
Great! I'll provide
Somehow the original message never reached my inbox, luckily a colleague
pointed this message out to me :).
I'd be happier to pull this if it had a reviewed-by tag from someone
with a bit of xcb knowledge (which is why I've cc'ed the xcb mailing list).
That would be nice. The xcb proto of
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.
Only the patches against the xserver needed some updating. Those updates
were:
- the renaming of struct list to struct xorg_list
- swapl/swaps now use only one argument
- some code layout fixes
- and two misuses (..I think..) of swaps were detected by new compiler
diagnostics of the revised
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
Here are few fixes we've sent to the list within the last three months
or so.
The following changes since commit 548c6fe044068ffba9b5306dc6b11f2ba22782a4:
Keith Packard (1):
Merge remote-tracking branch 'jturney/master'
are available in the git repository at:
Hello,
While processing my XRes 1.2 X-server implementation pull, Keith noticed
that the resource proto, which is a dependency for the implementation,
was not integrated. So here is the resource proto as a standalone pull
request. Let's try the X-server integration again once this is in :).
On 11.04.2011 19:12, Keith Packard wrote:
You want to just invoke damageReportDamage directly so that you use
the right damage object, rather than assuming that it is the first
one on the drawable list.
Right, my patch worked rather by accident than by solid code --
apparently my understanding
On 24.03.2011 15:41, Adam Jackson wrote:
There's still one semantic difference between this and the original:
you're not adding the initial region to the Damage. I'm not
completely sure if that matters in any existing app, but it's
probably better to assume it does.
It looks like
And sending this to the mailing list as well - Keith might be getting
this twice.
---
On 07.04.2011 07:06, Keith Packard wrote:
This looks ready to merge, and I would be replying with such a message
if test/Makefile.am wasn't separately updated since the place you
branched from.
Great! The
On 07.04.2011 12:38, Keith Packard wrote:
Where are the protocol header changes needed to actually compile this
stuff?
They'll need to be on the master branch of the resourceproto repository,
with a suitable version number and that version number will need to be
in xserver/configure.ac so that
On 05.04.2011 18:58, Keith Packard wrote:
On Tue, 05 Apr 2011 18:38:41 +0300, Erkki Seppalaerkki.sepp...@vincit.fi
wrote:
On 05.04.2011 17:54, Keith Packard wrote:
Please just fix users of the existing 'Hash' function to call
HashResourceID directly.
Hm, are you sure? It looks like this
Taking this back to list, in case it collects some more comments.
Context: I sent a PULL request of
git://gitorious.org/erkkise/fdo-xserver.git client-tracking-v2 to Keith,
given that the previous update had not risen any discussion.
On 04.04.2011 21:51, Keith Packard wrote:
On Mon, 04 Apr
On 05.04.2011 17:54, Keith Packard wrote:
Internally resource.c now uses the same static function Hash implemented
in terms of HashResourceID.
Please just fix users of the existing 'Hash' function to call
HashResourceID directly.
Hm, are you sure? It looks like this afterwards:
diff --git
On 31.03.2011 15:13, Mark Marshall wrote:
There's a (very unlikely) memory leak here.
(getenv_r() == -1 and errno != ERANGE)
Thanks! Can't believe how I missed that. (Or how I missed it in my
valgrind-based tests.)
___
xorg-devel@lists.x.org: X.Org
On 31.03.2011 16:13, Mark Kettenis wrote:
Sorry, but I think that is a bad API. It will lead to confusion
who allocated the buffer.
I would hope the documentation makes this clear. Unfortunately this is
that kind of API where one wants to look at the documentation :).
Also somebody noted
On 28.03.2011 14:59, Mark Kettenis wrote:
-static int bsize;
+static charbuf[PATH_MAX] = {0};
Static variables are automatically initialized to 0. Doing so
explicitly will increase the size of the binary, so it's better not to
do this.
That's a good point.
-strcpy
On 24.03.2011 19:31, Keith Packard wrote:
On Thu, 24 Mar 2011 15:18:17 +0100 (CET), Mark
Kettenismark.kette...@xs4all.nl wrote:
Actually, checking the return value of close(2) is fairly silly,
at least in this context. So you could write this as:
Yeah, what error are they looking for here?
On 24.03.2011 02:25, Keith Packard wrote:
That's icky. Fixing that without losing the damage sent to new clients
might be tricky though.
How about not using the existing machinery for sending the initial
event? I imagine it would not be many lines of code for that situation.
Possibly just
Hello,
I'm investigating an issue where applications receive damage events when
they create a new damage object. The code in question is this:
static int
ProcDamageCreate (ClientPtr client)
{
..
if (pDrawable-type == DRAWABLE_WINDOW)
{
pRegion = ((WindowPtr)
Oops, I intended to send this to the list.
On 16.03.2011 14:39, Erkki Seppala wrote:
I integrated all the changes into a new branch client-tracking-v2. This
pull request has only the X-server changes, the other parts have not
changed.
It turns out that the resource ids were already published
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
The following changes since commit 807a7fc0354f2212dfa5ff1f9e4ede56d8e69ef4:
Gaetan Nadon (1):
Docbook: change the book id to match the xml file basename
are available in the git repository at:
http://git.gitorious.org/erkkise/libx11-fixes.git fixes-missing-3
After reviewing the
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
On 10.03.2011 00:23, Keith Packard wrote:
Please clean up the whitespace mistakes in this patch and resubmit.
You aren't seriously editing code on Windows, are you?
Hmm.
I checked for the following factors:
- Consistent use of spaces versus tabs compared to the old code: check
- No trailing
On 10.03.2011 11:27, kei...@keithp.com wrote:
Oh. You sent it to my intel email address. I'll bet exchange mangled
it. I hadn't even thought to check that. kei...@keithp.com is a far
better plan for useful email. Sigh.
Oops. Yeah, I had actually intended to send to that address, but still
On 09.03.2011 15:57, Daniel Stone wrote:
You could get this automatically by having miSpriteDevPrivatesKey
allocate sizeof(miCursorInfoRec), rather than doing the allocation and
free separately.
Thanks for the feedback!
I considered this with Rami, but it appeared that it uses the NULLness
Oops, I intended to send this to you instead of just Keith and the list
- too fast with command line history - I hope you notice it at least
this way.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info:
Hello,
Here is the pull request for the two remaining fixes based on static
analysis results. Thanks for reviewing!
8
The following changes since commit 50f4107811249806718a100f9d34f996c58e5e25:
Alan Coopersmith (1):
Xrm.c: ReadInFile: refactor fstat error handling
are
Hello,
Here is the pull request for introducing and implementing XResource
extension v1.2. We decided against sending the patches to avoid spamming
the list, but we can send them on request. We have taken into account
all the review comments from the list so far. (Thanks for reviewing!)
On 01.02.2011 11:04, Ander Conselvan de Oliveira wrote:
xcms/LRGB: Add a label for freeing property_return.
That's a much better subject/shortlog line than the far too long one
you have
there now.
I agree with you and I actually wrote the commit message that way. Looks
like Erkki changed it
The following changes since commit e994ab227ed28655565c3193e63733630105e7f9:
Erkki Seppälä (1):
Comparing array against NULL is not useful xkb-server-vmods
!= NULL
are available in the git repository at:
g...@gitorious.org:erkkise/libx11-fixes.git fixes-reviewed-2011-02-01
Alan
On 27.01.2011 10:30, Alan Coopersmith wrote:
prop-name= (char *)_XkbAlloc(strlen(name)+1);
-if (!name)
- return NULL;
strcpy(prop-name,name);
prop-value= (char *)_XkbAlloc(strlen(value)+1);
if (!value) {
Looks like that should instead be checking if
On 27.01.2011 18:32, Matt Turner wrote:
-while((pBuf = fgets(buf, XCMSDB_MAXLINELEN, stream)) != NULL) {
+while((fgets(buf, XCMSDB_MAXLINELEN, stream)) != NULL) {
I'd think the reason the code is like this is to avoid warning messages like
warning: ignoring return value of ‘fgets’,
On 24.01.2011 02:04, Peter Hutterer wrote:
sorry, replied to the wrong email. I applied this one, please send me your
Signed-off-by though.
Oops.
Signed-off-by: Erkki Seppälä erkki.sepp...@vincit.fi
___
xorg-devel@lists.x.org: X.Org development
On 03.12.2010 17:15, Rami Ylimäki wrote:
-
+
Let's clean the dummy changes from the patch.
Oops. I had actually cleaned a few trailing whitespaces from the patch
to avoid git am from complaining, but apparently I've been overzealous :).
Check if memory allocation failed.
Right.
37 matches
Mail list logo
