On Donnerstag 20 April 2006 17:33, Tom Bridgwater wrote: > I have better luck using UDP for coherent debugging output. > > In /etc/directfbrc add (192.168.1.100 is the machine where you watch > the log): > log-udp=192.168.1.100:8088 > > On the machine where you watch the log, run: > socat - udp4-listen:8088,fork > > In your own program you can get your debugging in that same stream > using D_DEBUG macros instead of fprintf(stderr ...) or cerr<< > http://www.directfb.org/wiki/index.php/Direct:Debug >
Thanks for the hint, I guess I have to consider this for future debugging statements. I found the bug, and it's a plain softdevice bug. I copied vdr's setup.conf file from an existing vdr instance of mine. In this setup, I'd set our OSD drawing mode to software alpha blending. When this is set, constructor of cDFBVideoOut super class starts a thread for refreshing which takes some action, even constructor of derived class has not yet finished :-( . > /TomB > > On Apr 19, 2006, at 10:55 PM, Stefan Lucke wrote: > > >> Results are very strange. I thought a fprintf to stderr is > >> unbuffered, > >> but that seem to be no longer true, as I see your SetParms() method > >> beeing called when _not_ all messages from constructor are printed. > > -- Stefan Lucke _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
