search for: overscan

https://bugs.freedesktop.org/show_bug.cgi?id=47846 Bug #: 47846 Summary: Nouveau -> overscan using HDMI Classification: Unclassified Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at...

...itor (IPS235P) via HDMI. At boot time, the video card displays an image on the monitor that is scaled down and surrounded by a black border approximately one inch in width. As far as I've been able to determine, this black border is caused by the video card attempting to compensate for any overscanning done by the monitor. Since the monitor doesn't DO any overscanning, I'd like to PERMANENTLY disable the overscan compensation on the video card. I guess this requires modifying the video BIOS. Does anyone know what needs to be done and how? Best regards, Christian J?rgensen

...+0100, Boris Brezillon wrote: > @@ -924,6 +978,29 @@ struct drm_connector { > */ > struct drm_property_blob *path_blob_ptr; > > + /** > + * @underscan_mode_property: Optional connector underscan mode. Used by > + * the driver to scale the output image and compensate an overscan done > + * on the display side. > + */ > + struct drm_property *underscan_mode_property; > + > + /** > + * @underscan_hborder_property: Optional connector underscan horizontal > + * border (expressed in pixels). Used by the driver to adjust the > + * output image positi...

...m mmiotraces, assuming you can find a kernel that the blob > driver will load on. It's much better to work from the datasheet instead of doing mmiotraces, the blob only has a few modes built-in. The BT is actually a very flexible chip, and supports a very wide range of modes with different overscan amount, plus different filtering options. It probably wouldn't be hard to just take a few modes from nvtv and put them into nouveau, similar to the (very few) Chrontel modes. What's missing is some sort of infrastructure in X to say "look, on this hardware there are these two functio...

...69 appears to have 8 of them, of which I'm guessing only > 4 are actually usable, probably the RGB ones). The 8 "modes" are just predefined sets of values, baked into the chip for easier setup. There's basically an unlimited number of "modes", with any resolution or overscan, subject to timing constraints. Think modelines, but with more values and different registers. BTW, the RGB modes only make sense if you have a special kind of connector. The PAL and NTSC modes are the ones that are normally used on those cards. > The stuff about overscan/etc are exposed as...

...@ struct drm_connector { >> > */ >> > struct drm_property_blob *path_blob_ptr; >> > >> > + /** >> > + * @underscan_mode_property: Optional connector underscan mode. Used by >> > + * the driver to scale the output image and compensate an overscan done >> > + * on the display side. >> > + */ >> > + struct drm_property *underscan_mode_property; >> > + >> > + /** >> > + * @underscan_hborder_property: Optional connector underscan horizontal >> > + * border (expressed in pixels)....

...;> driver will load on. > > > > It's much better to work from the datasheet instead of doing mmiotraces, > > the blob only has a few modes built-in. > > > > The BT is actually a very flexible chip, and supports a very wide range > > of modes with different overscan amount, plus different filtering options. > > > > It probably wouldn't be hard to just take a few modes from nvtv and > > put them into nouveau, similar to the (very few) Chrontel modes. What's > > missing is some sort of infrastructure in X to say "look, on thi...

...gt; + * > + * This can be used to tell the CRTC how the image should be scaled/placed in > + * order to cover fit in the display connected through this connector. Most of > + * the time used to address situations where the display borders are hidden. > + * Can also be used to compensate overscan done on the display side. > + */ > +struct drm_underscan { I'd call this drm_underscan_state, similar to how we have drm_tv_connector_state. > + /** > + * @mode: Underscan mode. > + */ > + enum drm_underscan_mode mode; > + > + /** > + * @hborder: Horizontal borde...

...ind a kernel that the blob >> driver will load on. > > It's much better to work from the datasheet instead of doing mmiotraces, > the blob only has a few modes built-in. > > The BT is actually a very flexible chip, and supports a very wide range > of modes with different overscan amount, plus different filtering options. > > It probably wouldn't be hard to just take a few modes from nvtv and > put them into nouveau, similar to the (very few) Chrontel modes. What's > missing is some sort of infrastructure in X to say "look, on this hardware > ther...

Hello, This is an attempt at providing generic support for underscan connector props. We already have 3 drivers defining the same underscan, underscan vborder and underscan hborder properties (amd, radeon and nouveau) and I am about to add a new one, hence my proposal to put the prop parsing code in the core and add ->underscan fields to drm_connector_state. This v3 was based on the "VC4

https://bugs.freedesktop.org/show_bug.cgi?id=91411 Bug ID: 91411 Summary: TV hdmi output doesn't fit with desktop, minimize button(on windows) are missing, etc[NV50] Product: xorg Version: unspecified Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority:

...n. >> > >> > It's much better to work from the datasheet instead of doing mmiotraces, >> > the blob only has a few modes built-in. >> > >> > The BT is actually a very flexible chip, and supports a very wide range >> > of modes with different overscan amount, plus different filtering options. >> > >> > It probably wouldn't be hard to just take a few modes from nvtv and >> > put them into nouveau, similar to the (very few) Chrontel modes. What's >> > missing is some sort of infrastructure in X to say &q...

--- drivers/gpu/drm/i2c/ch7006_drv.c | 2 +- drivers/gpu/drm/i2c/ch7006_mode.c | 2 +- drivers/gpu/drm/i2c/ch7006_priv.h | 5 ++--- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index c2594a1..7df4b86 100644 --- a/drivers/gpu/drm/i2c/ch7006_drv.c +++ b/drivers/gpu/drm/i2c/ch7006_drv.c @@ -351,7 +351,7

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/i2c/ch7006_drv.c | 2 +- drivers/gpu/drm/i2c/ch7006_mode.c | 2 +- drivers/gpu/drm/i2c/ch7006_priv.h | 5 ++--- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index c2594a1..7df4b86 100644 ---

...ed to a connector state + * + * This can be used to tell the CRTC how the image should be scaled/placed in + * order to cover fit in the display connected through this connector. Most of + * the time used to address situations where the display borders are hidden. + * Can also be used to compensate overscan done on the display side. + */ +struct drm_underscan { + /** + * @mode: Underscan mode. + */ + enum drm_underscan_mode mode; + + /** + * @hborder: Horizontal border. This values encodes both the left and + * right borders: left_border = right_border = hborder / 2. + */ + unsigned int hborder;...

...> @@ -924,6 +978,29 @@ struct drm_connector { > > */ > > struct drm_property_blob *path_blob_ptr; > > > > + /** > > + * @underscan_mode_property: Optional connector underscan mode. Used by > > + * the driver to scale the output image and compensate an overscan done > > + * on the display side. > > + */ > > + struct drm_property *underscan_mode_property; > > + > > + /** > > + * @underscan_hborder_property: Optional connector underscan horizontal > > + * border (expressed in pixels). Used by the driver to adjus...

Hello, This is an attempt at providing generic support for underscan connector props. We already have 3 drivers defining the same underscan, underscan vborder and underscan hborder properties (amd, radeon and nouveau) and I am about to add a new one, hence my proposal to put the prop parsing code in the core and add ->underscan fields to drm_connector_state. Note that I use this new

...connector + * state + * + * This can be used to tell the CRTC how the image should be scaled/placed in + * order to cover fit in the display connected through this connector. Most of + * the time used to address situations where the display borders are hidden. + * Can also be used to compensate overscan done on the display side. + */ +struct drm_underscan_state { + /** + * @mode: Underscan mode. + */ + enum drm_underscan_mode mode; + + /** + * @hborder: Horizontal border. This values encodes both the left and + * right borders: left_border = right_border = hborder / 2. + */ + unsigned int hbo...

...* This can be used to tell the CRTC how the image should be scaled/placed in > > + * order to cover fit in the display connected through this connector. Most of > > + * the time used to address situations where the display borders are hidden. > > + * Can also be used to compensate overscan done on the display side. > > + */ > > +struct drm_underscan { > > I'd call this drm_underscan_state, similar to how we have > drm_tv_connector_state. > > > + /** > > + * @mode: Underscan mode. > > + */ > > + enum drm_underscan_mode mode; >...

Dirk Thierbach <dthierbach at gmx.de> writes: >[...] >> The stuff about overscan/etc are exposed as KMS properties (which in >> turn appear in xrandr) and not specific to the BT869. > > The problem is that there's no good way to just say "I want this > overscan" and then get a valid set of register values, because of > the timing constraints. Nv...