This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SitaraWare GrLib Update

I tried to send this message to sitaraware_support@list.ti.com, but the message was rejected.

Hello,

I have generated a patch to synchronize the SitaraWare 01.00.00.09 GrLib (originally forked at rev 6288 of StellarisWare) to StellarisWare rev 7611 GrLib. I did this to get extended font support, to support some ISO-8859-1 characters; I also added a few of these characters to the fontfixed6x8 font and included this as fontfixed6x8ex. Between 6288 and 7611, there were also some changes to the slider widget. Most of the changes are for the copyright notice and rev number update.

2148.0002-grlib-sync-SitaraWare-GrLib-with-StellarisWare-GrLib.txt

I sent a patch previously to fix the software implementation of CountLeadingZeros; when passed 0, CountLeadingZeros would return 0 instead of 32 as indicated by the ARM spec.

I am preparing two more patches for GrLib. One is to fix the unaligned accesses of the width and height fields in an image. It has been corrected in image.c, and the values don't ever seem to be used in the offscr*bpp.c files, but when the width field is written, it usually seems to overwrite the format field, which could cause problems with the Image Drawing routines that depend on that format.

Another patch is for a strange behavior I saw in determining the clipping region of a widget that is partially off the display, but has the OUTLINE style. By default, when a widget (like a PushButton) has an outline and contains an image or text, the clipping region of the widget is shrunk by 1 pixel per side after the outline is drawn before the text or image is drawn. This is to prevent the text or image from drawing on top of the outline. However, if the widget's bounds go off the display, the clipping region for the widget is initially set to the boundary of the screen on that side. But when the clipping region is shrunk, it creates a 1 pixel gap between the image/text and the side of the screen. The patch looks something like this, for pushbutton.c:
@@ -121,10 +121,12 @@ RectangularButtonPaint(tWidget *pWidget)
         //
         if(pPush->ulStyle & PB_STYLE_OUTLINE)
         {
-            sCtx.sClipRegion.sXMin++;
-            sCtx.sClipRegion.sYMin++;
-            sCtx.sClipRegion.sXMax--;
-            sCtx.sClipRegion.sYMax--;
+            tRectangle sA = pWidget->sPosition;
+            sA.sXMin++;
+            sA.sYMin++;
+            sA.sXMax--;
+            sA.sYMax--;
+            GrContextClipRegionSet(&sCtx, &sA);
         }

I don't know which other widgets exhibit this behavior, but if you're interested, I'll gladly send along the patches. I think that last one is a valid issue with StellarisWare also, if anyone would like to get in touch with them.

Thanks,
~Eric Wetzel

  • Thank you, Eric Wetzel,

    You can send other patches too and we will pull them in after validation. We will sync the patches with StellarisWare team.

    Regards

    Vichu

  • Should I post the patches to this forum or send them to sitaraware_support@list.ti.com? Frank Walzer said earlier that I should send bugs and feedback to the mailing list, and that posts to the forum could be missed, but I am rejected from sending e-mail to the mailing list.

    On a similar note, the TI Forums don't seem to allow me to upload .patch or .diff files, requiring me to rename files of those types to .txt. Not a huge problem, but git, which I am using for local revision control, outputs patches as .patch.

    Here is the patch to modify the clipping regions for widgets.

    8816.0001-grlib-change-widget-clipping-region-shrink.txt

    I suspect there might be some trickery in the ListBoxWidget, ImageButtonWidget, and SliderWidget for doing the same things, but I didn't dig into it. I use the CanvasWidget and rectangular PushButtonWidget, and I've tested these changes with those and they work, but I haven't tested the checkbox, radio button, or circular push button.

    ~Eric

  • I just found a new GrLib issue. gcc issues a compiler warning on string.c:

    ../../string.c: In function 'GrStringGet':
    ../../string.c:947:22: warning: array subscript is above array bounds

    The offending code is:

    unsigned long
    GrStringGet(long lIndex, char *pcData, unsigned long ulSize)
    {
        unsigned long ulLen, ulOffset, ulSubCode[16];
        long lPos, lIdx, lBit, lSkip, lBuf;
        unsigned char *pucBufferOut;
        const unsigned char *pucString;

        ASSERT(lIndex < g_usNumStrings);
        ASSERT(pcData != 0);

        //
        // Initialize the output buffer state.
        //
        lPos = 0;
        pucBufferOut = 0;

        //
        // if built up from another string, we need to process that
        // this could nest multiple layers, so we follow in
        //
        ulSubCode[lPos] = g_pulStringTable[(g_usLanguage * g_usNumStrings) +
                                           lIndex];

        if(SC_GET_LEN(ulSubCode[lPos]))
        {
            //
            // recurse down
            //
            while(lPos < 16)
            {
                //
                // Copy over the partial (if any) from a previous string.
                //
                lIdx = SC_GET_INDEX(ulSubCode[lPos++]);

                ulSubCode[lPos] = g_pulStringTable[(g_usLanguage *
                                                    g_usNumStrings) + lIdx];

                if(!SC_GET_LEN(ulSubCode[lPos]))
                {
                    //
                    // not linked, just string
                    //
                    break;
                }
            }
        }

    If lPos is 15 in the last recursion, lPos is incremented in "lIdx = SC_GET_INDEX(ulSubCode[lPos++]);" and the next line attempts assign to ulSubCode[16], but ulSubCode's last element is 15. I don't use the language table functions in GrLib, so I'm not sure if this is a realistic failure case, but gcc emits a warning. This is also present in StellarisWare.