Display

LCD screen

This is a 720p, 8-bits-per-channel LCD with a resistive touch-sensitive layer suitable for use with fingers as well as a high-precision passive stylus. Multi-touch detection is also possible to a limited degree. The market for small LCDs is largely driven by smartphones, making it prohibitively difficult to source a native landscape display. As a result, the Pyra uses a portrait display, with a dedicated video rotation chip interfacing with the CPU/GPU

Hardware:

• BOE BTL507212-W677L - 5" LCD Panel with 720(RGB)×1280 WXGA resolution
• Hirose FH26-39S-0.3SHW(05) - Display cable connector
• Also a LCD and a resisted touch-sensitive layer, of unknown provenance.

Tiler

The tiling and isometric lightweight engine for rotation (TILER) resides in the Memory Subsystem of the OMAP5 and Manages the virtual address, data, and byte-enable to match the requested 0-, 90-, 180-, or 270-degree orientation in a tiled 2D addressing space. Previously there was only an slow (because of Bugs) Driver Available, thus the decision above. Later a Community Member (Zmatt) wrote an new Driver, which performed perfectly.

The TILER is needed for rotation because the naive way of rotating a framebuffer (swapping X and Y coordinates) would give poor performance with modern DRAM, where accessing data from a different row of 8kB - which would be every few pixels in a simple rotated view - is significantly slower than accesses from the same row. Using "tiles" significantly improves this.

To use TILER in 2D mode from user-space, the generic DRM_IOCTL_MODE_CREATE_DUMB ioctl must be replaced with the OMAP-specific DRM_IOCTL_OMAP_GEM_NEW ioctl, with the OMAP_BO_TILED_32 or OMAP_BO_TILED_16 flag set depending on bpp. The stride must be a multiple 4096 bytes. Setting the rotation property of the plane should then use the tiled buffer for rotation. Legacy framebuffer code that accesses /dev/fb0 should be rotated automatically with the current TILER patches. tiler_rotate_shim can also perform the ioctl transformation to existing code, like the PowerVR drivers, using LD_PRELOAD.

Video Output

The Pyra has a digital video output supporting HDMI 1.4a, HDCP 1.4, and DVI 1.0 which can be used independently of and at higher resolutions than the built-in LCD. (Confirmation Needed)

It uses a 19-pin HDMI Type-D micro connector.

Hardware:

• TPD12S016RKTR - HDMI Companion Chip with I2C Level Shifting Buffer, 12-Channel ESD Protection, and Current-Limit Load Switch
• Molex 46765-2301 - HDMI Connector, Right-Angle Receptacle, Surface Mount, 0.40mm Pitch Micro
• DLP11SA900HL2L - Common Mode Chokes / Filters 90Ohm 20% 100MHz
  • 4x used on HDMI-DATA0 / 1 / 2 and HDMI-CLK lines.

Rotator (Not Used)

In an early design of the Pyra, a MIPI signal rotator by Solomon Systech chip was specified. It allows software to have direct access to the display in its physical orientation (landscape) instead of its native logical orientation (portrait). As noted above (under 'Tiler') Zmatt delivered a tiler driver that obviated the need for a discrete rotation chip.

Although it's possible to apply rotation in software, or by keeping the GPU powered up, this was designed to make porting games easier and quicker, as well as reducing GPU load. The rotator chip uses image compression internally due to memory constraints. This is lossy, but of sufficiently high quality as to be generally imperceptible. Sample images for comparison available here: [[1]]

However, the tiler is part of the SoC so powered up all of the time anyway while the system is on, and while the driver is running is hidden from the developer and just works. It doesn't use compression, so can provide theoretically improved clarity over the rotation chip too!

See also: GPU