Re: exynos-drm 1024x768 HDMI output

[Daniel Drake]

On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake dr...@endlessm.com wrote:
 What I feel we are missing here is an explanation for why the first
 row of pixels is treated differently from the rest. Every value that I
 tweak seems to have an effect on the first line (which was rendered
 OK) as well as all the others (which were bad). If it were just a
 matter of tweaking e.g. h_fsz then I would expect *all* rows of pixels
 to have been rendered badly in the first place.

 Nevertheless, I'm happy to continue throwing values at the variables
 if that is our best option... We need to find a way of making a change
 that effects the only first line, or all the lines except the first.

I have an idea, but my understanding of CRT timings isn't quite strong
enough to tell me exactly how to implement it. Maybe you can help
suggest what variables to tweak in order to try this experiment:

Lets just accept the fact that the first line of the output image is
rendered badly. Specifically, it has 257 black pixels added onto the
end of it. The following rows do not exhibit that problem.

To accept and ignore this oddity, I want to make the device start
outputting the image exactly 1024+257 pixels too early. i.e. I want
1281 junk pixels before the image starts.

Then, I want to adjust the timing parameters appropriately so that
those junk pixels do not appear on the display. I want those 1281 junk
pixels to be sent to the display during the horizontal scans that
happen before the top left visible pixel is clocked. I think I'm
saying: I want to adjust the field of view so that those 1281 junk
pixels are rendered inside the vertical back porch.

Does that make any sense?

Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exynos-drm 1024x768 HDMI output

[Daniel Drake]

On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake dr...@endlessm.com wrote:
 Lets just accept the fact that the first line of the output image is
 rendered badly. Specifically, it has 257 black pixels added onto the
 end of it. The following rows do not exhibit that problem.

 To accept and ignore this oddity, I want to make the device start
 outputting the image exactly 1024+257 pixels too early. i.e. I want
 1281 junk pixels before the image starts.

 Then, I want to adjust the timing parameters appropriately so that
 those junk pixels do not appear on the display. I want those 1281 junk
 pixels to be sent to the display during the horizontal scans that
 happen before the top left visible pixel is clocked. I think I'm
 saying: I want to adjust the field of view so that those 1281 junk
 pixels are rendered inside the vertical back porch.

Nearly got something working along these lines:

tg-vact_st -= 1
tg-vact_sz += 1

Now the 257 bad pixels start at the top left of my display (rather
than on the second row of visible pixels), and that causes the
annoying horizontal wrap that I wrote about in my first mail.
So add from earlier:
tg-hact_st -= 257
tg-hact_sz + 257

Now the displayed image looks good.

But looking closer, I am missing the first horizontal row of pixels,
and the rightmost vertical column of pixels.

Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exynos-drm 1024x768 HDMI output

[Sean Paul]

On Tue, Dec 3, 2013 at 5:07 PM, Daniel Drake dr...@endlessm.com wrote:
 Hi,

 Thanks a lot for this exynos-drm commit:

 commit 62747fe0ad5169a767987d9009e3398466555cde
 Author: Sean Paul seanp...@chromium.org
 Date:   Tue Jan 15 08:11:08 2013 -0500

 drm/exynos: hdmi: support extra resolutions using drm_display_mode timings

 As you probably know, many people had written off the Exynos4's
 capability to output to non-TV resolutions over HDMI. Now, with your
 patch, 640x480 works perfectly, and other resolutions are hopefully
 within reach.


Awesome, I'm glad it improved things :)

 I would like to get 1024x768 working on Exynos4412. I'm using a Sony
 TV which has an EDID that offers 1024x768 in its established timing
 bitmap - i.e. it supports 1024x768 via the standard/ancient VESA
 timings. I have tested the TV with other devices, it seems to work
 fine at this res.


I assume this is the 1024x768@60Hz mode in drm_edid.c?

ie:

hdisplay = 1024
hsync_start = 1048
hsync_end = 1184
htotal = 1344
vdisplay = 768
vsync_start = 771
vsync_end = 777
vtotal = 806

 However, on Exynos4412 with exynos-drm, running at this resolution is
 not quite right. The very first row of pixels is rendered perfectly,
 but all off the others are offset and wrapped. I'll try to explain
 with some ASCII art:

 A
 X
 B

 Imagine that is the complete first 3 rows of pixels shown on my display.
 The first row, with pixels A, is complete, and starts and finishes
 where it should do on the physical display.

 However, the second row on the display starts with a series of
 always-black pixels, this is the region marked X, which occupies 257
 pixels. Immediately after, the second row of pixels of the output
 image starts (B), then when it hits the end of the screen, it wraps
 around onto the next row of pixels on the screen. Then the third row
 of the image pixels starts (C) and so on.

 Sounds like a hsync issue, right? I have been playing with the
 register writes in hdmi_v14_mode_set() but I can't quite get a perfect
 output.

 Is there any documentation available for these registers? Why do we
 have to program the numbers twice (once in HDMI regs, once in timing
 generator regs)?


I don't have any documentation for the 4412, so I'm flying blind as well.


 Specifically, I have not yet found an explanation for why the first
 row gets rendered right, and I haven't found a way to reduce the size
 of region X, although I have figured out how to move it around:

 The standard timings for 1024x768 are:
 hdisplay=1024
 hsync_start=1048
 hsync_end=1185
 htotal=1344

 Using these numbers, exynos-drm writes:
 tg-hact_st = 320
 tg-hact_sz = 1024

 If I subtract and add 257 (the size of the black region X)  respectively, i.e.
 tg-hact_st = 63
 tg-hact_sz = 1288

 Then I get the following:

 X
 B
 C


Have you tried:

hact_st = 320
h_fsz += 257?

hact_st specifies where to start scanning out the buffer, so it's not
surprising that you're missing the first 257 pixels in this case.
Maybe bumping up the full size of the h_line will help?


Sean

 i.e. all rows of displayed output are now fine, except for the first.
 On the first row, the leftmost 257 pixels of output are no longer
 visible anywhere, the rest of them start in the wrong place (top left,
 rather than 257 pixels in), and the black region X is now positioned
 at the right hand side of the first row.

 That is the closest I have found so far.

 Any thoughts or tips much appreciated.

 Thanks
 Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html