Re: No icon on the gnome desktop using geode driver

[Michel Dänzer]

On Fri, 2010-04-09 at 14:55 +0800, Huang, FrankR wrote: 
> 
> Right now, we are debugging the geode driver. In three
> BTS, the big issue is the “no icon” bug on the desktop. 
> 
> I have written some simple Xlib programs trying  to
> reproduce this issue because it does not depend on the window manager.
> That will be more simple to fix on the bug root. But all these
> programs failed to reproduce.
> 
> Two Xlib application to demonstrate:
> 
> One is displaying an application icon via the Window
> manager using XCreateBitmapFromData() function. This icon can display
> on the application window correctly.
> 
> The other is an application using libxpm. It get the
> pixmap from a file using the function XpmReadFileToPixmap(). This icon
> can also display in the application.
> 
> Another example is the eog program under gnome. The button
> icon can not be displayed in the program. It is quite similar with our
> bug. But this program is written in GTK, no Xlib.
> 
> So is there some people know the mechanism of the GNOME to
> display the icon? I found that these files are png file format. Or any
> program can reproduce this using Xlib??
> 
> I attached a file to demonstrate this bug.

I followed up to https://bugs.freedesktop.org/show_bug.cgi?id=27243 .


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
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: Merged proto package

[Luc Verhaegen]

On Tue, Apr 06, 2010 at 11:14:18PM -0700, Keith Packard wrote:
> On Wed, 07 Apr 2010 07:38:12 +0200, Rémi Cardona  wrote:
> 
> > We (in gentoo) have spent a lot of time trying to figure out which
> > protos each app really needs. Now that the split has been done for so
> > long, I just don't see the advantage of merging them back.
> 
> For distros who have already done the work, the advantage is minimal,
> aside from only needing to repackage one thing when changes are made.
> 
> The people we're trying to reach with this are those people building
> From source.
> 
> For people like me, who really can't rely on a distribution to be up to
> date enough, I end up installing protocol headers. Of course, they go
> stale if I don't keep on top of them, and so I get accidental version
> skew. Reducing the number of packages I have to track from 20 to 1 would
> avoid this almost entirely.

How much work is this, really? Later on you say that there are no 
dependencies for them, so it just boils down to updating, running 
autogen.sh and make install.

It seems like this can be very easily scripted.
 
> For people who would like to try out current X server, mesa or driver
> bits, we stick them with a huge number of tiny packages to install to
> get stuff building. I was working with a hardware validation person just
> a few weeks ago; she had a list of some twenty modules required to build
> the current Intel driver and X server. 

I am sure that the proto headers are the least of this persons worry. 
What about the big dependencies, like the kernel and libdrm and then 
the forced update of mesa? Why try to tackle the non-issue first and 
avoid the real issues?

> > Or do we plan to break protos all over again?
> 
> No, we keep trying to avoid that. At least we'll catch it sooner if more
> people are up-to-date with the protocol headers?
> 
> Given that these packages all install only header files and have no
> dependencies, it's hard to see the value of breaking them up into
> separate packages.

But don't the protocol headers each have packages depending on them 
separately, so that an update of the amalgamut triggers an update of 
many of the packages above the protocol header amalgamut?

> When we did the modularization work, we split things up into the
> smallest possible units. For my part, this was probably a habit learned
> From working on tiny embedded systems. For libraries and applications, I
> think that's a good thing as those things take real space on lots of
> machines and can introduce security issues. For header files, I'm having
> a hard time seeing the value and I know it's costing the time of a lot
> of people who help with the project.

So you want the protocol headers, upon which those libraries and 
application depend, joined together, but keep the libraries and 
utilities, of which some just depend on some protocol headers and libc, 
all separate, even though a small update to any one currently 
separate proto package, will now trigger an update of all?

This does not make much sense to me.

> I don't want to merge the whole mess back together again, I think we're
> all happy to have the libraries and CLI applications live a separate
> life far from our daily activities. However, I do want to encourage
> people to develop and test stuff, and when it's reasonable, we should
> make that more convenient.

This is not the way to make it more convenient. A single big proto 
package will trigger an update of all packages which formerly depended 
on a single or a few protocol headers, which will in turn force updates 
of other packages up the stack.

You are making things a lot harder.

> In my ideal world, a user interested in trying out the latest driver
> bits for their video card would have to download two modules, the
> protocol headers and the X server/drivers. Just merging the protocol
> headers together gets us to four -- headers/server/video/evdev. Yeah,
> there are also kernel/mesa/libdrm issues, and we should figure out how
> to make that easier too.

In an ideal world, graphics drivers are slightly backwards compatible, 
so that no xserver, mesa, kernel, base libdrm updates need to happen 
(within a reasonable window that is up to the graphics driver 
developers, but you will have to be reasonable). This is not hard to 
achieve, not at all, but it is something that you have refused to occupy 
yourself with for as long as you have been doing driver development.

The proto change is a pointless change, or more accurately, it is one 
that will put us firmly on the path of re-modularization and it will 
make things a lot harder for everyone.

