...I think I'm fallen in love with it...
However, I'm facing a problem concerning it's TV encoder (VT1622),
or at least the register tables from viafb. Using 720x576 doesn't
produce a TV picture as expected. Even using overscan there's way too
much of it within the visible area of a standard TV set, i.e. the picture
is scaled down, producing interferential effects and blurry motions when
the framebuffer contains interlaced data. Also, the scaling results in a
pulpy picture in general.
I tried all supported modes with and without overscan. None of these
correctly passed through the interlaced information to the TV set.
I wrote a small test program which fills even lines with black and odd
lines with white pixels. The TV set should turn into a stroboscope, but
instead it shows a steady gray picture. Using the different modes just
varies how homogenous this gray picture is, actually making the interference
more or less visible.
I would appreciate any help or documentation about VT1622(M).
Ville: How does dfbmga display interlaced videos on CRTC2 flawlessly
regardless of how much the video is stretched to fullscreen? Does it
stretch the fields seperately?
----- Forwarded message from Denis Oliver Kropp via CVS <[EMAIL PROTECTED]> -----
To: [EMAIL PROTECTED]
From: Denis Oliver Kropp via CVS <[EMAIL PROTECTED]>
Subject: [directfb-cvs] DirectFB
Date: Fri, 28 Nov 2003 07:06:14 +0100
Reply-to: [EMAIL PROTECTED]
CVSROOT: /cvs/directfb
Module name: DirectFB
Changes by: dok 20031128 07:06:14
Modified files:
gfxdrivers/cle266: uc_accel.c uc_accel.h uc_hwmap.c uc_hwset.c
uc_state.c unichrome.c unichrome.h
Log message:
Disabled dithering again...
... because: I fixed the triangle (rectangle) color bug! ;-] *jump* *jump*
Use HC_HShading_FlatC instead of HC_HShading_FlatA, so the hardware takes the
color value from vertex C which is the only vertex being written twice, i.e.
once for each triangle. It seems that the hardware (which got the color via
vertex A only once for both triangles) kept an RGB16 version of the color
and used that for the second triangle...
To clarify this in the code even more, vertex A and vertex B have a '0' instead
of 'ucdev->color3d' written to the FIFO.
I also changed uc_fill_rectangle_3d() to use the "HC_HVCycle_AA, HC_HVCycle_BB,
HC_HVCycle_NewC" sequence to use HC_HShading_FlatC instead of HC_HShading_FlatA.
Heavy DMA problems with v4l overlay capture some to be gone! ;-] *jump* *jump*
Still some minor glitches are noticable under huge GPU load.
But these appear just for one frame. There are no dead regions
(bunch of lines which can't be written to for several seconds) anymore.
The fix seemed to be setting 'ucdev->must_wait = 1' after flushing the FIFO
in uc_emit_commands(), it was never set to 1 at all before.
Fixed the broken fonts problem! ;-] *jump* *jump*
Added uc_flush_texture_cache() which simply writes four entries to the FIFO.
These entries were written in uc_set_source3d() before my changes...
Use correct state invalidation now,
e.g. no longer set 'v_source3d = 0' if the source wasn't changed ;)
Removed UC_FIFO_FLUSH(fifo) from uc_set_state() again :-}
Use UC_FIFO_PAD_EVEN(fifo) at all places where 'cmdA_End' was replicated before,
doesn't give any performance improvement though...
Changed the FIFO depth from 2000 to 4096 entries to finish a complete string
without intermediate flushing, even if the string has more than ~70 characters.
Added timeout error message to uc_waitcmd() and uc_engine_sync().
Fixed passing of the destination format to uc_map_blending_fn().
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-cvs" as subject.
----- End forwarded message -----
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-users" as subject.
