h2. OMAPVideo h3. Introduction The OMAPVideo module, located at "bsd/RiscOS/Sources/Video/HWSupport/OMAPVideo":http://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/Video/HWSupport/OMAPVideo/ in CVS, is a driver for the display subsystem of the OMAP 3 and 4 range of SoC's. It uses the GraphicsV API to expose the hardware's functionality to RISC OS, thus allowing RISC OS to use the hardware as a display device. The driver is far from complete, but implements most of the functionality supported by the current GraphicsV spec. h3. Current functionality & limitations * Supports all current GraphicsV reason codes, except: ** Only limited support for accelerated rectangle copy/fill operations - sources/destinations must be at least byte aligned, and only solid fills with limited ECF patterns are supported. ** GraphicsV_SelectHead currently isn't supported * Has limited support for running on devices with fixed, 'dumb' LCD panels * The driver has basic support for TV-out. Except for on Pandora and OMAP4, if a TV is detected on machine startup then the TV will be used as the main display instead of the DVI output. * VIDC-style hardware scrolling isn't supported, due to restrictions in the display hardware. In some situations it could be emulated via the use of extra overlays, but this probably isn't worth the hassle, especially since RISC OS will fall back to the hardware-accelerated rectangle copies if full hardware scrolling isn't available. h3. Known issues * 16bpp modes rely on using the gamma table to map from RISC OS's 5:5:5 16bpp pixel format to the OMAP's 5:6:5 format. However this results in a mode with only 4 blue bits instead of 5, so a proper solution (i.e. implementing the [[Extended Framebuffer Format Specification]]) is stil desireable. * In the old HAL-based driver, the DSI PLL would fail to lock if RISC OS was not loaded by U-Boot. No checks have been made to determine whether this problem also exists with the new driver. * Mouse pointer updates lag behind the rest of the screen by 1 frame. This is because the display controller updates its internal registers from the shadow registers at the start of the vsync period, during which time RISC OS is probably only just entering the interrupt handler and calling the pointer update code. A better approach may be to program the controller to generate an interrupt a few scanlines before vsync is due, and use that as RISC OS’s vsync interrupt. With the right timing this will also allow programs that use double buffering & vsync-timed buffer flips to operate as expected. * The driver may malfunction if given bad mode timings (e.g. requesting a pixel rate of 3.6kHz resulted in a division by zero error!) * TV-out will be R/B swapped in 16 & 24bpp modes. The only way to fix this is to add support for extra pixel formats to RISC OS (e.g. the [[Extended Framebuffer Format Specification]]) h3. Future improvements Most major improvements (YUV overlays, display scaling & rotation, etc.) will come as a result of finalising and implementing the [[Proposed GraphicsV enhancements]]. Other potential improvements, not dependent on the GraphicsV improvements, are as follows: * Improved hardware acceleration ** Optimising the code and/or converting to assembler may result in worthwhile gains for small render operations ** Right-to-left rectangle copy operations, which are quite slow, may be sped up by splitting the copy rectangle into non-overlapping vertical strips, or making use of the new DMA list functionality in the AM/DM37x DMA controller. * Implement the missing GraphicsV reason codes As part of the development of the driver and the extensions to GraphicsV, some other parts of RISC OS are likely to see improvement as well (e.g. improving MakeModes and the display manager) h3(#debugging). Debugging A debug version of the module can be built by adding @-options DEBUG=TRUE@ to the OMAPVideo line in the components file (BuildSys.Components.ROOL.OMAP3). At the moment the default method for debug output is to use HAL_DebugTX to output it all via the serial port - so unless you change it to something else you'll need a serial cable connected to another machine to capture the output. Once the debug option is enabled, an ordinary ROM recompile (Make ROM, Install ROM, Join ROM) is all that's needed to produce the new ROM image. h4. Debug commands The following * commands are available in debug builds of the module: * VideoRegs - produces a dump of the main hardware registers * TVMode <mode> <type> <testcard> - for playing with TV-out. ** <mode> should be 0 for NTSC, or 1 for PAL. ** <type> should be 0 for Composite, 1 for S-Video, or -1 to disable the output (Note that most boards only support S-Video) ** <testcard> should be 1 to display the video encoder's built in colour bars image, or 0 to display the graphics/video overlays. * TVRegs - produces a dump of the VENC registers * TVOut <mode> - 0 switches the desktop to DVI output, 1 to TV. You'll need to change screen mode after issuing the command for it to have an effect. * SDMARegs - produces a dump of the SDMA registers used for GraphicsV_Render acceleration h3(#mdf). MDF entries This list of MDF entries is primarily intended for users of 'old' OMAPs (revision 3 and below), which had rather tight restrictions on the range of values supported by the porch & sync timing registers. The restrictions meant that they were typically unable to recreate the standard VESA mode timings and instead had to rely on 'reduced blanking' modes (such as those listed below). Newer OMAPs (revision 3.1 and above) have less restrictive timing registers, and so are likely to work with standard MDFs - however owners of new OMAPs may still find use for some of the modes listed here (e.g. 1280x1024). Note that the OMAPVideo driver currently gives little indication to the user of what OMAP revision is in use, so some trial and error may be required! Some other notes: * Some of the standard modes listed below (e.g. 1280×720) exhibit timing issues on the beagleboard, where the screen is shifted down one scanline with the bottom scanline replicated at the top of the screen. I’ve seen this on two monitors and in both RISC OS and Linux, so I’m fairly certain it’s a hardware bug (JL) * The 1920x1080 modes aren't likely to work on many monitors due to their 30Hz (or lower) refresh rate. <pre> <code> file_format:1 monitor_title:Beagleboard modes DPMS_state:3 # 640 x 256 (70Hz) startmode mode_name: x_res:640 y_res:256 pixel_rate:25175 h_timings:92,24,22,640,22,0 v_timings:2,106,0,256,0,85 sync_pol:2 endmode # 640x480@60Hz reduced blanking VESA CVT 0.31M3-R startmode mode_name:640 x 480 x_res:640 y_res:480 pixel_rate:23500 h_timings:32,80,0,640,0,48 v_timings:4,7,0,480,0,3 sync_pol:3 endmode # 640 x 512 (55Hz) startmode mode_name: x_res:640 y_res:512 pixel_rate:32000 h_timings:76,88,96,640,96,28 v_timings:3,19,16,512,16,2 sync_pol:0 endmode # 800x600@60Hz reduced blanking VESA CVT 0.48M3-R startmode mode_name:800 x 600 x_res:800 y_res:600 pixel_rate:35500 h_timings:32,80,0,800,0,48 v_timings:4,11,0,600,0,3 sync_pol:3 endmode # 1024x768@60Hz reduced blanking VESA CVT 0.79M3-R startmode mode_name:1024 x 768 x_res:1024 y_res:768 pixel_rate:56000 h_timings:32,80,0,1024,0,48 v_timings:4,15,0,768,0,3 sync_pol:3 endmode # 1280x720@60Hz reduced blanking VESA CVT 0.79M3-R startmode mode_name:1280 x 720 x_res:1280 y_res:720 pixel_rate:64000 h_timings:32,80,0,1280,0,48 v_timings:5,13,0,720,0,3 sync_pol:3 endmode # 720x480@60Hz CEA-861 Format 3 startmode mode_name:720 x 480 x_res:720 y_res:480 pixel_rate:27027 h_timings:62,60,0,720,0,16 v_timings:6,30,0,480,0,9 sync_pol:3 endmode # 720x576@60Hz CEA-861 Format 18 startmode mode_name:720 x 576 x_res:720 y_res:576 pixel_rate:27000 h_timings:64,68,0,720,0,12 v_timings:5,39,0,576,0,5 sync_pol:3 endmode # 1280x720@50Hz CEA-861B Format 19 startmode mode_name:1280 x 720 x_res:1280 y_res:720 pixel_rate:74250 h_timings:40,220,0,1280,0,440 v_timings:5,5,0,720,0,20 sync_pol:3 endmode # 1280x720@60Hz CEA-861B Format 4 startmode mode_name:1280 x 720 x_res:1280 y_res:720 pixel_rate:74250 h_timings:40,220,0,1280,0,110 v_timings:5,5,0,720,0,20 sync_pol:3 endmode # 1920x1080@24Hz CEA-861B Format 32 startmode mode_name:1920 x 1080 x_res:1920 y_res:1080 pixel_rate:74250 h_timings:44,638,0,1920,0,148 v_timings:5,4,0,1080,0,36 sync_pol:3 endmode # 1920x1080@25Hz CEA-861B Format 33 startmode mode_name:1920 x 1080 x_res:1920 y_res:1080 pixel_rate:74250 h_timings:44,528,0,1920,0,148 v_timings:5,4,0,1080,0,36 sync_pol:3 endmode # 1920x1080@30Hz CEA-861B Format 34 startmode mode_name:1920 x 1080 x_res:1920 y_res:1080 pixel_rate:74250 h_timings:44,88,0,1920,0,148 v_timings:5,4,0,1080,0,36 sync_pol:3 endmode # 1280x1024@57Hz startmode mode_name:1280 x 1024 x_res:1280 y_res:1024 pixel_rate:86000 h_timings:32,80,0,1280,0,48 v_timings:5,13,0,1024,0,3 sync_pol:3 endmode # 1600x1000@45Hz startmode mode_name:1600 x 1000 x_res:1600 y_res:1000 pixel_rate:86000 h_timings:32,108,14,1600,0,98 v_timings:5,16,0,1000,0,0 sync_pol:3 endmode # 1024 x 600 (98Hz) startmode mode_name:TouchBook x_res:1024 y_res:600 pixel_rate:64000 h_timings:3,39,0,1024,0,3 v_timings:1,7,0,600,0,2 sync_pol:3 endmode </code> </pre>