I'm fine with libsoup as well, I'll check it out and probably move all of the code over to using that instead. On Tue, 2016-11-15 at 12:44 +0100, Tomeu Vizoso wrote: > On 11 November 2016 at 18:53, Lyude Paul <lyude@xxxxxxxxxx> wrote: > > > > Alright, quick question: should we be going with your branch then > > or > > mine? > > I'm not going to be able to work on this in the short term, so I > think > it's up to you. > > Wonder if there are more opinions regarding xmlrpc vs. libsoup. I > liked it mostly because we already depend on glib. > > > > > On Wed, 2016-11-09 at 16:09 +0100, Tomeu Vizoso wrote: > > > > > > Hi Lyude, > > > > > > I think this looks very good. > > > > > > On 8 November 2016 at 01:05, Lyude <lyude@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > - While writing this patch series, I found that quite a few of > > > > the > > > > RPC calls > > > > for chameleond don't work as expected. For instance, I have > > > > had > > > > absolutely > > > > no luck getting CRCs from any of the display types that the > > > > chamelium > > > > supports. > > > > > > When I looked at this a few months ago, frame CRCs were working > > > just > > > fine. I was using libsoup, so maybe there's some problem with the > > > unpacking of the checksum? > > > > I'm pretty sure it's on the chameleond side of things. Using the > > test > > server application in chameleond's source shows the same issue. > > And what's the problem? You always get CRCs with a value of zero? I > only tried with HDMI, but IIRC I got to a point where > kms_universal_plane passed. The issue is I don't get CRCs, period :(. It looks like somewhere down the line chameleond is throwing a big fit whenever I try to get them: Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> p.Plug(1) >>> p.ComputePixelChecksum(1, 0, 0, 1920, 1080) Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib64/python2.7/xmlrpclib.py", line 1493, in parse_response return u.close() File "/usr/lib64/python2.7/xmlrpclib.py", line 800, in close raise Fault(**self._stack[0]) Fault: <Fault 1: "<type 'exceptions.OSError'>:[Errno 8] Exec format error"> >>> p.ComputePixelChecksum(1, 0, 0, 1920, 1080) Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib64/python2.7/xmlrpclib.py", line 1493, in parse_response return u.close() File "/usr/lib64/python2.7/xmlrpclib.py", line 800, in close raise Fault(**self._stack[0]) Fault: <Fault 1: "<type 'exceptions.OSError'>:[Errno 8] Exec format error"> Haven't had much luck with any of the other ports either > > Regards, > > Tomeu > > > > > > > > > > > > > > > > > > This isn't a huge deal though, since we usually just use the > > > > native CRC read back on the GPU anyway. > > > > > > I'm not completely sure what you mean by that, but not all > > > graphic > > > pipelines are able to provide frame CRCs so I think this > > > Chamelium > > > work will be very useful when running tests that do check frame > > > CRCs. > > I wasn't aware of that, thanks for letting me know > > > > > > > > > > > Regards, > > > > > > Tomeu > > > > > > > > > > > > > > > > > > > - Among other things that are broken with the chameleon, video > > > > signal > > > > detection for DisplayPort is one of them. After the first > > > > plug/unplug cycle, > > > > the DisplayPort receiver gets stuck and gives the wrong > > > > results > > > > for > > > > WaitForInputStable. Luckily I've already got a fix I'll be > > > > submitting to the > > > > ChromeOS guys when I get around to setting up their homebrew > > > > git > > > > tools: > > > > > > > > https://github.com/Lyude/chameleond/tree/wip/chameleon- > > > > fixe > > > > s > > > > > > > > For now, expect the dp-display tests to fail without those > > > > patches. > > > > > > > > Lyude (4): > > > > igt_aux: Add igt_skip_without_suspend_support() > > > > igt_aux: Add igt_set_autoresume_delay() > > > > igt_aux: Add some list helpers from wayland > > > > Add support for hotplug testing with the Chamelium > > > > > > > > configure.ac | 13 + > > > > lib/Makefile.am | 10 +- > > > > lib/igt.h | 1 + > > > > lib/igt_aux.c | 94 ++++++++ > > > > lib/igt_aux.h | 41 ++++ > > > > lib/igt_chamelium.c | 628 > > > > +++++++++++++++++++++++++++++++++++++++++++++++++ > > > > lib/igt_chamelium.h | 77 ++++++ > > > > lib/igt_kms.c | 107 +++++++++ > > > > lib/igt_kms.h | 13 +- > > > > scripts/run-tests.sh | 4 +- > > > > tests/Makefile.am | 5 +- > > > > tests/Makefile.sources | 1 + > > > > tests/chamelium.c | 549 > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > 13 files changed, 1538 insertions(+), 5 deletions(-) > > > > create mode 100644 lib/igt_chamelium.c > > > > create mode 100644 lib/igt_chamelium.h > > > > create mode 100644 tests/chamelium.c > > > > > > > > -- > > > > 2.7.4 > > > > > > > > _______________________________________________ > > > > Intel-gfx mailing list > > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > > Cheers, > > Lyude -- Cheers, Lyude _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
