BetXen wrote:
I've finally discovered that there is a little shift to the left. When I make a window fullscreen, the left border is hidden. After inspection, the display area does not use the 12-13 rightmost pixels. Can you easily modify this or do you agree to share the vfs ?.
I made some minor adjustments to the source file that might improve the situation. Since it sounds like we were very close, those changes were fairly small increments.
I've attached the newly adjusted format (vfo file). Here the output of a VFC analysis of the resulting microcode and source file:
Code:
Select all
IR-HDTV_1920x1080_59.93rb.vfo:
Total lines per frame: 1111
Total pixels per line: 2080
Active lines per frame: 1080
Active pixels per line: 1920
Frames per second: 59.93
Fields per frame: 1
Swaps per frame: 1
Pixel clock: 138.491 MHz, period = 7.22068 nsec
Hardware pixel rounding: every 2 pixels
Line analysis:
Length: 2080 Pixels, 1 Lines, 15.019 usec; (line 0)
Frequency: 66.5822 KHz, period = 15.019 usec
Horizontal Sync: 32 Pixels, 231.062 nsec; (line 28)
Horizontal Back Porch: 80 Pixels, 577.655 nsec; (line 28)
Horizontal Active: 1920 Pixels, 13.8637 usec; (line 28)
Horizontal Front Porch: 48.0001 Pixels, 346.593 nsec; (line 28)
Field Information:
Field Duration: 2.31088e+06 Pixels, 1111 Lines, 16.6861 msec; (line 0)
Vertical Sync: 12480 Pixels, 6 Lines, 90.1141 usec; (line 0)
Vertical Sync Pulse: 12512 Pixels, 6.01538 Lines, 90.3452 usec; (line 0)
Vertical Back Porch: 45760 Pixels, 22 Lines, 330.418 usec; (line 6)
Vertical Active: 2.2464e+06 Pixels, 1080 Lines, 16.2205 msec; (line 28)
Vertical Front Porch: 6240 Pixels, 3 Lines, 45.0571 usec; (line 1108)
The VFC analysis puts the newer version even closer to horizontal vertical frequencies spec'd in your owner's manual:
-
66.587KHz and 59.93Hz - as spec'd by your HDTV owner's manual
-
66.582Khz and 59.93Hz
- the newly adjusted format attached to this post
-
66.780KHz and 59.93Hz - the first format we tried
Hopefully it'll help. Additional mode info beyond just the horizontal and vertical frequencies given by your manual (or the same model HDTV in front of me as a cause-and-effect test platform) would probably be the next step if we're still a little off.
I did run across another site that discusses HDTV modelines:
http://www.gentoo-wiki.info/HOWTO_Xorg_HDTV
You mentioned your laptop is running windows, perhaps one of the Linux liveCDs would allow to temporarily boot linux and some of the suggestions on the Gentoo Wiki.
If you'd like to try recalculating the values used in the source file, just remove the .txt extension (added only to allow attachment of the file) and copy the .vfs file into /usr/gfx/vfc/vfs (change the file permissions to read-only). Alternatively you could the file anywhere you like and give VFC an implicit path to the file when ever you call on it. Because I've been working on creating formats for a number of different graphics boards and resolutions, to minimize clutter in /usr/gfx/* I prefer to run VFC from within the same directory in my user account (that holds the source files I create) and implicitly call out the path to the VFC chip and board definition files:
Code:
Select all
# vfc -c chip=/usr/gfx/ucode/vfc/rules/voc1.def,board=/usr/gfx/ucode/vfc/rules/dg4.def -o IR-HDTV_1920x1080_59.93rb.vfo IR-HDTV_1920x1080_59.93rb.vfs
If the image is still shifted to the left, it's possible to adjust the horizontal position of the image by changing the modeline so the values for the horizontal front and back porch are increased or decreased (so that one becomes larger and the other an equal amount smaller). These diagrams provide a very basic illustration of how some of the timing values in a VFC source file affect the resulting display:
As you can see it isn't quite as simple as changing just the horizontal front and back porch. Changes should made to the overall modeline so all the all of the horizontal values remain properly balanced.
If the microcode attached above doesn't resolve the off-centered image, the source file and vfo microcode (attached to the end of this post) should shift the position of the image eight pixels to the right. This was done by changing the horizontal values in the modeline to increase the horizontal back porch (by eight pixels) and decreasing the horizontal front porch by an equal amount. Care was taken when making those changes so that HorizontalSync or TotalPixelsPerLine (called 'Total clocks per line' in the second diagram) *weren't also changed. Shifting the position of the image eight pixels to the right changes the cvt-generated modeline from:
Code:
Select all
Modeline "1920x1080_59.93_rb" 138.25 1920 1968 2000 2080 1080 1083 1088 1111 +HSync -Vsync
to:
Code:
Select all
Modeline "1920x1080_59.93_right" 138.25 1920 1960 1992 2080 1080 1083 1088 1111 +HSync -Vsync
If the change works as expected, but the image doesn't move enough to the right, comparing the two modelines and the attached source files give some indication where changes were made.
On the odd chance you aren't already familiar with how VFC source file data is extracted from a modeline, here's my spin.
A modeline contains four horizontal (pixel) fields, and four vertical (line) fields. Looking at the modeline posted just above
Code:
Select all
Modeline "1920x1080_59.93_rb" 138.25 1920 1960 1992 2080 1080 1083 1088 1111 +HSync -Vsync
if we substitute the field names for the numerical values, the line reads:
Code:
Select all
Modeline "1920x1080_59,93.rb" PixelCk HDisp HSyncStart HSyncEnd HTotal VDisp VSyncStart VSyncEnd VTotal +HSync -VSync
which we can use with the info below to calculate VFC source file data.
From the horizontal portition of the modeline
(HDisp HSyncStart HSyncEnd HTotal):
TotalPixelsPerLine = HTotal
HorizontalBackPorch = HTotal minus HSyncEnd
HorizontalSync = HSyncEnd minus HSyncStart
HorizontalFrontPorch = HSyncStart minus HDisp
ActivePixelsPerLine = HDisp
From the vertical portion of the modeline
(VDisp VSyncStart VSyncEnd VTotal):
TotalLinesPerFrame = VTotal
VerticalBackporch = (VTotal minus VSyncEnd) minus 2 (see my note below in rule 2 of "editing vertical timing" for more on the 'minus 2')
VerticalSync = VSyncEnd minus VSyncStart
VerticalFrontPorch = VSyncStart minus VDisp
ActiveLinesPerFrame = VDisp
In most cases, FieldsPerFrame will equal 1, and FramesPerSecond will be the target refresh rate.
A few of the not always so obvious ground rules to keep in mind when manually editing modelines:
Editing modeline horizontal timing values to shift the image left or right:
1).
The rule of eights. All of the horizontal values in the modeline, HDisp, HSyncStart, HSyncEnd, and HTotal (1920, 1960, 1992 and 2080 in the shifted modeline above), are expressed as multiples of eight, and that each subsequent value in the string is numerically higher than the previous.
2).
When added together, the values used in the resulting source file (vfs) for ActivePixelsPerLine, HorizontalFrontPorch, HorizontalSync, and HorizontalBackPorch equal the TotalPixelsPerLine. In the shifted modeline (quoted above) those values are 1920 pixels, 40 pixels, 32 pixels and 88 pixels, which equal 2080 pixels (the TotalPixelsPerLine value). Note that values used for ActivePixelsPerLine, HorizontalFrontPorch, HorizontalSync, HorizontalBackPorch and TotalPixelsPerLine must also follow the rule of eights.
3).
To shift an off-centered the image to the right subtract equal amounts (in multiples of eight) from both HSyncEnd and HSyncStart; add equal amounts (again in factors of eight) to shift the image to the left.
When manually editing modeline vertical timing values to shift the image up or down:
1).
Vertical values in a modeline need not comply with the rule of eights.
2).
When added together the vertical (line) values used in the source file, ActiveLinesPerFrame, VerticalFrontPorch,VerticalSync, and VerticalBackPorch should equal TotalLinesPerFrame. Note that because of (undocumented) internal calculations performed by VFC, a "shorten your format" error may appear when VerticalFrontPorch,VerticalSync, VerticalBackPorch and TotalLinesPerFrame are calculated using industry standard methodology. There are a number of methods to correct the format length error state. One method of "shorten your format" error correction is to increase the TotalLinesPerFrame value inserted into the source file. Because the TotalLinesPerFrame value is derived unchanged from the modeline, if the TotalLinesPerFrame value is changed when inserted into the source file, all of the source file values calculated from the vertical portion of the modeline - VerticalSync, VerticalBackPorch and VerticalFrontPorch would no longer equal the changed TotalLinesPerFrame value. The result can be an unstable microcode format. My preference for dealing with "shorten your format" error is a marginally lesser evil, subtract 2 from the VerticalBackPorch value before inserting into the source file, but after checking that VerticalSync, VerticalBackPorch and VerticalFrontPorch equal TotalLinesPerFrame.
3).
If the displayed image is too high, subtract (small!) equal amounts from the VSyncEnd and VSyncStart values in the modeline; if the image is too low, add small equal amounts from VSyncEnd and VSyncStart. Note: the vertical (line) values in the modeline are VDisp, VSyncStart, VSyncEnd, and VTotal. Using the same shifted modeline as an example, those values are shown as 1080, 1083, 1088, and 1111. In a similar fashion to the horizontal portion of the modeline, each of the subsequent values in the vertical value string must be numerically higher than the last.
When manually editing a modeline to resolve image size issues:
1).
If the displayed image is too narrow, subtract very small increments form HTotal, if too wide add very small increments to HTotal. There is a limited range of adjustment to HTotal available. Changing HTotal directly effects blanking, and HTotal cannot have a numerical value smaller than any of the preceding horizontal values (see rule 1 in the 'changes to horizontal timing' section).
2).
If the displayed image is too short, subtract very small increments form VTotal, if too tall add very small increments to VTotal. There is a limited adjustment available, VTotal cannot have a numerical value smaller than any of the preceding vertical values (see rule 3 in the 'editing vertical timing values' section).
I've attached the changed microcode(as IR-HDTV_1920x1080_59.93
right
.vfo. Because the horizontal image adjustment was a shot in the dark I'd recommend trying the un-shifted version (IR-HDTV_1920x1080_59.93
rb
.vfo *first*.
Postscript:
yes! this was an early Christmas gift from Jesse Newcomb! the maker for jumboprawn O2 hehe he really is great guy, he even gave me just recently a two spare of the LCD and arrived last Friday here but didn't have the time yet to mount it maybe later?
