I'm using libDRM on the OMAP platform, and using the alpha channel of
the ARGB plane to merge in a YUV plane. I'm doing the drmModePageFlip
(for the ARGB) and the drmModeSetPlane (for the YUV) immediately after
I've done a done a drmHandleEvent (with page_flip_handler etc...),
which I thought meant that the page flips should happen immediately
after the vsync, and thus not cause any tearing. However I do get
tearing on the YUV plane.
On a similar vein, every now and then I see the following messages
printed to the console:
[161879.239227] omapdss DISPC error: GO bit not down for channel 1
this corresponds to a brief flicker on the screen where the YUV frame
is replaced with garbage. On the next screen update, the garbage
disappears, so it is only present for 1/60th of a second. However it
is quite noticeable.
Does anyone know how either of these two issues can be mitigated?
On Tue, Oct 9, 2012 at 5:12 PM, Andre Renaud <an...@bluewatersys.com> wrote:
> Hi,
> I'm using libDRM on the OMAP platform, and using the alpha channel of
> the ARGB plane to merge in a YUV plane. I'm doing the drmModePageFlip
> (for the ARGB) and the drmModeSetPlane (for the YUV) immediately after
> I've done a done a drmHandleEvent (with page_flip_handler etc...),
> which I thought meant that the page flips should happen immediately
> after the vsync, and thus not cause any tearing. However I do get
> tearing on the YUV plane.
I'd guess the tearing is on the producer side (ie. what is writing
into the buffer). The problem is that if you wait for the page-flip
event, then call drmModeSetPlane(), the scanout address for the
overlay is updated and GO bit set, but the previous frame is still on
screen until the *next* vblank.
The best thing you could do right now is call drmModeSetPlane()
immediately after or before drmModePageFlip(). And then wait for the
page-flip event to know when the overlay buffer can be given back to
the decoder. This is a bit racey, but as long as you aren't getting
close to the vblank before flipping the fb and overlay layer, then it
should roughly work.
The better solution is the atomic-pageflip stuff that I'm working on,
which will let you tell the kernel to update fb and zero or more
overlay layers in a single ioctl to guarantee that they are all
swapped on the same vblank:
That is the good news.. the bad news is that it is all based on newer
"vanilla" upstream kernel.. I should have updated RFC patches on 3.6+
sometime this week, I'm shooting to get this merged for 3.8 merge
window since we are already into 3.7 merge window. But this is on
upstream kernel missing gfx and ivahd stuff.. so for short term that
doesn't help you too much unless you want to do a bunch of backporting
or fwd porting..)
> On a similar vein, every now and then I see the following messages
> printed to the console:
> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
> this corresponds to a brief flicker on the screen where the YUV frame
> is replaced with garbage. On the next screen update, the garbage
> disappears, so it is only present for 1/60th of a second. However it
> is quite noticeable.
yeah, current 3.4 based stuff is missing something like:
I noticed that issue when working on the atomic-pageflip stuff..
although unfortunately the fix is lumped in w/ all the rest of the
atomic-pageflip stuff which makes it not so easy to cherry-pick. I
think all you should need is the 'if (omap_crtc->irq.registered) goto
out' stuff. If you have trouble backporting that, let me know and
I'll give a try, but might be a few days before I have time.
>> On a similar vein, every now and then I see the following messages
>> printed to the console:
>> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
>> this corresponds to a brief flicker on the screen where the YUV frame
>> is replaced with garbage. On the next screen update, the garbage
>> disappears, so it is only present for 1/60th of a second. However it
>> is quite noticeable.
> yeah, current 3.4 based stuff is missing something like:
> I noticed that issue when working on the atomic-pageflip stuff..
> although unfortunately the fix is lumped in w/ all the rest of the
> atomic-pageflip stuff which makes it not so easy to cherry-pick. I
> think all you should need is the 'if (omap_crtc->irq.registered) goto
> out' stuff. If you have trouble backporting that, let me know and
> I'll give a try, but might be a few days before I have time.
Thanks for that - adding in that snippet seems to have resolved the issue.
Can anyone clarify me some issues regarding with YUYV video rendering with DRM?
I am testing omapDRM driver and dumping all info. The problem is that I am calling the function drmModeGetPlane and it is returning that I have no free planes (it returns 0 count) that can be connected to my CRTC. Why?
Regards,
El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud escribió:
> >> On a similar vein, every now and then I see the following messages > >> printed to the console: > >> [161879.239227] omapdss DISPC error: GO bit not down for channel 1 > >> this corresponds to a brief flicker on the screen where the YUV frame > >> is replaced with garbage. On the next screen update, the garbage > >> disappears, so it is only present for 1/60th of a second. However it > >> is quite noticeable.
> > yeah, current 3.4 based stuff is missing something like:
> > I noticed that issue when working on the atomic-pageflip stuff.. > > although unfortunately the fix is lumped in w/ all the rest of the > > atomic-pageflip stuff which makes it not so easy to cherry-pick. I > > think all you should need is the 'if (omap_crtc->irq.registered) goto > > out' stuff. If you have trouble backporting that, let me know and > > I'll give a try, but might be a few days before I have time.
> Thanks for that - adding in that snippet seems to have resolved the issue.
On Mon, Feb 25, 2013 at 5:53 AM, <leo.armesto.an...@gmail.com> wrote:
> Can anyone clarify me some issues regarding with YUYV video rendering with
> DRM?
> I am testing omapDRM driver and dumping all info. The problem is that I am
> calling the function drmModeGetPlane and it is returning that I have no free
> planes (it returns 0 count) that can be connected to my CRTC. Why?
> Regards,
> El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud escribió:
>> Hi Rob,
>> >> On a similar vein, every now and then I see the following messages
>> >> printed to the console:
>> >> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
>> >> this corresponds to a brief flicker on the screen where the YUV frame
>> >> is replaced with garbage. On the next screen update, the garbage
>> >> disappears, so it is only present for 1/60th of a second. However it
>> >> is quite noticeable.
>> > yeah, current 3.4 based stuff is missing something like:
>> > I noticed that issue when working on the atomic-pageflip stuff..
>> > although unfortunately the fix is lumped in w/ all the rest of the
>> > atomic-pageflip stuff which makes it not so easy to cherry-pick. I
>> > think all you should need is the 'if (omap_crtc->irq.registered) goto
>> > out' stuff. If you have trouble backporting that, let me know and
>> > I'll give a try, but might be a few days before I have time.
>> Thanks for that - adding in that snippet seems to have resolved the issue.
>> Regards,
>> Andre
> --
> You received this message because you are subscribed to the Google Groups
> "pandaboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandaboard+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
That is exactly what I was refering to. I run the test and dump all available resources. The problem is that no plane resources are found and that is something that I did not expect. In theory I should have GFX, YUV1, YUV2 and YUV3 corresponding to old framebuffer with omapfb, isn't?
Regards,
El lunes, 25 de febrero de 2013 15:49:09 UTC+1, rob escribió:
> it is drmModeGetPlaneResources() that should return the # of overlays.
> Anyways, if you could run modetest that should correctly dump all the > available resources.
> BR, > -R
> On Mon, Feb 25, 2013 at 5:53 AM, <leo.arme...@gmail.com <javascript:>> > wrote: > > Can anyone clarify me some issues regarding with YUYV video rendering > with > > DRM?
> > I am testing omapDRM driver and dumping all info. The problem is that I > am > > calling the function drmModeGetPlane and it is returning that I have no > free > > planes (it returns 0 count) that can be connected to my CRTC. Why?
> > Regards,
> > El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud > escribió:
> >> Hi Rob,
> >> >> On a similar vein, every now and then I see the following messages > >> >> printed to the console: > >> >> [161879.239227] omapdss DISPC error: GO bit not down for channel 1 > >> >> this corresponds to a brief flicker on the screen where the YUV > frame > >> >> is replaced with garbage. On the next screen update, the garbage > >> >> disappears, so it is only present for 1/60th of a second. However it > >> >> is quite noticeable.
> >> > yeah, current 3.4 based stuff is missing something like:
> >> > I noticed that issue when working on the atomic-pageflip stuff.. > >> > although unfortunately the fix is lumped in w/ all the rest of the > >> > atomic-pageflip stuff which makes it not so easy to cherry-pick. I > >> > think all you should need is the 'if (omap_crtc->irq.registered) goto > >> > out' stuff. If you have trouble backporting that, let me know and > >> > I'll give a try, but might be a few days before I have time.
> >> Thanks for that - adding in that snippet seems to have resolved the > issue.
> >> Regards, > >> Andre
> > -- > > You received this message because you are subscribed to the Google > Groups > > "pandaboard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to pandaboard+...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out.
> That is exactly what I was refering to. I run the test and dump all > available resources. The problem is that no plane resources are found and > that is something that I did not expect. In theory I should have GFX, YUV1, > YUV2 and YUV3 corresponding to old framebuffer with omapfb, isn't?
> Regards,
> El lunes, 25 de febrero de 2013 15:49:09 UTC+1, rob escribió:
>> You might want to try the modetest app in libdrm/test
>> it is drmModeGetPlaneResources() that should return the # of overlays.
>> Anyways, if you could run modetest that should correctly dump all the >> available resources.
>> BR, >> -R
>> On Mon, Feb 25, 2013 at 5:53 AM, <leo.arme...@gmail.com> wrote: >> > Can anyone clarify me some issues regarding with YUYV video rendering >> with >> > DRM?
>> > I am testing omapDRM driver and dumping all info. The problem is that I >> am >> > calling the function drmModeGetPlane and it is returning that I have no >> free >> > planes (it returns 0 count) that can be connected to my CRTC. Why?
>> > Regards,
>> > El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud >> escribió:
>> >> Hi Rob,
>> >> >> On a similar vein, every now and then I see the following messages >> >> >> printed to the console: >> >> >> [161879.239227] omapdss DISPC error: GO bit not down for channel 1 >> >> >> this corresponds to a brief flicker on the screen where the YUV >> frame >> >> >> is replaced with garbage. On the next screen update, the garbage >> >> >> disappears, so it is only present for 1/60th of a second. However >> it >> >> >> is quite noticeable.
>> >> > yeah, current 3.4 based stuff is missing something like:
>> >> > I noticed that issue when working on the atomic-pageflip stuff.. >> >> > although unfortunately the fix is lumped in w/ all the rest of the >> >> > atomic-pageflip stuff which makes it not so easy to cherry-pick. I >> >> > think all you should need is the 'if (omap_crtc->irq.registered) >> goto >> >> > out' stuff. If you have trouble backporting that, let me know and >> >> > I'll give a try, but might be a few days before I have time.
>> >> Thanks for that - adding in that snippet seems to have resolved the >> issue.
>> >> Regards, >> >> Andre
>> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "pandaboard" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to pandaboard+...@googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out.
yes.. well, it depends a bit on bootargs/kernel config, but it can
partition GFX/VID1/VID2/VID3 between crtc's and planes.. I think by
default you should have two crtcs and two planes.
What kernel version are you using? Can you add drm.debug=7 to
bootargs and send me all the drm debug traces it dumps out at boot?
On Mon, Feb 25, 2013 at 12:01 PM, <leo.armesto.an...@gmail.com> wrote:
> sorry I meant VID1, VID2, VID3 of the DSS subsystem...
> Regards,
> Leo.
> El lunes, 25 de febrero de 2013 17:47:29 UTC+1, leo.arme...@gmail.com
> escribió:
>> That is exactly what I was refering to. I run the test and dump all
>> available resources. The problem is that no plane resources are found and
>> that is something that I did not expect. In theory I should have GFX, YUV1,
>> YUV2 and YUV3 corresponding to old framebuffer with omapfb, isn't?
>> Regards,
>> El lunes, 25 de febrero de 2013 15:49:09 UTC+1, rob escribió:
>>> You might want to try the modetest app in libdrm/test
>>> it is drmModeGetPlaneResources() that should return the # of overlays.
>>> Anyways, if you could run modetest that should correctly dump all the
>>> available resources.
>>> BR,
>>> -R
>>> On Mon, Feb 25, 2013 at 5:53 AM, <leo.arme...@gmail.com> wrote:
>>> > Can anyone clarify me some issues regarding with YUYV video rendering
>>> > with
>>> > DRM?
>>> > I am testing omapDRM driver and dumping all info. The problem is that I
>>> > am
>>> > calling the function drmModeGetPlane and it is returning that I have no
>>> > free
>>> > planes (it returns 0 count) that can be connected to my CRTC. Why?
>>> > Regards,
>>> > El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud
>>> > escribió:
>>> >> Hi Rob,
>>> >> >> On a similar vein, every now and then I see the following messages
>>> >> >> printed to the console:
>>> >> >> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
>>> >> >> this corresponds to a brief flicker on the screen where the YUV
>>> >> >> frame
>>> >> >> is replaced with garbage. On the next screen update, the garbage
>>> >> >> disappears, so it is only present for 1/60th of a second. However
>>> >> >> it
>>> >> >> is quite noticeable.
>>> >> > yeah, current 3.4 based stuff is missing something like:
>>> >> > I noticed that issue when working on the atomic-pageflip stuff..
>>> >> > although unfortunately the fix is lumped in w/ all the rest of the
>>> >> > atomic-pageflip stuff which makes it not so easy to cherry-pick. I
>>> >> > think all you should need is the 'if (omap_crtc->irq.registered)
>>> >> > goto
>>> >> > out' stuff. If you have trouble backporting that, let me know and
>>> >> > I'll give a try, but might be a few days before I have time.
>>> >> Thanks for that - adding in that snippet seems to have resolved the
>>> >> issue.
>>> >> Regards,
>>> >> Andre
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "pandaboard" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to pandaboard+...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
> --
> You received this message because you are subscribed to the Google Groups
> "pandaboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandaboard+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Thanks for your time. You are right, although I could find the solution myself. My confusion was that I set the number of CRTCs to 4 since I thought that it was referring to framebuffers (/dev/fbX) as in old omapfb driver. That's why the number of planes left was simply 0.
Regards,
Leo.
El jueves, 28 de febrero de 2013 01:20:30 UTC+1, rob escribió:
> yes.. well, it depends a bit on bootargs/kernel config, but it can > partition GFX/VID1/VID2/VID3 between crtc's and planes.. I think by > default you should have two crtcs and two planes.
> What kernel version are you using? Can you add drm.debug=7 to > bootargs and send me all the drm debug traces it dumps out at boot?
> BR, > -R
> On Mon, Feb 25, 2013 at 12:01 PM, <leo.arme...@gmail.com <javascript:>> > wrote: > > sorry I meant VID1, VID2, VID3 of the DSS subsystem...
> > Regards,
> > Leo.
> > El lunes, 25 de febrero de 2013 17:47:29 UTC+1, leo.arme...@gmail.com > > escribió:
> >> That is exactly what I was refering to. I run the test and dump all > >> available resources. The problem is that no plane resources are found > and > >> that is something that I did not expect. In theory I should have GFX, > YUV1, > >> YUV2 and YUV3 corresponding to old framebuffer with omapfb, isn't?
> >> Regards,
> >> El lunes, 25 de febrero de 2013 15:49:09 UTC+1, rob escribió:
> >>> You might want to try the modetest app in libdrm/test
> >>> it is drmModeGetPlaneResources() that should return the # of overlays.
> >>> Anyways, if you could run modetest that should correctly dump all the > >>> available resources.
> >>> BR, > >>> -R
> >>> On Mon, Feb 25, 2013 at 5:53 AM, <leo.arme...@gmail.com> wrote: > >>> > Can anyone clarify me some issues regarding with YUYV video > rendering > >>> > with > >>> > DRM?
> >>> > I am testing omapDRM driver and dumping all info. The problem is > that I > >>> > am > >>> > calling the function drmModeGetPlane and it is returning that I have > no > >>> > free > >>> > planes (it returns 0 count) that can be connected to my CRTC. Why?
> >>> > Regards,
> >>> > El miércoles, 10 de octubre de 2012 04:22:55 UTC+2, Andre Renaud > >>> > escribió:
> >>> >> Hi Rob,
> >>> >> >> On a similar vein, every now and then I see the following > messages > >>> >> >> printed to the console: > >>> >> >> [161879.239227] omapdss DISPC error: GO bit not down for channel > 1 > >>> >> >> this corresponds to a brief flicker on the screen where the YUV > >>> >> >> frame > >>> >> >> is replaced with garbage. On the next screen update, the garbage > >>> >> >> disappears, so it is only present for 1/60th of a second. > However > >>> >> >> it > >>> >> >> is quite noticeable.
> >>> >> > yeah, current 3.4 based stuff is missing something like:
> >>> >> > I noticed that issue when working on the atomic-pageflip stuff.. > >>> >> > although unfortunately the fix is lumped in w/ all the rest of > the > >>> >> > atomic-pageflip stuff which makes it not so easy to cherry-pick. > I > >>> >> > think all you should need is the 'if (omap_crtc->irq.registered) > >>> >> > goto > >>> >> > out' stuff. If you have trouble backporting that, let me know > and > >>> >> > I'll give a try, but might be a few days before I have time.
> >>> >> Thanks for that - adding in that snippet seems to have resolved the > >>> >> issue.
> >>> >> Regards, > >>> >> Andre
> >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "pandaboard" group. > >>> > To unsubscribe from this group and stop receiving emails from it, > send > >>> > an > >>> > email to pandaboard+...@googlegroups.com. > >>> > For more options, visit https://groups.google.com/groups/opt_out.
> > -- > > You received this message because you are subscribed to the Google > Groups > > "pandaboard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to pandaboard+...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out.
