How do I change the timing file in /sys/devices/platform/omapdss/display0/timings ? I can not edit the file directly. How do I configure my boot scripts to
update the timings file on startup??
See below for details:
When the system is up, cat the following file: /sys/devices/platform/omapdss/display0/timings
The output is in the format pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw
Field | Unit | Description |
- | - | - |
pixclock | picoseconds | The duration of one pixel |
xres | pixels | Width of visible area (typically width of framebuffer) |
hfp | pixels | Horizontal front porch |
hbp | pixels | Horizontal back porch |
hsw | pixels | Horizontal sync width |
yres | rows | Height of visible area (typically height of framebuffer) |
vfp | rows | Vertical front porch |
vbp | rows | Vertical back porch |
vsw | rows | Vertical sync “width” (in rows) |
Details are available in the kernel sources, in Documentation/arm/OMAP/DSS.
Getting an image at all
As root, experiment with the values in timings. If your monitor can display the current horizontal and vertical frequency, study how they change.
Try out various pixclock values first, until you have a stable image on the screen. Then tweak the porches and sync widths until you’re satisfied with the size and placement of the image.
Fixing the right border
Some display lines may look strange. This is because the digital data bus we’re sampling doesn’t revert to black after each display line, so the rightmost pixel will “carry over” through the horizontal blanking period and into the beginning of the next line. Some monitors calibrate themselves during horizontal blanking, so whatever voltage they see during that time will be considered black in the upcoming line. Try to move the mouse cursor along the right end of the screen and see if you get this strange phenomenon.
If so, you can fix it easily by adding a black pixel to the right of each video line:
The timings file describes the dimensions of the actual video signal. The framebuffer, i.e. the chunk of memory where all the pixels are stored, is described using something called an overlay (/sys/devices/platform/omapdss/overlay0/...).
This means that we can modify the dimensions of the video signal, extending it somewhat to the right, without modifying the size of the framebuffer. The width has to be a multiple of eight pixels, so we have to go from e.g. 1024 to 1032.
This fixes the VGA signal, but unfortunately the DVI-D picture now has a small black border along the right edge. I don’t know of a way to fix this properly, but most monitors allow the user to resize and move the image around freely, so you might be able to scroll those black pixels off the screen.
Examples
My monitor works with the following parameters:
Boot mode | Modified timings |
- | - |
1024x768-16@60|60000,1032/120/128/32,768/3/15/4|
800x600-16@75|50000,808/34/198/20,600/23/37/6|
I have configured my boot scripts to update the timings file automatically one second after x.org has started.
A better way?
Writing to timings directly is a kludge, and it’s probably possible to get x.org to use VGA-compatible timings in the first place. This will definitely be an issue if you want to be able to switch between different video modes during regular use. I’m using a fixed resolution, so I haven’t looked into this yet, but it’s probably just a matter of putting the right thing in your xorg.conf.