Information for Wayland/Weston

From Renesas.info

RZ-G


Note: weston-ini is located /etc/xdg/weston/weston.ini
To edit the file weston.ini you can use the 'vi' editor that is in the BSP.

Remove toolbar and clock

In weston-ini,

[shell]
clock-format=none
panel-position=none

Single color setting of background

In weston-ini,

[shell]
background-color=0xff000000   <- Black
background-color=0xffff0000   <- Red
background-color=0xff00ff00   <- Green
background-color=0xff0000ff   <- Blue

Top 8 bits are an alpha value. For example, 0x7fxxxxxx is translucent, but 0x00xxxxxx is not transparent and the wallpaper is displayed.

Remove Window Frame

To remove window frame on a Qt app, follow https://stackoverflow.com/questions/3948441/how-to-remove-the-window-border-containing-minimize-maximize-and-close-buttons

Changing the Video Mode for Weston

The display configuration is controlled by a file named 'weston.ini' located in the folder /etc/xdg/weston. Currently there is this section in it that sets some specific display timings.
In order to make a display work with the RZ/G2 board, the 'mode' settings need to be change to something that the display supports. In order to find those settings, run the 'cvt' command providing it the desired mode as parameters.
For example, on the RZ/G2E board, the maximum resolution is 1080p at 30Hz. Therefore you would use the command:

cvt 1920 1080 30  

This should give you the proper display timings for running your display at 1080p 30fps and will force that specific mode.

You can also just specify a resolution (without timing).

[output]  
name=HDMI-A-1 
mode=1280x720

After modifying the configuration and saving the file, restart the Weston desktop using this command:

systemctl restart weston

Another option is to set mode to "current" which keeps the current video resolution that the system was booted with.

[output]  
name=HDMI-A-1  
mode=current 

Then then set the resolution on the kernel command line in u-boot by changing the boot args to specify the resolution you want:

=> setenv bootargs 'root=/dev/mmcblk0p2 rootwait video=HDMI-A-1:1280x720-32 
=> saveenv

Take a Screenshot

You can take a screenshot on our board by using the utility weston-screenshooter.

  • Modify the file /etc/default/weston and add the line:
OPTARGS="--debug" 
  • Restart weston by using the command:
$ systemctl restart weston
  • While your application is running, use the following command:
$ weston-screenshooter
  • After running weston-screenshooter, a .png file will be created in that directory. For example: "wayland-screenshot-2020-09-20_10-47-10.png"

Enable /dev/fb0

The legacy Frame Buffer device interface (/dev/fb0) exists in the system, but when you write to it, nothing will be changed on the LCD when Weston is running. Therefore, if you want to use /dev/fb0, please disable weston.

systemctl stop weston

When you want to use weston again, please run

systemctl start weston

Multi-display with Wayland/Weston

One of the most frequently asked question is how to drive multiple display with RZ/G2 (RZ/G2E-N-M-H, since RZ/G2L cannot really drive two displays).

There are some limitations on what Weston, as Wayland compositor, can do. Some limitations are due to Wayland protocol itself.

The most important thing to bear in mind is that what Weston can do well is extended desktop, for clone mode there are patches but they are not tested, independent driving is not really supported because it would require two DRM/KMS devices. However, also in extended mode there are caveats. By design Wayland does not allow application to set the position, each new window has, instead, a random initial position and then the user can move it or set to full screen. Wayland does allow applications to open in full-screen but it will open in the current active display, that is the one with the mouse pointer or last touch input. (utouch-evemu could be theoretically used to select the current active display).

Because of this limitation, a workaround using IVI-shell (In-vehicle infotainment) can be considered: it extends the Wayland core protocol to tie wl_surface and a given ID. With this ID, shell can identify which wl_surface is drawn by which application.

Another possibility is not to use Weston to control both screen, so one display can be managed by Weston / DRM and therefore have the full HW acceleration, the other is instead handled by LinuxFB/DirectFB purely in SW. This can be often acceptable for relatively simple/static GUIs.

Qt

Regarding QT, theoretically there can be a Qt application using EGLFS and another one using OpenGLES through Wayland. However this option cannot work because RZ/G2 does not support EGLFS. More details about Qt for Embedded Linux are available here.

Android

On Android, instead, multi display is much better supported and the limitations above do not apply. There is also a demo showing the dual display support with RZ/G2M (details / link TBD).