Paulo Zanoni 7ead7ba3e6 testdisplay: don't enter the main loop if dump_info or test_all_modes
If calls inside update_display fail, the function returns and we don't
quit the program if dump_info or test_all_modes. So we enter the main
loop and keep waiting for user input, even on cases where we are not
supposed to require user input. To fix this, we move the check to
outside the update_display function.  As a side effect, we also do
cleanup instead of just exit(0) and we return 1 in case update_display
failed.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-09-15 19:38:21 +02:00
2011-09-12 20:39:45 +02:00
2011-02-09 10:19:51 +00:00
2011-09-13 17:20:12 +02:00
2011-06-08 12:16:23 +01:00
2011-09-13 11:43:06 +02:00
2011-09-15 19:38:14 +02:00

This is a collection of tools for development and testing of the Intel DRM
driver.  There are many macro-level test suites that get used against our
driver, including xtest, rendercheck, piglit, and oglconform, but failures
from those can be difficult to track down to kernel changes, and many require
complicated build procedures or specific testing environments to get useful
results.

Thus, intel-graphics-tools was a project I started to collect some low-level
tools I intended to build.

benchmarks/
	This should be a collection of useful microbenchmarks.  The hope is
	that people can use these to tune some pieces of DRM code in relevant
	ways.

	The benchmarks require KMS to be enabled.  When run with an X Server
	running, they must be run as root to avoid the authentication
	requirement.

tests/
	This is a set of automated tests to run against the DRM to validate
	changes.  Hopefully this can cover the relevant cases we need to
	worry about, including backwards compatibility.

	To run the tests, do "sudo make check" from this directory with
	KMS enabled.

tools/
	This is a collection of debugging tools that had previously been
	built with the 2D driver but not shipped.  Some distros were hacking
	up the 2D build to ship them.  Instead, here's a separate package for
	people debugging the driver.

	These tools generally must be run as root.

debugger/
	This tool is to be used to do shader debugging. It acts like a
	debug server accepting connections from debug clients such as
	mesa. The connections is made with unix domain sockets, and at some
	point it would be nice if this directory contained a library for
	initiating connections with debug clients..

	The debugger must be run as root: "sudo debugger/eudb"
Description
No description provided
Readme 18 MiB
Languages
C 95.5%
Yacc 2.5%
Makefile 0.5%
Shell 0.5%
Lex 0.3%
Other 0.6%