[PATCH input-evdev 3/3] config: evdev depends on RANDR through xf86.h

[Gaetan Nadon]

On Wed, 2010-06-09 at 21:15 -0400, Gaetan Nadon wrote:

> On Thu, 2010-06-10 at 08:50 +1000, Peter Hutterer wrote: 
> 
> > 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.
> > 
> 
> 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.
> 

I was mislead by #ifdef in the code, RANDR is not optional:

        AC_DEFINE(RANDR, 1, [Support RANDR extension])

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. 

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.

This makes xf86.h less of an issue. As long as it does not include
anything from the optional modules.

        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



> > Cheers,
> >   Peter
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100609/09dfc340/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100609/09dfc340/attachment-0001.pgp>