brokenness of dri1
marcoz at osource.org
Wed Sep 26 09:27:34 PDT 2012
I'm guessing this question has been asked a bunch of times, please
forgive me for asking yet again.
Is it possible to have automated regression and functional tests for
this stuff? Are machines needed with those particular cards? This
tinderbox just verifies that things compile correctly right? Not actual
functional test? (Correct me if I'm wrong.)
Peter is doing the XIT (pronounced either z-it or sh-it), Blaz worked
on piglit tests, ...
What is needed for us to have an automated regression test setup? Other
than needing people to actually spend the time to write tests?
I'm actually wanting to help with this type of stuff. I think it goes
nicely with the xserver stable branch maintenance.
As always, please re-steer me if I'm out in left field,
(still on vacation, may not respond until next week but I happened to
see this and really wanted to respond.)
On 09/26/2012 08:09 AM, Dave Airlie wrote:
> On Wed, Sep 26, 2012 at 3:43 PM, Dave Airlie <airlied at gmail.com> wrote:
>> In a further effort to show how little testing outside developers we
>> get, I tried to check dri1 :-)
>> Its been broken in a subtlle manner thanks to Keith at
>> faeebead7bfcc78535757ca7acc1faf7554c03b7 which was back in the 1.8
>> It was then noticeably broken by Daniel in
>> the thing is the check for DRIGeneration != serverGeneration was
>> probably always bogus, but in the first commit it meant we never
>> called DRIExtensionInit internals, the second commit moved some code
>> into that and that broken drm module loading as the drmServer stuff
>> never got initialised.
>> Now I'm wondering what the correct form for that check should be,
>> since at the moment DRIGeneration is 0 and serverGeneration is 1 at
>> entry to that function.
> Okay its not as bad as all that its just Daniel's commit that really
> broken stuff, since I didn't realise ExtensionInit we called after
> ScreenInit and Daniel's commit moved the drmSetServerInfo into there
> when its actually needed where the module loader used to call, nice
> I really hope the rest of the extension init changes are as quality.
> 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
More information about the xorg-devel