<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
On Wed, 2010-06-09 at 21:15 -0400, Gaetan Nadon wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
On Thu, 2010-06-10 at 08:50 +1000, Peter Hutterer wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Wed, Jun 09, 2010 at 06:12:57PM -0400, Gaetan Nadon wrote:
> On Thu, 2010-06-10 at 00:00 +0200, Julien Cristau wrote:
>
> > On Wed, Jun 9, 2010 at 17:57:45 -0400, Gaetan Nadon wrote:
> >
> > > Now I get it. However randr is an optional extension, it may or may not
> > > be defined in the server. On the other hand, the server should perhaps
> >
> > xorg-server.pc is generated, it can require randrproto or not depending
> > on whether xorg-server.h will define RANDR.
> >
>
>
> This sounds like the proper solution, which has to be implemented in the
> server. Currently, all input and video drivers have a dependency on
> RANDR coded in their configuration. Would you agree that, at the moment,
> this is unfortunately correct?
or clean up xf86.h so that the RandR specific function declarations are
defined elsewhere? Would this be an option? the only reason it is included
is the Rotation typedef.
</PRE>
</BLOCKQUOTE>
That was my initial thought, but I find the .pc solution attractive. Even if there were no problems to solve, the server should declare its dependencies there. It would also solves other indirect dependencies like randr which depends on render. Failing to include headers file is still not a perfect test for detecting dependencies. The xf86.h header should also be refactored as well, of course.<BR>
<BR>
</BLOCKQUOTE>
I was mislead by #ifdef in the code, RANDR is not optional:
<BLOCKQUOTE>
<PRE>
<TT>AC_DEFINE(RANDR, 1, [Support RANDR extension])</TT>
</PRE>
</BLOCKQUOTE>
I checked the server required modules, there are about 10 mandatory ones and 10 optionals. That would be 20 modules in Requires.private. It makes sense, drivers are part of the server, so they depend on all the packages the server depends on. <BR>
<BR>
I think all a driver really needs is to depend on xserver only. It can't use an extension that isn't defined in the server I suppose. It may simplify the configuration of synaptics regarding the recordproto extension.<BR>
<BR>
This makes xf86.h less of an issue. As long as it does not include anything from the optional modules.
<BLOCKQUOTE>
<PRE>
Required to configure xserver:
randrproto >= 1.2.99.3 renderproto >= 0.11 fixesproto >= 4.1 damageproto >= 1.1 xcmiscproto >= 1.2.0 xextproto >= 7.0.99.3 xproto >= 7.0.17 bigreqsproto >= 1.1.0 fontsproto inputproto >= 1.9.99.902 kbproto >= 1.0.3"
Optional modules:
glproto >= 1.4.10 dri2proto >= 2.3 xf86vidmodeproto >= 2.2.99.1 xf86driproto >= 2.1.0 videoproto compositeproto >= 0.4 recordproto >= 1.13.99.1 scrnsaverproto >= 1.1 resourceproto xineramaproto
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Cheers,
Peter
</PRE>
</BLOCKQUOTE>
<PRE>
_______________________________________________
<A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A>: X.Org development
Archives: <A HREF="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</A>
Info: <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>