From d796c9dd933ab96ec83b9a634feedd5d32e1ba3f Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Tue, 8 Nov 2011 12:31:36 -0600 Subject: Test conversion to TQt3 from Qt3 8c6fc1f8e35fd264dd01c582ca5e7549b32ab731 --- doc/html/emb-accel.html | 121 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 doc/html/emb-accel.html (limited to 'doc/html/emb-accel.html') diff --git a/doc/html/emb-accel.html b/doc/html/emb-accel.html new file mode 100644 index 000000000..de50e83c5 --- /dev/null +++ b/doc/html/emb-accel.html @@ -0,0 +1,121 @@ + + + + + +Adding an accelerated graphics driver to TQt/Embedded + + + + + + + +

Adding an accelerated graphics driver to TQt/Embedded

+ + + +

TQt/Embedded has the capacity to make use of hardware accelerators. +To use a hardware accelerator for a PCI or AGP driver, you must +perform the following steps: +

+Define an accelerated descendant of TQLinuxFbScreen. +
This should implement TQVoodooScreen::connect() to map its +registers. Use qt_probe_bus to get a pointer to the PCI config +space. This is where you should check that you're being pointed to the +right device (using the PCI device/manufacturer ID information). Then +use PCI config space to locate your device's accelerator registers in +physical memory and mmap the appropriate region from /dev/mem. +There is no need to map the framebuffer, TQLinuxFbScreen will do +this for you. Return FALSE if a problem occurs at any point. TQVoodooScreen::initDevice() will be called only by the TQWS server and +is guaranteed to be called before any drawing is done (and so is a +good place to set registers to known states). connect() will be called +by every connecting client. +
+Define an accelerated descendant of TQGfxRaster. +
This is where the actual drawing code goes. Anything not implemented +in hardware can be passed back to TQGfxRaster to do in software. Use +the optype variable to make sure that accelerated and unaccelerated +operations are synchronised (if you start drawing via software into an +area where the hardware accelerator is still drawing then your drawing +operations will appear to be in the wrong order). optype is stored in +shared memory and is set to 0 by unaccelerated operations; accelerated +operations should set it to 1. When a software graphics operation is +requested and optype is 1, TQGfxRaster::sync() is called; you should +provide your own implementation of this that waits for the graphics +engine to go idle. lastop is also available for optimisation and is +stored in the shared space: this will not be set by the software-only +TQGfx and can be used to store the type of your last operation (e.g. +drawing a rectangle) so that part of the setup for the next operation +can be avoided when many of the same operations are performed in +sequence. +
All drawing operations should be protected via a TQWSDisplay::grab() +before any registers, lastop or optype are accessed, and ungrabbed() at the end. This prevents two applications trying to +access the accelerator at once and possibly locking up the machine. +It's possible that your source data is not on the graphics card so you +should check in such cases and fall back to software if necessary. +Note that TQGfxRaster supports some features not directly supported +by TQPainter (for instance, alpha channels in 32-bit data and +stretchBlt's). These features are used by TQt; stretchBlt speeds up TQPixmap::xForm() and drawPixmap() into a transformed TQPainter, +alpha channel acceleration is supported for 32-bit pixmaps. +
+If you wish, define an accelerated descendant of TQScreenCursor. restoreUnder(), saveUnder(), drawCursor() and draw() should +be defined as null operations. Implement set(), move(), show() and hide(). 4KB is left for your cursor at the end of the +visible part of the framebuffer (i.e. at (width*height*depth)/8 ) +
+Implement initCursor() and createGfx() in your TQScreen +descendant. Implement useOffscreen() and return TRUE if you can +make use of offscreen graphics memory. +
+Implement a small function qt_get_screen_mychip(), which simply +returns a new TQMychipScreen +
+Add your driver to the DriverTable table in qgfxraster_qws.cpp, +e.g. +
```
+{ "MyChip", qt_get_screen_mychip,1 },
+
```
+ +
The first parameter is the name used with TQWS_DISPLAY to request your +accelerated driver. +
+To run with your new driver, +
```
+export TQWS_DISPLAY=MyChip 
+
```
+ +(optionally MyChip:/dev/fb<n> to request a different Linux +framebuffer than /dev/fb0), then run the program +

If your driver is not PCI or AGP you'll need to inherit TQScreen +instead of TQLinuxFbScreen and implement similar functionality to TQLinuxFbScreen, but otherwise the process should be similar. The most +complete example driver is qgfxmach64_qws.cpp; qgfxvoodoo_qws.cpp may provide a smaller and easier-to-understand +driver. +

+ +

Trademarks +

TQt 3.3.8

+ -- cgit v1.2.1