[PATCH 2/6] compositor-drm: Allow instant start of repaint loop.
mario.kleiner.de at gmail.com
Thu Apr 9 23:45:24 PDT 2015
On 04/08/2015 07:49 AM, Daniel Stone wrote:
> Hi Mario,
> On Wednesday, April 8, 2015, Mario Kleiner <mario.kleiner.de at gmail.com
> <mailto:mario.kleiner.de at gmail.com>> wrote:
> It should be fine, i was involved in this stuff for lots of XOrg
> DRI2/DRI3 work, but i also tested it on single display and
> dual-display for each of the two outputs and for both outputs
> simultaneously and different refresh rates, resolutions etc. --
> hence my other patches in the series fixing fullscreen/modesetting
> problems etc. i found when trying to do the multi-display timing testing
> Out of interest, are these tests available somewhere?
they are not standalone tests. I just manually ran various demos and
tests from my toolkit, checking if they roughly behave as expected. The
software is Psychtoolbox-3 (http://psychtoolbox.org), a popular MIT
licensed open-source toolbox to extend GNU/Octave and Matlab with
functionality needed for neuro-science/medical research. Think of it as
something like SDL but optimized for the needs of brain research. So all
tests are written as scripts for execution within Octave, or in case of
the compiled C plugins, as part of the toolkits builtin startup and
runtime consistency checks. The X11/GLX variant of the toolkit is
available on Debian/Ubuntu via apt-get octave-psychtoolbox-3, the latest
versions from neuro.debian.net ppa. However, I just started implementing
an experimental Wayland backend at the beginning of this year and this
is not yet available via Debian, only as a compile time option when
building it from source, with dependencies on libwaffle which is not
bundled with Debian, so getting it up on Wayland isn't exactly pain free
atm. I could step you through the procedure if you wanted, but it's
probably more easy to wait a bit more for the wayland backends build and
installation procedure to mature before some of this could serve as a
test case or actual test. The goal is for the wayland variant to match
or exceed the x11 variant in functionality and performance. Btw.,
running the x11 variant on XWayland instead of on a native X-Server is a
good method to crash or hang the toolkit, XWayland, or Weston ;)
> If you're going to respin this patch, you could take care
> of that whitespace issue also(*).
> What are actually the policies for indentation? I spent almost more
> time fighting my text editor for indentation than writing the code.
> The files use tabs instead of regular spaces for indenting like most
> other projects? Maybe i have my tab-width wrong and therefore
> struggle to get it right?
> Just like the kernel - hard tabs for alignment, tab width of 8.
Thanks! What a difference that tab width of 8 made, no more fighting
with the editor :)
More information about the wayland-devel