Meego Wiki
Views

Quality/TestSuite/Framebuffer Test Specification

From MeeGo wiki
< Quality | TestSuite(Difference between revisions)
Jump to: navigation, search
(Running test cases)
(Troubleshooting)
 
(6 intermediate revisions not shown)
Line 38: Line 38:
== Supported Devices and SW ==
== Supported Devices and SW ==
-
* List of supported (+ not supported devices, if needed for clarity)
+
The framebuffer tests should work with almost anything, that supports a framebuffer device. Given that the configuration is up to date and pointing to right framebuffer and backlight devices and limit values. The asset has been test to work with at least following Linux kernel versions: 2.6.28, 2.6.31 and 2.6.32.
-
** Versions
+
-
** Info about what is known to work
+
-
 
+
-
Supported
+
-
* N900
+
-
* nCDK Medfield (starting from version x.z)
+
-
 
+
-
Not supported
+
-
* Netbook
+
-
 
+
-
* Info about supported MeeGo releases (?)
+
== Test Cases ==
== Test Cases ==
Line 89: Line 78:
== Hardware setup and test environment ==
== Hardware setup and test environment ==
 +
 +
The device, be it a notebook or N900 or Ubuntu, needs to have following packages installed:
 +
 +
* libbltscommon1
 +
* blts-fbdev-tests-config (or something that provides this)
 +
*: blts-fbdev-tests-config-example provides this, but does not work as such. '''You will need to edit the configuration file.'''
 +
 +
It is recommended that you configure your device not to automatically dim the screen when it becomes idle. This is because of the backlight tests, which will fail if something else changes the backlight while the tests are running.
== Building packages ==
== Building packages ==
Line 124: Line 121:
== Test result analysis ==
== Test result analysis ==
-
* Where are the results?
+
Results are typically printed into stdout and stderr. If -axml or -xml parameter is used, then the result will be printed as xml into the pointed file.
-
* Log files?
+
 
 +
Log file is typically written into /var/log/tests/ dir. Default log file name is blts-fbdev-tests.txt. This can be tuned with -l command line parameter.
== Troubleshooting ==
== Troubleshooting ==
-
* What to do if something fails?
+
If something fails, then first thing to do is to check the configuration. It's likely that in case of backlight, the backlight path is incorrect, or the minimum and maximum lights in configuration are out of range.
-
* What to check first?
+
 
 +
If a framebuffer device fails to map into memory, it might be due to wrong used device. Check with other frame buffer devices. List of devices is easiest to get with "ls /dev/fb*".
 +
 
 +
If none of these work, file a bug with the test case logs. It is preferred that the test case is run with -vv command line parameter in this case to get as much information as possible.
== Configuration file examples ==
== Configuration file examples ==
Line 244: Line 245:
== Architecture ==
== Architecture ==
-
The test asset (blts-fbdev-tests) is built directly on top of the Linux kernel. Backlight tests use sysfs to test the functionality. The asset has been test to work with at least following Linux kernel versions: 2.6.28, 2.6.31 and 2.6.32.
+
The test asset (blts-fbdev-tests) is built directly on top of the Linux kernel. Backlight tests use sysfs to test the functionality.
= Known issues =
= Known issues =

Latest revision as of 14:25, 20 December 2010

Contents

Introduction

Overview

The framebuffer device is a device-independent interface for reading and writing raw data to the video memory. Uses of the device typically include things like text consoles, graphical boot progress indicators and so on. It is also possible to use the framebuffer device as a X11 window system display device.

The framebuffer device is typically used by memory-mapping the device file. The fbdev kernel driver translates any operations to the device-specific display driver. The blts-fbdev-tests asset tests the functionality and performance of this subsystem.

The display backlight driver registers a sysfs based directory upon device activation. This is how the blts-fbdev-tests asset uses the backlight system to change display brightness.

Getting the Latest Version

Sources can be found in gitorius:

To clone a copy of the repository, see guides in:

Latest binary release is planned to be available via MeeGo OBS, see MeeGo Build Infrastructure for more information.

