This include causes the visual studio pc simulator build to break:

https://github.com/littlevgl/lv_drivers/blob/78c4601f7132da08666bc180c08cafc5773234c5/indev/mouse.h#L26

It looks like that line can be deleted for both GCC and visual studio as that include will be pulled in by the MONITOR_SDL_INCLUDE_PATH macro instead (default handled a couple of lines lower).

Currently, fbdev driver does not support monochrome framebuffers.
The attached patch adresses this issue. I've tested on linux with ssd1307 frame buffer driver (https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/ssd1307fb.c) and it worked perfectly.

fbdev_patch.txt

The function fbdev_flush nicely confines the set area if it exceeds the screen size.

But in the line https://github.com/littlevgl/lv_drivers/blob/master/display/fbdev.c#L175 the original unconfined area value is used for width calculation which can result in memory corruption.

I don't have a monochrome display but line https://github.com/littlevgl/lv_drivers/blob/master/display/fbdev.c#L225 may also be affected by this problem.

Hi, I'm trying to use this library to interface with an Adafruit TFT display hooked to a raspberry pi 3.
I enabled the marker to work with the calibration and I swapped the X and Y axis through EVDEV_SWAP_AXES in lv_drv_conf.h. I enabled EVDEV_SCALE and EVDEV_CALIBRATE as well. By reading the comment just to the right of EVDEV_HOR_MIN I swapped it with its counterpart EVDEV_HOR_MAX but the axis is not inverting. Could this be a bug? (Ps. the Y axis is not inverting as well).

Hi,

the resolution of my touch input reveived from evdev does not match the resolution of my display.
With the following patch it would be possible to define a custom input resolution. Every position read from evdev would be scaled to the display resolution.

index 94027d8..e7346f7 100644
--- a/b/indev/evdev.c
+++ b/a/indev/evdev.c
@@ -90,21 +90,25 @@ bool evdev_read(lv_indev_data_t * data)
         }
     }

-
-    if(evdev_root_x < 0)
-        evdev_root_x = 0;
-    if(evdev_root_y < 0)
-        evdev_root_y = 0;
-    if(evdev_root_x >= LV_HOR_RES)
-        evdev_root_x = LV_HOR_RES - 1;
-    if(evdev_root_y >= LV_VER_RES)
-        evdev_root_y = LV_VER_RES - 1;
-
     /*Store the collected data*/
+#if SCALE_EVDEV
+    data->point.x = (evdev_root_x * LV_HOR_RES) / SCALE_EVDEV_HOR_RES;
+    data->point.y = (evdev_root_y * LV_VER_RES) / SCALE_EVDEV_VER_RES;
+#else
     data->point.x = evdev_root_x;
     data->point.y = evdev_root_y;
+#endif
     data->state = evdev_button;

+    if(data->point.x < 0)
+      data->point.x = 0;
+    if(data->point.y < 0)
+      data->point.y = 0;
+    if(data->point.x >= LV_HOR_RES)
+      data->point.x = LV_HOR_RES - 1;
+    if(data->point.y >= LV_VER_RES)
+      data->point.y = LV_VER_RES - 1;
+
     return false;
 }

index 449796c..2090830 100644
--- a/b/lv_drv_conf_templ.h
+++ b/a/lv_drv_conf_templ.h
@@ -207,6 +207,11 @@
 #define USE_EVDEV    0
 #if USE_EVDEV
 #define EVDEV_NAME   "/dev/input/event0"        /*You can use the "evtest" Linux tool to get the list of devices and test them*/
+#define SCALE_EVDEV  0                          /* Scale input, e.g. if touchscreen resolution does not match display resolution */
+#if SCALE_EVDEV
+#define SCALE_EVDEV_HOR_RES     (4096)          /* Horizontal resolution of touchscreen */
+#define SCALE_EVDEV_VER_RES     (4096)          /* Vertical resolution of touchscreen */
+#endif
 #endif

Hi,
I'm currently working on a project where I'm using lvgl and lv_drivers as git submodules.
The issue is that the following include:
https://github.com/littlevgl/lv_drivers/blob/117812eec9a5b82fe879f53ee0d1bf39cb9027c8/display/fbdev.h#L29

Breaks the build as the header lvgl.h is in "../../lvgl/lvgl.h" and not "lvgl/lvgl.h" as lv_drivers and lvgl are two separate directories.

Is this intentional or can this be updated to match "../../lv_drv_conf.h" include above it?

Best regards,
Vijay

Hello!

I'm setting up my project to use libinput for the touchscreen. When I enable this through the config file and make, I get several linking errors when calling libinput functions. I haven't modified the files within lv_drivers folder.

It seems the libinput library isn't being compiled into the lv_indev.o file correctly. Any ideas?

I'm using Ubuntu 14.04.

These are the errors below:

arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/opt/fsl-imx-x11/4.14-sumo/sysroots/cortexa9hf-neon-poky-linux-gnueabi -o demo ./main.o lv_group.o lv_indev.o lv_disp.o lv_obj.o lv_refr.o lv_style.o lv_debug.o lv_hal_disp.o lv_hal_indev.o lv_hal_tick.o lv_arc.o lv_bar.o lv_cb.o lv_cpicker.o lv_ddlist.o lv_kb.o lv_line.o lv_mbox.o lv_preload.o lv_roller.o lv_table.o lv_tabview.o lv_tileview.o lv_btn.o lv_calendar.o lv_chart.o lv_canvas.o lv_gauge.o lv_label.o lv_list.o lv_slider.o lv_ta.o lv_spinbox.o lv_btnm.o lv_cont.o lv_img.o lv_imgbtn.o lv_led.o lv_lmeter.o lv_page.o lv_sw.o lv_win.o lv_font.o lv_font_fmt_txt.o lv_font_roboto_12.o lv_font_roboto_16.o lv_font_roboto_22.o lv_font_roboto_28.o lv_font_unscii_8.o lv_circ.o lv_area.o lv_task.o lv_fs.o lv_anim.o lv_mem.o lv_ll.o lv_color.o lv_txt.o lv_math.o lv_log.o lv_gc.o lv_utils.o lv_async.o lv_printf.o lv_bidi.o lv_theme_alien.o lv_theme.o lv_theme_default.o lv_theme_night.o lv_theme_templ.o lv_theme_zen.o lv_theme_material.o lv_theme_nemo.o lv_theme_mono.o lv_draw_basic.o lv_draw.o lv_draw_rect.o lv_draw_label.o lv_draw_line.o lv_draw_img.o lv_draw_arc.o lv_draw_triangle.o lv_img_decoder.o lv_img_cache.o fbdev.o monitor.o R61581.o SSD1963.o ST7565.o UC1610.o SHARP_MIP.o FT5406EE8.o keyboard.o mouse.o mousewheel.o evdev.o libinput.o XPT2046.o win_drv.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
libinput.o: In function libinput_set_file': lv_drivers/indev/libinput.c:72: undefined reference to libinput_device_unref'
lv_drivers/indev/libinput.c:73: undefined reference to libinput_path_remove_device' lv_drivers/indev/libinput.c:76: undefined reference to libinput_path_add_device'
lv_drivers/indev/libinput.c:81: undefined reference to libinput_device_ref' libinput.o: In function libinput_init':
lv_drivers/indev/libinput.c:98: undefined reference to libinput_path_create_context' lv_drivers/indev/libinput.c:103: undefined reference to libinput_get_fd'
libinput.o: In function libinput_read': lv_drivers/indev/libinput.c:132: undefined reference to libinput_dispatch'
lv_drivers/indev/libinput.c:134: undefined reference to libinput_event_get_type' lv_drivers/indev/libinput.c:149: undefined reference to libinput_event_destroy'
lv_drivers/indev/libinput.c:133: undefined reference to libinput_get_event' lv_drivers/indev/libinput.c:138: undefined reference to libinput_event_get_touch_event'
lv_drivers/indev/libinput.c:139: undefined reference to libinput_event_touch_get_x_transformed' lv_drivers/indev/libinput.c:140: undefined reference to libinput_event_touch_get_y_transformed'
collect2: error: ld returned 1 exit status
Makefile:37: recipe for target 'default' failed
make: *** [default] Error 1

I think i found a way to use IRQ to read input device without need change lvgl. This way to work seems good to you ? I use 5-2 dev because input_dev got user_data.
in the input library i will get input function and irq function like this:

Library (WIP):

static bool ar10xx_input_get(lv_indev_data_t * data)
{
    ar10xx_t* dev = data->user_data;  //get input device
    if (!dev->flag) //no irq, return false
        return false;
   //
    int16_t xpos;
    int16_t ypos;
    bool pen = AR10XX_GetPos(&xpos, &ypos);
    /*Store the collected data*/
    data->point.x = xpos;
    data->point.y = ypos;
    data->state = pen ? LV_INDEV_STATE_PR : LV_INDEV_STATE_REL;
    if(dev->flag) dev->flag-- ;
    return (dev->flag) ? true : false;
}

inline void ar10xx_irq(const* ar10xx_t dev)
{
        dev->flag++ ; //event on irq
}

Main:

void indev_init(void)
{
    lv_indev_drv_t indev_drv;
    lv_indev_drv_init(&indev_drv);          /*Basic initialization*/
    indev_drv.type = LV_INDEV_TYPE_POINTER;
    indev_drv.read = ar10xx_input_get;         /*This function will be called periodically*/
    indev_drv.user_data = &ar10xx_dev,
    lv_indev_drv_register(&indev_drv);
}

inline void interupt_fn(void)
{
    ar10xx_irq(&dev);
}

lvgl functions are called constantly. I wonder if we can activate a task only when an event incoming.
A bit like using "Queue" in FreeRTOS. The task is waiting for a new information (here the flag) to activate the task.
The advantage of the interupt system above is do not do transmission when it is not needed.

Hi

FTDI/Bridgetek FT/BT8XX EVE/EVE2/EVE3 family controller displays can work with LVGL?

