[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

On Mon, Nov 07, 2016 at 03:46:52PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote:
> > Hi Russell,
> > 
> > On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote:
> > > > Yes. And that is an XBMC only solution, that doesn't work with the
> > > > fbdev emulation and is probably doing an additional composition to
> > > > scale down and center their frames through OpenGL.
> > > 
> > > Well, it will have to be doing a scaling step anyway.  If the video
> > > frame is a different size to the active area, scaling is required
> > > no matter what.  A 576p SD image needs to be scaled up, and a 1080p
> > > image would need to be scaled down for a 1080p overscanned display
> > > with a reduced active area to counter the overscanning - no matter
> > > how you do it.
> > 
> > Yes, except that scaling is not always an option. In my particular
> > example, there's no scaler after the CRTC, which essentially prevents
> > it from being used in that use case. Which is also why I ended up
> > reducing the mode reported to the user.
> 
> I think you completely missed my point.  Let me try again.
> 
> If you expose a reduced mode to the user, you are reporting that (eg)
> the 1080p-timings mode does not have 1920 pixels horizontally, and
> 1080 lines.  You are instead reporting that it has (eg) 1800 pixels
> horizontally and maybe 1000 lines.
> 
> So, when you play back a 1080 video, you are going to have to either:
> 
> 1. crop the extra 120 pixels horizontally and 80 lines vertically
> or
> 2. scale the image.
> 
> However, this is a completely independent issue to how we go about
> setting a video mode that is 1800x1000 in the first place.
> 
> What you're suggesting is that we add code to the kernel to report that
> your non-EDID, analogue output transforms the standard 1920x1080 timings
> such that it has a 1800x1000 active area.
> 
> I'm suggesting instead that you can do the same thing in userspace by
> specifically adding a mode which has the 1920x1080 standard timings,
> but with the porches increased and the active area reduced - in exactly
> the same way that you'd have to do within the kernel to report your
> active-area-reduced 1800x1000 mode.

Ah, yes, you meant input scaling, not output, sorry.

> > > For graphics, userspace could add mode(s) with increased porches and
> > > reduced active area itself to achieve an underscanned display on a
> > > timing which the display device always overscans - there's no need to
> > > do that in the kernel, all the APIs are there to be able to do it
> > > already.
> > > 
> > > That means your framebuffer will be smaller, but that's the case
> > > anyway.
> > 
> > Yes, that would be a good idea. But it's not always an option for
> > applications that would rely on the fbdev emulation (like QT's eglfs),
> > which would then have no way to change whatever default there is (and
> > the only one able to know how bad it actually is is the user).
> 
> I guess this is the problem with DRM people wanting to deprecate fbdev...
> too much stuff currently relies upon it, but DRM on x86 has always had
> the reduced functionality.
> 
> I guess there's two solutions here:
> 
> 1. Either DRMs fbdev gains increased functionality, or
> 2. The fbdev-only applications/libraries need to be ported over to
>support DRM natively.
> 
> This has been a bar for some time to moving over to DRM, and I've heard
> very little desire on either side to find some sort of compromise on the
> issue, so I guess things are rather stuck where they are.

I guess it really all boils down to this, and whether the userspace
will be able to set a custom mode on its own. "Advanced" stacks like
Xorg and Wayland will, but simpler and / or legacy applications will
depend on the fbdev emulation, either because they've not been
converted through DRM (like you suggested) or because it depends on a
blob that requires it (and then you're stuck).

And since the kernel already deals with overscan through a generic
property, it really feels like it's the place it should be done to
address all needs (and ideally in a generic way).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi Russell,

On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote:
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
> 
> Well, it will have to be doing a scaling step anyway.  If the video
> frame is a different size to the active area, scaling is required
> no matter what.  A 576p SD image needs to be scaled up, and a 1080p
> image would need to be scaled down for a 1080p overscanned display
> with a reduced active area to counter the overscanning - no matter
> how you do it.

Yes, except that scaling is not always an option. In my particular
example, there's no scaler after the CRTC, which essentially prevents
it from being used in that use case. Which is also why I ended up
reducing the mode reported to the user.

> For graphics, userspace could add mode(s) with increased porches and
> reduced active area itself to achieve an underscanned display on a
> timing which the display device always overscans - there's no need to
> do that in the kernel, all the APIs are there to be able to do it
> already.
> 
> That means your framebuffer will be smaller, but that's the case
> anyway.

Yes, that would be a good idea. But it's not always an option for
applications that would rely on the fbdev emulation (like QT's eglfs),
which would then have no way to change whatever default there is (and
the only one able to know how bad it actually is is the user).

> > > > The second one is that we still need to expose the reduced modes to
> > > > userspace, and not only the displayed size, so that the applications
> > > > know what they must draw on. But I guess this could be adjusted by the
> > > > core too.
> > > > 
> > > > In order to work consistently, I think all planes should be adjusted
> > > > that way, so that relative coordinates are from the primary plane
> > > > origin, and not the display origin. But that could be adjusted too by
> > > > the core I guess.
> > > 
> > > I'm not sure about that - we want the graphics to be visible, but that
> > > may not be appropriate for an video overlay frame.  It's quite common
> > > for (eg) broadcast video to contain dead pixels or other artifacts on
> > > the right hand side, and the broadcast video expects overscan to be
> > > present.
> > >
> > > I know this because I have run my TV with overscan disabled, even for
> > > broadcast TV.
> > 
> > I know, but on this particular hardware, composite really is just
> > another video output. There's not even a TV receiver in it, so I don't
> > think we have to worry about it.
> 
> Whether or not there's a TV receiver is irrelevant - if you can decode
> broadcast video, then you run into the problem.  For example, if you
> plug in a USB DVB stick, stream it across the network, etc.

Good point.

> Remember, you're proposing a generic solution, so making arguments
> about things that are not possible with your specific hardware isn't
> really that relevant to a generic solution.

This is definitely not what I'm proposing. I've been told very early
on that such a generic solution was not even worth working on.

> So, I may want my graphics to appear on an overscanned display such
> that I can see the borders, but I may want the overlaid video to use
> the full active area (including overscan) to hide some of the broadcast
> mess at the edges of the screen.
> 
> > > Yea, that's quite sad, "analog" has become a dirty word, but really
> > > this has nothing to do with "analog" at all - there are LCD TVs (and
> > > some monitors) out there which take HDMI signals but refuse to
> > > disable overscan no matter what you do to them if you provide them
> > > with a "broadcast"  mode - so the analog excuse is very poor.
> > 
> > I'd agree with you, but I was also told to not turn that into a
> > generic code and deal with that in my driver.
> 
> I guess whoever told you that was wrong.  I used to have a cheap TV
> here which took HDMI, and always overscans broadcast modes, and
> underscans PC modes.  No amount of fiddling with various settings
> (either in the TV or AVI frames) changes that.
> 
> I've run into that with a _monitor_ that Andrew Hutton has, which has
> a HDMI input - exactly the same thing - 1080p, 720p etc are all
> unconditionally overscanned, 1024x768 etc are all unconditionally
> underscanned and there's nothing that can be done to change it.
> 
> The problem is that TVs are at liberty to have this behaviour, so
> the overscaned problem is always going to be there, and each driver
> should not be dealing with it in their own specific ways.

I agree with you, however, without any directions on how to do this,
and willingness to merge this, I don't really see why we would work on
such a generic implementation in the first place.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Russell King - ARM Linux]

On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote:
> Hi Russell,
> 
> On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote:
> > > Yes. And that is an XBMC only solution, that doesn't work with the
> > > fbdev emulation and is probably doing an additional composition to
> > > scale down and center their frames through OpenGL.
> > 
> > Well, it will have to be doing a scaling step anyway.  If the video
> > frame is a different size to the active area, scaling is required
> > no matter what.  A 576p SD image needs to be scaled up, and a 1080p
> > image would need to be scaled down for a 1080p overscanned display
> > with a reduced active area to counter the overscanning - no matter
> > how you do it.
> 
> Yes, except that scaling is not always an option. In my particular
> example, there's no scaler after the CRTC, which essentially prevents
> it from being used in that use case. Which is also why I ended up
> reducing the mode reported to the user.

I think you completely missed my point.  Let me try again.

If you expose a reduced mode to the user, you are reporting that (eg)
the 1080p-timings mode does not have 1920 pixels horizontally, and
1080 lines.  You are instead reporting that it has (eg) 1800 pixels
horizontally and maybe 1000 lines.

So, when you play back a 1080 video, you are going to have to either:

1. crop the extra 120 pixels horizontally and 80 lines vertically
or
2. scale the image.

However, this is a completely independent issue to how we go about
setting a video mode that is 1800x1000 in the first place.

What you're suggesting is that we add code to the kernel to report that
your non-EDID, analogue output transforms the standard 1920x1080 timings
such that it has a 1800x1000 active area.

I'm suggesting instead that you can do the same thing in userspace by
specifically adding a mode which has the 1920x1080 standard timings,
but with the porches increased and the active area reduced - in exactly
the same way that you'd have to do within the kernel to report your
active-area-reduced 1800x1000 mode.

> > For graphics, userspace could add mode(s) with increased porches and
> > reduced active area itself to achieve an underscanned display on a
> > timing which the display device always overscans - there's no need to
> > do that in the kernel, all the APIs are there to be able to do it
> > already.
> > 
> > That means your framebuffer will be smaller, but that's the case
> > anyway.
> 
> Yes, that would be a good idea. But it's not always an option for
> applications that would rely on the fbdev emulation (like QT's eglfs),
> which would then have no way to change whatever default there is (and
> the only one able to know how bad it actually is is the user).

I guess this is the problem with DRM people wanting to deprecate fbdev...
too much stuff currently relies upon it, but DRM on x86 has always had
the reduced functionality.

I guess there's two solutions here:

1. Either DRMs fbdev gains increased functionality, or
2. The fbdev-only applications/libraries need to be ported over to
   support DRM natively.

This has been a bar for some time to moving over to DRM, and I've heard
very little desire on either side to find some sort of compromise on the
issue, so I guess things are rather stuck where they are.

> > So, I may want my graphics to appear on an overscanned display such
> > that I can see the borders, but I may want the overlaid video to use
> > the full active area (including overscan) to hide some of the broadcast
> > mess at the edges of the screen.
> > 
> > > > Yea, that's quite sad, "analog" has become a dirty word, but really
> > > > this has nothing to do with "analog" at all - there are LCD TVs (and
> > > > some monitors) out there which take HDMI signals but refuse to
> > > > disable overscan no matter what you do to them if you provide them
> > > > with a "broadcast"  mode - so the analog excuse is very poor.
> > > 
> > > I'd agree with you, but I was also told to not turn that into a
> > > generic code and deal with that in my driver.
> > 
> > I guess whoever told you that was wrong.  I used to have a cheap TV
> > here which took HDMI, and always overscans broadcast modes, and
> > underscans PC modes.  No amount of fiddling with various settings
> > (either in the TV or AVI frames) changes that.
> > 
> > I've run into that with a _monitor_ that Andrew Hutton has, which has
> > a HDMI input - exactly the same thing - 1080p, 720p etc are all
> > unconditionally overscanned, 1024x768 etc are all unconditionally
> > underscanned and there's nothing that can be done to change it.
> > 
> > The problem is that TVs are at liberty to have this behaviour, so
> > the overscaned problem is always going to be there, and each driver
> > should not be dealing with it in their own specific ways.
> 
> I agree with you, however, without any directions on how to do this,
> and willingness to merge this, I don't really see why we would work on
> such a 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi Sean,

On Thu, Nov 03, 2016 at 03:11:26PM -0600, Sean Paul wrote:
> On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
>  wrote:
> > Hi Russell,
> >
> > On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
> >> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> >> > The first one is that this overscanning should be reported by the
> >> > connector I guess? but this is really TV specific, so we need one way
> >> > to let the user tell how the image is displayed on its side, and we
> >> > cannot really autodetect it, and this needs to be done at runtime so
> >> > that we can present some shiny interface to let it select which
> >> > overscan ratio works for him/her.
> >>
> >> See xbmc... they go through a nice shiny setup which includes adjusting
> >> the visible area.  From what I remember, it has pointers on each corner
> >> which you can adjust to be just visible on the screen, so xbmc knows
> >> how much overscan there is, and xbmc itself reduces down to the user
> >> set size.
> >
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
> >
> > We might not have a GPU in the system, and we might not even have an
> > entire graphic stack on top either, so I don't think fixing at the
> > user-space level is a good option (especially since we already have an
> > overscan property in DRM).
> >
> 
> Hi Maxime,
> I took a quick look at the first 2 patches in the series and they look
> good at first glance. I have them in my queue to review more
> carefully.

Yes, the first one is pretty scary.

If it can ease your review, I made a bunch of unittests to test that
code. It's pretty hacky (basically a copy of some kernel structures
and the new logic to parse the command line), but it should test it
with a significant number of cases:

http://code.bulix.org/4lnlk7-107122?raw

It's pretty straightforward to compile, you just have to link against
cmocka.

> Can you explain why you can't fix this by specifying a new mode with
> big porches (as Russell suggested)?

I'll reply to his mail.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Sean Paul]

On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
 wrote:
> Hi Russell,
>
> On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
>> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
>> > The first one is that this overscanning should be reported by the
>> > connector I guess? but this is really TV specific, so we need one way
>> > to let the user tell how the image is displayed on its side, and we
>> > cannot really autodetect it, and this needs to be done at runtime so
>> > that we can present some shiny interface to let it select which
>> > overscan ratio works for him/her.
>>
>> See xbmc... they go through a nice shiny setup which includes adjusting
>> the visible area.  From what I remember, it has pointers on each corner
>> which you can adjust to be just visible on the screen, so xbmc knows
>> how much overscan there is, and xbmc itself reduces down to the user
>> set size.
>
> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.
>
> We might not have a GPU in the system, and we might not even have an
> entire graphic stack on top either, so I don't think fixing at the
> user-space level is a good option (especially since we already have an
> overscan property in DRM).
>

Hi Maxime,
I took a quick look at the first 2 patches in the series and they look
good at first glance. I have them in my queue to review more
carefully.

Can you explain why you can't fix this by specifying a new mode with
big porches (as Russell suggested)?

Sean


>> > The second one is that we still need to expose the reduced modes to
>> > userspace, and not only the displayed size, so that the applications
>> > know what they must draw on. But I guess this could be adjusted by the
>> > core too.
>> >
>> > In order to work consistently, I think all planes should be adjusted
>> > that way, so that relative coordinates are from the primary plane
>> > origin, and not the display origin. But that could be adjusted too by
>> > the core I guess.
>>
>> I'm not sure about that - we want the graphics to be visible, but that
>> may not be appropriate for an video overlay frame.  It's quite common
>> for (eg) broadcast video to contain dead pixels or other artifacts on
>> the right hand side, and the broadcast video expects overscan to be
>> present.
>>
>> I know this because I have run my TV with overscan disabled, even for
>> broadcast TV.
>
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.
>
>> > The fourth one being the major one. Every time I raised the issue on
>> > IRC, the answer basically was "we don't care about analog", so I'm a
>> > bit pessimistic about whether dealing with this in the core would be
>> > accepted, hence why I chose to deal with this at the driver level.
>>
>> Yea, that's quite sad, "analog" has become a dirty word, but really
>> this has nothing to do with "analog" at all - there are LCD TVs (and
>> some monitors) out there which take HDMI signals but refuse to
>> disable overscan no matter what you do to them if you provide them
>> with a "broadcast"  mode - so the analog excuse is very poor.
>
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.
>
> Do you have any suggestions?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi Russell,

On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > The first one is that this overscanning should be reported by the
> > connector I guess? but this is really TV specific, so we need one way
> > to let the user tell how the image is displayed on its side, and we
> > cannot really autodetect it, and this needs to be done at runtime so
> > that we can present some shiny interface to let it select which
> > overscan ratio works for him/her.
> 
> See xbmc... they go through a nice shiny setup which includes adjusting
> the visible area.  From what I remember, it has pointers on each corner
> which you can adjust to be just visible on the screen, so xbmc knows
> how much overscan there is, and xbmc itself reduces down to the user
> set size.

Yes. And that is an XBMC only solution, that doesn't work with the
fbdev emulation and is probably doing an additional composition to
scale down and center their frames through OpenGL.

We might not have a GPU in the system, and we might not even have an
entire graphic stack on top either, so I don't think fixing at the
user-space level is a good option (especially since we already have an
overscan property in DRM).

> > The second one is that we still need to expose the reduced modes to
> > userspace, and not only the displayed size, so that the applications
> > know what they must draw on. But I guess this could be adjusted by the
> > core too.
> > 
> > In order to work consistently, I think all planes should be adjusted
> > that way, so that relative coordinates are from the primary plane
> > origin, and not the display origin. But that could be adjusted too by
> > the core I guess.
> 
> I'm not sure about that - we want the graphics to be visible, but that
> may not be appropriate for an video overlay frame.  It's quite common
> for (eg) broadcast video to contain dead pixels or other artifacts on
> the right hand side, and the broadcast video expects overscan to be
> present.
>
> I know this because I have run my TV with overscan disabled, even for
> broadcast TV.

I know, but on this particular hardware, composite really is just
another video output. There's not even a TV receiver in it, so I don't
think we have to worry about it.

> > The fourth one being the major one. Every time I raised the issue on
> > IRC, the answer basically was "we don't care about analog", so I'm a
> > bit pessimistic about whether dealing with this in the core would be
> > accepted, hence why I chose to deal with this at the driver level.
> 
> Yea, that's quite sad, "analog" has become a dirty word, but really
> this has nothing to do with "analog" at all - there are LCD TVs (and
> some monitors) out there which take HDMI signals but refuse to
> disable overscan no matter what you do to them if you provide them
> with a "broadcast"  mode - so the analog excuse is very poor.

I'd agree with you, but I was also told to not turn that into a
generic code and deal with that in my driver.

Do you have any suggestions?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Russell King - ARM Linux]

On Thu, Nov 03, 2016 at 10:01:06AM +0100, Maxime Ripard wrote:
> Hi Russell,
> 
> On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
> > On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > > The first one is that this overscanning should be reported by the
> > > connector I guess? but this is really TV specific, so we need one way
> > > to let the user tell how the image is displayed on its side, and we
> > > cannot really autodetect it, and this needs to be done at runtime so
> > > that we can present some shiny interface to let it select which
> > > overscan ratio works for him/her.
> > 
> > See xbmc... they go through a nice shiny setup which includes adjusting
> > the visible area.  From what I remember, it has pointers on each corner
> > which you can adjust to be just visible on the screen, so xbmc knows
> > how much overscan there is, and xbmc itself reduces down to the user
> > set size.

I was replying to your comment "so we need one way to let the user tell
how the image is displayed".

> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.

Well, it will have to be doing a scaling step anyway.  If the video
frame is a different size to the active area, scaling is required
no matter what.  A 576p SD image needs to be scaled up, and a 1080p
image would need to be scaled down for a 1080p overscanned display
with a reduced active area to counter the overscanning - no matter
how you do it.

For graphics, userspace could add mode(s) with increased porches and
reduced active area itself to achieve an underscanned display on a
timing which the display device always overscans - there's no need to
do that in the kernel, all the APIs are there to be able to do it
already.

That means your framebuffer will be smaller, but that's the case
anyway.

> > > The second one is that we still need to expose the reduced modes to
> > > userspace, and not only the displayed size, so that the applications
> > > know what they must draw on. But I guess this could be adjusted by the
> > > core too.
> > > 
> > > In order to work consistently, I think all planes should be adjusted
> > > that way, so that relative coordinates are from the primary plane
> > > origin, and not the display origin. But that could be adjusted too by
> > > the core I guess.
> > 
> > I'm not sure about that - we want the graphics to be visible, but that
> > may not be appropriate for an video overlay frame.  It's quite common
> > for (eg) broadcast video to contain dead pixels or other artifacts on
> > the right hand side, and the broadcast video expects overscan to be
> > present.
> >
> > I know this because I have run my TV with overscan disabled, even for
> > broadcast TV.
> 
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.

Whether or not there's a TV receiver is irrelevant - if you can decode
broadcast video, then you run into the problem.  For example, if you
plug in a USB DVB stick, stream it across the network, etc.

Remember, you're proposing a generic solution, so making arguments
about things that are not possible with your specific hardware isn't
really that relevant to a generic solution.

So, I may want my graphics to appear on an overscanned display such
that I can see the borders, but I may want the overlaid video to use
the full active area (including overscan) to hide some of the broadcast
mess at the edges of the screen.

> > Yea, that's quite sad, "analog" has become a dirty word, but really
> > this has nothing to do with "analog" at all - there are LCD TVs (and
> > some monitors) out there which take HDMI signals but refuse to
> > disable overscan no matter what you do to them if you provide them
> > with a "broadcast"  mode - so the analog excuse is very poor.
> 
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.

I guess whoever told you that was wrong.  I used to have a cheap TV
here which took HDMI, and always overscans broadcast modes, and
underscans PC modes.  No amount of fiddling with various settings
(either in the TV or AVI frames) changes that.

I've run into that with a _monitor_ that Andrew Hutton has, which has
a HDMI input - exactly the same thing - 1080p, 720p etc are all
unconditionally overscanned, 1024x768 etc are all unconditionally
underscanned and there's nothing that can be done to change it.

The problem is that TVs are at liberty to have this behaviour, so
the overscaned problem is always going to be there, and each driver
should not be dealing with it in their own specific ways.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Russell King - ARM Linux]

On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> The first one is that this overscanning should be reported by the
> connector I guess? but this is really TV specific, so we need one way
> to let the user tell how the image is displayed on its side, and we
> cannot really autodetect it, and this needs to be done at runtime so
> that we can present some shiny interface to let it select which
> overscan ratio works for him/her.

See xbmc... they go through a nice shiny setup which includes adjusting
the visible area.  From what I remember, it has pointers on each corner
which you can adjust to be just visible on the screen, so xbmc knows
how much overscan there is, and xbmc itself reduces down to the user
set size.

> The second one is that we still need to expose the reduced modes to
> userspace, and not only the displayed size, so that the applications
> know what they must draw on. But I guess this could be adjusted by the
> core too.
> 
> In order to work consistently, I think all planes should be adjusted
> that way, so that relative coordinates are from the primary plane
> origin, and not the display origin. But that could be adjusted too by
> the core I guess.

I'm not sure about that - we want the graphics to be visible, but that
may not be appropriate for an video overlay frame.  It's quite common
for (eg) broadcast video to contain dead pixels or other artifacts on
the right hand side, and the broadcast video expects overscan to be
present.

I know this because I have run my TV with overscan disabled, even for
broadcast TV.

> The fourth one being the major one. Every time I raised the issue on
> IRC, the answer basically was "we don't care about analog", so I'm a
> bit pessimistic about whether dealing with this in the core would be
> accepted, hence why I chose to deal with this at the driver level.

Yea, that's quite sad, "analog" has become a dirty word, but really
this has nothing to do with "analog" at all - there are LCD TVs (and
some monitors) out there which take HDMI signals but refuse to
disable overscan no matter what you do to them if you provide them
with a "broadcast"  mode - so the analog excuse is very poor.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Jean-Francois Moine]

