On Wed, Dec 4, 2013 at 12:14 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > I assume this is the "1024x768@60Hz" mode in drm_edid.c? > > hdisplay = 1024 > hsync_start = 1048 > hsync_end = 1184 > htotal = 1344 > vdisplay = 768 > vsync_start = 771 > vsync_end = 777 > vtotal = 806 That's the one. > I don't have any documentation for the 4412, so I'm flying blind as well. What about documentation for exynos5, which runs from the same driver? >> 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: >> >> AAAAAAAAAAAAAAAAAAAAAAAAXXXXXXXXX >> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB >> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC > > 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? If I do: hact_st = 320 (no change) hact_sz += 257 h_fsz = h_line = 1344 (no change) then I don't see any change in behaviour to the base case, where the second line is 'indented' by 257 black pixels. If I change h_fsz alone, or h_line alone, I get no display at all on the TV. I can only change them in harmony. If I do: hact_st = 320 (no change) hact_sz = 1024 (no change) h_fsz += 257 h_line += 257 then my TV thinks it is outputting at 1281x768. To the left and right of the image, where I would expect black side bars (its a widescreen TV, so it will pad the sides with black to fit a 4:3 resolution on), I now get visual corruption (basically one of the pixels from the screen repeated forming a horizontal line). The first 257 pixels of the first row of the image output are not shown anywhere. The second row of pixels (and the ones that follow) start roughly in the right place but the final 257 pixels are not displayed anywhere. 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. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |