Displaying 20 results from an estimated 51 matches for "vrefresh".
Did you mean:
refresh
2020 Apr 28
0
[PATCH v3 03/16] drm: Nuke mode->vrefresh
From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
Get rid of mode->vrefresh and just calculate it on demand. Saves
a bit of space and avoids the cached value getting out of sync
with reality.
Mostly done with cocci, with the following manual fixups:
- Remove the now empty loop in drm_helper_probe_single_connector_modes()
- Fix __MODE() macro in ch7006_mode.c
- Fix DRM_MOD...
2020 Apr 04
0
[PATCH v2 03/17] drm: Nuke mode->vrefresh
Hi Ville
Thanks for the patch.
One comment below.
Thanks
Abhinav
On 2020-04-03 13:39, Ville Syrjala wrote:
> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in
> drm_helper_probe_single_connector_modes()
> - Fix __MODE()...
2020 Apr 03
3
[PATCH v2 03/17] drm: Nuke mode->vrefresh
From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
Get rid of mode->vrefresh and just calculate it on demand. Saves
a bit of space and avoids the cached value getting out of sync
with reality.
Mostly done with cocci, with the following manual fixups:
- Remove the now empty loop in drm_helper_probe_single_connector_modes()
- Fix __MODE() macro in ch7006_mode.c
- Fix DRM_MOD...
2020 Feb 19
5
[PATCH 04/12] drm: Nuke mode->vrefresh
From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
Get rid of mode->vrefresh and just calculate it on demand. Saves
a bit of space and avoids the cached value getting out of sync
with reality.
Mostly done with cocci, with the following manual fixups:
- Remove the now empty loop in drm_helper_probe_single_connector_modes()
- Fix __MODE() macro in ch7006_mode.c
- Fix DRM_MOD...
2020 Feb 25
2
[PATCH 04/12] drm: Nuke mode->vrefresh
On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> On 19.02.2020 21:35, Ville Syrjala wrote:
> > From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
> >
> > Get rid of mode->vrefresh and just calculate it on demand. Saves
> > a bit of space and avoids the cached value getting out of sync
> > with reality.
> >
> > Mostly done with cocci, with the following manual fixups:
> > - Remove the now empty loop in drm_helper_probe_single_connector_modes()
&g...
2020 Feb 24
0
[PATCH 04/12] drm: Nuke mode->vrefresh
On 19.02.2020 21:35, Ville Syrjala wrote:
> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro i...
2020 Feb 25
0
[PATCH 04/12] drm: Nuke mode->vrefresh
On 25.02.2020 12:21, Ville Syrj?l? wrote:
> On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
>> On 19.02.2020 21:35, Ville Syrjala wrote:
>>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
>>>
>>> Get rid of mode->vrefresh and just calculate it on demand. Saves
>>> a bit of space and avoids the cached value getting out of sync
>>> with reality.
>>>
>>> Mostly done with cocci, with the following manual fixups:
>>> - Remove the now empty loop in drm_helper_probe_single_conne...
2010 Jun 17
0
nouveau - artefacts and crash with composite enabled (kwin4)
...ction Monitor0
[ 4325.073] (**) NOUVEAU(0): Option "PreferredMode" "1280x1024_60.00"
[ 4325.232] (II) NOUVEAU(0): Output DVI-D-1 has no monitor section
[ 4325.339] (II) NOUVEAU(0): EDID for output VGA-1
[ 4325.339] (II) NOUVEAU(0): Not using default mode "640x350" (vrefresh
out of range)
[ 4325.339] (II) NOUVEAU(0): Not using default mode "320x175" (vrefresh
out of range)
[ 4325.340] (II) NOUVEAU(0): Not using default mode "640x400" (vrefresh
out of range)
[ 4325.340] (II) NOUVEAU(0): Not using default mode "320x200" (vrefresh
out...
2020 Apr 03
0
[PATCH v2 03/17] drm: Nuke mode->vrefresh
Hi Ville,
Thank you for the patch.
On Fri, Apr 03, 2020 at 11:39:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro...
2020 Apr 06
1
[PATCH v2 03/17] drm: Nuke mode->vrefresh
...On 2020-04-03 13:39, Ville Syrjala wrote:
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index fec1c33b3045..e3d5f011f7bd 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -759,9 +759,7 @@ int drm_mode_vrefresh(const struct drm_display_mode
>> *mode)
>> {
>> int refresh = 0;
>>
>> - if (mode->vrefresh > 0)
>> - refresh = mode->vrefresh;
>
> The mode->vrefresh has been replaced with calling this API in all its
> usages.
> However in this AP...
2020 Feb 25
2
[PATCH 04/12] drm: Nuke mode->vrefresh
...02.2020 12:21, Ville Syrj?l? wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_...
2020 Feb 25
0
[PATCH 04/12] drm: Nuke mode->vrefresh
...?l? wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2020 21:35, Ville Syrjala wrote:
> > >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com>
> > >>>
> > >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> > >>> a bit of space and avoids the cached value getting out of sync
> > >>> with reality.
> > >>>
> > >>> Mostly done with cocci, with the following manual fixups:
> > >>> - Remove t...
2018 Aug 24
0
Nouveau doesn't detect DVI - Monitor
...400 403 409 417 -hsync +vsync (25.0 kHz)
[ 8.612] (II) NOUVEAU(0): Modeline "640x350"x59.8 17.52 640 664 720 800 350 353 363 366 -hsync +vsync (21.9 kHz)
[ 8.613] (II) NOUVEAU(0): EDID for output DVI-D-1
[ 8.613] (II) NOUVEAU(0): Not using default mode "640x350" (vrefresh out of range)
[ 8.613] (II) NOUVEAU(0): Not using default mode "320x175" (vrefresh out of range)
[ 8.613] (II) NOUVEAU(0): Not using default mode "640x400" (vrefresh out of range)
[ 8.613] (II) NOUVEAU(0): Not using default mode "320x200" (vrefresh out of r...
2020 Feb 22
0
[PATCH 04/12] drm: Nuke mode->vrefresh
...3 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -538,7 +538,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> */
> /* (ps/s) / (pixels/s) = ps/pixels */
> pclk = DIV_ROUND_UP_ULL(1000000000000,
> - (mode->vrefresh * mode->htotal * mode->vtotal));
> + (drm_mode_vrefresh(mode) * mode->htotal * mode->vtotal));
> dev_dbg(d->dev, "picoseconds between two pixels: %llu\n",
> pclk);
>
This just caught my eye while browsing the patch.
It looks like a backward way to get...
2017 Jan 17
0
[PATCH 5/6] drm: Delete "mandatory" stereographic modes
...rm_edid.c b/drivers/gpu/drm/drm_edid.c
index 336be31..723116a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2926,70 +2926,6 @@ do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
return modes;
}
-struct stereo_mandatory_mode {
- int width, height, vrefresh;
- unsigned int flags;
-};
-
-static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
- { 1920, 1080, 24, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
- { 1920, 1080, 24, DRM_MODE_FLAG_3D_FRAME_PACKING },
- { 1920, 1080, 50,
- DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
-...
2023 Oct 07
1
[PATCH] drm/nouveau/dispnv04: fix a possible null pointer dereference
...17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -209,6 +209,8 @@ static int nv17_tv_get_ld_modes(struct drm_encoder *encoder,
struct drm_display_mode *mode;
mode = drm_mode_duplicate(encoder->dev, tv_mode);
+ if (!mode)
+ continue;
mode->clock = tv_norm->tv_enc_mode.vrefresh *
mode->htotal / 1000 *
--
2.37.2
2009 Nov 24
13
[Bug 25258] New: [9400M] KMS and X do not use monitor's native resolution
http://bugs.freedesktop.org/show_bug.cgi?id=25258
Summary: [9400M] KMS and X do not use monitor's native resolution
Product: xorg
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at
2009 Oct 05
4
[PATCH 1/3] drm/nouveau: Ignore DCB I2C indices for on-chip TV-out.
The nv31m in bug 23212 claims its TV-out and LVDS are in the same
connector. Ignore it completely as it's otherwise useless.
Signed-off-by: Francisco Jerez <currojerez at riseup.net>
---
drivers/gpu/drm/nouveau/nouveau_bios.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
2005 Nov 22
3
x windows dell inspiron 1200 setting for 1366x768
...71 777 806
-hsync -vsync
ModeLine "1366x768" 85.5 1366 1494 1624 1798 768 770 776 795
-hsync +vsync
Option "dpms"
EndSection
There is a line in the log file of:
(II) I810(0): Monitor0: Using hsync range of 31.00-70.00 kHz
(II) I810(0): Monitor0: Using vrefresh range of 50.00-85.00 Hz
(II) I810(0): Not using mode "1366x768" (no mode of this name)
(II) I810(0): Not using built-in mode "1600x1200" (width too large for
virtual size)
(II) I810(0): Not using built-in mode "1280x1024" (width too large for
virtual size)
(1366x768,...
2008 Apr 04
1
Driver Problem with 7150M
...NOUVEAU(0): Using DFP on CRTC 0
(--) NOUVEAU(0): Panel size is 1280 x 800
(II) NOUVEAU(0): Panel is LVDS
(--) NOUVEAU(0): VideoRAM: 131072 kBytes
(==) NOUVEAU(0): Using gamma correction (1.0, 1.0, 1.0)
(II) NOUVEAU(0): Monitor0: Using hsync range of 31.50-50.00 kHz
(II) NOUVEAU(0): Monitor0: Using vrefresh range of 56.00-65.00 Hz
(WW) NOUVEAU(0): Unable to estimate virtual size
(II) NOUVEAU(0): Clock range: 12.00 to 400.00 MHz
(II) NOUVEAU(0): Not using default mode "640x350" (vrefresh out of
range)
(II) NOUVEAU(0): Not using default mode "320x175" (bad mode
clock/interlace/doubl...