https://brtchip.com/eve/
https://www.ftdichip.com/EVE.htm
https://brtchip.com/ft80x/
https://brtchip.com/ft81x/
https://brtchip.com/bt81x/

greetings

I'm working on an application that is meant to be run on many different types of devices which means I can't hard-code the /dev/input/event... paths because I don't know them at build time. It would be great if the libinput driver could provide an interface for automatically detecting touchscreens, pointer devices and keyboards.

I have some very rudimentary code here that basically just walks the /dev/input/event... files, makes a libinput call to determine the device capabilities and then filters the files based on that.

I'd be interested to know if you would consider adding something like this to lv_drivers? I think this could be beneficial to other users as well.

Hi !

I'm running into trouble by using both repositories with the current master branch.

• lvgl: 2a78353ca485e9d07e2aa5f5543db13e6370580a
• lv_driver: bc24e9f

Maybe the lvgl update to V7 is not considered fully in lv_drivers - I found the following issues:

wrong header file location

The lv_drv_conf_templ.h has 3 devices enabled per default

• #define USE_SSD1306 1
• #define USE_SSD1306 1
• #define USE_AR10XX (1)

Additionally for these devices the normally used code template is missing:

#ifndef USE_<device>
#  define USE_<device>         0
#endif

This leads for all 3 devices to a header include error

fatal error: lvgl/lv_misc/lv_color.h: No such file or directory 
#include "lvgl/lv_misc/lv_color.h"

The lv_color.h file is found at lvgl/src/lv_misc/lv_color.h
(quickly fixed by disabling the drivers which are not used in my project anyway)

the cpp keyword "template" is used as function argument

I'm using the lvgl framework in a c/cpp project and this error pops up after updating to master branch

In file included from /home/pi/work/lora/Rfm96Raspberry/Application/lv_drivers/display/fbdev.h:20,                                                
                 from /home/pi/work/lora/Rfm96Raspberry/Application/gui.h:12,                                                                     
                 from /home/pi/work/lora/Rfm96Raspberry/Application/main.cpp:9:                                                                   
/home/pi/work/lora/Rfm96Raspberry/Application/lv_drivers/display/../../lv_drv_conf.h: At global scope:                                            
/home/pi/work/lora/Rfm96Raspberry/Application/lv_drivers/display/../../lv_drv_conf.h:235:70: error: expected ‘,’ or ‘...’ before ‘template’       
 static inline int lv_spi_repeat(lv_spi_handle_t spi_dev, const void* template, uint32_t repeats, uint8_t template_size)

Renaming the function argument template in lv_drv_conf_templ.h fixes this issue.

warnings

Compiling the master branch shows a lot of new warnings, mainly

• warning: unused parameter
• warning: no return statement in function

Currently I'm ignoring this warning and after fixing the other issues temporarily my little demo application is running nearly the same as for V6 (except of the look and feel due to the changed theme handling ;-) )

The driver is not up to date, the result code for the read should always return false. When implemented as in this sample, the touch does not respond precisely. The returned x/y coordinates have a variation of about 30 pixels on the same position.
https://github.com/littlevgl/lv_drivers/blob/9fb21b087b52b46eca015d80d27eefcd71739786/indev/XPT2046.c#L109
The porting template in lvgl is correct:
https://github.com/littlevgl/lvgl/blob/master/porting/lv_port_indev_template.c

I just updated to the latest commit of the new_api branch and am having visual artifacts. I looked through the new SSD1306 code, but I don't seem anything obviously wrong with it; however, I am not super familiar with the VDB system. Previously, everything worked fine with the old fill/flush method. The odd thing is it only happens sometimes; full screen refreshes seem fine, as well as some scrolling text.

Microcontroller: ESP32
Display: I2C SSD1306

Changing the VDB size seems to have no impact.

Attached gif demonstrating the issue:
https://gfycat.com/AgileDemandingHound

@Zaltora , can you offer any insight on this?

Hi,

when compiling the mentioned project for a rPi project with a touchscreen that needs to be scaled I get following error 2x

 error: ‘drv->disp->driver’ is a pointer

to solve this i have changed lines (from 215) in evdev.c from

    data->point.x = map(evdev_root_x, EVDEV_HOR_MIN, EVDEV_HOR_MAX, 0, drv->disp->driver.hor_res);
    data->point.y = map(evdev_root_y, EVDEV_VER_MIN, EVDEV_VER_MAX, 0, drv->disp->driver.ver_res);

to

    data->point.x = map(evdev_root_x, EVDEV_HOR_MIN, EVDEV_HOR_MAX, 0, drv->disp->driver->hor_res);
    data->point.y = map(evdev_root_y, EVDEV_VER_MIN, EVDEV_VER_MAX, 0, drv->disp->driver->ver_res);

tried to create a pull request but was unable to do this from the lv_port_linux_frame_buffer project as lv_drivers is a submodule and i do not yet know how to do this.

thanks for your nice library
Jef

Does LVGL support X11 on Linux?

https://github.com/littlevgl/lv_platformio/blob/master/platformio.ini#L26-L27

