weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2019-06-27T13:39:46Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/227ARM Mali support for GBM_BO_IMPORT_WL_BUFFER2019-06-27T13:39:46ZRandy LiARM Mali support for GBM_BO_IMPORT_WL_BUFFERI wondered why the weston can't select a new DRM plane for a windows which is not overlay.
We though it is gbm problem, because the gbm failed at gbm_bo_import() with GBM_BO_IMPORT_WL_BUFFER type.
I verified GBM_BO_IMPORT_FD before, it...I wondered why the weston can't select a new DRM plane for a windows which is not overlay.
We though it is gbm problem, because the gbm failed at gbm_bo_import() with GBM_BO_IMPORT_WL_BUFFER type.
I verified GBM_BO_IMPORT_FD before, it would work.
@daniels pointed out it is a problem of the ARM Mali DDK. To make it work, we need to
a) the Mali DDK (EGL client side) needs to be changed to use zwp_linux_dmabuf_v1, just like Mesa's EGL client code does
b) the Mali DDK (Wayland server side) needs to be changed to expose EGL_EXT_image_dma_buf_import_modifiers - even if you only use linear buffers, the import_modifiers extension adds query functions to declare which formats are supported. without this extension, it is impossible to know which formats the EGL stack supports.
Although only adapted the second idea would make thing easy, but you need to modify a ARM fork weston to avoid supporting gbm_bo_import() with GBM_BO_IMPORT_WL_BUFFER type in this path.https://gitlab.freedesktop.org/wayland/weston/-/issues/233Controlling display standby and wakeup2022-01-18T10:32:44ZAnte TrbojevicControlling display standby and wakeupIs there a way to tell Weston from client application to send displays to standby mode (controlling DPMS modes) or wake up them when app wants it?
I know I can disable idle in weston config file, however I would like to have a full cont...Is there a way to tell Weston from client application to send displays to standby mode (controlling DPMS modes) or wake up them when app wants it?
I know I can disable idle in weston config file, however I would like to have a full control of standby/wakeup displays in the client app.https://gitlab.freedesktop.org/wayland/weston/-/issues/261Weston Master fails to compile after recent changes2019-07-02T23:10:32Zn3rdopolisWeston Master fails to compile after recent changesIt could be because I am building it with 8 threads?
This is what I get
```
[121/418] cc -Ilibweston/2b98b6d@@weston-7@sha -Ilibweston -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibweston/../shared -I../libweston/../shared -Iinc...It could be because I am building it with 8 threads?
This is what I get
```
[121/418] cc -Ilibweston/2b98b6d@@weston-7@sha -Ilibweston -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibweston/../shared -I../libweston/../shared -Iinclude -I../include -I. -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -MD -MQ 'libweston/2b98b6d@@weston-7@sha/touch-calibration.c.o' -MF 'libweston/2b98b6d@@weston-7@sha/touch-calibration.c.o.d' -o 'libweston/2b98b6d@@weston-7@sha/touch-calibration.c.o' -c ../libweston/touch-calibration.c
[122/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o' -c ../libweston/backend-drm/drm.c
FAILED: libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o
cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/drm.c.o' -c ../libweston/backend-drm/drm.c
../libweston/backend-drm/drm.c: In function ‘drm_output_start_repaint_loop’:
../libweston/backend-drm/drm.c:563:2: warning: implicit declaration of function ‘drm_output_assign_state’; did you mean ‘drm_output_state_free’? [-Wimplicit-function-declaration]
drm_output_assign_state(state, DRM_STATE_APPLY_ASYNC);
^~~~~~~~~~~~~~~~~~~~~~~
drm_output_state_free
../libweston/backend-drm/drm.c:563:33: error: ‘DRM_STATE_APPLY_ASYNC’ undeclared (first use in this function); did you mean ‘AT_STATX_FORCE_SYNC’?
drm_output_assign_state(state, DRM_STATE_APPLY_ASYNC);
^~~~~~~~~~~~~~~~~~~~~
AT_STATX_FORCE_SYNC
../libweston/backend-drm/drm.c:563:33: note: each undeclared identifier is reported only once for each function it appears in
[123/418] cc -Ilibweston/renderer-gl/15977bd@@gl-renderer@sha -Ilibweston/renderer-gl -I../libweston/renderer-gl -Ilibweston/renderer-gl/../.. -I../libweston/renderer-gl/../.. -Ilibweston/renderer-gl/../../shared -I../libweston/renderer-gl/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include/pixman-1 -I/opt/include -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -MD -MQ 'libweston/renderer-gl/15977bd@@gl-renderer@sha/gl-renderer.c.o' -MF 'libweston/renderer-gl/15977bd@@gl-renderer@sha/gl-renderer.c.o.d' -o 'libweston/renderer-gl/15977bd@@gl-renderer@sha/gl-renderer.c.o' -c ../libweston/renderer-gl/gl-renderer.c
[124/418] cc -Ilibweston/backend-drm/75c3287@@backlight@sta -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -I/opt/include -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -MD -MQ 'libweston/backend-drm/75c3287@@backlight@sta/libbacklight.c.o' -MF 'libweston/backend-drm/75c3287@@backlight@sta/libbacklight.c.o.d' -o 'libweston/backend-drm/75c3287@@backlight@sta/libbacklight.c.o' -c ../libweston/backend-drm/libbacklight.c
[125/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/modes.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/modes.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/modes.c.o' -c ../libweston/backend-drm/modes.c
[126/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/state-helpers.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/state-helpers.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/state-helpers.c.o' -c ../libweston/backend-drm/state-helpers.c
[127/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/fb.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/fb.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/fb.c.o' -c ../libweston/backend-drm/fb.c
[128/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/state-propose.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/state-propose.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/state-propose.c.o' -c ../libweston/backend-drm/state-propose.c
[129/418] cc -Ilibweston/backend-drm/75c3287@@drm-backend@sha -Ilibweston/backend-drm -I../libweston/backend-drm -Ilibweston/backend-drm/../.. -I../libweston/backend-drm/../.. -Ilibweston/backend-drm/../../shared -I../libweston/backend-drm/../../shared -Ilibweston -I../libweston -Iinclude -I../include -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -pthread -MD -MQ 'libweston/backend-drm/75c3287@@drm-backend@sha/kms.c.o' -MF 'libweston/backend-drm/75c3287@@drm-backend@sha/kms.c.o.d' -o 'libweston/backend-drm/75c3287@@drm-backend@sha/kms.c.o' -c ../libweston/backend-drm/kms.c
[130/418] cc -Ilibweston/2b98b6d@@weston-7@sha -Ilibweston -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibweston/../shared -I../libweston/../shared -Iinclude -I../include -I. -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -MD -MQ 'libweston/2b98b6d@@weston-7@sha/input.c.o' -MF 'libweston/2b98b6d@@weston-7@sha/input.c.o.d' -o 'libweston/2b98b6d@@weston-7@sha/input.c.o' -c ../libweston/input.c
[131/418] cc -Ilibweston/2b98b6d@@weston-7@sha -Ilibweston -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibweston/../shared -I../libweston/../shared -Iinclude -I../include -I. -Iprotocol -I/opt/include -I/opt/include/pixman-1 -I/opt/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -Os -Wno-error -fPIC -MD -MQ 'libweston/2b98b6d@@weston-7@sha/compositor.c.o' -MF 'libweston/2b98b6d@@weston-7@sha/compositor.c.o.d' -o 'libweston/2b98b6d@@weston-7@sha/compositor.c.o' -c ../libweston/compositor.c
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/wayland/weston/-/issues/319After the compilation of global keymap is failure, weston dies suddenly2019-12-04T02:48:04ZJay JeonAfter the compilation of global keymap is failure, weston dies suddenlyWeston version : v1.12.0
Hi all,
if weston was failure for compiling global keymap, some problems are happened from weston.
**1. Two key events are occuring per one key action**
When I push and release a button, weston detects fo...Weston version : v1.12.0
Hi all,
if weston was failure for compiling global keymap, some problems are happened from weston.
**1. Two key events are occuring per one key action**
When I push and release a button, weston detects four key-events for one key-action.
Actually, the real key-event is two, but all key-codes are same.
**weston.log**
```
[19:58:55.297] input device 'tca8418', /dev/input/event0 is tagged by udev as: Keyboard
[19:58:55.297] input device 'tca8418', /dev/input/event0 is a keyboard
[19:58:55.299] input device 'Rohm-CTP-BU21023MUV', /dev/input/event1 is tagged by udev as: Touchscreen
[19:58:55.300] kernel bug: Device 'Rohm-CTP-BU21023MUV' has min == max on ABS_PRESSURE
[19:58:55.300] input device 'Rohm-CTP-BU21023MUV', /dev/input/event1 was rejected.
[19:58:55.383] not using input device '/dev/input/event1'.
[19:58:55.384] failed to compile global XKB keymap
```
**When WAYLAND_DEBUG is enabled**
```
$ libinput-in-debug-events
-event0 DEVICE_ADDED tca8418 seat0 default group1 cap:k
-event0 KEYBOARD_KEY +4.72s KEY_1 (2) pressed
event0 KEYBOARD_KEY +4.72s KEY_1 (2) released
[2744315.415] wl_keyboard@3.key(289, 4453816, 2, 1)
[2744315.807] wl_keyboard@3.key(290, 4453816, 2, 0)
[2744315.949] wl_keyboard@3.key(291, 4453816, 2, 1)
[2744316.119] wl_keyboard@3.key(292, 4453816, 2, 0)
```
**2. weston sometimes dies suddenly**
I tried to get some logs when weston died, but I didn't get any logs from weston.
I just want to know the reason why weston dies.
Is this issue resolved on the next version?
I compared 'input.c' file with the latest code, but too many liens were changed. So I didn't know what's the patch for this issue.https://gitlab.freedesktop.org/wayland/weston/-/issues/364Any Linear gradient drawing like API supported ?2020-02-14T10:11:36ZbutterAny Linear gradient drawing like API supported ?Hi,
I'm new to weston and still learning the code. Since from the code reading and search , I do not find API like Linear gradient drawing in compositor module. Is there magic API hidden or I need to add my own implementation , or I n...Hi,
I'm new to weston and still learning the code. Since from the code reading and search , I do not find API like Linear gradient drawing in compositor module. Is there magic API hidden or I need to add my own implementation , or I need to draw Linear gradient for a windows before sending to compositor?
Thanks.https://gitlab.freedesktop.org/wayland/weston/-/issues/379Firefox crashes with `xdg_surface buffer does not match the configured state`2020-03-17T13:28:57ZPaul MenzelFirefox crashes with `xdg_surface buffer does not match the configured state`Using Debian Sid/unstable with 32-bit user space and with Weston 8.0 and Firefox 73.0.1, starting Firefox
MOZ_ENABLE_WAYLAND=1 firefox
it crashes with `xdg_surface buffer does not match the configured state`.
Sometimes the Firefox...Using Debian Sid/unstable with 32-bit user space and with Weston 8.0 and Firefox 73.0.1, starting Firefox
MOZ_ENABLE_WAYLAND=1 firefox
it crashes with `xdg_surface buffer does not match the configured state`.
Sometimes the Firefox window is visible, sometimes it’s not. It seems to work better with Sway WM on the same system.https://gitlab.freedesktop.org/wayland/weston/-/issues/386Westond freeze after Display Port connector is replugged2020-05-06T08:50:10ZRobertWestond freeze after Display Port connector is repluggedHello,
I have found that sometimes weston do not recapture primary plane after connector re-plug (I am testing a driver for display port]. When I disconnect a connect DP cable sometimes Weston loose track to primary plane. I found that i...Hello,
I have found that sometimes weston do not recapture primary plane after connector re-plug (I am testing a driver for display port]. When I disconnect a connect DP cable sometimes Weston loose track to primary plane. I found that in function drm_plane_is_available() in [libweston/compositor-drm.c] is a condition if (plane->state_cur->output && plane->state_cur->output != output) which sometimes failed. When I bypassed this condition with a little "pig like" code plane->state_cur->output = output; problem disappeared. Of course it is not solution it is rather "forcing my opinion".
We are using weston 5.0.0 from NXP YOCTO distribution. our git: git.congatec.com/imx8m_early_access/meta-fsl-bsp-release
(I will check public access).
Thanks for support. - mails: robert.pasz@congatec.com robo.pasz@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/-/issues/391how to select wayland output for my application2020-04-17T11:45:16ZHaihua Huhow to select wayland output for my applicationI'm running wayland/weston 8.0 on imx8 platform with multidisplay. The embedded system has 3 independent display controller and weston manage they as 3 wl_outputs. How can I programmable select which output(display) I want the app run on...I'm running wayland/weston 8.0 on imx8 platform with multidisplay. The embedded system has 3 independent display controller and weston manage they as 3 wl_outputs. How can I programmable select which output(display) I want the app run on? Is there any protocol or api I can use in my wayland app?https://gitlab.freedesktop.org/wayland/weston/-/issues/406Virtual keyboard does not come up when expected, is there a way to find out why?2020-06-18T17:22:49ZgosphVirtual keyboard does not come up when expected, is there a way to find out why?I'm using weston (weston-desktop-shell) on a mobile phone running [Postmarket OS](https://wiki.postmarketos.org). `weston-keyboard` is running, and it does show up when tapping on one of the entries in `weston-editor`, but does not when ...I'm using weston (weston-desktop-shell) on a mobile phone running [Postmarket OS](https://wiki.postmarketos.org). `weston-keyboard` is running, and it does show up when tapping on one of the entries in `weston-editor`, but does not when a text-input widget in any other application I've tried so far recieves focus.
I've also tried other virtual keyboards (e.g., matchbox-keyboard) in weston.ini; the result was the keyboard appeared, centered on screen, but did not respond to any widget recieving focus, i.e., as if it was a normal application window.
Looking into weston.log, I find that my devices' physical buttons are recognized as keyboards by libinput (see the attached weston.log, ll. 23-37).
Could that be the cause?
Another theory I have is that this may be related to the small screen size (it's a relatively old mobile phone) and when weston-keyboard appears for weston-editor, it does not manage to fit screen width, only displaying the keys between e and p.
Attached files:
- [weston.log](/uploads/c7f20f12007f544c02b8221359d14010/weston.log)
- [weston.ini](/uploads/b742e5091f43ee6ef443b066326c3471/weston.ini)https://gitlab.freedesktop.org/wayland/weston/-/issues/407Weston crashes on launching dolphin-emu on a Nouveau GPU using PRIME2020-06-02T10:37:33ZLink MauveWeston crashes on launching dolphin-emu on a Nouveau GPU using PRIMEHere is the relevant log from stderr:
```
[11:12:21.835] Spawned Xwayland server, pid 4179
glamor: No eglstream capable devices found
[11:12:21.962] xfixes version: 5.0
[11:12:21.966] created wm, root 924
The XKEYBOARD keymap compiler (x...Here is the relevant log from stderr:
```
[11:12:21.835] Spawned Xwayland server, pid 4179
glamor: No eglstream capable devices found
[11:12:21.962] xfixes version: 5.0
[11:12:21.966] created wm, root 924
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Unsupported maximum keycode 569, clipping.
> X11 cannot support keycodes above 255.
> Internal error: Could not resolve keysym Invalid
Errors from xkbcomp are not fatal to the X server
weston: cairo-xcb-screen.c:219: _get_screen_index: Assertion `!"reached"' failed.
(EE) failed to read Wayland events: Broken pipe
```
Since this is Xwayland, running a Qt application (so otherwise using EGL), this might be caused by drawing the frame around the X11 window.
I’m on Weston master (https://gitlab.freedesktop.org/wayland/weston/-/commit/40c519a3e6130f4f5f41b564057507a1e993fb5d), Xwayland 1.20.8, Mesa 20.1.0, Linux 5.6.15, on a Nvidia 1070 running Nouveau, while Weston renders/scanouts on an Intel UHD630.
This might be linked to https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035, which happens in the exact same environment, except without using `DRI_PRIME=1`.https://gitlab.freedesktop.org/wayland/weston/-/issues/411unable to set screen resolution on cubieboard2 (Allwinner A20)2020-06-18T09:12:26ZderMartunable to set screen resolution on cubieboard2 (Allwinner A20)Hi, I am using armbian 20.05 focal on the cubieboard2\
It uses the lima mesa driver and the sun4i drm driver. weston version 8.0.0\
I am unable to set the screen resolution (always uses current/monitor preferred, which is 1280x1024)\
I a...Hi, I am using armbian 20.05 focal on the cubieboard2\
It uses the lima mesa driver and the sun4i drm driver. weston version 8.0.0\
I am unable to set the screen resolution (always uses current/monitor preferred, which is 1280x1024)\
I am trying to set 800x600 which is listed as possible resolution when weston starts[weston.log](/uploads/a387f1aca7fa7eac28c675f3dffd9081/weston.log)[dmesg.log](/uploads/d75cc9df8d5ae6a196e02dcb814f12fb/dmesg.log).
Added one output section to the ini file
```
[output]
mode=800x600
```
Weston launches, but resolution stays 1280x1024. No mention about trying to set 800x600 in the weston log (weston.log)\
I also enabled drm_debug as shown [here](https://github.com/swaywm/wlroots/wiki/DRM-Debugging) but this output (dmesg.log) also does not list any attempt to switch to 800x600
Any idea what is wrong here?
best
Martinhttps://gitlab.freedesktop.org/wayland/weston/-/issues/417Surfaces and views not marked as is_mapped2021-02-04T16:39:22ZJoseph Newmanjoseph@josephn.netSurfaces and views not marked as is_mappedWithin `libweston` `compositor.c`, I can not determine where surfaces and views are marked as `is_mapped = true`, except for the `view_list_add_subsurface_view()` and `subsurface_committed()` cases.
Symptom is I cannot clear a surface b...Within `libweston` `compositor.c`, I can not determine where surfaces and views are marked as `is_mapped = true`, except for the `view_list_add_subsurface_view()` and `subsurface_committed()` cases.
Symptom is I cannot clear a surface by attaching a NULL buffer using `wl_surface_attach()` (and of course damaging the area and committing), because the surface was never marked as `is_mapped` in the first place. Therefore, `weston_surface_unmap()` is not called from `weston_surface_attach()`.
The surface was created using `wl_compositor_create_surface()`.
I am not sure in what cases `is_mapped` should be set for the surface/views and where it should be set from for the case described above. I can see that desktop shell manages this flag itself, but I am not using desktop shell.
Thank you for your time.https://gitlab.freedesktop.org/wayland/weston/-/issues/447video output flickering / tearing using weston 8.0.0 / weston 9.0.0 thru drm-...2023-02-06T13:44:39ZLim Siew Hoonvideo output flickering / tearing using weston 8.0.0 / weston 9.0.0 thru drm-backend.soThe video playback using sample_decode from MSDK library is flickering & tearing happening after upgrade weston 8.0.0 / weston 9.0.0 release. In weston 7.0.0 still didn't see this issue.
This issue not able to reproduce in X11 in westo...The video playback using sample_decode from MSDK library is flickering & tearing happening after upgrade weston 8.0.0 / weston 9.0.0 release. In weston 7.0.0 still didn't see this issue.
This issue not able to reproduce in X11 in weston side in weston 8.0.0 running same video clip and command.
Between 8.0.0 version & 7.0.0 version:
Found out the flickering start happen with this commit, we noticed a lot of changed added in.
https://github.com/wayland-project/weston/commit/2538aaccc7bef6d6f790731aa4697071eb00e23a
So, we using weston 8.0.0 code based continue help to narrow down what is causing. Just do quick check is this causing my cursor update. At drm_output_prepare_cursor_view function, I put straight return NULL without do any extra execution. The flickering / tearing disappear. We need advice and help at here.
Here is sample code that touch on wayland using wayland-drm-protocol.c.
https://github.com/Intel-Media-SDK/MediaSDK/tree/master/samples/sample_misc/wayland/src
Command:
export LD_LIBRARY_PATH=/usr/lib64/mfx/samples/
./sample_decode h264 -i /media/H264_Videos/Demuxed_H264_Videos/Puppies_1920x1080_40mbps_30fps_Main_at_L4.1.h264 -rwld -rgb4 -f 30https://gitlab.freedesktop.org/wayland/weston/-/issues/451Should libexec_weston be promoted into a proper public library?2020-11-06T10:33:29ZPekka Paalanenppaalanen@gmail.comShould libexec_weston be promoted into a proper public library?Currently, libexec_weston is a private shared convenience library that contains essentially everything that makes the `weston` binary, and is installed without a pkg-config file into an unconventional library path to avoid other projects...Currently, libexec_weston is a private shared convenience library that contains essentially everything that makes the `weston` binary, and is installed without a pkg-config file into an unconventional library path to avoid other projects linking to it. It is unversioned and has no stable ABI. You cannot install multiple versions of it simultaneously, like you can't install multiple versions of Weston the compositor.
Libexec_weston exists for two reasons:
- Weston plugins can be built with all symbols resolved when they link to it. (Libweston plugins do not need or use it.)
- Weston test suite uses it to run the compositor in-process.
Other projects cannot currently do either. Would other projects be interested in having those possibilities?
If we were to promote libexec_weston as a proper public library:
- It needs to be versioned. That means it has it's own major version number separate from libweston.
- It needs to have a defined ABI, so that we know when we break it and need to bump the major version.
- It probably needs a better name. `libweston-frontend` maybe?
- It needs a pkg-config file.
It would also cause questions and issues:
- Does it need to be parallel-installable like libweston is? What to do with the installed file resources it needs?
- It would be a library that does process-wide actions, e.g. sets up signal handlers.
- Do we keep the project version derived from libweston major version and let libweston-frontend major version diverge? What happens to the project version when libweston-frontend bumps major but libweston does not?
The version number questions would have applied to libweston-desktop as well if it wasn't decided to strictly follow libweston major both ways. Doing that with yet another library may be going too far.
Should we go for this? If yes, why?https://gitlab.freedesktop.org/wayland/weston/-/issues/457Moving client leaves previous image on ivi-shell2020-11-30T01:54:22ZJunMoving client leaves previous image on ivi-shellI've changed a SoC chip from included arm gpu to imagination gpu recently.
I ran weston-simple-shm and moved the location from <0,0,250,250> to <100,100,250,250> with LayerManagerControl tool.
On chip with arm gpu, the previous image(0,0...I've changed a SoC chip from included arm gpu to imagination gpu recently.
I ran weston-simple-shm and moved the location from <0,0,250,250> to <100,100,250,250> with LayerManagerControl tool.
On chip with arm gpu, the previous image(0,0,250,250) is cleared, but on new chip with imagination gpu, the previous image remains.
So I reported to imagination that there is an issue, but they said that there is different implementation each vendor.
> "for EGL_BUFFER_DESTROYED, the spec. leave each GPU vendor decide if they want to destroy color buffer contents or change by the swapbuffer operation. From our previous debugging experience on ARM, it choose the first one.(destroy color buffer contents which might imply color buffer clear) IMG implement the second one.(changed by the swapbuffer operation which imply we just keep the content on color buffer so we will see the previous content) So if ARM EGL_SWAP_BEHAVIOR is this and if they will do color buffer clear for the EGL_BUFFER_DESTROYED swap behavior, we won't see this issue on ARM."
The arm gpu clears color buffer immediately, but img gpu keeps color buffer until eglSwapBuffers(). So If the GL_BLEND is enabled in first draw-call of gles context, img gpu refer to the previous image(framebuffer) and blending them. I attached dump of egl/gles calls.
![1606451068](/uploads/e2f3ccfa5b189f51f24045e26db91542/1606451068.png)
Additionally, I ran same test with pixman renderer and there is still previous image. So I confused that is this intended? or am I missing something?
Thanks.https://gitlab.freedesktop.org/wayland/weston/-/issues/476kiosk-shell systemd start script, touchscreen calibration2021-03-18T09:31:33Zgearheadkiosk-shell systemd start script, touchscreen calibrationI am trying to figure out wayland/weston and trying to migrate from xorg. This is on a RaspberryPi running Arch Linux. I have googled around and figured out how to launch kiosk with a full screen browser from a vt, but need to be able to...I am trying to figure out wayland/weston and trying to migrate from xorg. This is on a RaspberryPi running Arch Linux. I have googled around and figured out how to launch kiosk with a full screen browser from a vt, but need to be able to launch it as a systemd service and cannot figure out how to do it. I googled around and was able to make a script that launches what I want
```
# Make sure that $DISPLAY is unset.
unset DISPLAY
# And that $XDG_RUNTIME_DIR has been set and created.
if test -z "${XDG_RUNTIME_DIR}"; then
export XDG_RUNTIME_DIR=/run/weston
if ! test -d "${XDG_RUNTIME_DIR}"; then
mkdir "${XDG_RUNTIME_DIR}"
chmod 0700 "${XDG_RUNTIME_DIR}"1
fi
fi
# Run weston:
weston &
sleep 1s # could be less
export WAYLAND_DISPLAY=wayland-0
export DISPLAY=:1
exec /usr/bin/luakit http://localhost
```
so then I tried to make a service file to do the same
```
[Unit]
Description=Weston Local Browser Kiosk mode
After=network.target
[Service]
Type=notify
PAMName=login
RuntimeDirectory=weston
RuntimeDirectoryMode=0700
WorkingDirectory=/srv/http
Environment="HOME=/srv/http"
Environment="XDG_RUNTIME_DIR=/run/weston"
Environment="WAYLAND_DISPLAY=wayland-0"
Environment="DISPLAY=:1"
ExecStart=/usr/bin/weston
ExecStartPost=/usr/bin/sleep 2s ; /usr/bin/luakit http://localhost
ExecStop=/usr/bin/pkill -15 weston
IgnoreSIGPIPE=no
Restart=always
RestartSec=1
[Install]
WantedBy=multi-user.target
```
but every time I get this and no display:
```
Mar 08 08:46:45 rune64 systemd[1]: Starting Weston Local Browser Kiosk mode...
Mar 08 08:46:45 rune64 weston[4330]: Date: 2021-03-08 CST
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.879] weston 9.0.0
Mar 08 08:46:45 rune64 weston[4330]: https://wayland.freedesktop.org
Mar 08 08:46:45 rune64 weston[4330]: Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Mar 08 08:46:45 rune64 weston[4330]: Build: 9.0.0
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.879] Command line: /usr/bin/weston
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.879] OS: Linux, 5.10.20-1-ARCH, #1 SMP PREEMPT Fri Mar 5 05:40:43 MST 2021, aarch64
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.879] Using config file '/srv/http/.config/weston.ini'
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.879] Output repaint window is 7 ms maximum.
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.880] Loading module '/usr/lib/libweston-9/fbdev-backend.so'
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.885] initializing fbdev backend
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.888] logind: not running in a systemd session
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.889] logind: cannot setup systemd-logind helper (-61), using legacy fallback
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.889] <stdin> not a vt
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.889] if running weston from ssh, use --tty to specify a tty
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.889] fatal: fbdev backend should be run using weston-launch binary, or your system should provide the logind D-Bus API.
Mar 08 08:46:45 rune64 weston[4330]: [08:46:45.889] fatal: failed to create compositor backend
Mar 08 08:46:45 rune64 systemd[1]: local-browser_w.service: Main process exited, code=exited, status=1/FAILURE
Mar 08 08:46:45 rune64 systemd[1]: local-browser_w.service: Failed with result 'exit-code'.
Mar 08 08:46:45 rune64 systemd[1]: Failed to start Weston Local Browser Kiosk mode.
```
I get similar response if I use the drm-backend. What is the appropriate way to do this? I think the answer to this will be useful to others trying to move from a xorg kiost install to a wayland/weston kiosk...https://gitlab.freedesktop.org/wayland/weston/-/issues/480framebuffer backend not supporting alpha channel2021-03-18T07:49:18Zcurious_beastframebuffer backend not supporting alpha channelI've got weston with fbdev backend working but no matter what, the alpha channel didn't make it into the framebuffer. 🙁
When I took a screenshot with `cat /dev/fb0 > screenshot.data`, it always ended up with alpha='ff' (while with the xs...I've got weston with fbdev backend working but no matter what, the alpha channel didn't make it into the framebuffer. 🙁
When I took a screenshot with `cat /dev/fb0 > screenshot.data`, it always ended up with alpha='ff' (while with the xserver it always was alpha='00').
I've tried the following things:
weston config (weston.ini):
[core]
backend=fbdev-backend.so # also tried with drm-backend.so, but this won't fill the framebuffer, and on the screen it looked exactly the same as fbdev
[keyboard]
keymap_layout=de
repeat-keys=40 # tracking key repeats for long key press detection in delhi-gui didn't work, despite key repeat working with e.g. zoom
[shell]
type=desktop-shell.so # also tried fullscreen-shell.so and ivi-shell.so, the desktop always looked the same, not sure what these do?
# background-image= # tried with empty image, image with alpha channel set to 0
background-color=0x00000000 # 0xaarrggbb / tried with 0x00ffffff, 0x50505050 and some others, but no transparent framebuffer
[launcher]
path=/usr/bin/weston-terminal
icon=/usr/share/icons/gnome/24x24/apps/terminal.png
[launcher]
icon=/usr/share/icons/gnome/24x24/apps/terminal.png
I also tried to get another wayland compositor working that is specifically made
as "kiosk compositor", which means it runs only one app in fullscreen.
The compositor is called 'cage': https://github.com/Hjdskes/cagehttps://gitlab.freedesktop.org/wayland/weston/-/issues/487cheapest blend2021-04-12T15:14:02ZAndre Osku Schmidtcheapest blendi want to draw/animate this thing:
1. draw filled rectangle with dark transparent color, over the size of area</li>
1. draw filled rectangle with light transparent color, over the size of data</li>
1. wait and repeat (i don't need short...i want to draw/animate this thing:
1. draw filled rectangle with dark transparent color, over the size of area</li>
1. draw filled rectangle with light transparent color, over the size of data</li>
1. wait and repeat (i don't need shorter wait time than ~250msec)
this example html/js thing shows exactly what i want:
```html
<canvas width="128" height="32"></canvas>
<script>
const ctx = document.querySelector("canvas").getContext("2d")
setInterval(function(){
ctx.fillStyle = "rgba(0, 0, 0, 0.2)"
ctx.fillRect(0, 0, 128, 32)
ctx.fillStyle = "rgba(0, 255, 0, 0.2)"
for (let i = 0; i < 4; i++) {
let r = Math.sin(Date.now()/1000+(1*i)) * 0.5 + 0.5
ctx.fillRect(0, 0+((32/4)*i), 128*r, 32/4)
}
}, 250)
</script>
```
> ignore the maths and numbers, it's about `fillStyle` and `fillRect`, and how they blend with previous drawing. (you can save that to a file and open in any modern browser)
i was able to boil it down to this opengl/c code:
```c
#include <GL/gl.h>
#include <GLFW/glfw3.h>
#include <unistd.h>
#include <math.h>
int main (void) {
float s = 2.0 / 4;
double t; int i;
GLFWwindow* window;
if (!glfwInit()) return 1;
window = glfwCreateWindow(128, 32, "test", NULL, NULL);
if (!window) { glfwTerminate(); return 2; }
glfwMakeContextCurrent(window);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
while (1) {
t = glfwGetTime();
glColor4f(0, 0, 0, 0.2);
glRectf(-1, -1, 1, 1);
for (i = 0; i < 4; i++) {
glColor4f(0, 1, 0, 0.2);
glRectf(-1, -1+(s*i), sin(t+i), -1+(s*(i+1)));
}
glFlush();
glfwSwapBuffers(window);
usleep(1000 * 250);
}
return 0;
}
```
> build with: `gcc foo.c -o foo $(pkg-config --cflags --libs glfw3 gl) -lm`
that opengl/c code renders the same as the html/js version, but only on x11 (openbox). on wayland with weston (or wayfire) the blending is "all bonkers", so i wonder...
- why does that opengl/c code work on x11?
- why does it not work the same on weston (wayland)? (or does it for you?)
- or it should work, and the bug is somewhere (else)?
- optional: what is the cheapest way to draw this on/for weston/wayland?
as i'm a total wayland/opengl/c noob (and mostly trial-and-error until something (seems) to work >.<*), i would be very thankful for any related/specific clarification (links) :heart:
ps. i wonder if/when we get single buffer with glfw, if that's gonna solve the problem? https://github.com/glfw/glfw/issues/1843https://gitlab.freedesktop.org/wayland/weston/-/issues/492Weston: Starting with no config file2021-04-28T01:44:28ZWade XuWeston: Starting with no config fileHi
I'm a green hand about weston. I want to use weston under the wayland. When I run the command 'weston', the screen show the following messages:
```
Command line: weston
OS: Linux, 4.19.132-cip-rt59-yocto-standard, #3 SMP...Hi
I'm a green hand about weston. I want to use weston under the wayland. When I run the command 'weston', the screen show the following messages:
```
Command line: weston
OS: Linux, 4.19.132-cip-rt59-yocto-standard, #3 SMP PREEMPT RT Wed Apr 21 08:56:15 CST 2021, aarch64
malformed section header: [core]
Starting with no config file
Output repaint window is 7 ms maximum.
Loading module '/usr/lib/libweston-10/wayland-backend.so'
Error: Failed to connect to parent Wayland compositor: No such file or directory
display option: (none), WAYLAND_DISPLAY=wayland-0
fatal: failed to create compositor backend
```
and there is my weston.ini file:
```
[core]
repaint-window=34
require-input=false
[v4l2-renderer]
device-module=vsp2
[output]
name=LVDS-2
mode=off
[output]
name=HDMI-A-1
#mode=79.75 1920 1976 2168 2416 1080 1083 1088 1102 -hsync +vsync
mode=current
```
and my environment variables
```
SHELL=/bin/bash
PKG_CONFIG_PATH=/usr/lib/pkgconfig/:/usr/share/pkgconfig/
EDITOR=vim
XDG_SEAT=seat0
PWD=/home/tsinglin
LOGNAME=tsinglin
XDG_SESSION_TYPE=tty
HOME=/home/tsinglin
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
WAYLAND_DISPLAY=wayland-0
WESTON_CONFIG_FILE=/etc/xdg/weston/weston.ini
INVOCATION_ID=fe4e3dfbd8ab41d79b49dad181c478ce
XDG_SESSION_CLASS=user
TERM=linux
USER=tsinglin
SHLVL=1
WESTON_LAUNCHER_SOCK=6
XDG_VTNR=2
XDG_SESSION_ID=c1
LD_LIBRARY_PATH=/usr/lib
XDG_RUNTIME_DIR=/run/user/1000
WLD=/usr
JOURNAL_STREAM=8:8760
HUSHLOGIN=FALSE
PATH=/home/tsinglin/.local/bin:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/tsinglin/.local/bin
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/mail/tsinglin
_=/usr/bin/env
OLDPWD=/mnt
```
Someone know what cause this?
Thanks
Wadehttps://gitlab.freedesktop.org/wayland/weston/-/issues/493Failed to process Wayland connection: Connection reset by peerpipe_resource_g...2021-04-28T00:52:40ZWade XuFailed to process Wayland connection: Connection reset by peerpipe_resource_get_param: Assertion '0' failed.le or direction (search paths /usr/lib/dri)Dears
When I run the command 'weston --log=weston.log',there comes the following message.
`
Failed to process Wayland connection: Connection reset by peerpipe_resource_get_param: Assertion '0' failed.le or direction (search paths /...Dears
When I run the command 'weston --log=weston.log',there comes the following message.
`
Failed to process Wayland connection: Connection reset by peerpipe_resource_get_param: Assertion '0' failed.le or direction (search paths /usr/lib/dri)
failed to create display: Connection reset by peer
`
I'm using the default weston.ini file and running under wayland. But I don't know what's wrong in the log file.
The weston.ini and weston.log are in the attach file.
[weston.ini](/uploads/00361508dbe64b9b09aff817d1da861b/weston.ini)
[weston.log](/uploads/ff5beb770af9aa3252ed65e787efb765/weston.log)
What should I do now?
Thanks & Best Regards
Wade