pciaccess conversion the revenge..

[Paulo Cesar Pereira de Andrade]

Daniel Stone wrote:
>>   The apm driver, you just changed, needs at least some kind of
>> check to build conditionally based on the dev privates changes:
>> -%<-
>>     if (ApmGeneration != serverGeneration) {
>> 	if ((ApmPixmapIndex = AllocatePixmapPrivateIndex()) < 0)
>> 	    return FALSE;
>> 	ApmGeneration = serverGeneration;
>>     }
>>
>>     if (!AllocatePixmapPrivate(pScreen, ApmPixmapIndex, sizeof(ApmPixmapRec)))
>> 	return FALSE;
>> -%<-
>> in src/apm_driver.c:ApmScreenInit() or it will not even start due to
>> the missing symbols AllocatePixmapPrivateIndex and AllocatePixmapPrivate.
>
> That driver doesn't see any changes at all, so might as well just tell
> people with older servers to use an older version, since the code is
> otherwise identical.
>
>>   I feel it will work if you just #if 0 that code as it would only
>> be used if XF86RUSH is defined (and apm_rush.c would be compiled), but
>> I think it is never defined, and the other code that uses this in
>> apm_accel.c is already #if 0'ed, see:
>> -%<-
>> extern int	ApmPixmapIndex;
>> #define APM_GET_PIXMAP_PRIVATE(pix)\
>> 	((ApmPixmapPtr)(((PixmapPtr)(pix))->devPrivates[ApmPixmapIndex].ptr))
>> -%<-
>> in src/apm.h.
>
> Rush isn't used anywhere at all.

  So the proper fix would be something like (pseudo patch):
+#if XF86RUSH
     if (ApmGeneration != serverGeneration) {
         if ((ApmPixmapIndex = AllocatePixmapPrivateIndex()) < 0)
             return FALSE;
         ApmGeneration = serverGeneration;
     }
     if (!AllocatePixmapPrivate(pScreen, ApmPixmapIndex, 
sizeof(ApmPixmapRec)))
         return FALSE;
+#endif

>>> so you can consider a lot of these conversions to be just making noise
>>> to wake up the people who own this hardware and can thus test and
>>> perhaps fix it.
>>   I did some minor work on it, but gave up because of this same reason,
>> i.e. not being able to test the changes.
>>
>>   I was also looking at the possibility, and wrote some initial code, not
>> yet functional, to create a scanpci.so and xf86ansic.so modules, that could
>> be installed somewhere like /usr/lib/xorg/modules/compat, just as a way to
>> allow binary compatibility with old modules, and possibly compile new modules
>> using an interface that exports the old api, using libpciaccess, and
>> those modules could just be loaded, adding a Load in the Module section in
>> xorg.conf. But the "scanpci" module would not be trivial to write...
>
> It's so, so much easier to just fix up all the old drivers.
  Not really, if the developer cannot test the changes.

  In the current state things got on, probably it would be wise to add 
some huge
"warning" being printed to the log file and console about the state of 
the driver.
And hope someone, with knowledge about the card and working with OSS, will
volunteer to maintain the driver.

  Something like libpciaccess should have been ported to drivers, before 
being made
the only option. Otherwise, mainly due to the way people "colaborate" 
with "X",
and how "X" receives the "colaboration", either you try to adapt new 
features to not
break those old drivers, or you have no other option than throwing it away.


> Cheers,
> Daniel

Paulo