linux icon indicating copy to clipboard operation
linux copied to clipboard

incorrect lines doubled in 480i (only) using kms/fkms

Open alanbork opened this issue 3 years ago • 17 comments

480i (but not 1080i) content seems to have some kind of resampling/line skipping in both x and y directions, see test image below. I have verified that this occurs under both kms and fkms on a pi4, with releases as new as efe79c1df6df24e666c08dd68e1636ed24210fc1** and at least as old as 9dbcd6dfed16cc7de4a67b9ca445c4847f68c4c2 - I haven't tested outside this range, but I suspect it goes way further back in time I just didn't have a good test image to catch it until now.

image

(observed on left, desired on right).

this is not a TV deinterlacing artifact as the same image is displayed just fine when rendered on a pi0 using the dispmanx firmware. note also that if it were deinterlacing you'd expect it to be an issue in one direction only, but it's clear that vertical lines are being dropped/doubled, too. In this particular case it's a TCL S423 TV but I suspect it's not TV specific, either. The same TV shows the test image just fine in 480p.

test environment: bare console, no x11, using drm/kms to initialize and draw to screen.

footnote: **actually, fkms doesn't work at all for 480i with this release, you have to go back a few releases before it can produce 480i, but when it does work at all, it has this distortion.

alanbork avatar Sep 17 '21 21:09 alanbork

Sounds like this issue which had a recent fix for fkms, but hasn't been fixed on kms.

popcornmix avatar Sep 18 '21 09:09 popcornmix

looks like that's not yet hit rpi-update? or is there a proper hash to grab and test this from the Hexxeh github releases?

I know the below rpi-update shouldn't work but figured I'd try anyway ;-)

/root #rpi-update b80f36b3fb1566c028771d4a5ac9b23edf22069a *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom [...] *** Invalid hash given

On Sat, Sep 18, 2021 at 2:55 AM popcornmix @.***> wrote:

Sounds like this issue https://forum.libreelec.tv/thread/24415-le-10-beta-for-i4-force-hdmi-resolution/ which had a recent fix for fkms, but hasn't been fixed on kms.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/4588#issuecomment-922251374, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5LGJJINJPZYBVKQQN3UCROYZANCNFSM5EILKR3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

alanbork avatar Sep 19 '21 01:09 alanbork

rpi-update gets its releases from a different repo: https://github.com/Hexxeh/rpi-firmware/commits/master The equivalent release in this case is f8357e4d1dbc6b98dcec9acae9dbba5d9fb86040

pelwell avatar Sep 19 '21 08:09 pelwell

rpi-update f8357e4d1dbc6b98dcec9acae9dbba5d9fb86040: fkms: tv reports no signal for 480i (already reported under https://github.com/raspberrypi/firmware/issues/1626) kms: also tested this just in case, no change (480i image distorted both in x +y)

alanbork avatar Sep 19 '21 16:09 alanbork

You might as well try the latest release as well - just sudo rpi-update.

pelwell avatar Sep 19 '21 19:09 pelwell

That's efe79c1df6df24e666c08dd68e1636ed24210fc1 isn't it? it can't display 480i content at all.

alanbork avatar Sep 20 '21 05:09 alanbork

Just tested with new release 15471b6e99b6db2f3206f0aed67d0aebbfc9f9cf, behavior the same (fkms broken, kms distorted).

alanbork avatar Sep 22 '21 18:09 alanbork

looking more carefully at the test image I think what's happening here is that pairs of vertical lines are being read out from their left or right, depending on the line in question:

x+1 = x, and x+2=x+3.

Wild, can't imagine what would cause that kind of error especially in the vertical direction since scan out is fundamentally a horizontal signal. I could be wrong maybe it's just that each pair of vertical lines are doubled(x = x, x+1 =x). In any case, I don't think the horizontal lines are being doubled as I had originally suggested.

I've also confirmed that many models of TVs (all I've tested) show this error for 480i on a pi4.

alanbork avatar Oct 01 '21 18:10 alanbork

I checked if there has been progress since 2021, with rpi-update 1c56b3a58974f725e1ac63214eeaf914c5908302 , hoping I could close this, but in fact things are worse now. under fkms 480i just gives a blank screen (480p works fine). 1080i works and maybe has the problem fixed but it's hard to tell for sure since the pixels are so small.

under kms the problem is still present, exactly as was in 2021.

alanbork avatar May 11 '22 02:05 alanbork

Looking at this, I'm not sure it can be fixed fully.

