pciaccess conversion the revenge..
Dave Airlie
airlied at gmail.com
Tue Mar 11 14:29:10 PDT 2008
On Wed, Mar 12, 2008 at 5:24 AM, Paulo Cesar Pereira de Andrade
<pcpa at mandriva.com.br> wrote:
> 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.
>
>
No you fixup the drivers to build, shove them into a distro, and sit
back and wait for the testers to come to you.
The thing is you will never have all the hardware, so you have to find
someone who cares enough to test the code and any patches you might
make..
They don't need to be a programmer, they just need to be willing to
test some rpms you make for them..
The problem is finding these people, I know from Fedora's smolt that
there are a few people out there running Fedora on these cards, so I
can
now hope they care enough to do something when F9 beta lands, or maybe
F9 itself.
Dave.
More information about the xorg
mailing list