Now need to define MONITOR_HOR_RES & MONITOR_VER_RES in every platform.ini. Not a problem, but in 99% looks like useless garbage.

May be worth add such fallback defines near MONITOR_ZOOM ?

https://github.com/littlevgl/lv_drivers/blob/master/display/monitor.c#L29-L31

With the new lvgl 5.2, i see some special function/configuration for monochrome display. with discussion here, i see more function : lvgl/lvgl#300

#define LV_VDB_PX_BPP
...
 void (*vdb_wr)(uint8_t * buf, lv_coord_t buf_w, lv_coord_t x, lv_coord_t y, lv_color_t color, lv_opa_t opa);

The vdb_rd function doesn't exist yet ?
What is the rounder function described in the commit ?
If i set 1bpp color for vdb, the buffer size will be lower than use 1 byte by pixel ?

It is a WIP feature ?

This function is called inside sdl_init() and just opens the device keyboard when running lvgl, which is not desired for me.

I commented the function and now the app works fine. I am not sure what this function is exactly used for but i'm typing this because it might be looked at. My device is the Nintendo Switch.

When using the LV_INDEV_TYPE_KEYPAD type, the evdev driver supports a limited number of keys (backspace, enter, up right, left, down). Any other keys are ignored. It would be great if the driver would handle input from a regular keyboard so that, for instance, typed characters are forwarded into a textarea.

I'm not sure if there is a better way to achieve this other than adding further cases for the relevant key codes and handling things like SHIFT manually.

Maybe ASCII characters or characters found on common US English keyboard layouts would be enough for a start as that would limit the amount of switching.

I'm curious if you'd be open to adding this to lv_drivers and would be happy to help implement it.

Hi!

I'm trying the driver (new_api) for the screen I have (it was sold as a SSD1306, but works better when I select SH1106 in the typedef). This one have the pins for I2C.
I'm using this with an STM32F091RC nucleo board, to make the code I like IDEs and as much debugging possibilities as I can have, then I'm using Eclipse with the GNU MCU Eclipse plugins + OCD, and CubeMX to generate the base.
I don't know if this is the 'correct' way, but the only way I was able to make this work was adding a call for the function ssd1306_load_frame_buffer(&dev) in the main loop of my main, don't know if this is documented somewhere, I didn't find it, just figured out.

here is the relevant part of the main:

lv_init();
ssd1306_t scr;
scr.height = 64;
scr.width =128;
scr.protocol = SSD1306_PROTO_I2C;
scr.screen = SH1106_SCREEN; //SSD1306_SCREEN ; //
scr.i2c_dev = &hi2c1;
scr.rst_pin = 0;
ssd1306_init(&scr);

lv_disp_drv_t disp_drv; /Descriptor of a display driver/
lv_disp_drv_init(&disp_drv);

disp_drv.disp_flush = ssd1306_flush; /Used in buffered mode (LV_VDB_SIZE != 0 in lv_conf.h)/
// disp_drv.disp_fill = ssd1306_fill; /Used in unbuffered mode (LV_VDB_SIZE == 0 in lv_conf.h)/
// disp_drv.disp_map = ssd1306_map; /Used in unbuffered mode (LV_VDB_SIZE == 0 in lv_conf.h)/

lv_disp_drv_register(&disp_drv);

///////////////////////////*******\\\\\\\\\\\\\\\\\\\\

lv_obj_t * label1 = lv_label_create(lv_scr_act(), NULL);

/Modify the Label's text/
lv_label_set_text(label1, "Hello world!");

/* Align the Label to the center

• NULL means align on parent (which is the screen now)
• 0, 0 at the end means an x, y offset after alignment*/
  lv_obj_align(label1, NULL, LV_ALIGN_CENTER, 0, 0);

/* USER CODE END 2 */

/* Infinite loop /
/ USER CODE BEGIN WHILE */
while (1)
{
HAL_Delay(5);
lv_tick_inc(5);
lv_task_handler();
if (ssd1306_need_redraw()) ssd1306_load_frame_buffer(&scr);

/* USER CODE END WHILE */

}

the next problem I had was with the function to talk with i2c in lv_drv_conf.h, here is the code I wrote:
static inline int lv_i2c_write(lv_i2c_handle_t i2c_dev, uint8_t reg, void* data_out, uint8_t datalen)
{
//Do the dependant port here
uint8_t buffer[datalen +1];
uint8_t *ptr = data_out;
buffer[0] = reg;

for (int i = 1; i <= datalen +1; i++) buffer[i] = *(ptr++);
HAL_I2C_Master_Transmit(i2c_dev, 0x78, buffer ,datalen + 1, HAL_MAX_DELAY);

}

this function is called from lv_drv_common.h with
static inline int i2c_send(const lv_i2c_handle_t i2c_dev, uint8_t reg, uint8_t* data, uint8_t len)
{
return lv_i2c_write(i2c_dev, &reg, data, len);
}
which is called form SSD1306.c in the command and data sections, the command is more easy to read:
err_control(i2c_send(dev->i2c_dev, 0, &cmd, 1));