On Tue, 18 Oct 2016 12:03:49 +0200
Maxime Ripard  wrote:

> The fourth one being the major one. Every time I raised the issue on
> IRC, the answer basically was "we don't care about analog", so I'm a
> bit pessimistic about whether dealing with this in the core would be
> accepted, hence why I chose to deal with this at the driver level.

The same problem exists with HDMI and old TVs (mine is an ASUS 22T1E):
these TVs overscan as soon as AVI frames are in the stream.

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi Russell,

On Tue, Oct 18, 2016 at 10:24:22AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> > The Allwinner display engine doesn't have any kind of hardware help to deal
> > with TV overscan.
> 
> I'm not sure I follow.  My understanding (from reading the CEA specs)
> is that TVs are expected to overscan the image, so the upper left, and
> bottom right pixels are not visible.

Yes, this is why we have to work around it somehow.

> I assume we are talking about TVs connected via HDMI.  In the HDMI AVI
> infoframe, there are bits which specify whether the image should be
> overscanned or underscanned - however, whether a TV implements those
> bits is rather sketchy.  I assume when you say "any kind of hardware
> help" you mean you can't control these bits?
> 
> However, some (most?) TVs now implement a menu option which allows the
> (over)scan mode to be selected.  Others assume that if it's a TV mode,
> it's supposed to be overscanned, if it's a "PC" mode, it should be
> underscanned and provide no option to change the behaviour.

