littleVGL now supports FreeBSD framebuffer

Sun Aug 18 23:00:04 UTC 2019

On 18/8/19 2:45 am, Christian Mauderer wrote:
> On 17/08/2019 18:05, Vijay Kumar Banerjee wrote:
>>
>>
>>
>> On Thu, Aug 15, 2019 at 3:46 AM Chris Johns <chrisj at rtems.org
>> <mailto:chrisj at rtems.org>> wrote:
>>
>>     On 15/8/19 2:07 am, Vijay Kumar Banerjee wrote:
>>     > I wrote a patch for lv_drivers repository to support FreeBSD
>>     framebuffer
>>     > in fbdev, which they merged to the master today.
>>
>>     Well done, that is great.
>>
>>     > I have tested
>>     > the driver to be working with an app that I wrote on FreeBSD and
>>     > tested it on Beaglebone black image 12-STABLE.
>>
>>     Awesome.
>>
>>     > I intend to write an RSB recipe to build littleVGL and seek some
>>     guidance
>>     > on how to proceed. :)
>>
>>     Please review
>>     https://docs.rtems.org/branches/master/user/rsb/third-party-packages.html
>>
>>     I suggest you see how the curl package is done. It is a nice clean
>>     example.
>>
>>     The packages are sort of based on the FreeBSD ports layout.
>>     Littlevgl is not a
>>     port so we can use `graphics/littlevgl`.
>>
>>     The file pattern used in the RSB for a 3rd party package is:
>>
>>     - A buildset or bset file, this is the top level wrapper for the
>>     config files
>>     and selects the version to be built...
>>
>>     https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl.bset
>>
>>     - The version specific config file that sets the version and
>>     checksum for the
>>     package. It includes the build config or recipe...
>>
>>     https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl-7.65.1-1.cfg
>>
>>     Note, this is a 3prd party package so includes `rtems-bsp.cfg`. This
>>     create a
>>     suitable environment to build a package for a BSP.
>>
>>     - The build config file ...
>>
>>     https://git.rtems.org/rtems-source-builder/tree/source-builder/config/curl-1.cfg
>>
>> Hi,
>>
>> I have some doubts regarding the build.
>> The lvgl needs two directoried, lvgl (main) and lv_drivers (for the
>> driver). And on
>> top of both, there needs to be two header files to configure the
>> library, lvgl_conf.h
>> and lvgl_drv_conf.h . These conf headers are supposed to be edited by
>> the user
>> to set the options.

Enable all the features. A user with tight memory needs will need to customise
the config and so handle littlevgl themselves.

> Do we want to build both the directories
>> separately?  

I think together. I have not tried to build the various hardware drivers the
package provides. If a driver builds with RTEMS then I suggest we build them. If
they need special config file settings it will be harder to do and I suspect we
cannot build them.

>> Or do we
>> want to create our own directoy and put both driver and other stuffs in it?

We may but that is something we look at later.

>>
>> Also, lvgl doesn't have its own makefile, so we have to write our own. in my
>> application, I included the .mk file in my app's makefile and added the
>> build recipe
>> for it. How do we want to handle this in RSB? 

I suggest we build the package using rtems_waf. It is the only clean way we
currently have to get the needed BSP ABI build flags.

Could a git repo be created where littlevgl and rtems_waf are submodules?

To get hold of the sources to build I am using a script that creates a Makefile
that runs and outputs the list of source ...

-----------
#! /bin/sh

set -e
#set -x

cd $(dirname $0)

cleanup()
{
    rm -f Makefile.gen
}

trap cleanup EXIT

cat <<EOF > Makefile.gen
LVGL_DIR = \$(CURDIR)
include lvgl/lvgl.mk
include lv_drivers/lv_drivers.mk
CSRCS:
        @echo "\$(CSRCS)"
EOF

excludes="R61581.c SSD1963.c ST7565.c UC1610.c FT5406EE8.c XPT2046.c"

csrcs=$(make -f Makefile.gen CSRCS)
srcs=