when the function was called all the time with the third argument as '0' I never get a 0 at the interface (was reading that with the scope all the time), I tried several ways to write 'reg' but I always get 63 or 60 or 6B when should be 0 and 47 when should be 40 (both hex)
I ended writing the function inside ssd1306_command and _load_frame_buffer, like:
{
#if (SSD1306_I2C_SUPPORT)
case SSD1306_PROTO_I2C:
// err_control(i2c_send(dev->i2c_dev, 0, &cmd, 1));
;
uint8_t buffer[2];
buffer[0] = 0x00;
buffer[1] = cmd;

    HAL_I2C_Master_Transmit(&hi2c1, 0x78, buffer, 2, HAL_MAX_DELAY);
    break;

the other is a bit more long but same idea.

Any idea about what I'm doing wrong here?

and lastly, in the init procedure, this option should be false:
&& !ssd1306_set_whole_display_lighting(dev, false) // was true!!
if is set to true the whole screen remains white.

Hi, I'm currently porting lvgl to work with mbed-os using platformio. The screen I'm using is an ST7565 LCD 128x64 monochrome (specs). I was able to get "Hello World!" to draw on the screen, however the entire screen background is solid black (the text can be seen if the screen is tilted, see attached images). I'm struggling to figure out what is wrong. I do have a feeling that my lv_conf.h is mis-configured, so I will keep digging on my end. If anyone have any ideas or suggestions, please do let me know.

main.cpp
lv_conf.h

We're using the SDL display and mouse drivers. We had naively assumed that if the UI worked with a mouse then it'd work with a touchscreen, however touchscreen events are completely ignored.

In our use case I fixed this by adding the following to mouse_handler(), but not sure if this is the correct general solution. Maybe you'd prefer it if this went into a separate touchscreen driver.

        case SDL_FINGERUP:
            left_button_down = false;
            last_x = LV_HOR_RES_MAX * event->tfinger.x / MONITOR_ZOOM;
            last_y = LV_VER_RES_MAX * event->tfinger.y / MONITOR_ZOOM;
            break;
        case SDL_FINGERDOWN:
            left_button_down = true;
            last_x = LV_HOR_RES_MAX * event->tfinger.x / MONITOR_ZOOM;
            last_y = LV_VER_RES_MAX * event->tfinger.y / MONITOR_ZOOM;
            break;
        case SDL_FINGERMOTION:
            last_x = LV_HOR_RES_MAX * event->tfinger.x / MONITOR_ZOOM;
            last_y = LV_VER_RES_MAX * event->tfinger.y / MONITOR_ZOOM;
            break;

Hi,

I use littlevgl in embed linux, and i have a touch screen use input evdev interface. I notice that mouse_hid use evdev interface, and only support EV_REL event (my touch screen need support EV_ABS and BTN_TOUCH event). So maybe mouse_hid shoud rename to evdev more precisely and add EV_ABS and BTN_TOUCH support.

Below is the patch to support EV_ABS and BTN_TOUCH:

diff --git a/indev/mouse_hid.c b/indev/mouse_hid.c
index b2e91de..6907c32 100644
--- a/indev/mouse_hid.c
+++ b/indev/mouse_hid.c
@@ -76,15 +76,22 @@ bool mouse_hid_read(lv_indev_data_t * data)
             if (in.code == 1)
                 mouse_hid_root_y += in.value;
         } else if (in.type == 1) {
-            if (in.code == 272) {
+            if (in.code == 272 || in.code == BTN_TOUCH) {
                 if (in.value == 0)
                     mouse_hid_button = LV_INDEV_STATE_REL;
                 if (in.value == 1)
                     mouse_hid_button = LV_INDEV_STATE_PR;
             }
+        } else if (in.type == EV_ABS)
+        {
+            if (in.code == 0)
+                mouse_hid_root_x = in.value;
+            if (in.code == 1)
+                mouse_hid_root_y = in.value;
         }
     }
 
+
     if (mouse_hid_root_x < 0)
         mouse_hid_root_x = 0;
     if (mouse_hid_root_y < 0) 

When working with PIO drivers, i could not understand concept of this repo. It looks like "assorted collection of different useful things", and may be tries to emulate features of missed package manager.

Of cause, i understand, we need to do something to make lvgl work, but there are no clean limits "where to stop" and everything is tight-coupled via template header.

I had to copy-paste files and edit hardcoded paths. That's strange and not good for maintenance.

Goals

I'd like to understand concept and make some (or all parts) useable from PIO with ease.

Problems

1. It's not clear, which drivers are about SDL.
2. Grouping by display / indev looks strange. And it's not clear why win_drv placed separate, in root.
3. Global header required, which defines everything, even if i need only SDL drivers with couple of defines.

Suggestions

1. Global header should NOT be mandatory.

It worth to cleanup such patterns:

#ifndef USE_SSD1963
#  define USE_SSD1963         0
#endif

User should be able to pass #define-s only for used "drivers"

2. Improve isolation