So, either tackle the real issue, which is that of lacking (build time) 
compatibility of both the xserver and the drivers (imagine being able to 
build an xserver that is compatible with a slightly older dri2 -- then 
you do not have to update the proto either, and you can just drop in 
the new xserver and test all the other bits of it just fine witho

Re: Merged proto package

[Luc Verhaegen]

On Wed, Apr 07, 2010 at 07:03:56AM -0700, Dan Nicholson wrote:
> On Wed, Apr 7, 2010 at 6:50 AM, Tiago Vignatti  
> wrote:
> > On Wed, Apr 07, 2010 at 08:14:18AM +0200, ext Keith Packard wrote:
> >>
> >> In my ideal world, a user interested in trying out the latest driver
> >> bits for their video card would have to download two modules, the
> >> protocol headers and the X server/drivers. Just merging the protocol
> >> headers together gets us to four -- headers/server/video/evdev. Yeah,
> >> there are also kernel/mesa/libdrm issues, and we should figure out how
> >> to make that easier too.
> >>
> >
> > Well, the user would have also to care about some libraries: libpciaccess,
> > libXfont, libfontenc, libXau, libpixman, libxdmcp and etc, just to mention
> > some. So, besides protocol and drivers, do we intent to merge libraries 
> > back?
> 
> Only a couple libraries are used from the server, and ideally none of
> the X libraries. On the client side, people have this under control
> and often just use the libraries from their distro. I would hope the
> libraries don't get merged together

What stops them from being merged together, they will already be, to 
some large extent, in lock-step on the proto stuff. Update the proto 
amalgamut, and you're update the libs. It won't take long until the next 
person with the next "bright idea" comes along.

Luc Verhaegen
___
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: Merged proto package

[Luc Verhaegen]

On Thu, Apr 08, 2010 at 12:14:50PM -0700, Dan Nicholson wrote:
> 
> You'd have to change all the libraries and apps that depend on them.
> That's fine for xorg packages, but it's a little tougher to know about
> libraries out in the wild. At the very least, it would require that
> you reinstall all your xorg libraries with references to the
> individual package names removed so that pkg-config calls would
> resolve correctly. That seems excessive.

Welcome to what apparently will be the future. This will be our faith 
from now on.

The results of the need to do massive updates will follow soon.

People will either:
* become _extremely_ prudent of protocol changes, and no changes will 
end up happening any more.
* or protocol will get changed without bumping any version anymore 
(that sounds like fun to debug).
* or the mass updates further limits the ability and especially 
willingness of users updating their xserver, or any other packages that
depend on the proto amalgamut.

If the initial goal is to:
* speed up development
* ease debugging
* increase uptake of development xserver versions
then congratulations, you are about to achieve the exact opposite.

Luc Verhaegen.
___
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: Merged proto package

[Florian Mickler]

On Fri, 9 Apr 2010 09:45:01 +0200
Luc Verhaegen  wrote:

> 
> But don't the protocol headers each have packages depending on them 
> separately, so that an update of the amalgamut triggers an update of 
> many of the packages above the protocol header amalgamut?

is this a valid concern? 
what libraries and packages depend on the new xproto package and how
backwards-incompatible are the changes done to these proto's normally?

what other packages depend on these which do not depend on the xserver?

> 
> So, either tackle the real issue, which is that of lacking (build time) 
> compatibility of both the xserver and the drivers (imagine being able to 
> build an xserver that is compatible with a slightly older dri2 -- then 
> you do not have to update the proto either, and you can just drop in 
> the new xserver and test all the other bits of it just fine without 
> changing anything else in your system), or own up to the fact that 
> you're going for a full re-modularization.
> 
> Luc Verhaegen.

the thing is, that i get the feeling, that some of the driver writers
don't want to have this n:m relationship between xserver and
video-driver because they make fundamental changes to both(?) codebases
which require parallel codepaths for different versions and thus split
the testing coverage... they want xserver and driver to be 1:1.
but this is about the proposed merge of the proto packages.. let's not
get carried away.

cheers,
Flo

p.s.: starting off in a thread with personal insults is probably not
the best strategy if you want to be taken for full...

___
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: [PATCH:macros] doc: add XORG_CHECK_SGML_DOCTOOLS to detect xorg-sgml-doctools

[Dan Nicholson]

On Thu, Apr 8, 2010 at 11:22 PM, Yaakov (Cygwin/X)
 wrote:
> On 2010-04-08 08:14, Dan Nicholson wrote:
>>
>> Huh, I hadn't noticed that. I think we should demand that you have the
>> version with the .pc file once there's a release. For the very few
>> people who are going to attempt to build the sgml documentation, I
>> think they can be bothered to grab a newer doctools package.
>
> That would be easier, and indeed the first version of my patch did just
> that, but Gaetan pointed out that this would cause a regression if macros is
> updated but not doctools.  Whether or not that is acceptable as a tradeoff
> for the functionality of using pkg-config needs to be decided.

As long as someone makes a release of the doctools, I'd be willing to
make that sacrifice.

1. The number of people actually building the sgml docs is likely
extremely small and probably is encompassed by x developers trying to
make a katamari release and a handful of distro packagers. I think
they can be bothered to update one more package that has 0
dependencies.

2. The gain in proper versioning outweighs the loss of backwards
compatibility in my mind.

3. The time when people will be attempting to build the docs is likely
just before or after the next Xorg release. They'll be wanting to
download the new doctools for the updated entities anyway.

--
Dan
___
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: [PATCH 0/5] Change the mask specification theme and a few corrections

[Dirk Wallenstein]

On Thu, Apr 08, 2010 at 08:46:32PM -0700, Alan Coopersmith wrote:
> Dirk Wallenstein wrote:
> > Move all of kbproto and the corresponding manuals in libX11 to the
> > (next-1) mask specification theme. This makes editing the flags less
> > error-prone and it did already let me find some errors. This also fixes
> > those errors I found on the way.
> > 
> > To print the shift level and hex-value correspondence in python:
> > python -c "for i in range(16): print '%2i => %#x' % (i , ((1< > 
> > 
> > For the kbproto component:
> > 
> > Dirk Wallenstein (2):
> >   Use the correct value for XkbAllAccessXEventsMask
> >   Convert mask specifications to (next - 1) scheme
> > 
> >  XKB.h  |   34 +-
> >  XKBgeom.h  |2 +-
> >  XKBproto.h |2 +-
> >  3 files changed, 19 insertions(+), 19 deletions(-)
> > 
> > 
> > For the libX11 component:
> > 
> > Dirk Wallenstein (3):
> >   man: Add missing geometry component flag
> >   man: Correct the XkbAllAccessXEventsMask mask name
> >   man: Sync mask specification with source code
> 
> I've pushed patches 1, 3 & 4 from this series as it looks like
> you withdrew 2 & 5 after discussion.   Thanks for submitting these.

Yes, although the revocation comment was a bit hidden. Next time I put
that in the subject.

Thanks,
Dirk
___
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

[PATCH] vfb: add a name to the pointer and keyboard

[Julien Cristau]

Fixes a crash in XIQueryDevice which calls strlen on a NULL pointer.

 #0  strlen () at ../sysdeps/x86_64/strlen.S:31
 #1  0x004c16ed in SizeDeviceInfo (dev=0x969bd0)
 at ../../Xi/xiquerydevice.c:204
 #2  0x004c1a01 in ProcXIQueryDevice (client=0xa57510)
 at ../../Xi/xiquerydevice.c:98

Debian bug#575905 

Reported-by: "Bernhard R. Link" 
Signed-off-by: Julien Cristau 
Reviewed-by: Fernando Carrijo 
---
 hw/vfb/InitInput.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c
index 35d1dc4..1fcd025 100644
--- a/hw/vfb/InitInput.c
+++ b/hw/vfb/InitInput.c
@@ -139,7 +139,9 @@ InitInput(int argc, char *argv[])
 p = AddInputDevice(serverClient, vfbMouseProc, TRUE);
 k = AddInputDevice(serverClient, vfbKeybdProc, TRUE);
 RegisterPointerDevice(p);
+p->name = xnfstrdup("mouse");
 RegisterKeyboardDevice(k);
+k->name = xnfstrdup("keyboard");
 (void)mieqInit();
 }
 