We're talking about plain dumb composite output, so no infoframes,
setup or anything here :)

> > This means that if we use the only mode the hardware provides (either PAL
> > or NTSC, or something else), most of the screens will crop the borders of
> > the image, which is bad.
> 
> I think you're trying to apply monitor-type behaviour to TVs...

Yes, kind of. Our users are usually running a desktop distro, and the
default output on those boards are just plain composite, which means
running any DE onto a TV.

Note that it's not only about the interface itself, but you'll lose
content for all pictures displayed. And no one cares about the TV safe
area anymore these days (starting with the framebuffer console).

> > We can however use somekind of a hack, to instead reduce the mode
> > exposed to the userspace, and center it in the final image. We
> > would expose different overscan ratio to be able to deal with most
> > of the screens, each reducing more the displayable area.
> 
> I'm not sure we need "a hack".  What if we treated the primary plane just
> like any other (eg, overlay) plane?  We could then specify (eg) a 1920x1080
> display mode, but with the primary plane reduced in size, positioned in
> the centre of the display mode?
> 
> I know that there's hardware out there which can do exactly that - Marvell
> Dove implements this: you set the display size separately from two planes,
> one graphics plane and one video plane.  Both planes can be positioned
> anywhere in the displayed size.

This might have been poorly worded on my side, but it's exactly what
I'm doing in those patches.