https://github.com/littlevgl/lv_drivers/blob/master/display/monitor.c#L20-L22 - it's very suspicious, when one driver goes for another one, out of it's scope (folder)

Probably, may worth to more flat layout with prefixes, OR may be move SDL drivers to separate repo.

If drivers are independent, probably those could be in separate folder each (something like mono repository, but not sure).

Hi,
I want to add the function as follows:

evdev.c

bool evdev_set_file(char* dev_name)
{ 
     if(evdev_fd != -1) {
        close(evdev_fd);
     }
     evdev_fd = open(dev_name, O_RDWR | O_NOCTTY | O_NDELAY);

     if(evdev_fd == -1) {
        perror("unable open evdev interface:");
        return false;
     }

     fcntl(evdev_fd, F_SETFL, O_ASYNC | O_NONBLOCK);

     evdev_root_x = 0;
     evdev_root_y = 0;
     evdev_button = LV_INDEV_STATE_REL;

     return true;
}

Can I commit & push? Or do you have additional code rules to follow?

Hi, my test wiht ILI9341 parallel port.
Lvgl library compiling ok (Eclipse NXP).

how to init driver sequence
ex 1:
static ili9341_t _xParDev;
ili9341_t* _pxdev = &_xParDev;
_pxdev->par_dev = (lv_par_handle_t)&_xParDev;
_pxdev->protocol = ILI9341_PROTO_8080_8BIT;
....
...
lv_label_set_text(label1, "Hello world!");

ex 2:
how to modifier bus ILI9341_PROTO_8080_8BIT to ILI9341_PROTO_8080_16BIT
in driver : lv_par_write();

thanks
Carlos.

Hi,

I have a touchscreen that - similar to issue #35 - has a scaling that doesn't equal the display resolution. Additionally the x and y axes are swapped and the reported coordinates have quite a big offset from 0 and 4096, resp. I do have an xorg.conf that came with the screen and contains the calibration values.

I added options to swap x and y axes, invert one or both axes (on my touchscreen the x axis is inverted) and apply min/max values for the x and y axes to calibrate the screen. I'd be happy to create a pull request if you're interested.

Refs:

• lvgl/lv_platformio#14
• https://forum.littlevgl.com/t/lv-drivers-sd2-builds-use-unificaion-for-different-os-es/1780

Problem: user still needs to apply additional OS-dependent actions to build emulator (sdl2-based PC drivers) for different OS. That's not convenient, and worth to improve.

In ideal world, user should only install sdl2 bin+headers and add those into PATH. Everything else should be transparent.

After updating the lv_drivers folder for our application, the X/Y coordinates being reported to our application are not correct. Looks like the problem is in evdev.c and is related to the check in commited on Nov 24, 2019.

In our case, the data->point.x/y calculated in the #if EVDEV_SCALE section is being overwritten by the #else portion of the #if EV_CALIBRATE section (lines 189-199).

I am not sure what case the Nov 2019 checkin was addressing but looks like the code will now always override the x/y values calculated using the scaling code. So I'm not sure if that check in should just be reverted or if it needs modified in some manner.

I've been swamping you folks with PRs lately so I thought I'd write this one up as an issue first before sending yet another PR. 🙂

I ran into this when following up on #164. As described in that pull request, I'm working on a framebuffer application that covers only part of the screen and leaves the rest of it untouched for other programs to use. When trying this out on a touch screen, I noticed that the libinput touch driver uses LV_HOR_RES and LV_VER_RES to transform the touch to screen coordinates.

case LIBINPUT_EVENT_TOUCH_MOTION:
case LIBINPUT_EVENT_TOUCH_DOWN:
  touch_event = libinput_event_get_touch_event(event);
  most_recent_touch_point.x = libinput_event_touch_get_x_transformed(touch_event, LV_HOR_RES);
  most_recent_touch_point.y = libinput_event_touch_get_y_transformed(touch_event, LV_VER_RES);
  libinput_button = LV_INDEV_STATE_PR;
  break;

When the display size is reduced with the API introduced in #164, however, that means touches outside of the actual display area are proportionally mapped into the display area. Or in other words, the touch is registered in a different place than the one you touched.

I found a way to fix this by injecting the full screen size and display offset into the driver:

case LIBINPUT_EVENT_TOUCH_MOTION:
case LIBINPUT_EVENT_TOUCH_DOWN: {
  touch_event = libinput_event_get_touch_event(event);
  lv_coord_t y = libinput_event_touch_get_y_transformed(touch_event, full_display_height) - display_y_offset;
  if (y < 0) {
    break; /* ignore touches that are out of bounds */
  }
  most_recent_touch_point.x = libinput_event_touch_get_x_transformed(touch_event, LV_HOR_RES);
  most_recent_touch_point.y = y;
  state->button = LV_INDEV_STATE_PR;
  break;

I'm curious if you'd accept a corresponding contribution. We could default full_display_height to LV_VER_RES and display_y_offset to 0 so that no client change is required if you're using a fullscreen display.

In version 8 it seems that evdev_read should return void not bool. I get a compiler error on it.
bool evdev_read(lv_indev_drv_t * drv, lv_indev_data_t * data);

Some devices have dedicated power buttons that emit the KEY_POWER scan code. Here's an example from the power button on my laptop:

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0
Input device name: "Power Button"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 116 (KEY_POWER)
Properties:
Testing ... (interrupt to exit)
Event: time 1631010379.405744, type 1 (EV_KEY), code 116 (KEY_POWER), value 1
Event: time 1631010379.405744, -------------- SYN_REPORT ------------
Event: time 1631010379.405837, type 1 (EV_KEY), code 116 (KEY_POWER), value 0
Event: time 1631010379.405837, -------------- SYN_REPORT ------------

As an addendum to #153 and #155, it would be nice if:

1. the libinput driver could automatically recognize power-button devices
2. the evdev / libinput drivers could handle KEY_POWER

For 1, we'd just have to add another case to the libinput_capability enum and a corresponding capability check (just like we do for the other device types in #157).

For 2, performing the shutdown is as easy as

#include <sys/reboot.h>
sync();
reboot(RB_POWER_OFF);

However, I am not sure how to best integrate this into the existing drivers. 🤔

We could add a new case to LV_INDEV_TYPE_POWER to the lv_indev_type_t enum in lvgl but that might mean quite invasive changes.

Alternatively, we could just use LV_INDEV_TYPE_KEYPAD for power button devices and handle the key in indev_keypad_proc. It'll feel a little odd to refer to the device as "keypad" but after all the kernel treats it as a keyboard, too, because it can send keys so maybe that's the best approach.

Since i update the library SSD1306, i got a lot of visual problem in my final application. the "hello world" example work but my app got more objects.

I need to clean some thing.

• I need a custom (perfect) monochrome style setting
• I didn't found the way to set a custom style by default like "font"

For my current Test, i use VDB screen sized (128*64). My first thought about the problem is the wrong style setting.
I got a second thought about the rounder function that will erase object already updated (not confirmed).
I will test more.

I checked out the v8.0 branch in lv_drivers in the hope to have a more-or-less stable branch instead of being on the latest greatest but untested master.
https://github.com/lvgl/lv_drivers/tree/release/v8.0
tag v8.0.1

This branch fails to compile because indev/evdev.c references
drv->disp->driver.hor_res
instead of using a '->' in the last part

This (and more) has been fixed on master
Can we update the v8.0 branch to a working version again?

Line 46 should be:

void sharp_mip_flush(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p);

Line 50 should be:

void sharp_mip_com_inversion(void);

win_drv.c uses the function lv_task_create which does not exist in lvgl v8.0

Someone please implement a VGA display and PS/2(keyboard and mouse) LVGL driver for embedded devices which is implemented on software side and depends only on GPIO access. I came across two such similar libraries- FabGL and vgax but both of them are hardware (ESP32/ARDUINO) specific, would be happy if there is no hardware-specific code in the new driver.

Hi,

I have the following issue with my setup. The data lines for red and blue channels of the LCD are inverted. This leads to having red and blue colors swapped between the UI on desktop (dev env) and UI on target (production env).

I noticed the returned value for red, green and blue channels are not really as expected and as assumed by LVGL (and plenty other tools like https://github.com/phoenix826/fb-test-app). Each pixel is not RGBA (32bits) but rather BGRA (32bits).

One can read this info from struct fb_var_screeninfo. I have not tested, but it looks like this guy is leveraging that data to properly fill pixels into the memory mapped framebuffer https://github.com/sigma-embedded/fbtest/blob/master/fbtest.c.

Here is an extract from the linux kernel fb API (include/uapi/linux/fb.h):

/* Interpretation of offset for color fields: All offsets are from the right,
 * inside a "pixel" value, which is exactly 'bits_per_pixel' wide (means: you
 * can use the offset as right argument to <<). A pixel afterwards is a bit
 * stream and is written to video memory as that unmodified.
 *
 * For pseudocolor: offset and length should be the same for all color
 * components. Offset specifies the position of the least significant bit
 * of the pallette index in a pixel value. Length indicates the number
 * of available palette entries (i.e. # of entries = 1 << length).
 */
struct fb_bitfield {
	__u32 offset;			/* beginning of bitfield	*/
	__u32 length;			/* length of bitfield		*/
	__u32 msb_right;		/* != 0 : Most significant bit is */ 
					/* right */ 
};

struct fb_var_screeninfo {
	__u32 xres;			/* visible resolution		*/
	__u32 yres;
	__u32 xres_virtual;		/* virtual resolution		*/
	__u32 yres_virtual;
	__u32 xoffset;			/* offset from virtual to visible */
	__u32 yoffset;			/* resolution			*/

	__u32 bits_per_pixel;		/* guess what			*/
	__u32 grayscale;		/* 0 = color, 1 = grayscale,	*/
					/* >1 = FOURCC			*/
	struct fb_bitfield red;		/* bitfield in fb mem if true color, */
	struct fb_bitfield green;	/* else only length is significant */
	struct fb_bitfield blue;
	struct fb_bitfield transp;	/* transparency			*/	
	[...]
}

I guess my issue is very specific and I managed to get around it by switching channels in lv_color_t right before it is copied into the framebuffer device.

But how much work would that represent to get support for color channels into fbdev?

Thanks!

I am trying to use LittlevGL with SSD1306 (OLED, Monochrome). I have found this repo containing SSD1306 drivers.

But I couldn't understand how to use these driver with lvgl library and port this driver to my MCU.

Can somebody please help me ?

The driver for display GC9A01 contains macro call to LV_DRV_DISP_SPI_FREQ and LV_DRV_DISP_SPI_MODE. These are not included in the driver config template.

I suggest to remove the SPI settings and let the application set these parameters.

The driver model with the macros also does not support multiple instances of displays, which is possible with lvgl.

Anyway, thanks for the driver templates.

The current evdev and libinput drivers store state in static variables. That means they can only be used with one device at a time but I cannot use, say, two trackpads or a trackpad and a keyboard at the same time (or at least my weak C-fu doesn't let me see how).

It would be great if the driver state could instead be stored in an external structure, to be managed by the caller. This way I could connect an arbitrary number of input devices via either of these drivers.

In order to not break the interface of the existing evdev / libinput drivers maybe a new driver with support for multiple devices could be created and the existing drivers could be changed to use the new one under the hood.

The link in readme document for LVGL porting guide is broken. https://littlevgl.com/porting

Also the one which comes in google search also broken. https://docs.lvgl.io/en/html/porting/index.html

In raspberry pie, the device name of the touch screen and the mouse changes each time depending on whether the mouse is used or not. When the mouse is connected / dev / input / event0 (mouse) and / dev / input / event1 (touch screen), If the mouse is not connected / dev / input / event1 (touch screen).
Therefore, I want to modify a function that can set the touch screen device in such a way that the driver parameter is passed to the function instead of the method defined in the existing lv_drv_conf.h.

~before
evdev_init()

~after
evdev_init(char* device_name)

Hi,

In the current release of LVGL drivers, the linux framebuffer driver is present in display/fbdev.{h,c}. But does it use the fbdev(4) as described here https://manpages.debian.org/stretch/xserver-xorg-video-fbdev/fbdev.4.en.html?

We are developing an GUI using LVGL and a custom linux distribution built with yocto on targeting an i.MX6ULL platform. The display attached is by default in landscape mode, but we want the LVGL GUI to be in portrait mode. We currently set USE_FBDEV=1 and USE_EVDEV=1 in the config file.

Hence, with such a setup, would it be possible to rotate the screen CCW by 90° to achieve expected portrait mode?

In the yocto recipe, we are using the framebuffer distribution, no X11, no Wayland. I'd like to keep it like that because our need is simple: a fullscreen GUI without any desktop environment. I could eventually add X11 to the image and use Xorg.conf file as stipulated int the link above, but wouldn't LVGL bypass X11 since the display/fbdev.c directly use mapped memory to flush graphics?

Thanks for the help,
Hugo

I am trying to port to a Raspberry Pi 4 using gcc compiler.

Attempting to build with evdev enabled yields the following error:
/home/pi/lvgl-test/lv_drivers/indev/evdev.c:228:42: error: ‘drv->disp->driver’ is a pointer; did you mean to use ‘->’?

Changing lines 228-231 in evdev.c to use to arrow operator instead of dot operator fixes the issue on my end.
if(data->point.x >= drv->disp->driver->hor_res) data->point.x = drv->disp->driver->hor_res - 1; if(data->point.y >= drv->disp->driver->ver_res) data->point.y = drv->disp->driver->ver_res - 1;

https://github.com/littlevgl/lv_drivers/blob/2423e655b0b6b7fc82d40889ca7c6ada1ec5528f/indev/libinput.h#L26

Should be #include "lvgl/src/lv_hal/lv_hal_indev.h"

HI!

If i try to use the linux framebuffer code it alwas ends with a compile fail. The failure occurs inside codeblocks that belongs to fbsd. This occurs irrespecitively of how i configre littlvgl in lv_drv_conf.h

in lv_drv_conf.h the use of the freebsd framebuffer code is defined like this

#ifndev USE_BSD_FBDEV
#   deine USE_BSD_FBDEV   0
#endif

Its the same pattern used in all config files, and that means that USE_BSD_FBDEV is always defined and is either 0 or 1.

But in fbdev.c the code checks if USE_BSD_FBDEV is defined or not, and it will always be defined, so the bsd code will always be used.

#ifdef USE_BSD_FBDEV
#include <sys/fcntl.h>
#include <sys/time.h>
#include <sys/consio.h>
#include <sys/fbio.h>
#else  /* USE_BSD_FBDEV */
#include <linux/fb.h>
#endif /* USE_BSD_FBDEV */

The code works fine if its altered to check if USE_BSD_FBDEV is 0 or 1 instead of if it is defined att all. Eg just replace #ifdef with #if in the few locations where the code checks for USE_BSD_FBDEV

Which license does lv_drivers use? How can I use files from this repo?