On 24.04.2012 15:57, Peter Harris wrote:
On Tue, Apr 24, 2012 at 6:35 AM, Erkki Seppala wrote:
/
+
length
3
4
or not, hopefully someone can chime in.
If it really is a list of CARD32s, with the length given in bytes
(unlike most of the
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 the
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
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 macr
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.
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 cl
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:
git://gitorious.org/erk
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 damageRepor
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 t
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 la
On 05.04.2011 18:58, Keith Packard wrote:
On Tue, 05 Apr 2011 18:38:41 +0300, Erkki Seppala
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 afterwards:
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 a/
2011 12:14:19 +0300, Erkki Seppala
wrote:
dix: add hashing functions to resource.h for others to use.
CompareResourceID should not be in resource.c
You should not create a new 'HashResourceID' function with a weird
signature. Instead, you should change the function signat
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 t
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 30.03.2011 16:18, Dan Nicholson wrote:
wrote:
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 7a23253..114bdc3 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -1459,8 +1459,9 @@ configInputDevices(XF86ConfLayoutPtr layou
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 (buf,
On 24.03.2011 19:31, Keith Packard wrote:
On Thu, 24 Mar 2011 15:18:17 +0100 (CET), Mark
Kettenis 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?
No particular reason
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 cal
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) pDrawable)->borderC
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 a
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 branche
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 pat
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
som
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 wh
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:
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
of
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 ava
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!)
Vers
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
Al
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 f
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 (!prop->n
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’, dec
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ä
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
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.
_
38 matches
Mail list logo