On Tue, Aug 12, 2008 at 10:44:37PM +0100, Gavin Hamill wrote:
I have a system not dissimilar to yours.. it's a P3-1GHz with PCI Radeon 7000. OS is Ubuntu hardy with the patches from your 0.0.2 release.
ok
Now that I've got the patches in place, I get a stable desktop display on the TV.
good
If I start vdr / xineliboutput, the picture will be Ok for a second.. then it'll move up and down (like camera wobble, but it moves the onscreen logos / VDR menus, too!).
I guess it's because it wants to resync the inital field polarity.
I see this kind of thing at least once per second :
[ 2706.402871] [drm] changed radeon drift trim from 00520125 -> 0052018c
right. The lowest byte 8c confirms my assumption about field polarity.
If I quit vdr (leaving X running), and run the 'drift_control' tool, I see a drift speed of approx -3900 for 4 seconds, then +16000 marked 'excessive drift speed'
I think it is the best to gradually step forward. Could you please do the following and report the results. To be on the safe side I just repeated all steps myself with reproducible results:
1. for the moment please encomment both in 'radeon_video.c' and 'drift_control'
//#define RESYNC_FIELD_POLARITY_METHOD1 //#define RESYNC_FIELD_POLARITY_METHOD2
because this must clearly be fixed in xine. Though it works in my current configuration. Maybe we can reenable it later.
2. start the Xserver (but still without vdr) 3. run 'drift_control a'
this should give you typically an output like this:
# drift_control a tv now: 1218633290.553468 tv vbl: 1218633290.538542 vbls: 43163 trim: 0x00520100 sync point displacement: 9871 drift speed: -19 overall compensation: 339 o. c. clipped: 339 trim absolute: 339 t. a. clipped: 37 new trim: 0x80520125
tv now: 1218633291.553497 tv vbl: 1218633291.539525 vbls: 43213 trim: 0x00520125 sync point displacement: 3972 drift speed: -954 overall compensation: 104 o. c. clipped: 104 trim absolute: 141 t. a. clipped: 37 new trim: 0x80520125
tv now: 1218633292.553471 tv vbl: 1218633292.540529 vbls: 43263 trim: 0x00520125 sync point displacement: 2942 drift speed: -1030 overall compensation: 65 o. c. clipped: 65 trim absolute: 102 t. a. clipped: 37 new trim: 0x80520125
tv now: 1218633293.553429 tv vbl: 1218633293.541534 vbls: 43313 trim: 0x00520125 sync point displacement: 1895 drift speed: -1047 overall compensation: 29 o. c. clipped: 29 trim absolute: 66 t. a. clipped: 37 new trim: 0x80520125
tv now: 1218633294.553387 tv vbl: 1218633294.542539 vbls: 43363 trim: 0x00520125 sync point displacement: 848 drift speed: -1047 overall compensation: -6 o. c. clipped: -6 trim absolute: 31 t. a. clipped: 31 new trim: 0x8052011f
tv now: 1218633295.553358 tv vbl: 1218633295.543374 vbls: 43413 trim: 0x0052011f sync point displacement: -16 drift speed: -864 overall compensation: -30 o. c. clipped: -30 trim absolute: 1 t. a. clipped: 1 new trim: 0x80520101
tv now: 1218633296.553329 tv vbl: 1218633296.543358 vbls: 43463 trim: 0x00520101 sync point displacement: -29 drift speed: -13 overall compensation: -1 completed o. c. clipped: -1 trim absolute: 0 t. a. clipped: 0 new trim: 0x80520100
tv now: 1218633297.553298 tv vbl: 1218633297.543296 vbls: 43513 trim: 0x00520100 sync point displacement: 2 drift speed: 31 overall compensation: 1 completed o. c. clipped: 1 trim absolute: 1 t. a. clipped: 1 new trim: 0x80520101
tv now: 1218633298.553269 tv vbl: 1218633298.543262 vbls: 43563 trim: 0x00520101 sync point displacement: 7 drift speed: 5 overall compensation: 0 completed o. c. clipped: 0 trim absolute: 1 t. a. clipped: 1 new trim: 0x80520101
it is important after some time 'sync point displacement' and 'drift speed' are floating around zero.
4. stop drift_control 5. unload all dvb modules (there are known issues with some) 6. start vdr with local sxfe frontend (make channels.conf zero size file) 7. start replay of some recording. Because field polarity is not synced automatically anymore you can manually restart replay until polarity is correct.
this should give you typically an output (Xorg.0.log) like this:
sync point displacement: -7816 drift speed: -716 overall compensation: -294 sync point displacement: -7503 drift speed: 832 overall compensation: -230 sync point displacement: -6514 drift speed: 1293 overall compensation: -180 sync point displacement: -5394 drift speed: 906 overall compensation: -154 sync point displacement: -4261 drift speed: 1226 overall compensation: -104 sync point displacement: -3142 drift speed: 1154 overall compensation: -68 sync point displacement: -2006 drift speed: 1034 overall compensation: -33 sync point displacement: -875 drift speed: 1218 overall compensation: 11 sync point displacement: 89 drift speed: 796 overall compensation: 30 sync point displacement: 470 drift speed: -75 overall compensation: 13 sync point displacement: 235 drift speed: -391 overall compensation: -5 sync point displacement: -127 drift speed: -258 overall compensation: -13 sync point displacement: -230 drift speed: 55 overall compensation: -6 sync point displacement: -38 drift speed: 271 overall compensation: 8 sync point displacement: 99 drift speed: 43 overall compensation: 4 sync point displacement: 93 drift speed: -62 overall compensation: 1 completed sync point displacement: -15 drift speed: -107 overall compensation: -4 sync point displacement: -58 drift speed: -2 overall compensation: -2 sync point displacement: -30 drift speed: 41 overall compensation: 0 completed sync point displacement: 23 drift speed: -27 overall compensation: 0 completed
again as in our previous example with drift_control the value of 'sync point displacement' starts mostly at very high offset. The algorithm uses 'drift speed' to converge 'sync point displacement' against zero. After a few cycles even an 'overall compensation' of 0 is possible.
The picture quality should be as good as accustomed from RGB/PAL CRT.
If the 'drift speed' value finally does show large deviations from zero this could be a problem in your xine-lib. In that case I upload my current xine-lib version to my web server.
Good luck Thomas