> > Usually, I’d say that should be gstreamer’s job. They should provide unit > > tests that allow testing a gstreamer implementation on a linux > > system/board. > > Agreed, and you'd expect that a decent Linux distribution runs them to be > sure > that they've installed everything correctly. > > But we're discussing a non-decent state already. If we could provide a > handful > of manual test scripts that let people check their conditions, we can isolate > the problem and convince them it's not our fault. >
I have to say I agree. In practice a lot of systems are very poorly configured to the point that functionality that the vendor specifically advertises does not work. I'm currently looking at a board where a glClear() followed by eglSwapBuffers() does not run above 52 fps on a 60hz display. This is clearly an issue outside Qt - I am able to demonstrate this with a sample that uses DRM, GBM and EGL directly. As long as Qt is in the equation there is always the suspicion that the cause lies with it. This is not the first time I have to show that some issue is not caused by Qt. I have also watched many of my colleagues go through contortions to convince customers that their setups are just broken or plain not fast enough - although of course sometimes it really is down to something within Qt. :) Even for those cases an independent "Qt Conformance Suite" would be useful. Maybe such tests could be incorporated into the module unit tests as a sort of precondition - if these tests don't work, then the module won't work properly either. -- Louai _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