> We could then specify at DRM level that a connected device overscans by
> N%, and have the primary plane adjusted by DRM itself.

I'd agree with you, however, there's a few issues with that I
think.

The first one is that this overscanning should be reported by the
connector I guess? but this is really TV specific, so we need one way
to let the user tell how the image is displayed on its side, and we
cannot really autodetect it, and this needs to be done at runtime so
that we can present some shiny interface to let it select which
overscan ratio works for him/her.

The second one is that we still need to expose the reduced modes to
userspace, and not only the displayed size, so that the applications
know what they must draw on. But I guess this could be adjusted by the
core too.

In order to work consistently, I think all planes should be adjusted
that way, so that relative coordinates are from the primary plane
origin, and not the display origin. But that could be adjusted too by
the core I guess.

The fourth one being the major one. Every time I raised the issue on
IRC, the answer basically was "we don't care about analog", so I'm a
bit pessimistic about whether dealing with this in the core would be
accepted, hence why I chose to deal with this at the driver level.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi,

The Allwinner display engine doesn't have any kind of hardware help to deal
with TV overscan.

This means that if we use the only mode the hardware provides (either PAL
or NTSC, or something else), most of the screens will crop the borders of
the image, which is bad.

We can however use somekind of a hack, to instead reduce the mode exposed
to the userspace, and center it in the final image. We would expose
different overscan ratio to be able to deal with most of the screens, each
reducing more the displayable area.