In the original setup (and still in the current config for KMS), any pixel repetition is done in the pixelvalve, and that is then fed at 2 pixels/clock to the HDMI block. However it repeats each clock cycle, so instead of pixels AABBCCDD you get ABABCDCD.

The firmware change shifted the repetition to the HDMI block as it can also perform that function. That then exposes the issue that both 576i and 480i have an odd number of pixels for HSync and HBP (576i), or HFP and HBP (480i). Due to sending 2 pixels/clock there is no option for signalling a sync event between the 2 pixels, so it can not be correctly signaled from PV to HDMI. This is the reason 1366x768 gets filtered out as it also has odd values in the horizontal timing.

1366x768 was discounted for a workaround as different monitors objected to tweaking the timings by 1 pixel, so there was no guaranteed setting. With 480i and 576i the hardware I have seems to be more accepting, so we can attempt to tweak the timings.

480i should be horizontal timings of 720 active pixels, HFP 19, HSync 62, HBP 57, all then doubled. If we can juggle it to 720 / 18 / 62 / 58, or 720 / 20 / 62 / 56 and it works, then that is reasonable. Likewise 576i should be 720 / 12 / 63 / 69, so we can probably tweak it to 720 / 12 / 64 / 68, or 720 / 12 / 62 / 70.

6by9 avatar May 17 '22 15:05 6by9

@alanbork are you able to build and test this kernel? https://github.com/raspberrypi/linux/pull/5040

popcornmix avatar May 17 '22 17:05 popcornmix

That's fantastic that you worked on this, so please don't take the following as a lack of interest or appreciation:

I've never built a kernel other than what is installable from apt-get, and I'm somewhat short on time to learn how today, though I do have time to test anything that's rpi-updateable. Furthermore I'm leaving on a trip tomorrow and won't be able to do any testing after that until june. So sorry!

On Tue, May 17, 2022 at 10:28 AM popcornmix @.***> wrote:

@alanbork https://github.com/alanbork are you able to build and test this kernel? #5040 https://github.com/raspberrypi/linux/pull/5040

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/4588#issuecomment-1129131171, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5IUTFA3B2CLTOOOJCLVKPJLVANCNFSM5EILKR3Q . You are receiving this because you were mentioned.Message ID: @.***>

alanbork avatar May 17 '22 17:05 alanbork

If you do have time, kernel build instructions are here. https://www.raspberrypi.com/documentation/computers/linux_kernel.html#building

JamesH65 avatar May 18 '22 08:05 JamesH65

@alanbork it's in latest rpi-update kernel if you are still around.

popcornmix avatar May 18 '22 11:05 popcornmix

Sorry for the long delay. I am finally back and have tested this using 2f60255653636e9d0a270a5572c77d937321bbdd. It produces a proper image, which is great and a significant improvement to 480p60.0 and 480p59.97.

I do notice the timing has changed a tiny bit, with the lag between buffer swap and tv response time now being about 1ms longer, and now matching the timing for 480p almost exactly. This is very likely a TV implementation detail, but it does suggest the TV is handing this signal a bit differently than it did before. Encouragingly, if I compare timing between this new 480i and a pi0 running the dispmanx firmware outputing 480i the lag is very close, so I don't think the new 480i is making the tv do anything really strange. If anything the old pi4 480i implementation was causing the TV to act strangely.

I have not had a chance to use this beyond my standard test bed so I cannot comment as to the generality of the timing change or the overall compatibility of this tweaked 480i mode with other displays as of yet. Other than using rpi-update and rebooting there is no way to switch back and forth between the new 480i and the version used before this update?

alanbork avatar Jun 09 '22 16:06 alanbork

Other than using rpi-update and rebooting there is no way to switch back and forth between the new 480i and the version used before this update?

No

popcornmix avatar Jun 16 '22 10:06 popcornmix

I've had the chance to test on another tv of a much older vintage(2008) and it works there too. I won't bother to further update y'all unless I find one that doesn't work.

On Thu, Jun 16, 2022 at 3:58 AM popcornmix @.***> wrote:

Other than using rpi-update and rebooting there is no way to switch back and forth between the new 480i and the version used before this update?

No

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/4588#issuecomment-1157525403, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5JQRYCLA2EF6J2Q3QTVPMCFTANCNFSM5EILKR3Q . You are receiving this because you were mentioned.Message ID: @.***>

alanbork avatar Jun 16 '22 16:06 alanbork

Closing as appears to be resolved.

popcornmix avatar Jan 24 '23 18:01 popcornmix