User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc7 Firefox/2.0.0.14 Used yum to install blt from Fedora repository. blt version: blt.i386 0:2.4-28.z.fc10 Results from uname -a: Linux ccdlab.ucolick.org 2.6.27.24-170.2.68.fc10.i686 #1 SMP Wed May 20 23:10:16 EDT 2009 i686 i686 i386 GNU/Linux When the blt tabset widget is used with tabs rotated by any angle other than 0 a X error occurs: X Error of failed request: BadMatch (invalid parameter attributes) Reproducible: Always Steps to Reproduce: 1. Copy this little program to a file: #! /usr/bin/wish package require Tclx package require BLT namespace import blt::* tabset .ts -side left -rotate 90 -activebackground green .ts insert end .tstab -text "Test" pack .ts 2. Make it executable and run it. 3. Try -rotate 0. It works. Try anything else, it fails. Actual Results: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RENDER) Minor opcode of failed request: 4 (RenderCreatePicture) Serial number of failed request: 141 Current serial number in output stream: 150 Expected Results: A little widget with the word Test in it. This breaks a major piece of software for us.
I've reproduced this with the barchart1 demo. I'll poke upstream and see if they have any suggestions.
This is actually a bug in the Tk_DrawChars() function in Tk with xft support enabled, that I only see get triggered by BLT. Here's a pointer to a discussion of the problem: http://objectmix.com/tcl/303826-8-5b3-linked-against-x11.html The recommendation is to not call Tk_DrawChars() on a drawable with depth 1, which is precisely what blt is doing. Here's the stack trace when the BadMatch error occurs: #0 _XError (dpy=0x62bb70, rep=0x8988e0) at XlibInt.c:2879 #1 0x0000003a0464ce5f in process_responses (dpy=0x62bb70, wait_for_first_event=0, current_error=0x7fffffff9908, current_request=1971) at xcb_io.c:138 #2 0x0000003a0464d20a in _XReply (dpy=0x62bb70, rep=0x7fffffff9950, extra=0, discard=1) at xcb_io.c:370 #3 0x0000003a04640ca3 in XSync (dpy=0x62bb70, discard=0) at Sync.c:48 #4 0x0000003a04640e5b in _XSyncFunction (dpy=0x62bb70) at Synchro.c:37 #5 0x0000003a04e04d77 in XRenderCreatePicture (dpy=0x62bb70, drawable=69206203, format=0x7a95e0, valuemask=0, attributes=0x7fffffff99e0) at Picture.c:99 #6 0x0000003a0880916d in _XftDrawRenderPrepare (draw=0x898a30) at xftdraw.c:400 #7 0x0000003a088093b3 in XftDrawGlyphFontSpec (draw=0x898a30, color=0x7f8de8, glyphs=0x7fffffff9b00, len=10) at xftdraw.c:717 #8 0x0000003a04aef1c1 in Tk_DrawChars (display=0x841f50, drawable=1, gc=<value optimized out>, tkfont=0x7f8d40, source=0x7f6ea2 "", numBytes=0, x=72, y=10) at /usr/src/debug/tk8.5.3/unix/tkUnixRFont.c:725 #9 0x00007ffff2c7b421 in DrawTextLayout () at ../bltText.c:52 #10 Blt_CreateTextBitmap (tkwin=0x650400, textPtr=0x8987a0, tsPtr=0x83ea28, bmWidthPtr=0x7fffffffdce4, bmHeightPtr=0x7fffffffdce0) at ../bltText.c:541 #11 0x00007ffff2c7b76d in Blt_DrawTextLayout (tkwin=0x62bb70, drawable=69206192, textPtr=0x8987a0, tsPtr=0x83ea28, x=72, y=241) at ../bltText.c:746 #12 0x00007ffff2c7c355 in Blt_DrawText (tkwin=0x650400, drawable=69206192, string=<value optimized out>, tsPtr=0x83ea28, x=72, y=241) at ../bltText.c:853 #13 0x00007ffff2c00d1a in DrawAxis () at ../bltGrAxis.c:2413 #14 Blt_DrawAxes (graphPtr=0x812230, drawable=69206192) at ../bltGrAxis.c:4243 #15 0x00007ffff2c20278 in DrawMargins () at ../bltGraph.c:2104 #16 Blt_DrawGraph (graphPtr=0x812230, drawable=69206192, backingStore=<value optimized out>) at ../bltGraph.c:2221 #17 0x00007ffff2c20438 in DisplayGraph (clientData=<value optimized out>) at ../bltGraph.c:2334 The problem really starts at step #10, where Blt_CreateTextBitmap creates a pixmap with depth=1, and later calls Tk_DrawChars() on it. I'm still looking for a solution...
It looks like it might be fixed in upstream CVS, but the changes appear to be very intrusive. If I can't get a decent patchset to fix this problem, then the only solution may be to upgrade to the latest upstream cvs code.
Which upstream CVS do you mean? tk or BLT? I decided to try my hand at changing blt to use 8 bit pixmaps, but it still crashes. I've written to the BLT author, but he drops out of sight for long periods of time.
In effect, the problem is due to the call to Tk_DrawChars. The following patch bypasses the problem. It is simple but it doesn't use Xft for Blt texts. --- blt2.4z/src/bltText.c 2009-08-05 11:31:28.936922322 +0200 +++ blt2.4z.new/src/bltText.c 2009-08-05 13:47:07.446070675 +0200 @@ -48,12 +48,15 @@ fragPtr = textPtr->fragArr; for (i = 0; i < textPtr->nFrags; i++, fragPtr++) { +/* #if HAVE_UTF Tk_DrawChars(display, drawable, gc, font, fragPtr->text, fragPtr->count, x + fragPtr->x, y + fragPtr->y); #else +*/ XDrawString(display, drawable, gc, x + fragPtr->x, y + fragPtr->y, fragPtr->text, fragPtr->count); +#if HAVE_UTF #endif /*HAVE_UTF*/ } } Basically, I just commented out the Tk_DrawChars section of the #if / #endif. I investigated the code further to see how can we get Xft fonts eventually. My guess is that XftDrawCreateBitmap() should be called before drawing the text in it. The bitmap on which BLT draws is created by Blt_CreateTextBitmap() with Tk_GetPixmap(), that is just a wrapper of XCreatePixmap(). With the previous patch all is done in pure old X.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug still exists in Fedora 11 release. I'm am running with blt version: 2.4 patch level 2.4z blt library: /usr/share/tcl8.5/blt2.4 /proc/version gives: Linux version 2.6.29.6-217.2.16.fc11.i586 (mockbuild.phx.redhat.com) (gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) ) #1 SMP Mon Aug 24 17:01:46 EDT 2009
blt-2.4-32.z.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update blt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0417
blt-2.4-31.z.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update blt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0409
blt-2.4-31.z.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
blt-2.4-32.z.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.