-- 
1.7.0.4

___
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: [PATCH 1/5] Replace DDXBEFORERESET with a more general way of doing DDX-specific hooks

[Jon TURNEY]

On 07/04/2010 18:32, Jamey Sharp wrote:

I'm confused about whether multiple declarations of the same global
are allowed. In this case, ddxHooks is declared in both
xwin/InitOutput.c and dispatch.c. But as far as I can tell, this can't
hurt any DDX except Xwin, and I assume you've tested that it works
there, so I'd guess it's fine. :-)


Hmmm yes

Rereading the language of section 6.9.2 of the C standard (or at least the 
draft I could find, since I seem to have mislaid my copy of the C89 standard 
:-) ), the tentative declaration only is only required to remain tentative to 
the end of a file.


I guess this means this approach won't work if gcc -fno-common (or another 
compiler which behaves like that) is used.


So, I suppose I need to change this to use a functional interface to 
initialize ddxHooks.


___
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: Merged proto package

[Adam Jackson]

On Thu, 2010-04-08 at 13:59 -0700, Keith Packard wrote:
> On Thu, 08 Apr 2010 14:24:29 -0400, Gaetan Nadon  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.

Please leave all the pc files in place and keep them up to date.
Breaking this solves nothing.

- ajax


signature.asc
Description: This is a digitally signed message part
___
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

[PATCH] glx: Set the pbuffer bit for dri2 fbconfigs

[Kristian Høgsberg]

They've been implemented for a while, but we never advertised them.  All we
need to do is set the GLX_PBUFFER_BIT in the drawable type fbconfig
field when we're using DRI2.

Signed-off-by: Kristian Høgsberg 

https://bugs.freedesktop.org/show_bug.cgi?id=26581
---
 glx/glxdri.c   |7 +++
 glx/glxdri2.c  |5 -
 glx/glxdricommon.c |   13 -
 glx/glxdricommon.h |3 ++-
 glx/glxdriswrast.c |5 -
 5 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/glx/glxdri.c b/glx/glxdri.c
index 21e44d1..9810a73 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -939,9 +940,6 @@ initializeExtensions(__GLXDRIscreen *screen)
 }
 }
 
-extern __GLXconfig *
-glxConvertConfigs(const __DRIcoreExtension *core, const __DRIconfig **configs);
-
 static __GLXscreen *
 __glXDRIscreenProbe(ScreenPtr pScreen)
 {
@@ -1131,7 +1129,8 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
goto handle_error;
 }
 
-screen->base.fbconfigs = glxConvertConfigs(screen->core, driConfigs);
+screen->base.fbconfigs = glxConvertConfigs(screen->core,
+  driConfigs, GLX_WINDOW_BIT);
 
 initializeExtensions(screen);
 
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index e791bf6..4c9f381 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -748,7 +748,10 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
 
 initializeExtensions(screen);
 
-screen->base.fbconfigs = glxConvertConfigs(screen->core, driConfigs);
+screen->base.fbconfigs = glxConvertConfigs(screen->core, driConfigs,
+  GLX_WINDOW_BIT |
+  GLX_PIXMAP_BIT |
+  GLX_PBUFFER_BIT);
 
 __glXScreenInit(&screen->base, pScreen);
 