for c in ${csrcs}
do
    found=no
    for e in ${excludes}
    do
        if [ $c = $e ]; then
           found=yes
        fi
    done
    if [ $found != yes ]; then
        name=$(find . -name $c)
        srcs="${srcs} ${name}"
    fi
done

#
# Add something to write littlevgl.py which can be imported in a
# wscript file
#
------------

>> If I create an lvgl tar with drivers and library in it, along with a
>> makefile, will it go
>> into our ftp server somewhere?  Can this be an approach to build the
>> whole stuff?
> 
> Hm. Difficult case. We should also take into account that lvgl doesn't
> necessarily have to use the FreeBSD frame buffer but can use some other
> displays too. So what you do would be more a "lvgl-libbsd" packet.

It can support any driver, the FB driver is just one. You can use the same build
of the core, draw etc code with any other driver. The user needs to register the
driver functions during initialisation so they can be the FreeBSD FB one or
something else.

In v6 the resolution is set at run time and the conf file are just defaults.

There is one issue, the path to the frame buffer is currently hard coded in the
conf file and I would like to change that in littvlg so the path is passed in. I
am not sure how this can be done without breaking the API. Maybe a new call.

Another change is to the memory allocator to not loop forever on an error. It
would be nice to register a fault handler that is called.

> If
> such a packet is created, it should most likely contain everything
> necessary: lvgl, lv_drivers and the config files (I hope they are not
> target specific but only display specific?)

I suggest the configuration file enables all features present plus the frame
buffer driver. I am not sure which input drivers to enable.

> Regarding where to put files: RSB can use quite some sources. See
> https://docs.rtems.org/branches/master/user/rsb/configuration.html#source-and-patches
> 
> If the config and a Makefile can be put into a patch: It's also not
> uncommon to use patches from the mailing list like that:
> 
> rtems/config/tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg:31:%patch
> add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/3242/gcc-sparc-ticket-3242-v2.patch
> 
> I think Chris knows RSB a lot better than me. Maybe he has some better
> suggestions.

A repo would be nice. We are discussing in another thread related to the multiio
package if that stays as a separate repo and we grow the number we have or do we
create a packages repo and collect it and this as separate pieces?

Chris

> 
>>
>>     These configs do not include any other configs and could be used to
>>     build a
>>     native package for a host or a 3rd party package for RTEMS.
>>
>>     - The `%prep` section prepares the source to build. For github if we are
>>     building from master we select a commit and fetch a compressed
>>     tarball. This
>>     means we can snapshot the source when making a release. The RSB can work
>>     directly with the git repo however this has proven to be more
>>     fragile than a
>>     tarball.
>>
>>     - The `%build` section builds the package. The contents of this file
>>     are used to
>>     create a shell script. Use --dry-run, --trace and --log to debug what is
>>     happening. The shell script contents should be viewable in the log
>>     file if a dry
>>     run does not created it. There is a lot of trace but searching will
>>     help you
>>     locate the piece you are interested in. The `source_dir_*` shell
>>     variable is the
>>     directory created by extracting the tarfile. The macros
>>     `%{build_directory}` and
>>     `%{host_build_flags}` are defined in `defaults.mc
>>     <http://defaults.mc>` and should handle the
>>     compiler and flags. You may want to check libbsd is installed in
>>     your config,
>>     see ...
>>
>>     https://git.rtems.org/rtems-source-builder/tree/rtems/config/rtems-bsp.cfg#n198
>>
>>     .. for an example of how to check and add `%error This package needs
>>     libbsd,
>>     please build and install` or something like that as an error. The
>>     paths to
>>     install to are set up for you, these match how a BSP and RTEMS are
>>     installed.
>>     The layout needs to be followed or applications will not be able to
>>     find the
>>     header or the library.
>>
>>     - The `%install` section installs the package. The install process
>>     is to a
>>     staging area `${SB_BUILD_ROOT}`. Nothing is installed unless all
>>     parts build so
>>     we do not have an inconsistent build in the install prefix.
>>
>>     Chris
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>