Support & Contacts

Documentation

Check the package README file (essentially contains same info as this page):

Licensing

  • Please see the file called COPYING

Supported Devices and SW

The framebuffer tests should work with almost anything, that supports a framebuffer device. Given that the configuration is up to date and pointing to right framebuffer and backlight devices and limit values. The asset has been test to work with at least following Linux kernel versions: 2.6.28, 2.6.31 and 2.6.32.

Test Cases

  1. Core-Framebuffer read frame buffer information with ioctl
    Reads variant and fixed screen information from frame buffer device(s).
  2. Core-Framebuffer set blanking levels
    Tests each of the blanking levels on all configured framebuffer devices.
  3. Core-Framebuffer 1-pixel uncached read
    Performance test of reading visible framebuffer pixel by pixel. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer into the log and standard output. Done for all configured framebuffer devices.
  4. Core-Framebuffer 1-pixel uncached write
    Performance test of writing into visible framebuffer pixel by pixel. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer device into the log and standard output. Done for all configured framebuffer devices.
  5. Core-Framebuffer 1-pixel uncached modify
    Performance test of both reading and vriting into visible framebuffer pixel by pixel. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer into the log and and stadard output. Done for all configured framebuffer devices.
  6. Core-Framebuffer fullscreen buffer read
    Performance test of reading a fullscreen framebuffer at once. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer into the log and standard output. Done for all configured devices.
  7. Core-Framebuffer fullscreen buffer write
    Performance test of writing into a fullscreen framebuffer at once. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer into the log and standard output. Done for all configured devices.
  8. Core-Framebuffer fullscreen buffer modify
    Performance test of both reading and writing into a fullscreen framebuffer at once. Uses rusage to estimate the CPU usage %. Prints information about the test and framebuffer into the log and standard output. Done for all configured devices.
  9. Core-Backlight verify backlight levels
    Verify backlight system's backlight level limits against configured limits. Tests the limit values, by using the actual limit and going one step over it.
  10. Core-Backlight linear backlight level changes
    Linearly goes through all values between configured minimum and maximum values, by first going from min -> max and then from max -> min. NOTE: This case can timeout if the min and max are very big. The case sleeps for two seconds between each step.
  11. Core-Backlight logarithmic backlight level changes
    Goes through all values between configured minimum and maximum values, by going from min -> max. The values are increased by following pattern: (max light / log10 (max light)) * log10 (between min and max). NOTE: This case can timeout if the min and max are very big. The case sleeps for two seconds between each step.

Coverage

blts-fbdev-tests (0.0.8) is testing Linux kernel framebuffer ioctls and backlight subsystem via sysfs. The test driver accesses /dev/fbX directly with open(), close(), ioctl() and m(un)map(). Sysfs is accessed directly via fopen(), fprintf(), fscanf() and fclose().

Hardware coverage is device-dependent, but includes at least the data path diplay device - video memory - system memory.

Current framebuffer coverage matrix:

Running the Tests

Hardware setup and test environment

The device, be it a notebook or N900 or Ubuntu, needs to have following packages installed:

  • libbltscommon1
  • blts-fbdev-tests-config (or something that provides this)
    blts-fbdev-tests-config-example provides this, but does not work as such. You will need to edit the configuration file.

It is recommended that you configure your device not to automatically dim the screen when it becomes idle. This is because of the backlight tests, which will fail if something else changes the backlight while the tests are running.

Building packages

The build environment must have the following packages installed:

The source package includes the pack.sh script, which is used for building RPM and Debian packages and source tar packages. To build an RPM package with the script, execute this command in the top level source directory of asset:

./pack.sh -r

To get help about the packaging script, execute

./pack.sh -h

The asset can also be built manually by executing:

./autogen.sh
./configure
make

Running test cases

The tests can be run with

$ blts-fbdev-tests

Command line arguments:

USAGE: blts-fbdev-tests [-l mylog.txt] [-e test1,test2...] [-en "my test"] [-s] [-?] [-v] [-C variation_config.cnf] [-auto|-v|-vv] [-xml|-axml filename] 
 -l: Used log file, default blts-fbdev-log.txt
 -e: Execute single or multiple selected tests, for example -e 1,4,5.
 -en: Execute test by name, for example -en "My test X"
 -s: Show list of all tests
 -C: Used parameter configuration file
 -?: This message
 -xml, -axml: Create result XML. -axml appends results to an existing XML file.
 -auto: Silent logging for test automation. Only the results are printed to stdout.
 -v: Verbose logging (default)
 -vv: Even more verbose logging

Test cases must be run with root priviliges.

Test result analysis

Results are typically printed into stdout and stderr. If -axml or -xml parameter is used, then the result will be printed as xml into the pointed file.

Log file is typically written into /var/log/tests/ dir. Default log file name is blts-fbdev-tests.txt. This can be tuned with -l command line parameter.

Troubleshooting

If something fails, then first thing to do is to check the configuration. It's likely that in case of backlight, the backlight path is incorrect, or the minimum and maximum lights in configuration are out of range.

If a framebuffer device fails to map into memory, it might be due to wrong used device. Check with other frame buffer devices. List of devices is easiest to get with "ls /dev/fb*".

If none of these work, file a bug with the test case logs. It is preferred that the test case is run with -vv command line parameter in this case to get as much information as possible.

Configuration file examples

To run test case with variable data you need to specify where configuration file is located. You can edit the configuration file yourself.

To run "Core-Backlight linear backlight level changes" case you can use:

$ blts-fbdev-tests -l /var/log/tests/Core-Backlight_linear_backlight_level_changes.log -en "Core-Backlight linear backlight level changes" -C /etc/blts/blts-fbdev-tests.cnf

Example of a configuration file (blts-fbdev-tests.cnf):

# Parameter configuration for blts-fbdev

# Valid framebuffer devices for HW.
[parameter]
	name framebuffer_device
	const "/dev/fb0"
[end_parameter]

# Valid backlight subsystem for HW
[parameter]
	name backlight_subsystem
	const "/sys/class/backlight/<enter_valid_sysfs_entry_here>"
[end_parameter]

# Minimum light level
[parameter]
	name minimum_level
	const 0
[end_parameter]

# Maximum light level
[parameter]
	name maximum_level
	const 255
[end_parameter]

# Minimum light level for logarithmic tests
[parameter]
	name logarithmic_min
	const 1
[end_parameter]

# Maximum light level for logarithmic tests
[parameter]
	name logarithmic_max
	const 255
[end_parameter]

# Test case configurations
[test]
	name "Core-Framebuffer read frame buffer information with ioctl"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer set blanking levels"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer 1-pixel uncached read"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer 1-pixel uncached write"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer 1-pixel uncached modify"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer fullscreen buffer read"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer fullscreen buffer write"
	params framebuffer_device
[end_test]

[test]
	name "Core-Framebuffer fullscreen buffer modify"
	params framebuffer_device
[end_test]

[test]
	name "Core-Backlight verify backlight levels"
	params backlight_subsystem minimum_level maximum_level
[end_test]

[test]
	name "Core-Backlight linear backlight level changes"
	params backlight_subsystem minimum_level maximum_level
[end_test]

[test]
	name "Core-Backlight logarithmic backlight level changes"
	params backlight_subsystem logarithmic_min logarithmic_max
[end_test]

Replace "/sys/class/backlight/<enter_valid_sysfs_entry_here>" with a valid path to the backlight system your device registers.

Module Design and Architecture

Architecture

The test asset (blts-fbdev-tests) is built directly on top of the Linux kernel. Backlight tests use sysfs to test the functionality.

Known issues

  • The backlight cases take a lot of time. These cases try to go through all defined backlight levels. Might be better to define amount of steps or something similar into configuration.
  • Check for open bugs: MeeGo Core Test Suite Bugs

Future improvements

The test driver should attemp to access the edges of the reported display area. Advanced improvements might include things like external camera use to determine whether the output from the test driver matches the actual on-screen results, aka test automation.

References

Personal tools