ca9bfa7eed
We have a pretty decent confusion about vertical timings of interlaced modes. Peter Ross has written a patch that makes interlace modes work on a lot more platforms/output combinations by doubling the vertical timings. The issue with that patch is that core drm _does_ support specifying whether we want these vertical timings in fields or frames, we just haven't managed to consistently use this facility. The relavant function is drm_mode_set_crtcinfo, which fills in the crtc timing information. The first thing to note is that the drm core keeps interlaced modes in frames, but displays modelines in fields. So when the crtc modeset helper copies over the mode into adjusted_mode it will already contain vertical timings in half-frames. The result is that the fixup code in intel_crtc_mode_fixup doesn't actually do anything (in most cases at least). Now gen3+ natively supports interlaced modes and wants the vertical timings in frames. Which is what sdvo already fixes up, at least under some conditions. There are a few other place that demand vertical timings in fields but never actually deal with interlaced modes, so use frame timings for consistency, too. These are: - lvds panel, - dvo encoders - dvo is the only way gen2 could support interlaced mode, but currently we don't support any encoders that do. - tv out - despite that the tv dac sends out an interlaced signal it expects a progressive mode pipe configuration. All these encoders enforce progressive modes by resetting interlace_allowed. Hence we always want crtc vertical timings in frames. Enforce this in our crtc mode_fixup function and rip out any redudant timing computations from the encoders' mode_fixup function. v2-4: Adjust the vertical timings a bit. v5: Split out the 'subtract-one for interlaced' fixes. v6: Clarify issues around tv-out and gen2. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
||
|---|---|---|
| .. | ||
| exynos | ||
| gma500 | ||
| i2c | ||
| i810 | ||
| i915 | ||
| mga | ||
| nouveau | ||
| r128 | ||
| radeon | ||
| savage | ||
| sis | ||
| tdfx | ||
| ttm | ||
| via | ||
| vmwgfx | ||
| ati_pcigart.c | ||
| drm_agpsupport.c | ||
| drm_auth.c | ||
| drm_buffer.c | ||
| drm_bufs.c | ||
| drm_cache.c | ||
| drm_context.c | ||
| drm_crtc.c | ||
| drm_crtc_helper.c | ||
| drm_debugfs.c | ||
| drm_dma.c | ||
| drm_dp_i2c_helper.c | ||
| drm_drv.c | ||
| drm_edid.c | ||
| drm_edid_modes.h | ||
| drm_encoder_slave.c | ||
| drm_fb_helper.c | ||
| drm_fops.c | ||
| drm_gem.c | ||
| drm_global.c | ||
| drm_hashtab.c | ||
| drm_info.c | ||
| drm_ioc32.c | ||
| drm_ioctl.c | ||
| drm_irq.c | ||
| drm_lock.c | ||
| drm_memory.c | ||
| drm_mm.c | ||
| drm_modes.c | ||
| drm_pci.c | ||
| drm_platform.c | ||
| drm_proc.c | ||
| drm_scatter.c | ||
| drm_stub.c | ||
| drm_sysfs.c | ||
| drm_trace.h | ||
| drm_trace_points.c | ||
| drm_usb.c | ||
| drm_vm.c | ||
| Kconfig | ||
| Makefile | ||
| README.drm | ||
************************************************************
* For the very latest on DRI development, please see: *
* http://dri.freedesktop.org/ *
************************************************************
The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).
The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:
1. The DRM provides synchronized access to the graphics hardware via
the use of an optimized two-tiered lock.
2. The DRM enforces the DRI security policy for access to the graphics
hardware by only allowing authenticated X11 clients access to
restricted regions of memory.
3. The DRM provides a generic DMA engine, complete with multiple
queues and the ability to detect the need for an OpenGL context
switch.
4. The DRM is extensible via the use of small device-specific modules
that rely extensively on the API exported by the DRM module.
Documentation on the DRI is available from:
http://dri.freedesktop.org/wiki/Documentation
http://sourceforge.net/project/showfiles.php?group_id=387
http://dri.sourceforge.net/doc/
For specific information about kernel-level support, see:
The Direct Rendering Manager, Kernel Support for the Direct Rendering
Infrastructure
http://dri.sourceforge.net/doc/drm_low_level.html
Hardware Locking for the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
A Security Analysis of the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/security_low_level.html