weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2019-12-12T11:31:47Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/326XWM: get_atom_name() could maybe cache the names2019-12-12T11:31:47ZPekka Paalanenppaalanen@gmail.comXWM: get_atom_name() could maybe cache the names`struct weston_wm` could perhaps grow a hash table of known atom names, so that each and every call to `get_atom_name()` would not need to be a roundtrip to the X server. We use `get_atom_name()` a lot, also in `wm_printf()` arguments wh...`struct weston_wm` could perhaps grow a hash table of known atom names, so that each and every call to `get_atom_name()` would not need to be a roundtrip to the X server. We use `get_atom_name()` a lot, also in `wm_printf()` arguments where it is almost always done for no use (no-one subscribed to the debug scope).
However, as it is, `get_atom_name()` acts as a synchronization point with the X server, because it is a blocking roundtrip to the X server. Removing that synchronization or making it happen randomly may cause new issues and may hide existing issues.https://gitlab.freedesktop.org/wayland/weston/-/issues/323RDP-backend to-do from review2020-01-03T23:12:32ZPekka Paalanenppaalanen@gmail.comRDP-backend to-do from reviewWishing for the RDP-backend to improve, I read through its code. These are my notes. I did not bother to open a new issue for each single one, but feel free to open Issues or MRs as you see fit, mention them here and I will update this d...Wishing for the RDP-backend to improve, I read through its code. These are my notes. I did not bother to open a new issue for each single one, but feel free to open Issues or MRs as you see fit, mention them here and I will update this description with a link.
- [ ] seat release, needs safe wl_global removal in libweston core from #322
- [ ] call `weston_head_set_monitor_strings()` when creating the head
- [ ] `weston_head_set_physical_size()` parameters from remote screen physical size? #324
- [ ] drop manually created shadow buffer, seems unused
- [ ] prevent mode list from growing unlimited in `ensure_matching_mode()`
- [ ] `rdp_output_repaint()`: implement frame-dropping or throttle to transmission framerate to avoid slow-motion updates in the remote?
- `rdp_peer_refresh_raw()`:
- [ ] `marker.frameID++` uninitialized?
- [ ] what if `heightIncrement` starts zero due to a very wide rect?
- `rdp_peer_refresh_nsc()`:
- [ ] suspicious `#ifdef`-skipping of `memset()` to zero; would be better to use unconditional initialization
- [ ] why does it use damage extents instead of rects?
- `rdp_peer_refresh_rfx()`:
- [ ] suspicious `#ifdef`-skipping of `memset()` to zero; would be better to use unconditional initialization
- [ ] why offset `ptr` by extents `x1`, `y1`?
- [ ] log RDP remote actions with a new debug scope, e.g. `rdp_peer_refresh_*()`, input events, connects and disconnects
- [ ] clean up `#ifdef`s for old freerdp versions according to what the build requires todayhttps://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/317Document config_parser API, make Weston use public API2020-08-17T12:56:49ZDaniel Stonedaniel@fooishbar.orgDocument config_parser API, make Weston use public APIThe following discussion from !314 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/314#note_322336): (+1 comment)
> LGTM, follows what the public headers declare.
...The following discussion from !314 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/314#note_322336): (+1 comment)
> LGTM, follows what the public headers declare.
>
> This could use two follow-up issues: documenting the `weston_config` helper API, and making Weston depend on these exports instead of getting them directly from libshared.https://gitlab.freedesktop.org/wayland/weston/-/issues/316Stop the C++ confusion in docs2020-10-16T10:57:53ZPekka Paalanenppaalanen@gmail.comStop the C++ confusion in docsLooking at https://wayland.pages.freedesktop.org/weston/genindex.html, it is full of "C++" when libweston and weston are pure C.
However, this could be unfixable, see the discussion at https://gitlab.freedesktop.org/wayland/weston/merge...Looking at https://wayland.pages.freedesktop.org/weston/genindex.html, it is full of "C++" when libweston and weston are pure C.
However, this could be unfixable, see the discussion at https://gitlab.freedesktop.org/wayland/weston/merge_requests/182#note_175667 about why the primary domain is set to C++. So probably this needs to be fixed in Breathe and/or Doxygen as well.
When I insert links to documented macros, I have to use `:c:macro:FOO` and `:c:func:TEST` because the default domain is `cpp` instead.Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/315Integrate man-pages with Sphinx2020-10-16T10:57:53ZPekka Paalanenppaalanen@gmail.comIntegrate man-pages with SphinxCurrently the Weston man-pages are written in TROFF or whatever the traditional dialect is. That makes them both hard to write and probably hard to incorporate in the Sphinx generated documentation web site https://wayland.pages.freedesk...Currently the Weston man-pages are written in TROFF or whatever the traditional dialect is. That makes them both hard to write and probably hard to incorporate in the Sphinx generated documentation web site https://wayland.pages.freedesktop.org/weston/.
The web site should have a chapter on Weston the compositor for end users, but I do not want to duplicate the documentation between that and man-pages. I would probably prefer if the man-pages could be included as pages in the web site.
How could we include the man-pages as pages in the web site?
I presume the man-pages would have to be converted into a more modern format that can produce both traditional man-pages for installation and be used with Sphinx. What would that format be?https://gitlab.freedesktop.org/wayland/weston/-/issues/313More robust plugin tracking2019-11-22T14:17:19ZPekka Paalanenppaalanen@gmail.comMore robust plugin trackingThe following discussion from !290 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/290#note_284395): (+9 comments)
> My thinking is more along the lines of havin...The following discussion from !290 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/290#note_284395): (+9 comments)
> My thinking is more along the lines of having plugin loading pull an exported `struct weston_plugin` const data struct from the DSO, which would have `init` (with init returning a user_data variable which is used to reference the plugin internally) and `teardown` members, as well as optionally things like names and whatever. Each `weston_compositor` could then track those plugins in a list, and call teardown automatically, or plugins could call an unregister function at any time which would remove them from the list.
>
> That would remove the requirement for plugins to set their own teardown listener.https://gitlab.freedesktop.org/wayland/weston/-/issues/311Test harness re-design, step 2: asserts, checks, and runners2021-07-12T10:37:04ZPekka Paalanenppaalanen@gmail.comTest harness re-design, step 2: asserts, checks, and runnersThe following discussion from !287 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/287#note_282295): (+1 comment)
> Since we are running all tests of one program w...The following discussion from !287 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/287#note_282295): (+1 comment)
> Since we are running all tests of one program without forking, any test that fails an `assert()` or such will cause the whole program to quit, meaning that following tests in the program will not be run.
The question about what to replace asserts with is part of a bigger question if we should be using a ready-made test framework. Evaluate Check, gtest, whatever C test frameworks there are, and also the ZUC framework that exists already in Weston but is underused. Some evaluation criteria are:
- allows us to not `fork()`
- does not need environment variable setup or special command line options
- makes tests easier to write
- makes tests more clear to read
- if it replaces the Meson test runner, it provides reports suitable for Gitlab consumption
Most of the above are goals from #289 and !287.https://gitlab.freedesktop.org/wayland/weston/-/issues/309Measure test coverage2021-03-09T10:11:10ZPekka Paalanenppaalanen@gmail.comMeasure test coverageWe have a test suite in Weston (soon looking quite different under the hood due to !287), we assume we are poor with test coverage, but how poor are we exactly?
Experiment with [Meson's coverage support](https://mesonbuild.com/Unit-test...We have a test suite in Weston (soon looking quite different under the hood due to !287), we assume we are poor with test coverage, but how poor are we exactly?
Experiment with [Meson's coverage support](https://mesonbuild.com/Unit-tests.html#coverage) and see what we can get out.
Gitlab seems to be very limited with its [coverage reporting support](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#test-coverage-parsing), but I'm thinking of something more like... [sunburst charts](https://plot.ly/python/sunburst-charts/) where the center is the project root directory with the total coverage percentage, and directories and files fan out from it, having source code files at the leaves. With color coding for coverage. So on a glance you can see that `fullscreen-shell/*` is completely untested but has little code, much of `clients/*` is never exercised but is not that much code either, `libweston/*` is (hopefully!) a little better and contains a huge load of code, and so on.
How to publish a chart from e.g. a CI run is a good question.
What would be most interesting is how each MR changes the coverage numbers, but I have no idea how that could be implemented.
It would also be nice to compare coverage reports, so that when you add a new test, you can see exactly which bits of code started being tested.https://gitlab.freedesktop.org/wayland/weston/-/issues/308`ninja clean` is not enough to clean up Sphinx temporary files2020-10-16T10:57:53ZPekka Paalanenppaalanen@gmail.com`ninja clean` is not enough to clean up Sphinx temporary filesDoing a build check across multiple commits that change Spinx documentation bits may fail, because the outdated temporary files, which `ninja clean` does not remove, cause warnings or errors in the doc build. Running `ninja docs` manuall...Doing a build check across multiple commits that change Spinx documentation bits may fail, because the outdated temporary files, which `ninja clean` does not remove, cause warnings or errors in the doc build. Running `ninja docs` manually does not fix the issue.
It seems the foremost culprit are `.rst` files copied to the build directory by Meson. They do not get deleted when rewinding to before a commit that adds some, but Sphinx will still read them. The stale files may have references to things that do not exist after rewinding, like some Doxygen entities (e.g. a group used with `doxygengroup` Sphinx directive).https://gitlab.freedesktop.org/wayland/weston/-/issues/306[xwm] Jump in size with interactive resize on X11 with CSD windows2019-11-18T10:23:38ZOlivier Fourdan[xwm] Jump in size with interactive resize on X11 with CSD windowsStarting an interactive resize on an X11 CSD window causes a jump in size.
Steps to reproduce:
1. Run gtk3-demo under X11/Xwayland:
`$ GDK_BACKEND=x11 gtk3-demo`
2. Resize the window from one of its edges
Actual result...Starting an interactive resize on an X11 CSD window causes a jump in size.
Steps to reproduce:
1. Run gtk3-demo under X11/Xwayland:
`$ GDK_BACKEND=x11 gtk3-demo`
2. Resize the window from one of its edges
Actual result:
* There is a jump in the window size which grows of several pixels all at once leaving the pointer far inside the surface
Expected result:
* The window size follows the pointer position giving a continuous resize.
Additional information:
Client side decorations under X11 is achieved by setting the Motif WM hints to set no decorations from the X11 window manager.
Then interactive resize with CSD uses the `_NET_WM_MOVERESIZE` protocol, which is handled in weston XWM in `weston_wm_window_handle_moveresize()`.
IIUC, that should end up in desktop-shell/shell.c `surface_resize()` which gets the surface geometry and resize according to the surface geometry.
However, the surface is actually larger than the window with CSD (due to the drop shadow being part of the client side decorations), so I reckon this is what causes the jump in size.https://gitlab.freedesktop.org/wayland/weston/-/issues/305Manual DRM-backend smoke-test with VKMS2020-05-26T09:30:02ZPekka Paalanenppaalanen@gmail.comManual DRM-backend smoke-test with VKMSAdd a test in the test suite that runs Weston/DRM/pixman using the non-default seat `seat-vkms`. Whether this actually runs depends on whether there is a DRM device available on `seat-vkms`, otherwise the test is skipped. Input devices a...Add a test in the test suite that runs Weston/DRM/pixman using the non-default seat `seat-vkms`. Whether this actually runs depends on whether there is a DRM device available on `seat-vkms`, otherwise the test is skipped. Input devices are not required or used.
I call this a manual test, because this test would depend on the local system setup to have VKMS kernel module loaded and `seat-vkms` configured.
It requires Weston to be able to start on a non-default seat with normal user permissions: either the user must have access to the VKMS DRM device, or logind needs to be able to hand that out. `weston-launch` cannot be used, because it would require root permissions to install as setuid-root, and without setuid-root it cannot provide anything useful.
Weston on non-default seat depends also on skipping all VT/tty setup.
This task depends on !287.https://gitlab.freedesktop.org/wayland/weston/-/issues/301WLCS support2022-09-13T15:14:10ZPekka Paalanenppaalanen@gmail.comWLCS supportEmbrace [Wayland Conformance Test Suite](https://github.com/MirServer/wlcs): make it possible to run WLCS against Weston.
After that is done, follow-up work would include:
- fix all bugs it finds
- make it part of Weston CIEmbrace [Wayland Conformance Test Suite](https://github.com/MirServer/wlcs): make it possible to run WLCS against Weston.
After that is done, follow-up work would include:
- fix all bugs it finds
- make it part of Weston CIChristopher James Halse RogersChristopher James Halse Rogershttps://gitlab.freedesktop.org/wayland/weston/-/issues/297weston unit test framework issue when having multi-displays2019-11-22T10:29:16ZJiayuan Renweston unit test framework issue when having multi-displaysIn the event-test.c, it requires that the surface should be in the output.
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/event-test.c#L32-41
```
static int
output_contains_client(struct client *client)
{
struct output ...In the event-test.c, it requires that the surface should be in the output.
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/event-test.c#L32-41
```
static int
output_contains_client(struct client *client)
{
struct output *output = client->output;
struct surface *surface = client->surface;
return !(output->x >= surface->x + surface->width
|| output->x + output->width <= surface->x
|| output->y >= surface->y + surface->height
|| output->y + output->height <= surface->y);
}
```
updated here:
When we have 2 (or more than 1) displays, we will xzalloc 2 outputs in https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/weston-test-client-helper.c#L766-773
But we only save the last output (output2) in the client.
the output_handle_geometry() will be called twice for 2 outputs. (more details, see the comments below.)
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/weston-test-client-helper.c#L673-687
```
static void
output_handle_geometry(void *data,
struct wl_output *wl_output,
int x, int y,
int physical_width,
int physical_height,
int subpixel,
const char *make,
const char *model,
int32_t transform)
{
struct output *output = data;
output->x = x;
output->y = y;
}
```
For example, the first display resolution = 1200x1920, the second display resolution=1200x1920.
```
output_handle_geometry is called, x=0
output_handle_geometry is called, x=1200
```
But the surface is always created in the first display (no offset has been applied)
https://gitlab.freedesktop.org/wayland/weston/blob/master/tests/event-test.c#L60
So the event-test.c failed when the device have multi-display.
Idea 1: Always use the last display.
We can add the output's offset to the surface to let the surface in the output.
But it will fail other unit tests (touch and pointer), probably they also need to have an offset.
```
void
move_client(struct client *client, int x, int y)
{
struct surface *surface = client->surface;
int done;
client->surface->x = x + client->output->x;
client->surface->y = y + client->output->y;
```
}
```
Idea2: Always use the first display.
Only save the first display's info in the output_handle_*() functions, and return directly afterward. (rough idea)
It will be appreciated if someone owns this weston unit test framework and fixes it quickly. :-)
or can anyone provide some feedback on which direction we should go? I can try to fix that.
Thanks.https://gitlab.freedesktop.org/wayland/weston/-/issues/295Remove the partial_dependency workaround2023-12-07T08:11:19ZPekka Paalanenppaalanen@gmail.comRemove the partial_dependency workaroundSee the XXX in https://gitlab.freedesktop.org/wayland/weston/blob/ccf24076ddd42b1523e135e0827a31358d6fbd19/libweston/meson.build#L105 .
Once we require at least Meson 0.50.1, remove the workaround.See the XXX in https://gitlab.freedesktop.org/wayland/weston/blob/ccf24076ddd42b1523e135e0827a31358d6fbd19/libweston/meson.build#L105 .
Once we require at least Meson 0.50.1, remove the workaround.https://gitlab.freedesktop.org/wayland/weston/-/issues/294Input and output control protocols for the headless backend2024-01-19T11:41:30ZPekka Paalanenppaalanen@gmail.comInput and output control protocols for the headless backendI believe that the headless backend would have much more value if it exposed external interfaces for
- dynamically creating, configuring, and removing heads, and
- dynamically creating, configuring, and removing `wl_seat`s.
The weston-t...I believe that the headless backend would have much more value if it exposed external interfaces for
- dynamically creating, configuring, and removing heads, and
- dynamically creating, configuring, and removing `wl_seat`s.
The weston-test plugin already has a rudimentary Wayland interface for input device control, but it is completely ad hoc and organic. I envision something that would be well structured and more or less match the libweston backend API and the `wl_seat` family of Wayland interfaces.
Controlling heads would allow automated testing of monitor hotplug, and controlling input devices would allow automated testing of input device hotplug and synthetic input events. These would be useful in testing not only the Weston frontend and libweston core behaviour, but it would also create a nice test bed for application testing. Especially the synthetic input events should be a great help for automating application UI testing without involving uinput.
The natural choice would be to write these interfaces as Wayland protocol extensions implemented directly in the headless backend.
This idea is continuation from using GL-renderer with the headless backend, allowing headless hardware-accelerated graphics, which is already implemented.https://gitlab.freedesktop.org/wayland/weston/-/issues/292screenshare Weston plugin uses private libweston API2019-10-24T10:32:26ZPekka Paalanenppaalanen@gmail.comscreenshare Weston plugin uses private libweston APIScreenshare plugin needs to deliver input events into the core compositor, but libweston does not offer any public API to do that. Therefore screenshare violates the API rules and uses the backend API to deliver input.
Either screenshar...Screenshare plugin needs to deliver input events into the core compositor, but libweston does not offer any public API to do that. Therefore screenshare violates the API rules and uses the backend API to deliver input.
Either screenshare needs to become a libweston plugin instead of being a Weston plugin (short term specific solution), or libweston needs to grow a public API for delivering input events (long term generic solution).https://gitlab.freedesktop.org/wayland/weston/-/issues/291CI testing without GL dev packages2019-10-24T13:38:37ZPekka Paalanenppaalanen@gmail.comCI testing without GL dev packagesThe current CI image comes with all EGL and GL -dev packages installed and headers installed into system include directories, which means that if a Weston build accidentally includes a EGL/GL/GBM header when it should not (e.g. EGL/GBM/g...The current CI image comes with all EGL and GL -dev packages installed and headers installed into system include directories, which means that if a Weston build accidentally includes a EGL/GL/GBM header when it should not (e.g. EGL/GBM/gl-renderer disabled), or looks for a pkg-config file, it will find them and no error is raised.
I've pondered different ways to raise those errors, but the only non-hacky thing is to just have a CI docker image without those packages installed.
That means we would need to build two "layers": one image without Mesa dev packages, and another image based on the first one (an additional layer) that would have our current image contents.
Then we could change the new test case added in !282 to use the image without Mesa dev packages.
One reason why I wasn't fond of this approach before is that it probably doesn't scale - Weston has several optional dependencies and testing all combinations of each one present vs. missing is not feasible. Well, it's not feasible in the first place, with or without a docker image per configuration, so I guess that's not a reason to not test without Mesa dev packages.https://gitlab.freedesktop.org/wayland/weston/-/issues/288timeline: Support notification whenever surface changed its title for forcing...2019-10-18T08:20:25ZMarius Vladtimeline: Support notification whenever surface changed its title for forcing object refreshA piece left for the timeline part is to signal (from shell, by calling `weston_timeline_refresh_subscription_objects()`) whenever the surface title has changed. It appears that the notification for that has to happen through the shell (...A piece left for the timeline part is to signal (from shell, by calling `weston_timeline_refresh_subscription_objects()`) whenever the surface title has changed. It appears that the notification for that has to happen through the shell (but there doesn't seem to be any listeners for that?).
I had a tentative to fix it: https://gitlab.freedesktop.org/wayland/weston/merge_requests/233/diffs?commit_id=8ee186a815c1cf46eafa479926bbbf765b7ab6db, but it is not correct.
More background about this issue as described by @pq : https://gitlab.freedesktop.org/wayland/weston/merge_requests/233#note_260495Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/287Libweston internal flat view list: always remove before insert2019-11-18T10:34:07ZPekka Paalanenppaalanen@gmail.comLibweston internal flat view list: always remove before insertReplace !269 with an approach that always keeps the view links valid. Every time a view link is added to a list, it needs to be removed first.
The following discussion from !269 should be addressed:
- [ ] @pq started a [discussion](htt...Replace !269 with an approach that always keeps the view links valid. Every time a view link is added to a list, it needs to be removed first.
The following discussion from !269 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/269#note_257406): (+4 comments)
> There is another way of doing this. Instead of overwriting everything at once, we could remove the list head and initialize it. That would leave all the elements still in an "anoymous" list, one that has no head. But then we need to modify each place in code that used to assume the view link was uninitialized to first remove before it inserts. We also need to ensure that a created view has its link initialized so removing is ok, and destroying a view also removes first.
>
> Why go through the hassle instead of doing exactly what you propose? It would give us the precondition that the link of a view is always valid. That makes reasoning about code a lot easier. I don't think there is another variable that could tell if the link is valid or not, it has all been just implicit - and as your issue proves, that code had bugs.
>
> What do you think of the alternative approach?
>
> Looks like `weston_view_create()` already initializes the link and `weston_view_destroy()` removes it. So the code is already kind of relying on the link being always valid, but getting indirectly dropped from the view list was overlooked until your patch.