diff --git a/glx/glxdricommon.c b/glx/glxdricommon.c
index faaa3b7..454aa55 100644
--- a/glx/glxdricommon.c
+++ b/glx/glxdricommon.c
@@ -121,7 +121,7 @@ setScalar(__GLXconfig *config, unsigned int attrib, 
unsigned int value)
 static __GLXconfig *
 createModeFromConfig(const __DRIcoreExtension *core,
 const __DRIconfig *driConfig,
-unsigned int visualType)
+unsigned int visualType, unsigned int drawableType)
 {
 __GLXDRIconfig *config;
 unsigned int attrib, value;
@@ -167,13 +167,14 @@ createModeFromConfig(const __DRIcoreExtension *core,
 config->config.next = NULL;
 config->config.xRenderable = GL_TRUE;
 config->config.visualType = visualType;
-config->config.drawableType = GLX_WINDOW_BIT | GLX_PIXMAP_BIT;
+config->config.drawableType = drawableType;
 
 return &config->config;
 }
 
 __GLXconfig *
-glxConvertConfigs(const __DRIcoreExtension *core, const __DRIconfig **configs)
+glxConvertConfigs(const __DRIcoreExtension *core,
+ const __DRIconfig **configs, unsigned int drawableType)
 {
 __GLXconfig head, *tail;
 int i;
@@ -183,7 +184,8 @@ glxConvertConfigs(const __DRIcoreExtension *core, const 
__DRIconfig **configs)
 
 for (i = 0; configs[i]; i++) {
tail->next = createModeFromConfig(core,
- configs[i], GLX_TRUE_COLOR);
+ configs[i], GLX_TRUE_COLOR,
+ drawableType);
if (tail->next == NULL)
break;
 
@@ -192,7 +194,8 @@ glxConvertConfigs(const __DRIcoreExtension *core, const 
__DRIconfig **configs)
 
 for (i = 0; configs[i]; i++) {
tail->next = createModeFromConfig(core,
- configs[i], GLX_DIRECT_COLOR);
+ configs[i], GLX_DIRECT_COLOR,
+ drawableType);
if (tail->next == NULL)
break;
 
diff --git a/glx/glxdricommon.h b/glx/glxdricommon.h
index f88964b..41e2d27 100644
--- a/glx/glxdricommon.h
+++ b/glx/glxdricommon.h
@@ -33,7 +33,8 @@ struct __GLXDRIconfig {
 };
 
 __GLXconfig *
-glxConvertConfigs(const __DRIcoreExtension *core, const __DRIconfig **configs);
+glxConvertConfigs(const __DRIcoreExtension *core,
+ const __DRIconfig **configs, unsigned int drawableType);
 
 extern const __DRIsystemTimeExtension systemTimeExtension;
 
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index c647d83..918383c 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdriswrast.c
@@ -506,7 +506,10 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
 
 initializeExtensions(screen);
 
-screen->base.fbconfigs = glxConvertConfigs(screen->core, driConfigs);
+screen->base.fbconfigs = glxConvertConfigs(screen->core, driConfigs,
+  GLX_WINDOW_BIT |
+  GLX_PIXMAP_BIT |
+  GLX_PBUFFER_BIT);
 
 __glXScreenInit(&screen->base, pS

[PATCH xserver] xf86ScaleAxis: support for high resolution devices

[Benjamin Tissoires]

High resolution devices was generating integer overflow.
For instance the wacom Cintiq 21UX has an axis value up to
87000. Thus the term (dSx * (Cx - Rxlow)) is greater than
MAX_INT32.

Using 64bits integer avoids such problem.

Signed-off-by: Philippe Ribet 
Signed-off-by: Benjamin Tissoires 
---
 hw/xfree86/common/xf86Xinput.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 8229227..80bdd19 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -1172,12 +1172,12 @@ xf86ScaleAxis(int   Cx,
   int  Rxlow )
 {
 int X;
-int dSx = Sxhigh - Sxlow;
-int dRx = Rxhigh - Rxlow;
+int64_t dSx = Sxhigh - Sxlow;
+int64_t dRx = Rxhigh - Rxlow;
 
 dSx = Sxhigh - Sxlow;
 if (dRx) {
-   X = ((dSx * (Cx - Rxlow)) / dRx) + Sxlow;
+   X = (int)(((dSx * (Cx - Rxlow)) / dRx) + Sxlow);
 }
 else {
X = 0;
-- 
1.6.6.1

___
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: [PATCH:macros] doc: add XORG_CHECK_SGML_DOCTOOLS to detect xorg-sgml-doctools

[Gaetan Nadon]

On Fri, 2010-04-09 at 06:11 -0700, Dan Nicholson wrote:

> On Thu, Apr 8, 2010 at 11:22 PM, Yaakov (Cygwin/X)
>  wrote:
> > On 2010-04-08 08:14, Dan Nicholson wrote:
> >>
> >> Huh, I hadn't noticed that. I think we should demand that you have the
> >> version with the .pc file once there's a release. For the very few
> >> people who are going to attempt to build the sgml documentation, I
> >> think they can be bothered to grab a newer doctools package.
> >
> > That would be easier, and indeed the first version of my patch did just
> > that, but Gaetan pointed out that this would cause a regression if macros is
> > updated but not doctools.  Whether or not that is acceptable as a tradeoff
> > for the functionality of using pkg-config needs to be decided.
> 
> As long as someone makes a release of the doctools, I'd be willing to
> make that sacrifice.
> 
> 1. The number of people actually building the sgml docs is likely
> extremely small and probably is encompassed by x developers trying to
> make a katamari release and a handful of distro packagers. I think
> they can be bothered to update one more package that has 0
> dependencies.
> 
> 2. The gain in proper versioning outweighs the loss of backwards
> compatibility in my mind.
> 
> 3. The time when people will be attempting to build the docs is likely
> just before or after the next Xorg release. They'll be wanting to
> download the new doctools for the updated entities anyway.
> 

I don't have objections in this case to somewhat break compatibility. I
routinely test for such a scenario when making changes as I have been
reminded that changes and new features in macros should not adversely
affect current or previous versions of clients. There is some leeway
here as long as it does not just plain break and is easy to figure out.
It's a judgement call. 



> --
> Dan
> ___
> 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


signature.asc
Description: This is a digitally signed message part
___
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: [PATCH xserver] xf86ScaleAxis: support for high resolution devices

[Dan Nicholson]

On Fri, Apr 9, 2010 at 7:51 AM, Benjamin Tissoires  wrote:
> High resolution devices was generating integer overflow.
> For instance the wacom Cintiq 21UX has an axis value up to
> 87000. Thus the term (dSx * (Cx - Rxlow)) is greater than
> MAX_INT32.
>
> Using 64bits integer avoids such problem.
>
> Signed-off-by: Philippe Ribet 
> Signed-off-by: Benjamin Tissoires 
> ---
>  hw/xfree86/common/xf86Xinput.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
> index 8229227..80bdd19 100644
> --- a/hw/xfree86/common/xf86Xinput.c
> +++ b/hw/xfree86/common/xf86Xinput.c
> @@ -1172,12 +1172,12 @@ xf86ScaleAxis(int       Cx,
>               int      Rxlow )
>  {
>     int X;
> -    int dSx = Sxhigh - Sxlow;
> -    int dRx = Rxhigh - Rxlow;
> +    int64_t dSx = Sxhigh - Sxlow;
> +    int64_t dRx = Rxhigh - Rxlow;

Not sure, but would you not also need to change the function
parameters to int64_t? I guess you're just avoiding a cast below,
though. Also, could you explicitly include  instead of
getting it implicitly?

>
>     dSx = Sxhigh - Sxlow;

Could you kill this redundant line while you're at it?

>     if (dRx) {
> -       X = ((dSx * (Cx - Rxlow)) / dRx) + Sxlow;
> +       X = (int)(((dSx * (Cx - Rxlow)) / dRx) + Sxlow);
>     }
>     else {
>        X = 0;
> --
> 1.6.6.1

--
Dan
___
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: [PATCH 1/5] dix: make MAXSCREENS run-time configurable

[Tiago Vignatti]

On Thu, Apr 08, 2010 at 11:23:21PM +0200, ext Keith Packard wrote:
> 
> Yeah, for things which are created after the ScreenRec is allocated, it
> makes sense to just allocate them right in the ScreenRec.
> 
> For things which are in the xfree86 DDX and are allocated before the
> ScreenRec, those can be in ScrnInfo.
> 
> If there are things outside the xfree86 DDX which are allocated before
> the ScreenRec, we'd need a third plan.
> 

that what Keith said summarizes pretty well indeed.

I thought a bit and started a draft of a patch what we can make this stuff
"maxscreensless". And what seemed to be the hard part is actually there: I
brought all global definitions inside AddScreen, reallocating them (well, I'll
have do the same with WindowTable there). See the attached.

Now it seems the rest is bit trivial then, don't? I meant, like Keith and
Aaron said, is just a matter to add a new struct member in both ScreenRec and
ScrnInfo. 


Who tries? :)

Tiago
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 982c808..bf064f7 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3975,6 +3975,44 @@ static int indexForScanlinePad[ 65 ] = {
 	 3		/* 64 bits per scanline pad unit */
 };
 
+static void
+ReallocGlobals (void)
+{
+DDXPointRec *dixScreenOriginsNew;
+int *cursorScreenDevPrivNew;
+ScreenSaverStuffRec *savedScreenInfoNew;
+ScreenPtr   *screensNew;
+
+if (serverGeneration == 1) {
+
+	if (screenInfo.numScreens) {
+	dixScreenOriginsNew = xrealloc(dixScreenOrigins,
+(screenInfo.numScreens + 1) * sizeof(DDXPointRec));
+	cursorScreenDevPrivNew = xrealloc(cursorScreenDevPriv,
+(screenInfo.numScreens + 1) * sizeof(int));
+	savedScreenInfoNew = xrealloc(savedScreenInfo,
+(screenInfo.numScreens + 1) * sizeof(ScreenSaverStuffRec));
+	screensNew = xrealloc(screenInfo.screens,
+(screenInfo.numScreens + 1) * sizeof(struct _Screen));
+	}
+	else {
+	dixScreenOriginsNew = xalloc(sizeof(DDXPointRec));
+	cursorScreenDevPrivNew = xalloc(sizeof(int));
+	savedScreenInfoNew = xalloc(sizeof(ScreenSaverStuffRec));
+	screensNew = xalloc(sizeof(struct _Screen));
+	}
+	dixScreenOrigins = dixScreenOriginsNew;
+	cursorScreenDevPriv = cursorScreenDevPrivNew;
+	savedScreenInfo = savedScreenInfoNew;
+	screenInfo.screens = screensNew;
+
+	/* Initialize DevPrivates as 0 is fundamental. TODO: justify why */
+	cursorScreenDevPriv[screenInfo.numScreens] = 0;
+}
+
+MAXSCREENSALLOC_FATAL(WindowTable);
+}
+
 /*
 	grow the array of screenRecs if necessary.
 	call the device-supplied initialization procedure
@@ -4056,6 +4094,9 @@ AddScreen(
multiple screens.
 */
 pScreen->rgf = ~0L;  /* there are no scratch GCs yet*/
+
+ReallocGlobals();
+
 WindowTable[i] = NullWindow;
 screenInfo.screens[i] = pScreen;
 screenInfo.numScreens++;
diff --git a/dix/main.c b/dix/main.c
index edd66a1..b9b6f64 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -148,16 +148,6 @@ void SetMaxScreens(int maxscreens)
 MAXSCREENS = maxscreens > 0 ? maxscreens : MAXSCREENSDEFAULT;
 }
 
-static void InitGlobals(void)
-{
-if (!MAXSCREENS) SetMaxScreens(MAXSCREENSDEFAULT);
-
-MAXSCREENSALLOC_FATAL(dixScreenOrigins);
-MAXSCREENSALLOC_FATAL(cursorScreenDevPriv);
-MAXSCREENSALLOC_FATAL(savedScreenInfo);
-MAXSCREENSALLOC_FATAL(screenInfo.screens);
-}
-
 #ifdef XQUARTZ
 #include 
 
@@ -189,8 +179,6 @@ int main(int argc, char *argv[], char *envp[])
 
 ProcessCommandLine(argc, argv);
 
-InitGlobals();
-
 alwaysCheckForInput[0] = 0;
 alwaysCheckForInput[1] = 1;
 while(1)
@@ -233,10 +221,6 @@ int main(int argc, char *argv[], char *envp[])
 	screenInfo.arraySize = MAXSCREENS;
 	screenInfo.numScreens = 0;
 
-	MAXSCREENSALLOC(WindowTable);
-	if (!WindowTable)
-	FatalError("couldn't create root window table");
-
 	InitAtoms();
 	InitEvents();
 	InitSelections();
___
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

[PATCH] exa: check for valid SourceValidate callback ptr

[Jerome Glisse]

During rotation the screen SourceValidate ptr is set to NULL
(see hw/xfree86/modes/xf86Rotate.c xf86RotateRedisplay) to avoid
segfaulting in exa unaccelerated path check for a valid SourceValidate
ptr.

Signed-off-by: Jerome Glisse 
---
 exa/exa_unaccel.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index b4ead7f..d4133bf 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -465,7 +465,9 @@ ExaSrcValidate(DrawablePtr pDrawable,
 REGION_UNINIT(pScreen, ®);
 
 swap(pExaScr, pScreen, SourceValidate);
-pScreen->SourceValidate(pDrawable, x, y, width, height);
+if (pScreen->SourceValidate) {
+pScreen->SourceValidate(pDrawable, x, y, width, height);
+}
 swap(pExaScr, pScreen, SourceValidate);
 }
 
-- 
1.7.0.1

___
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

libX11 and xcb

[Jeremy Huddleston]

So what is the general recommendation at this point for how to ship libX11?  
I'm still shipping a build --without-xcb mainly because we wanted to play it 
safe during xcb's infancy.  Has anyone did performance comparisons recently?  
Are there any bugs or support issues with the switch that I should be aware of? 
 I've been using it locally without any problem, but I'd like to check in 
before shipping it.

--Jeremy

___
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

[PATCHv2 1/2] DRI2: Track DRI2 drawables as resources, not privates

[Kristian Høgsberg]

The main motivation here is to have the resource system clean up the
DRI2 drawable automatically so glx doesn't have to.  Right now, the
glx drawable resource must be destroyed before the X drawable, so that
calling DRI2DestroyDrawable doesn't crash.  By making the DRI2
drawable a resource, GLX doesn't have to worry about that and the
resource destruction order becomes irrelevant.

https://bugs.freedesktop.org/show_bug.cgi?id=26394

Signed-off-by: Kristian Høgsberg 
---

Here's a different approach to fixing 26394.  It's more invasive and there's
a little piece of uglyness in the DRI2DrawableGone implementation.  We
pass the root window to DestroyBuffer instead of the actual drawable, since
the drawable may have been freed at this point.  The driver only uses the
drawable to lookup the screen anyway, but it is a change in the DRI2 API
semantics.

 glx/glxdri2.c |5 --
 hw/xfree86/dri2/dri2.c|  139 
 hw/xfree86/dri2/dri2ext.c |   22 ---
 3 files changed, 38 insertions(+), 128 deletions(-)

diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index e791bf6..8c883b0 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -105,11 +105,6 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
 
 (*core->destroyDrawable)(private->driDrawable);
 
-/* If the X window was destroyed, the dri DestroyWindow hook will
- * aready have taken care of this, so only call if pDraw isn't NULL. */
-if (drawable->pDraw != NULL)
-   DRI2DestroyDrawable(drawable->pDraw);
-
 __glXDrawableRelease(drawable);
 
 xfree(private);
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 2bdb733..6c4dabc 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -48,15 +48,14 @@
 CARD8 dri2_major; /* version of DRI2 supported by DDX */
 CARD8 dri2_minor;
 
-static int dri2ScreenPrivateKeyIndex;
+static int   dri2ScreenPrivateKeyIndex;
 static DevPrivateKey dri2ScreenPrivateKey = &dri2ScreenPrivateKeyIndex;
-static int dri2WindowPrivateKeyIndex;
-static DevPrivateKey dri2WindowPrivateKey = &dri2WindowPrivateKeyIndex;
-static int dri2PixmapPrivateKeyIndex;
-static DevPrivateKey dri2PixmapPrivateKey = &dri2PixmapPrivateKeyIndex;
+static RESTYPE   dri2DrawableRes;
+
+typedef struct _DRI2Screen *DRI2ScreenPtr;
 
 typedef struct _DRI2Drawable {
-unsigned intrefCount;
+DRI2ScreenPtrdri2_screen;
 int width;
 int height;
 DRI2BufferPtr  *buffers;
@@ -73,9 +72,8 @@ typedef struct _DRI2Drawable {
 int swap_limit; /* for N-buffering */
 } DRI2DrawableRec, *DRI2DrawablePtr;
 
-typedef struct _DRI2Screen *DRI2ScreenPtr;
-
 typedef struct _DRI2Screen {
+ScreenPtr   screen;
 unsigned intnumDrivers;
 const char **driverNames;
 const char *deviceName;
@@ -101,45 +99,35 @@ DRI2GetScreen(ScreenPtr pScreen)
 static DRI2DrawablePtr
 DRI2GetDrawable(DrawablePtr pDraw)
 {
-WindowPtrpWin;
-PixmapPtrpPixmap;
+DRI2DrawablePtr pPriv;
+int rc;
 
-if (!pDraw)
+rc = dixLookupResourceByType((pointer *) &pPriv, pDraw->id,
+dri2DrawableRes, NULL, DixReadAccess);
+if (rc != Success)
return NULL;
 
-if (pDraw->type == DRAWABLE_WINDOW)
-{
-   pWin = (WindowPtr) pDraw;
-   return dixLookupPrivate(&pWin->devPrivates, dri2WindowPrivateKey);
-}
-else
-{
-   pPixmap = (PixmapPtr) pDraw;
-   return dixLookupPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey);
-}
+return pPriv;
 }
 
 int
 DRI2CreateDrawable(DrawablePtr pDraw)
 {
 DRI2ScreenPtr   ds = DRI2GetScreen(pDraw->pScreen);
-WindowPtr  pWin;
-PixmapPtr  pPixmap;
 DRI2DrawablePtr pPriv;
 CARD64  ust;
+intrc;
 
-pPriv = DRI2GetDrawable(pDraw);
-if (pPriv != NULL)
-{
-   pPriv->refCount++;
-   return Success;
-}
+rc = dixLookupResourceByType((pointer *) &pPriv, pDraw->id,
+dri2DrawableRes, NULL, DixReadAccess);
+if (rc == Success || rc != BadValue)
+   return rc;
 
 pPriv = xalloc(sizeof *pPriv);
 if (pPriv == NULL)
return BadAlloc;
 
-pPriv->refCount = 1;
+pPriv->dri2_screen = ds;
 pPriv->width = pDraw->width;
 pPriv->height = pDraw->height;
 pPriv->buffers = NULL;
@@ -158,43 +146,30 @@ DRI2CreateDrawable(DrawablePtr pDraw)
 pPriv->last_swap_msc = 0;
 pPriv->last_swap_ust = 0;
 
-if (pDraw->type == DRAWABLE_WINDOW)
-{
-   pWin = (WindowPtr) pDraw;
-   dixSetPrivate(&pWin->devPrivates, dri2WindowPrivateKey, pPriv);
-}
-else
-{
-   pPixmap = (PixmapPtr) pDraw;
-   dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, pPriv);
-}
+if (!AddResource(pDraw->id, dri2DrawableRes, pPr

[PATCHv2 2/2] glx: Drop DestroyWindow hook

[Kristian Høgsberg]

Now that glx doesn't call DRI2DestroyDrawable anymore, we don't need to
force a specific resource destruction order in the DestroyWindow hook.

Signed-off-by: Kristian Høgsberg 
---
 glx/glxscreens.c |   28 
 glx/glxscreens.h |1 -
 2 files changed, 0 insertions(+), 29 deletions(-)

diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 58d8ee0..b75aea6 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -215,7 +215,6 @@ glxCloseScreen (int index, ScreenPtr pScreen)
 __GLXscreen *pGlxScreen = glxGetScreen(pScreen);
 
 pScreen->CloseScreen = pGlxScreen->CloseScreen;
-pScreen->DestroyWindow = pGlxScreen->DestroyWindow;
 
 pGlxScreen->destroy(pGlxScreen);
 
@@ -347,31 +346,6 @@ pickFBConfig(__GLXscreen *pGlxScreen, VisualPtr visual)
 return best;
 }
 
-static Bool
-glxDestroyWindow(WindowPtr pWin)
-{
-ScreenPtr pScreen = pWin->drawable.pScreen;
-__GLXscreen *pGlxScreen = glxGetScreen(pScreen);
-Bool retval = TRUE;
-
-FreeResource(pWin->drawable.id, FALSE);
-
-/* call lower wrapped functions */
-if (pGlxScreen->DestroyWindow) {
-   /* unwrap */
-   pScreen->DestroyWindow = pGlxScreen->DestroyWindow;
-
-   /* call lower layers */
-   retval = (*pScreen->DestroyWindow)(pWin);
-
-   /* rewrap */
-   pGlxScreen->DestroyWindow = pScreen->DestroyWindow;
-   pScreen->DestroyWindow = glxDestroyWindow;
-}
-
-return retval;
-}
-
 void __glXScreenInit(__GLXscreen *pGlxScreen, ScreenPtr pScreen)
 {
 __GLXconfig *m;
@@ -394,8 +368,6 @@ void __glXScreenInit(__GLXscreen *pGlxScreen, ScreenPtr 
pScreen)
 
 pGlxScreen->CloseScreen = pScreen->CloseScreen;
 pScreen->CloseScreen = glxCloseScreen;
-pGlxScreen->DestroyWindow = pScreen->DestroyWindow;
-pScreen->DestroyWindow = glxDestroyWindow;
 
 i = 0;
 for (m = pGlxScreen->fbconfigs; m != NULL; m = m->next) {
diff --git a/glx/glxscreens.h b/glx/glxscreens.h
index bff4363..d52099f 100644
--- a/glx/glxscreens.h
+++ b/glx/glxscreens.h
@@ -173,7 +173,6 @@ struct __GLXscreen {
 /*...@}*/
 
 Bool (*CloseScreen)(int index, ScreenPtr pScreen);
-Bool (*DestroyWindow)(WindowPtr pWindow);
 };
 
 
-- 
1.7.0.1

___
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

[PATCH input-acecad] config: remove AH_TOP autoheader statement

[Gaetan Nadon]

The generated config.h does not need to include xorg-server.h
for the content it provides.
Add #include  in .[hc] files as needed.

Signed-off-by: Gaetan Nadon 
---
 configure.ac |2 --
 src/acecad.c |3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index d71f9d7..fd7d1cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -45,8 +45,6 @@ AC_DISABLE_STATIC
 AC_PROG_LIBTOOL
 AC_PROG_CC
 
-AH_TOP([#include "xorg-server.h"])
-
 AC_ARG_WITH(xorg-module-dir,
 AC_HELP_STRING([--with-xorg-module-dir=DIR],
[Default xorg module directory 
[[default=$libdir/xorg/modules]]]),
diff --git a/src/acecad.c b/src/acecad.c
index 61e4c21..2c8c78b 100644
--- a/src/acecad.c
+++ b/src/acecad.c
@@ -24,8 +24,11 @@
  *
  */
 
+#ifdef HAVE_CONFIG_H
 #include "config.h"
+#endif
 
+#include 
 #include 
 #define XORG_VERSION_BOTCHED XORG_VERSION_NUMERIC(1,4,0,0,0)
 #if XORG_VERSION_CURRENT >= XORG_VERSION_BOTCHED
-- 
1.6.0.4

All drivers have this AH_TOP config line and I suspect only a few really need 
it.
Is there any reason (workaround or whatever) for xorg-server.h to be obtained
through this round about way?



___
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: libX11 and xcb

[Jamey Sharp]

On Fri, Apr 9, 2010 at 10:58 AM, Jeremy Huddleston
 wrote:
> So what is the general recommendation at this point for how to ship
> libX11?  I'm still shipping a build --without-xcb mainly because we
> wanted to play it safe during xcb's infancy.

I'm curious to hear from packagers myself. I think most packagers are
building --with-xcb at this point, on Linux, BSD, and Solaris? I don't
know though.

> Has anyone did performance comparisons recently?

I re-ran performance tests when we switched to the "socket handoff" API,
and my results showed very little difference between libX11 built with
and without XCB. I think that testing was with a simple application that
sends NoOperation requests as fast as it can, which is a worst-case for
X protocol marshalling performance.

It's expected that throughput and latency are basically unchanged in the
"socket handoff" implementation, because in that version libX11 mostly
works just the way it always did, and then calls writev(2) just like it
always did, except now through a trivial XCB wrapper that tracks the
number of requests issued.

> Are there any bugs or support issues with the switch that I should be
> aware of?  I've been using it locally without any problem, but I'd like
> to check in before shipping it.

As far as I can tell, very few users have any trouble. When I do see a
bug report, it's almost always triggered by some piece of closed-source
software, so the reports we get at this point are usually tricky or
impossible to track down. That's frustrating for everybody...

I may not have a complete picture of support issues, though. Ubuntu
apparently fails to send XCB-related bug reports upstream, for example,
and naturally I can't tell if other distros are failing the same way.

So again, I'd like to learn the answers to your questions, too. :-)

Jamey
___
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: libX11 and xcb

[Alan Coopersmith]

Jamey Sharp wrote:
> I'm curious to hear from packagers myself. I think most packagers are
> building --with-xcb at this point, on Linux, BSD, and Solaris? I don't
> know though.

Solaris 10 and older are still X11R6 libX11, so no xcb in them.
For OpenSolaris and the next Solaris release, we're getting ready to
turn --with-xcb on soon, in the development cycle for the next release,
now that our spring distro release has branched.

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
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: libX11 and xcb

[Matthieu Herrb]

On Fri, Apr 09, 2010 at 11:36:55AM -0700, Jamey Sharp wrote:
> On Fri, Apr 9, 2010 at 10:58 AM, Jeremy Huddleston
>  wrote:
> > So what is the general recommendation at this point for how to ship
> > libX11?  I'm still shipping a build --without-xcb mainly because we
> > wanted to play it safe during xcb's infancy.
> 
> I'm curious to hear from packagers myself. I think most packagers are
> building --with-xcb at this point, on Linux, BSD, and Solaris? I don't
> know though.

OpenBSD 4.7 (already finished, waiting for release in may) will ship
with a xcb-enabled libX11.
FreeBSD 7.3 and 8 are also shipping a xcb-enabled libX11.

Afaik, NetBSD is still shipping the --without-xcb version on all their
releases and in -current.
-- 
Matthieu Herrb
___
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: libX11 and xcb

[Yaakov (Cygwin/X)]

On 2010-04-09 13:36, Jamey Sharp wrote:

I'm curious to hear from packagers myself. I think most packagers are
building --with-xcb at this point, on Linux, BSD, and Solaris? I don't
know though.


Cygwin has shipped libX11 --with-xcb since X11R7.4.


Yaakov
Cygwin/X
___
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: libX11 and xcb

[Timo Aaltonen]

On Fri, 9 Apr 2010, Jamey Sharp wrote:


I may not have a complete picture of support issues, though. Ubuntu
apparently fails to send XCB-related bug reports upstream, for example,
and naturally I can't tell if other distros are failing the same way.


Is this upstream enough?

http://bugzilla.freedesktop.org/show_bug.cgi?id=27552

though it probably should've been upstreamed earlier, my bad for assuming 
it was a dupe of the libXext related crasher. The component might still be 
wrong, adjust if needed.


Other than that it has been quite stable.


--
Timo Aaltonen
Systems Specialist
IT Services, Aalto University
___
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: libX11 and xcb

[Jamey Sharp]

On Fri, Apr 9, 2010 at 2:49 PM, Timo Aaltonen  wrote:
> On Fri, 9 Apr 2010, Jamey Sharp wrote:
>> I may not have a complete picture of support issues, though. Ubuntu
>> apparently fails to send XCB-related bug reports upstream, for example,
>> and naturally I can't tell if other distros are failing the same way.
>
> Is this upstream enough?
>
> http://bugzilla.freedesktop.org/show_bug.cgi?id=27552

Yes! Thanks. :-)

Though I'd like to encourage people with libX11 bugs that might be
XCB-related to CC x...@lists.freedesktop.org, when filing them in
Bugzilla. That helps ensure that XCB experts see them.

> though it probably should've been upstreamed earlier, my bad for assuming it
> was a dupe of the libXext related crasher.

I was just grumpy that if I see an Ubuntu bug related to XCB, it's
often full of negative comments. If what's really going on is that
you're protecting me from your users' wrath, then thank you. :-)

> Other than that it has been quite stable.

That's good to hear!

Jamey
___
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