littleVGL now supports FreeBSD framebuffer
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Mon Aug 26 19:49:20 UTC 2019
On Mon, Aug 19, 2019 at 4:26 AM Chris Johns <chrisj at rtems.org> wrote:
> 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?
>
> Hi,
Sorry for the late reply, I had to visit home and didn't get much time, so
I decided
to do it out of GSoC.
I started the repo as you suggested and it's in the initial state. The
repository is
pushed in GitHub here:
https://github.com/thelunatic/littlevgl-rsb .
I'm starting to write the wscript for the repo by taking reference from
your script below
to get the file sources.
> 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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190827/7d62db52/attachment-0002.html>
More information about the devel
mailing list