The first patches are rework for the command line parser in order to be
able to use named modes. This is going to be helpful for us, since
different modes might have the same timings but only differ on a few
settings not exposed in the modes, but it might eventually be used for the
*VGA modes for example.

The last patches extend the current driver to deal with the changes used
to introduce the overscan.

Let me know what you think,
Maxime

Maxime Ripard (5):
  drm/modes: Rewrite the command line parser
  drm/modes: Support modes names on the command line
  drm/sun4i: Add custom crtc state
  drm/sun4i: Compute TCON1 mode from tv mode
  drm/sun4i: Add support for the overscan profiles

 drivers/gpu/drm/drm_connector.c   |   3 +-
 drivers/gpu/drm/drm_fb_helper.c   |   4 +-
 drivers/gpu/drm/drm_modes.c   | 324 +--
 drivers/gpu/drm/sun4i/sun4i_backend.c |  18 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.c|  37 ++-
 drivers/gpu/drm/sun4i/sun4i_crtc.h|  16 +-
 drivers/gpu/drm/sun4i/sun4i_rgb.c |  10 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c  |  75 --
 include/drm/drm_connector.h   |   1 +-
 9 files changed, 342 insertions(+), 146 deletions(-)

-- 
git-series 0.8.10

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Russell King - ARM Linux]

