• Replies 23 replies
  • Subscribers 330 subscribers
  • Views 6989 views
  • Users 0 members are here
Options
Related

RZG1M Display configuration in RGB888 format settings

Charan K S
over 1 year ago

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
  • over 1 year ago
    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
  • over 1 year ago in reply to 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
  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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

  • over 1 year ago in reply to Charan K S

    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.

  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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
  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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

  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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

  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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
  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to 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

  • over 1 year ago in reply to Charan K S
    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
  • over 1 year ago in reply to Charan K S
    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
Reply
  • over 1 year ago in reply to Charan K S
    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
Children
No Data