RZG1M Display configuration in RGB888 format settings

Hello,

 

We are using the elinux yocto 2.0 build system, we would like to configure our display in RGB888 format, where we need to modify to make it work for RGB888 format?

Note : we are using the lvds display which support the RGB888 format.

 

Regards,

Charan

Parents
  • Hi Charan,

    The output of the Display Unit in RZ/G1 is RGB888 and that is connected to the LVDS module.

    Are you asking about the format of the data that you send to the Display Unit?
    In that case RGB888 is not supported, the data format is ARGB, i.e. 32 bit per pixel. That should be the default configuration already, isn't it so in your case?

    What API are you using to talk to the display (framebuffer, DRM/KMS, Wayland)?

    Regards,
    Georgi
  • Hello Georgi,

    Thanks for the reply,

    I think we are using the frame buffer, I attached the document in the below link, which explains the problems we are facing, can you look into it suggest us what can be done to make the display work?

    drive.google.com/open

    Regards,
    Charan
  • Hi Charan,

    From your screenshots it looks like you are using the Weston desktop manager and have some GUI application running on top of it. Is it just this application that is displaying correctly or do other applications have this issue as well?
    E.g. you can run 'weston-simple-egl' from the command line and see what it looks like.

    There are two different schreenshots of the framebuffer configuration - one is 1280x800 and the other one is 1920x1080, so I am not sure which one is the one that has the issue.

    A couple of things you can try -
    1. Set the screen resolution in u-boot. Modify the parameter bootargs and add something like this -
    video=LVDS-1:1280x800-32@60

    2. Set the resolution in Weston.ini -
    Edit the file /etc/xdg/weston/weston.ini and add a section like this -
    [output]
    name=LVDS1
    mode=1280x800

    Regards,
    Georgi
  • Hello Georgi,

    All the applications have the same issues, I attached the video captured from the display after runinng the 'weston-simple-egl' from the command line.
    drive.google.com/open

    The frame buffer configuration with 1280x800 have the issue.

    I tried both the configuration as you suggested but no improvements,

    Below is the bootargs command what i set during boot time

    setenv bootargs 'console=ttySC10,38400 ignore_loglevel rw root=/dev/nfs nfsroot=192.168.2.6:/nfs/skrzg1m,nfsvers=3 ip=192.168.2.10:192.168.2.6::255.255.255.0:skrzg1m vmalloc=384M video=LVDS-1:1280x800-32@60'


    saveenv

     

    Updates:

    Hello georgi, we have improvements after made some modifications in the bootargs, that is video=LVDS-1:1280x800-16@60.

    because of this change During the boot time we will get the yocto image that is coming good but after that when weston starts display again going to be blured as previous issue.

     

    Regards,

    Charan

  • Hi Charan,

    A couple of suggestions -

    1. Make some modification to the [output] section in weston.ini to make sure that the section is being processed. E.g. change the resolution, or rotate the screen -
    [output]
    name=...
    transform=180

    2. Set the 'mode' parameter in the same section to 'current', which should prevent Weston from changing the current mode -
    [output]
    name=...
    mode=current

    Regards,
    Georgi
  • Hello Georgi,

    weston file which is present in the path /etc/xdg/weston/weston.ini does not contain any data, I added the below lines, after that i did the reset to check but no improvements(The changes we made in the weston.ini are not reflecting after reset, for example transform=180 should rotate the screen but its not happening).
    [output]
    name=LVDS1
    mode=current
    transform=180


    When i ran the command weston-info in command line, I got the below informations,
    weston-info
    interface: 'wl_compositor', version: 3, name: 1
    interface: 'wl_subcompositor', version: 1, name: 2
    interface: 'wl_scaler', version: 2, name: 3
    interface: 'presentation', version: 1, name: 4
    presentation clock id: 1 (CLOCK_MONOTONIC)
    interface: 'wl_data_device_manager', version: 2, name: 5
    interface: 'wl_shm', version: 1, name: 6
    formats: RGB565 XRGB8888 ARGB8888
    interface: 'wl_kms', version: 2, name: 7
    interface: 'wl_seat', version: 4, name: 8
    name: default
    capabilities: pointer keyboard touch
    keyboard repeat rate: 40
    keyboard repeat delay: 400
    interface: 'wl_output', version: 2, name: 9
    x: 0, y: 0,
    physical_width: 229 mm, physical_height: 149 mm,
    make: 'unknown', model: 'unknown',
    subpixel_orientation: unknown, output_transform: normal,
    mode:
    width: 1280 px, height: 800 px, refresh: 60 Hz,
    flags:
    mode:
    width: 1280 px, height: 800 px, refresh: 60 Hz,
    flags:
    mode:
    width: 1280 px, height: 800 px, refresh: 60 Hz,
    flags: current
    interface: 'wl_input_panel', version: 1, name: 10
    interface: 'wl_input_method', version: 1, name: 11
    interface: 'wl_text_input_manager', version: 1, name: 12
    interface: 'wl_shell', version: 1, name: 13
    interface: 'xdg_shell', version: 1, name: 14
    interface: 'desktop_shell', version: 3, name: 15
    interface: 'workspace_manager', version: 1, name: 16
    interface: 'screenshooter', version: 1, name: 1

     

    Update:

    When i am trying to run the weston example application by executing the command weston-subsurfaces below are the config details visible.

    weston-subsurfaces
    Chosen EGL config details:
        RGBA bits: 8 8 8 8
        swap interval range: 0 - 1

    But what we set in the boot args for display is video=LVDS-1:1280x800-16@60. (I think this RGB565).


    Regards,
    Charan

  • Hi Charan,

    It looks like in the Yocto 2.0 BSP the name of the LVDS output in Weston is 'LVDS-1', not 'LVDS1'. Would you please give that a try?

    If that doesn't work, you can also look at the Weston log to see what name is listed there for the output.

    Regards,
    Georgi
  • HI Georgi,

    As you suggested I tried it, Now display transformation is happening, but the display blurness still existed as mentioned in previous conversation, I am not sure why display is not coming properly once the weston starts.

    Regards,

    Charan

  • Hello Georgi,

    Just to be in the track the issue we are facing is:

    The lvds display not running properly after Weston starts [(some color are missing or wrong pixel format its referring not sure)] , but before Weston starts yocto image(Symbol) will come during boot it is displaying fine. Currently lvds is configured with pixel size 16(we tested 24 as well as 32 for these values even yocto symbol also will not display properly).

    since lvds display is working fine with the yocto 1.6, We tried to understand what are the changes between the yocto 1.6 and yocto 2(We are having issue in display), we found following changes as seen the below diagram,

    1. In yocto 2 default pixel size is 32(RGB888) whereas in yocto 1.6 its 24 (RGB666),

    And also In yocto 2 we tried to change the pixel size to 16, 18, 24, 32 no improvements except the pixel size 16, where the yocto image during boot time coming properly as mentioned in previous mails but after Weston starts the display again not proper.

    2. As you asked in previous mails which api you are using to communicate to display unit -> we didn't get how to check that, but when i checked the back-end which is used by Weston to run it looks like drm back-end.

    Please suggest the ways to debug to get the useful information to solve the issue.

  • Hi Charan,

    Did you try the combination of the correct name for the LVDS output and 'current' mode in Weston.ini? I.e. -
    [output]
    name=LVDS-1
    mode=current
    (and specify 16 bit color in 'bootargs')

    Another thing you can try is set the pixel format in Weston.ini -
    [core]
    gbm-format=rgb565

    Regards,
    Georgi
  • Hi Georgi,

    Thanks for the response,

    Did you try the combination of the correct name for the LVDS output and 'current' mode in Weston.ini? I.e. -
    [output]
    name=LVDS-1
    mode=current
    (and specify 16 bit color in 'bootargs')
    --> Yes i tried by editing the weston.ini file with below details
    [output]
    name=LVDS-1
    mode=current
    transform=180
    -->Transform is happening i.e display is rotating by 180 degrees. But the color blurness still there.

    Another thing you can try is set the pixel format in Weston.ini -
    [core]
    gbm-format=rgb565
    --> When i adding the gbm-format=rgb565 display is not coming, i got the following error in the weston log,
    [19:34:44.863] weston 1.9.0
    http://wayland.freedesktop.org
    Bug reports to: bugs.freedesktop.org/enter_bug.cgi
    Build: 1.8.93-2-gb05cdb8 configure.ac: bump to version 1.9.0 for
    [19:34:44.863] OS: Linux, 4.4.6, #1 SMP PREEMPT Thu Apr 4 00:45:20 IST 2019, arm
    [19:34:44.866] Using config file '/etc/xdg/weston/weston.ini'
    [19:34:44.872] Loading module '/usr/lib/weston/drm-backend.so'
    [19:34:44.960] Output repaint window is 7 ms maximum.
    [19:34:44.960] initializing drm backend
    [19:34:44.963] using /dev/dri/card0
    [19:34:44.966] Loading module '/usr/lib/weston/gl-renderer.so'
    [19:34:45.027] warning: either no EGL_EXT_platform_base support or specific plat
    [19:34:45.082] warning: EGL_EXT_buffer_age not supported. Performance could be a
    [19:34:45.083] warning: EGL_EXT_swap_buffers_with_damage not supported. Performa
    [19:34:45.153] input device 'USB Optical Mouse', /dev/input/event1 is tagged by
    [19:34:45.153] input device 'USB Optical Mouse', /dev/input/event1 is a pointer
    [19:34:45.154] input device 'gpio-keys', /dev/input/event0 is tagged by udev as:
    [19:34:45.154] input device 'gpio-keys', /dev/input/event0 is a keyboard
    [19:34:44.002] failed to create gbm surface
    [19:34:44.002] Failed to init output gl state
    [19:34:44.002] No currently active connector found.
    [19:34:44.003] failed to create output for /sys/devices/platform/feb00000.displa
    [19:34:44.290] fatal: failed to create compositor backend

    doubt : When i am doing search in internet i found that, the kernel we are using have theDRM driver supports emulation for the fbdev display interface, does the drm and fb have the different values for pixel size? is that causing the issue?
    here i found the details -> developer.toradex.com/.../display-output-resolution-and-timings-linux

    Regards,
    charan
  • Hi Charan,

    I don't think Weston is using the framebuffer interface, it uses DRM/KMS directly. However, it is a good idea to see if the framebuffer interface works fine. You can do a test like this -
    1. Stop Weston
    2. Write a test application that draws something directly to the framebuffer ('/dev/fb0'), e.g. a square, and see whether that displays fine.

    Regards,
    Georgi
  • Hello Georgi,

    we tried to run an sample application that will display multiple colors by directly to the frame buffer. It worked perfectly.
    for testing the application I stopped the weston and run the sample application as you suggested it worked fine.

    please help us to resolve the weston issue.

    Regards,
    charan

Reply
  • Hello Georgi,

    we tried to run an sample application that will display multiple colors by directly to the frame buffer. It worked perfectly.
    for testing the application I stopped the weston and run the sample application as you suggested it worked fine.

    please help us to resolve the weston issue.

    Regards,
    charan

Children
  • Hi Charan,

    So it looks like the problem is either in Weston or in the EGL library.
    These messages below are actually displayed by the graphics library -

    dc_linuxfb - Found usable fbdev device ():
    range (physical) = 0x57900000-0x57ce8000
    size (bytes) = 0x3e8000
    xres x yres = 1280x800
    xres x yres (v) = 1280x800
    img pix fmt = 20
    num buffers = 1

    Can you tell me what is the value that you see for 'img pix fmt' now that you specify 16-bit color in u-boot?

    Another question - are you using the RZ/G1M Starter Kit board or a board that has an HDMI output?
    If so, can you connect a display to the HDMI port and see if the image on that display will have the same issue?

    Regards,
    Georgi
  • Hello Georgi,

    yes we are specified 16-bit color in u-boot using the boot argument video=LVDS-1:1280x800-16@60.

    Below is the screen shot for the img pix fmt value displaying during boot messages. It is showing value 1.

     

    We are using the RZ/G1M starter kit same as image shown in the below link.

    https://elinux.org/RZ-G/Boards/SK-RZG1M

     

    In the starter kit we have the HDMI port and we are not facing any issue with HDMI display, we are getting proper display output.

     

    Regards,

    Charan

  • Hi Charan,

    Ok, 'img pix fmt' of 1 means RGB565 in the graphics library, so that is confirmed.

    I would suggest these as next steps -

    1. Remove the line 'transform=180' or any other line from the [output] section in weston.ini other than the lines for 'name' and 'mode'. I think if you have any other parameter there that may be overriding the flag 'name=current'. I.e. the section should look like this -

    [output]
    name=LVDS-1
    mode=current

    2. Completely remove the usage of the graphics library -
    2.1. Make sure Weston is not using the GPU for composition. Check the file /etc/defaults/weston and verify that OPTARGS has this part in it -> "--use-v4l2".
    2.2. Rename the file /etc/init.d/rc.pvr and create an empty file with the same location and the same name. This is the script that loads the graphics library, so we don't want it to do that.
    2.3. Restart the board. When you log in and check /proc/modules, there should be no module named 'pvrsrvkm' there.

    Check how the Weston background looks. You can also run some Weston examples that don't need OpenGL, e.g. 'weston-flower' and see how those look on the screen.

    By the way, you mentioned before that in Yocto 1.6 the default pixel size is 24 bits (RGB666) while in Yocto 2.0 it is 32 bits (RGB888). Where did you see this?

    Regards,
    Georgi
  • Hello Georgi,

    1. In the weston.ini file default no section, we added to test, as you suggested i kept only below lines,

    [output]
    name=LVDS-1
    mode=current

    2.
    2.1. I checked the file Check the file /etc/defaults/weston, it contains below lines in that there is no part --use-v4l2,
    #!/bin/sh

    OPTARGS="--idle-time=0"

    now i updated for testing as below
    #!/bin/sh
    OPTARGS="--use-v4l2 --idle-time=0"

    2.2 There is no folder named /proc/modules i checked /proc folder there is a module called pvr, after making the modification as you suggested that is, renaming the /etc/init.d/rc.pvr and added new empty file with the same name, inside the /proc folder the pvr module no more exist after restart.

    After doing all the changes and reset still the behavior not changed, issue still existed and weston-flower example also not coming properly.


    By the way, you mentioned before that in Yocto 1.6 the default pixel size is 24 bits (RGB666) while in Yocto 2.0 it is 32 bits (RGB888). Where did you see this?
    --> before setting the boot argument video=LVDS-1:1280x800-16@60, we tested the command fbset command. The response is as below for yocto 1.6

    mode "1280x800-0"
    # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
    geometry 1280 800 1280 800 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
    endmode

    and for yocto 2.0
    rgba displayed with the 888.

    Based on that we thought its rgb888.

    Regards,
    Charan
  • Hi Charan,

    At the beginning of this thread you had linked a file where you were showing some code changes that you made to panel-simple.c. There you had specified 8 bits per pixel and RGB888 format. This is probably why you are seeing that in fbset.

    Why did you make those changes? I am looking at my Yocto 2.0 build environment and panel-simple.c there has a definition for the hannstar panel, specifying 6 bits per pixel and RGB666 format. I think this is the format that you should use. Do you try to run it this way?

    Regards,
    Georgi
  • Hello Georgi,

    we tried by making 666 as well as 888 format, currently we are using the RGB666 format only, I attached the screen shot of the  panel-simple.c which we made changes. { we tested all your above thread suggestion related to weston.ini and weston are tested in RGB666 format}.

     

    Regards,

    Charan

  • Hello Georgi,

    Updates:
    In order make sure whether the timing parameter we updated for hannstar display in panel-simple.c is working or not, we made the .clock value to 0 and also .vrefresh to 0.
    We expected that since the frequency and refresh value is zero, display should not come, but there is effect on the display its coming as previous.
    Do we miss something here?
    why if we change the display timings its not reflecting?

    Do we have any command to test what is the clock frequency, refresh rate, vsync hsync etc during run time?

    Regards,
    Charan
  • Hi Charan,

    Even if you specify zeros for some parameters the driver will ignore them if they are not valid and will make sure to specify valid values to the hardware.

    I am not sure what else I can suggest, other than troubleshooting this at the driver level and seeing what the differences are between the way the driver configures the hardware in Yocto 1.6 and Yocto 2.0.

    To check the various timing parameters from the command line you can use modetest -
    modetest -M rcar-du

    To troubleshoot the driver, just trace the display timing values in the function rcar_du_crtc_set_display_timing(), located in -
    drivers/gpu/drm/rcar-du/rcar_du_crtc.c.
    There must be some difference in those values between Yocto 1.6 and 2.0 that explains the display issue you are seeing.

    Regards,
    Georgi