commit 6946914c42ba2bb0f6f7b6d1351f33af53a145fd Author: Daniel Vetter Date: Tue Aug 11 13:12:06 2009 +0200 Implement drmmode overlay This does not restore the overlay on EnterVT/disable it on LeaveVT. Does not look like this is necessary. Signed-off-by: Daniel Vetter commit 361705901f128de9afac9b43d386abf0be87a5b3 Author: Daniel Vetter Date: Tue Jun 30 11:19:05 2009 +0200 Xv: introduce an overlay hal This is the last preparatory step for overlay support with drmmode. Safe two (specially marked) function calls in the setup code, all hw accessing code goes now through these three new functions with the ums_overlay prefix. Signed-off-by: Daniel Vetter commit 3f8b26f517d6bea6dc326136b6e9ea9d210e9a5a Author: Daniel Vetter Date: Tue Aug 11 15:56:34 2009 +0200 Xv: rework overlay buffer management The basic idea is to only pin the buffer into the gtt when the overlay hw is actually using it. This results in a few changes: - Unify data copied/buffer handling with textured video. Now offsets are always buffer relative and we just use drm_bo_map to access a buffer. - Implement double buffering using two bo's. This is necessary because we can't pin the same buffer to the gtt and map it as normal memory. - Kill XV_DOUBLE_BUFFER. With the above changes, overlay video is always doubel buffered. There is still the XvMC passthrough case, which makes the code slightly ugly. Unfortunately we can't get at the bo behind this buffer. Changes since the last review-round: - Don't overallocate by a factor of 2. - Prevent possible use-after-free issue. commit 06188abbed359c266f2033d8b3b28aa0aaf8aada Author: Daniel Vetter Date: Mon Jun 29 11:32:54 2009 +0200 Xv: create xvmc_passthrough helper This way all thes strange special cases make much more sense. Signed-off-by: Daniel Vetter commit a7f820dc61efe4aa77b22dd4aaefd08ca97213a6 Author: Daniel Vetter Date: Mon Jun 29 10:25:07 2009 +0200 Xv: scrap overlay offscreen pixmap support The code looks like it's been bitrotting since being copied over from the i810 driver. Furthermore painting rgb pixmaps with the overlay engine is in these days of modern compositing X an absolute no-go. And textured video doesn't support it neither, so its likely never ever used by applications. Signed-off-by: Daniel Vetter commit 3a4e39fa527e6f1bec9306a0c9d7b69b222532a6 Author: Daniel Vetter Date: Thu Jul 2 13:50:09 2009 +0200 Xv: small cleanups in I830PutImage - scrap unused variable overlay - scrap an superflous if and attach the code to the preceeding else - tiny layout fix. Signed-off-by: Daniel Vetter commit b8bdd7f6ec3ac9aa7406ec92c86c3652e1044e42 Author: Daniel Vetter Date: Thu Jul 2 13:45:05 2009 +0200 Xv I830PutImage splitup: extract i830_wait_for scanline Also scrap the unecessary variable sync in I830PutImage and the accompanying obfuscated logic. Signed-off-by: Daniel Vetter commit 52250eeaf73398c9c1f91ca7b2317f785f8eba56 Author: Daniel Vetter Date: Thu Jul 2 13:34:20 2009 +0200 Xv I830PutImage splitup: extract i830_copy_video_data Just moves the code and passes back allocation failures. Signed-off-by: Daniel Vetter commit c90e5dfcd7d5789ff41d69c60accb4bd59190337 Author: Daniel Vetter Date: Thu Jul 2 13:28:38 2009 +0200 Xv I830PutImage splitup: extract i830_setup_video_buffer Just move the code and pass back allocation failures. Signed-off-by: Daniel Vetter commit 3e0435569d2d7f58d58eb2f7c8a6952cc29b6934 Author: Daniel Vetter Date: Thu Jul 2 13:19:53 2009 +0200 Xv I830PutImage splitup: extract i830_dst_pitch_and_size Just moves the code. Signed-off-by: Daniel Vetter commit 8a3ddc0d78dcb40a14f8037b81cf202eaa40c301 Author: Daniel Vetter Date: Sat Jun 27 23:08:58 2009 +0200 Xv: kill destId in I830PutImage It's only used to remember that XvMC has ỲV12 as output. is_planar_fourcc already takes care of that in all necessary cases. Signed-off-by: Daniel Vetter commit 2096013512e0099bfbb89439943c1b70cccabc92 Author: Daniel Vetter Date: Tue Aug 11 13:54:23 2009 +0200 Xv: kill hw double buffering logic The idea for the hw double buffering support is to program two fixed buffers and then only switch buffers in the OCMD register. But the driver as-is always programs the new buffer address (in both register sets when double buffered). Therefore we gain nothing by using this hw capability. Scrap the software support for it. When double buffered, we now allocate just a buffer of size 2*size and switch between the two parts purely in software. To make reviewing this easier, I'll shortly explain the differences of how double-buffering (i.e. tear-free video) is achieved before and after this change: - When double buffer, allocate a buffer twice the size (unchanged). - Depending upon the currently shown buffer-half, copy the new frame into the other buffer-half. In the old code this is done by using the right set of buffer offsets, either *Buf0Offset or *Buf1Offset. The new code simply programs the offset for the right buffer-half into the single set of offsets. The end-result is unchanged. Now the big difference in hw-programming: Old: Programm new buffer offset into both sets of _hw_ buffer offset registers. Depending upon the current _sw_ buffer, select the _hw_ buffer and program this into the OCMD register. This just complicates matters unnecessarly. New: Just always use the hw buffer 0. And then it's again the same story in both old and new code: - Execute an overlay flip (MI_OVERLAY_FLIP) to read in the contents of the hw registers into the shadow hw registers (which are actually being used by the overlay, not the ones we write stuff into). This is synchronized with the respective crtc vblank by the hw. Signed-off-by: Daniel Vetter commit 891b387c6b31972a3e339508e57bd660b2991a17 Author: Daniel Vetter Date: Fri Jul 3 09:59:40 2009 +0200 Xv: use is_planar_fourcc helper some more Signed-off-by: Daniel Vetter commit f09d9543216d129f2abd0d3ad871519d0cee2eba Author: Daniel Vetter Date: Fri Jul 3 09:57:33 2009 +0200 Xv: introduce planar memcpy helper Reduced 3 copies of the same code to one. Signed-off-by: Daniel Vetter commit 10614c7dd4ecbb1b4d3dd6a15b949cb389053f1f Author: Daniel Vetter Date: Thu Jul 2 12:32:53 2009 +0200 Xv: rename i830_display_video to i830_display_overlay This function only programs the overlay and is never called for textured video. Make this obvious. Signed-off-by: Daniel Vetter commit c10db56e09177cfc2192dc632aa5df8f1d791139 Author: Daniel Vetter Date: Thu Jul 2 12:31:37 2009 +0200 Xv i830_display_video splitup: extract i830_overlay_cmd This slightly moves around (and simplifies) the OSTRIDE reg programming, too. Signed-off-by: Daniel Vetter commit 0328734a90544a6cd72d9eaf64015db9d3462921 Author: Daniel Vetter Date: Tue Aug 11 13:51:51 2009 +0200 Xv i830_display_video splitup: extract i830_calc_src_regs Also introduce an is_planar_fourcc helper. I'll use that one later. In i830_display_video this changeset moves the XVMC case (previously obscured as the default case) around. I've figured this default case does not make sense, here's why: XvMC is everywhere else handled as a planar format (e.g. in the register programming a few lines down). Furthermore the id variable gets mapped to FOURCC_YV12 if IS_I915(pI830) is true in I830PutImage. There's a second caller in the offscreen overlay support code. But I think that code is bitrotten and not reliable as an information source. So we have a different behaviour only for id=FOURCC_XVMC and i965 class hw (i830 class doesn't have xvmc). I've crawled through various sources/intel documentations. Finally in the textured video implemention for i965 class hw (src/i965_video.c) I've found a switch statement that puts XVMC into the same case as I420 and YV12. So also in i965 class hw xvmc uses a planar format. In conclusion I claim that this code was bogus and XvMC on i965 class hw over Xv overlay was most likely broken. Signed-off-by: Daniel Vetter