- 07 9月, 2009 1 次提交
-
-
由 Zhao Yakui 提交于
When we need to add the standard timing mode, we will firstly check whether it can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate. If it can't be found, then we will use the cvt/gtf to add the required mode. If it can be found, it will be returned. At the same time the function of drm_mode_vrefresh is also fixed. It will return the result of actual refresh_rate plus 0.5. For example: When the calculated value is 84.9, then the fresh_rate is 85. When the calculated value is 70.02, then the fresh_rate is 70. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 8月, 2009 1 次提交
-
-
由 Francisco Jerez 提交于
The calculated vdisplay was half the right value. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 09 8月, 2009 1 次提交
-
-
由 Keith Packard 提交于
The code which takes probed modes and adds them to a connector eliminates duplicate modes by comparing them using drm_mode_equal. That function doesn't consider the type bits, which means that any modes which differ only in the type field will be lost. One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit. If the mode with that bit is lost, then higher level code will not know which mode to select, causing a random mode to be used instead. This patch simply merges the two mode type bits together; that seems reasonable to me, but perhaps only a subset of the bits should be used? None of these can be user defined as they all come from looking at just the hardware. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 8月, 2009 2 次提交
-
-
由 Zhao Yakui 提交于
Two macro definitions of DRM_DEBUG_KMS/MODE can be used to add the debug info related with KMS. It is confusing. So remove the macro definition of DRM_DEBUG_MODE. Instead it can be replaced by the DRM_DEBUG_KMS. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Acked-by: NIan Romanick <ian.d.romanick@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Zhao Yakui 提交于
We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS /DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME as default prefix. So remove the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Acked-by: NIan Romanick <ian.d.romanick@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 7月, 2009 2 次提交
-
-
由 Zhao Yakui 提交于
Add the GTF algorithm in kernel space. And this function can be called to generate the required modeline. I copied it from the file of xserver/hw/xfree86/modes/xf86gtf.c. What I have done is to translate it by using integer calculation. This is to avoid the float-point calculation in kernel space. At the same tie I also refer to the function of fb_get_mode in drivers/video/fbmon.c Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Zhao Yakui 提交于
Add the CVT algorithm in kernel space. And this function can be called to generate the required modeline. I copied it from the file of xserver/hw/xfree86/modes/xf86cvt.c. What I have done is to translate it by using integer calculation. This is to avoid the float-point calculation in kernel space. [airlied:- cleaned up some bits] Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 12 6月, 2009 1 次提交
-
-
由 yakui_zhao 提交于
Replace the DRM_DEBUG with DRM_DEBUG_MODE macro to print the info in drm_mode. airlied:- fixed up to remove a conflicting #define Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 29 12月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
Add mode setting support to the DRM layer. This is a fairly big chunk of work that allows DRM drivers to provide full output control and configuration capabilities to userspace. It was motivated by several factors: - the fb layer's APIs aren't suited for anything but simple configurations - coordination between the fb layer, DRM layer, and various userspace drivers is poor to non-existent (radeonfb excepted) - user level mode setting drivers makes displaying panic & oops messages more difficult - suspend/resume of graphics state is possible in many more configurations with kernel level support This commit just adds the core DRM part of the mode setting APIs. Driver specific commits using these new structure and APIs will follow. Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com> Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-