[PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 4:42 PM Christian Mauderer
<christian.mauderer at embedded-brains.de> wrote:
>
> On 05/06/2020 12:29, Vijay Kumar Banerjee wrote:
> > On Fri, Jun 5, 2020 at 1:59 PM Christian Mauderer
> > <christian.mauderer at embedded-brains.de> wrote:
> >>
> >> Hello Vijay,
> >>
> >> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> >>> ---
> >>>  lv_drv_conf.h | 6 +++++-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/lv_drv_conf.h b/lv_drv_conf.h
> >>> index 697ceaf..e8d2c40 100644
> >>> --- a/lv_drv_conf.h
> >>> +++ b/lv_drv_conf.h
> >>> @@ -322,7 +322,11 @@
> >>>  #  define USE_EVDEV           0
> >>>  #endif
> >>>
> >>> -#if USE_EVDEV
> >>> +#ifndef USE_BSD_EVDEV
> >>> +#  define USE_BSD_EVDEV           1
> >>> +#endif
> >>
> > Hi!
> >
> >> I haven't tested it and haven't had a detailed look. But first question
> >> that springs to my mind: Can we still use no evdev on targets without it
> >> with this change? Or becomes some evdev module for libbsd mandatory with
> >> it if you want to use lvgl?
> >>
> > With this change in the configuration, the evdev module will be
> > required to compile as it includes the evdev header files if this
> > option is set, just like in the case of fbdev. The build options still
> > remain same, so we can add --no-drivers and these files won't be
> > touched during the build. If it needs to be further broken down in
> > such a manner that the fbdev is required but not evdev, then I think
> > we can keep this option enabled and check it during waf configuration
> > if evdev is available. If not, we can skill building the evdev files.
> >
> > Do you think such checking would be necessary or would it be
> > sufficient to have the --no-drivers option? I'll work on it
> > accordingly if more options are required.
>
> First: --no-drivers should be enough for now.
>
> On the long term, I think we should slowly move to a better
> configurability. I'm not sure yet how that could look. The method that
> we use to build littlevgl is a bit limiting. The library has a quite
> fixed configuration (the lv_conf.h). For example if you want to use a
> different color depth than 16 bit, you have to adapt the build. If you
> want to use a different maximum resulution, you have to adapt the build.
>
> That's quite limiting. Either the settings in our repository match your
> requirements or you have to build the library yourself. It would be
> great if we could get a bit of more flexibility. Of course some of these
> points can't really be changed easily. It's just how littlevgl works.
>
> But it's the reason that I'm a bit careful when we add something that
> adds further restrictions. We maybe end up with a really nice build
> system that can build the library for exactly one demo application.
>

Since the lvgl is too dependent on the conf files, I was thinking of
an approach to generate the whole conf file according to the input
from the user. There will be default values but the user can change it
when prompted about it during the configuration. Or the user can just
choose to press enter to all the prompts and a file with default
configuration will be created.

BTW, I posted about an example app based on these patches here:
https://lists.rtems.org/pipermail/devel/2020-June/060054.html
Please have a look (especially the video ;) ) and review the app when
you have time :)


Best regards,

Vijay
> The drivers part is a quite separate and less critical one. So
> --no-drivers should be OK for that. So feel free to go on with it.
>
> Best regards
>
> Christian
>
> >
> > Thanks for the review.
> >
> > Best regards,
> > Vijay
> >> Best regards
> >>
> >> Christian
> >>
> >>> +
> >>> +#if USE_EVDEV || USE_BSD_EVDEV
> >>>  #  define EVDEV_NAME   "/dev/input/event0"        /*You can use the "evtest" Linux tool to get the list of devices and test them*/
> >>>  #  define EVDEV_SWAP_AXES         0               /*Swap the x and y axes of the touchscreen*/
> >>>
> >>>
> >>
> >> --
> >> --------------------------------------------
> >> embedded brains GmbH
> >> Herr Christian Mauderer
> >> Dornierstr. 4
> >> D-82178 Puchheim
> >> Germany
> >> email: christian.mauderer at embedded-brains.de
> >> Phone: +49-89-18 94 741 - 18
> >> Fax:   +49-89-18 94 741 - 08
> >> PGP: Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.