On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> The Allwinner display engine doesn't have any kind of hardware help to deal
> with TV overscan.

I'm not sure I follow.  My understanding (from reading the CEA specs)
is that TVs are expected to overscan the image, so the upper left, and
bottom right pixels are not visible.

I assume we are talking about TVs connected via HDMI.  In the HDMI AVI
infoframe, there are bits which specify whether the image should be
overscanned or underscanned - however, whether a TV implements those
bits is rather sketchy.  I assume when you say "any kind of hardware
help" you mean you can't control these bits?

However, some (most?) TVs now implement a menu option which allows the
(over)scan mode to be selected.  Others assume that if it's a TV mode,
it's supposed to be overscanned, if it's a "PC" mode, it should be
underscanned and provide no option to change the behaviour.

> This means that if we use the only mode the hardware provides (either PAL
> or NTSC, or something else), most of the screens will crop the borders of
> the image, which is bad.

I think you're trying to apply monitor-type behaviour to TVs...

> We can however use somekind of a hack, to instead reduce the mode exposed
> to the userspace, and center it in the final image. We would expose
> different overscan ratio to be able to deal with most of the screens, each
> reducing more the displayable area.

I'm not sure we need "a hack".  What if we treated the primary plane just
like any other (eg, overlay) plane?  We could then specify (eg) a 1920x1080
display mode, but with the primary plane reduced in size, positioned in
the centre of the display mode?

I know that there's hardware out there which can do exactly that - Marvell
Dove implements this: you set the display size separately from two planes,
one graphics plane and one video plane.  Both planes can be positioned
anywhere in the displayed size.

We could then specify at DRM level that a connected device overscans by
N%, and have the primary plane adjusted by DRM itself.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.