weston issueshttps://gitlab.freedesktop.org/wayland/weston/issues2018-12-12T16:43:11Zhttps://gitlab.freedesktop.org/wayland/weston/issues/121Add Meson build system2018-12-12T16:43:11ZPekka Paalanenppaalanen@gmail.comAdd Meson build systemWe want the Meson build system in Weston for going forward. Once it's in, let's do a release with both autotools and Meson before removing autotools.
Meson should make the build system much more approachable and easier to enhance.
Build options handling should not follow autotools to the letter, but it should be made more clean and easier to understand (especially the options around building or installing clients). Since the syntax changes for meson, might rework the options as well. If there is an option to not install something, that could as well not build it either.Good for new contributorsBuild systemPekka Paalanenppaalanen@gmail.comPekka Paalanenppaalanen@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/issues/241No way to force DRM connectors reprobe2019-05-14T10:56:55ZSimon SerNo way to force DRM connectors reprobeAccording to [a recent discussion on dri-devel](https://lists.freedesktop.org/archives/dri-devel/2019-May/217588.html), userspace should provide a way to force a full reprobe of the DRM connectors:
>User opens the screen configuration tool -> usually at that point the
tool/compositor force a full reprobe, which then often triggers the
automatic reconfiguring. E.g. on one laptop I have here when I plug in
random shit projectors at conferences nothing happens, until I run
xrandr, which triggers the full reprobe, which then makes the kernel
realize something change, sending and uevent, which starts the
automatic reconfigure machinery.
This is really not great, but the kernel folks say there's no way around that.DRM/KMS backendhttps://gitlab.freedesktop.org/wayland/weston/issues/182Need a general key listener2019-01-31T01:38:44ZsichemNeed a general key listenerHi, I am writing a libweston based compositor and I intend to implement the Emacs style key bindings (where the binding can be a sequence, thus they form a tree instead of a list). I found that I cannot achieve it with libweston's binding system. While I can successfully activate the bindings if I pressed the right key, but if the next key is not on the list, there is no way I can know about it and quit the bindings.
Good news that this can be easily done by a simple patch to libweston. I already implemented it and I can make a merge request very soon.Inputhttps://gitlab.freedesktop.org/wayland/weston/issues/134Support EGL_KHR_partial_update for performance2019-02-08T13:51:57ZDaniel Stonedaniel@fooishbar.orgSupport EGL_KHR_partial_update for performanceWeston's gl-renderer currently uses `EGL_EXT_buffer_age` to determine the 'age' of the back buffer it's currently rendering into, to enable partial renders. It would be great if we could use `EGL_KHR_partial_update` where possible instead, as it's much more efficient.
When gl-renderer repaints an output, we know the 'damage' (changed / needs-repaint) region of that output. If we only repaint the damaged area, we save the workload of painting something which has already changed. The 'buffer age' extension enables this: it tells us how 'old' (in number of `eglSwapBuffers` calls) our current GLES buffer is. If the buffer is, say, two frames old, then we know in order to make it current, we must paint the current damaged area, as well as the damage area from the previous frame as well. This can be a very useful performance optimisation when only changing small areas.
Turning on the triangle-fan debug mode can show this in action, and demonstrate just how little of the screen we repaint.
Whilst this mode is good for immediate-rendering GPUs, it's less good for tiled-mode GPUs, as found in mobile devices. Whilst IMR architectures typically render directly to the buffer in memory, tilers first have to load the old data into a tile buffer, render into another part of the tile buffer, then flush the tile buffer back to main memory. This can sometimes result in unnecessarily loading the entire old buffer back into memory first, making it _slower_ than we would have without the performance optimisation. A real-life example can be found at lima/mesa#59.
`EGL_KHR_partial_update` solves this by making the communication between Weston and the EGL driver two-way. Weston still queries for the buffer age, but it then also feeds its intended damage area into EGL with `eglSetDamageRegionKHR`. As the driver knows which regions will be changed and which regions will be preserved, it can avoid loading old buffer content into memory if that content is going to be overwritten, preserving our optimisation.
Preferentially using `partial_update` over `buffer_age` would be useful and a very good first patch for someone looking to get into Weston.Good for new contributorsGL rendererhttps://gitlab.freedesktop.org/wayland/weston/issues/119Update the example clients to support the stable version of xdg_shell2018-12-13T14:45:11ZeyelashUpdate the example clients to support the stable version of xdg_shellI am trying to update a simple wayland compositor that I wrote to the stable version of xdg_shell and it would be great to have some simple clients to test against.Good for new contributorsxdg_shell and wl_shellClientshttps://gitlab.freedesktop.org/wayland/weston/issues/219Reorganize libweston source files2019-04-23T11:36:28ZPekka Paalanenppaalanen@gmail.comReorganize libweston source filesThe amount of code in libweston has grown and will grow more, there are files that could use splitting. The separation between public and private API is not obvious at a glance.
- Move public installed headers into a new sub-directory to make them stand out.
- The directory shall be `libweston/include/libweston/`, with include directory pointing to `libweston/include/`.
- Install public headers into `${incdir}/libweston-$MAJOR/libweston/` while pkg-config points includedir to `${incdir}/libweston-$MAJOR/`.
- This means both weston (`main.c` et al.) and third party users need to start doing `#include <libweston/compositor.h>` instead of `#include <compositor.h>`. This should help avoiding name conflicts better, not that any have been reported.
- Move GL-renderer into a new sub-directory. The HDR work (e.g. !132) needs to add more files and `gl-renderer.c` could use splitting in the future.
- Move every backend into a new sub-directory. Some backends have files that could use splitting, and for consistency move them all.
- Build files (`libinput-*.c`, `libbacklight.c`) used by multiple backends into static libs and do not move them.
- Start separating backend and private things out of `compositor.h`.
- Rename backend headers to `backend-*.h`.
Should any of the installed headers be renamed in addition to moving them under `libweston/`? Now would be a good time when we are breaking all users anyway.
Should `libweston-desktop.h` be available under `#include <libweston-desktop/desktop.h>` or something?libwestonCore compositorPekka Paalanenppaalanen@gmail.comPekka Paalanenppaalanen@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/issues/216libweston documentation / and the tools to generate it2019-05-24T12:33:57Zmarius vladlibweston documentation / and the tools to generate itThis issue is about agreeing on the tools/methods to document libweston as to make it more accessible to a
broader audience, and obviously make it a little bit easier to understand how to use the library itself to develop,
adapt or construct a compositor.
With that in mind I've followed a few **directions**:
- hotdoc (https://hotdoc.github.io/)
- sphinx (https://www.sphinx-doc.org/en/master/index.html)
- kerneldoc (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/kernel-doc?h=v5.1-rc1)
- sphinx with hawkmoth (https://github.com/jnikula/hawkmoth)
- sphinx with breathe (https://breathe.readthedocs.io/en/latest/index.html)
The major differences between these two is the fact sphinx is using restructuredText and the tools that parse code follow that (follows rst code documentation tags), while hotdoc uses markdown.
**Examples of code generated for each of those**
- hotdoc: https://people.collabora.com/~mvlad/libweston-hotdoc/libweston/html/
@ https://gitlab.freedesktop.org/marius.vlad0/weston/tree/libweston-hotdoc
- sphinx w/ kerneldoc: https://people.collabora.com/~mvlad/libweston-sphinx-kerneldoc/
@ https://gitlab.freedesktop.org/marius.vlad0/weston/tree/libweston-sphinx
- sphinx w/ hawkmoth: https://people.collabora.com/~mvlad/libweston-sphinx-hawkmoth/
@ https://gitlab.freedesktop.org/marius.vlad0/weston/tree/libweston-sphinx-hawkmoth
- sphinx w/ breathe: https://people.collabora.com/~mvlad/libweston-sphinx-breathe/
@ https://gitlab.freedesktop.org/marius.vlad0/weston/tree/libweston-sphinx-breathe
Some of the good/bad items I've discovered along the way (at least at this stage):
- **hotdoc**
- uses gtkdoc (atm I haven't tested https://github.com/hotdoc/hotdoc_c_extension/tree/master/hotdoc_c_extension) for getting code documentation
- has meson module from meson 0.48
- had some issues when installing it, but resolved afterwards
- gstreamer + meson seems to be the only users
- forward declarations will not be overwritten by declaration itself and we have a few in compositor.h
- can't document pointer to functions
- **sphinx (kerneldoc)**
- uses kernel-doc script which might be harder to support (is in Linux kernel project -- harder to push things)
- has the ability to filter by functions, would allow parts of the library being grouped
- **sphinx (hawkmoth)**
- one-man project
- uses clang and all python, much more modern than kerneldoc (and kernel-doc script implicitly)
- easy to install using pip3 and friends
- will need improvement if we want \memberof or \addgroup, \ingroup -- that is splitting logically libweston into various parts
- **sphinx (breathe)**
- doxygen support ofc
- minimal changes to current code documentation (which is rather sparse)
- a bit more heavy on the CPU (the sphinx extension will take some until it parses the XMLS generated by doxygen)
- grouping (actually rst output) is printed rather ugly imo (the feat is there but it is barely useful).Documentationmarius vladmarius vladhttps://gitlab.freedesktop.org/wayland/weston/issues/173Delay start-up until a graphics device is present2018-12-07T15:06:22ZPekka Paalanenppaalanen@gmail.comDelay start-up until a graphics device is presentI just learned about https://gitlab.gnome.org/GNOME/gdm/issues/103 and I got the feeling that solving the same issue in Weston might be beneficial to those who run Weston as a system service.
In short, when using logind, check the specific property, and if it is false, delay initialization of the DRM backend until it changes to true.
I think this is a well-defined and fairly isolated task, so I marked it as good for new contributors.
However, this is very low priority as I don't recall anyone asking for this feature.libwestonGood for new contributorsDRM/KMS backendhttps://gitlab.freedesktop.org/wayland/weston/issues/151Merge request: weston_desktop_surface_set_size causes a segfault on xwayland ...2018-11-17T10:33:21ZJohn GoodMerge request: weston_desktop_surface_set_size causes a segfault on xwayland desktop_surface that is going to be destroyedCalling weston_desktop_surface_set_size with as argument a desktop_surface that corresponds to a xwayland window that does not exist any more, but that has not yet been notified as destroyed by the surface_removed callback, causes a segmentation fault in the module xwayland.so.
The simplest way to reproduce the bug is to run a X terminal application in weston. Type in it something like :
sleep 5; exit
then keep on resizing the window with the mouse. When the terminal closes, weston crashes. Alternatively, in the surface_removed callback, you can set the size of all the existing windows (not yet notified as destroyed by the surface_removed callback). Then run any X application that closes two windows at a time (e.g., a dialog in an editor asking if you want to quit without saving).https://gitlab.freedesktop.org/wayland/weston/issues/148Make unhandled buffer type a disconnecting error2018-11-02T14:36:12ZPekka Paalanenppaalanen@gmail.comMake unhandled buffer type a disconnecting errorCurrently `gl_renderer_attach()` simply logs a message `unhandled buffer type!` when it cannot use the provided buffer in compositing. This leads to a silent failure where the window is not updated or does not appear.
Instead, send a fatal protocol error to the client with an explanation. Do this also in pixman renderer.
Prompted by #141.Pixman rendererGood for new contributorsGL rendererhttps://gitlab.freedesktop.org/wayland/weston/issues/144Post-mortem debugging from assertion failures2019-05-23T07:38:35ZDaniel Stonedaniel@fooishbar.orgPost-mortem debugging from assertion failures#143 describes how to make our `assert()`s more helpful for users and us upstream trying to triage issues. Often though, the response to a bug report is asking the reporter to re-run the same scenario with more logging information, sometimes with bespoke add-more-logging patches. This might be difficult, especially if the issue only happens intermittently and would require gigabytes of log data to be generated.
Since we already generate log data with the debug infrastructure from #133, it would be great if we could selectively enable post-mortem debugging where:
* all (or selected) debug scopes were active all the time regardless of whether or not there was an active streaming client
* an internal client was created always recording these scopes into a ring buffer
* on assertion failure, these ring buffers would all be dumped, along with any head information required (e.g. the timeline scope would need to be preceded by a dump of all available objects)
* to debug things which don't trip asserts (e.g. screen blinks unpleasantly, glitch observed in animations, whatever), a debug hotkey was available which would dump the last available debug data for later analysis
The internal stream 'client' might also be useful for simplifying the implementation of Weston's 'log' scope, and allowing other scopes to be captured. For example, there is no way currently to capture output from the `drm-backend` during startup.Core compositormarius vladmarius vladhttps://gitlab.freedesktop.org/wayland/weston/issues/143Better debug information from assertion failures2019-04-02T07:44:17ZDaniel Stonedaniel@fooishbar.orgBetter debug information from assertion failuresWeston heavily uses `assert()` to ensure sanity and core constraints are not violated. This is particularly notable in the DRM backend and repaint machinery, where any unexpected condition (e.g. output paint completion being called at an unexpected time) will take Weston down hard with an `assert()` failure.
On one hand, this is good because we can be pretty sure our compositor works like how we think it does, and we find out about problems pretty quickly. On the other hand, this is a terrible user experience: internal errors (which may be harmless!) result in Weston instantly crashing hard, with the only indication why in stderr.
This indication is not in itself always useful: telling us that `output->repaint_status != REPAINT_IDLE` is helpful, but printing the _exact_ repaint status would be even more helpful. Even more helpful again would be dumping as much output as possible from the core timeline (#142) and backend (#133).
Most of the time these asserts don't catch memory-safety errors (e.g. use-after-free, type mismatch), but impossible internal states. Therefore we can assume that inspecting memory is mostly safe to do, and that the compositor isn't in a death spiral.
I suggest we:
* switch uses of `assert()` to new Weston-specific assert macros; the kernel uses `BUG_ON()` for 'something bad has happened and I'm going to crash immediately', and `WARN_ON()` for 'something bad happened but I think I can recover', which might be something to consider
* where possible, use operator-specific macros from ZUC; this lets us print something like `error: expected output->repaint_status to be 0 but it was 3', which makes bug reports far more useful
* dump this information not just to stderr, but to the Weston log and any clients streaming the Weston log through the debug protocol (flushing those FDs so it gets out before we die)
* at the end of this, still throw `SIGABRT` or similar so core dumps are generated
* include a link to our bug-reporting guide as well as our bug-report formGood for new contributorsCore compositormarius vladmarius vladhttps://gitlab.freedesktop.org/wayland/weston/issues/130Cursor often keeps a previous image when on an atomic plane with two outputs2018-07-26T13:45:02ZLink MauveCursor often keeps a previous image when on an atomic plane with two outputsWhen two outputs are enabled in Weston and cursors aren’t set to broken and the legacy API isn’t used, the cursor often fails to update its image when it should, despite updating every other parameter (such as the hit point). It does change again after moving the pointer to an area which changes the cursor.
In every other situation, or when taking a screenshot or wcap capture, the cursor updates properly.DRM/KMS backendDaniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.orghttps://gitlab.freedesktop.org/wayland/weston/issues/82Weston master causes mouse input to stop working with wl_shell applications2019-04-26T08:39:43ZBugzilla Migration UserWeston master causes mouse input to stop working with wl_shell applications## Submitted by n3rdopolis
Assigned to **Wayland bug list**
**[Link to original bug (#97892)](https://bugs.freedesktop.org/show_bug.cgi?id=97892)**
## Description
Created attachment 126719
The log of Weston with WAYLAND_DEBUG=server, and standarddialogs connected to it
It seems to be a very weird issue with Qt 5.7.x and Qt 5.8 when using QtWayland with the default wl_shell integration (doesn't seem to happen when it's using xdg_shell, but xdg_shell is not the default for QtWayland without an env var
(and EFL if you export EFL_WAYLAND_DONT_USE_XDG_SHELL=1, I was able to replicate this, however the only EFL application that I know of, and have that actually utilizes child windows is the elementary_test that comes with EFL)
I can replicate this by even unsetting QT_WAYLAND_DECORATION, and KDE_FULL_SESSION to get minimal Qt.
I can test with an example client, standarddialogs
https://quickgit.kde.org/?p=qt%2Fqtbase.git&a=tree&h=ffe4a1df1c641df4b3738887d02214082aa7aa12&hb=25e9bde2d665866f7a9a40d1ed3aa8fabcf2ac2f&f=examples%2Fwidgets%2Fdialogs%2Fstandarddialogs
With standarddialogs, I start the application up, open, and then close a dialog, and then leave the mouse pointer on the main surface. After a few seconds, the cursor changes to a busy cursor, and it stops responding to mouse input, as if though it's not responding to wl_pings (where the whole window becomes draggable).
The whole surface stops responding to mouse input.
It does however appear to respond to Keyboard input, I can press tab to move the selection around, and press space to press a button to open another dialog. The dialog seems to respond to input, but the main surface that stops responding to mouse input, never responds to it again
**Attachment 126719**, "The log of Weston with WAYLAND_DEBUG=server, and standarddialogs connected to it":
[wlserverlog.txt](/uploads/35d7b686e001a06518517ba37688b897/wlserverlog.txt)7.0.0Inputxdg_shell and wl_shellhttps://gitlab.freedesktop.org/wayland/weston/issues/246Remoting: initialize real DRM output before remoted output2019-05-24T08:19:15ZTomohito EsakiRemoting: initialize real DRM output before remoted outputCurrently, if remoting is enabled, a remoted output location is (0, 0) and real DRM output is located the right of the remoted output because the remoted output is registered before real DRM output. I think that it is better swapping both outputs, so that I want to initialize remoting plugin after real DRM output.
compositor/main.c:
```c
int main(int argc, char *argv[])
{
...
if (load_backend(wet.compositor, backend, &argc, argv, config) < 0) {
weston_log("fatal: failed to create compositor backend\n");
goto out;
}
weston_compositor_flush_heads_changed(wet.compositor);
if (wet.init_failed)
goto out;
+ /* How about initializing remoting plugin in here? for example: */
+ if (strstr(backend, "drm-backend.so"))
+ load_remoting(wet.compositor, config);
```
What do you think?https://gitlab.freedesktop.org/wayland/weston/issues/245Report user idle times to logind2019-05-23T08:23:51ZPekka Paalanenppaalanen@gmail.comReport user idle times to logindSee https://lists.freedesktop.org/archives/systemd-devel/2019-May/042742.html for the rationale.
Logind offers a standard interface for querying system or session idle time, but it works only if the main operator of the session (usually the display server) tells the idle time to logind.
Implement this in libweston's logind support part and add the necessary core framework to track idle time to begin with.UtilitiesInputCore compositorhttps://gitlab.freedesktop.org/wayland/weston/issues/244libweston/DRM renderless (planes only) compositing mode2019-05-23T07:38:33ZPekka Paalanenppaalanen@gmail.comlibweston/DRM renderless (planes only) compositing modeThis is an idea suggestion and I have no personal interest in it for now. I just recalled some IRC discussions from months back.
Particularly on closed embedded systems (TVs, set-top-boxes, special video equipment, ...) the whole system from hardware to software may be designed so that all compositing needs should be satisfied by the display hardware, making renderers useless. That is, when things actually work as designed. It will allow to cut costs in hardware e.g. by choosing a very cheap and slow GPU, while still being able to push full framerate 4K whatever video through by using dedicated display hardware features.
To help people develop and push such systems in the wild, libweston/DRM could do a few things:
- Whenever libweston falls back to the renderer at all, make it print the reasons why it did so. This should likely just re-use the framework developed for solving #144.
- Make `zwp_linux_dmabuf` implementation (the check hook) verify that the created buffer at least has some chances of being scanout-able. Importing as a DRM FB would be the most reliable check, but if that is somehow not acceptable, then the very least the dmabuf format and modifier should be checked against the KMS supported formats and `IN_MODIFIERS`. If there it seems impossible to scan out the dmabuf directly, reject it, so the client can try something else. This might be crucial since normally client side doesn't really care and relies on luck for scanout-ability.
- The GL-renderer tint mode could be activated to show which parts are render-composited on screen.
- Make Pixman-renderer not reject dmabufs when renderless compositing mode is set. This will allow the system designer to avoid OpenGL completely. All dmabufs should be CPU-mmappable nowadays, so Pixman-renderer could support them instead of just not rendering.Pixman rendererDRM/KMS backendhttps://gitlab.freedesktop.org/wayland/weston/issues/243Remove my Developer access rights2019-05-24T13:25:41ZeucanRemove my Developer access rightsHello,
I will move to a different team at Bosch in the end of this month. Therefore, I will not have time to take care about ivi-shell merge requests.
I propose to grant developer access right to @efriedrich instead of me.
Best Regards,
EmreAccountshttps://gitlab.freedesktop.org/wayland/weston/issues/242Weston should have the ability to try all possible CRTCs2019-05-15T17:24:26ZRobert BeckettWeston should have the ability to try all possible CRTCsWeston should be able to iterate through all permutations of outputs and crtcs to find a suitable routing for all outputs.
I am coming to this issue from a place of hotplug failure, where the driver is unable to meet the timing requirements for 2 outputs where the hardware shares a base clock near the base of the clock tree. In this case, the 2 pixel clocks cant be generated with enough accuracy for both based on the shared clock with each pixel clock being driven by independent trees of dividers from the base.
This occurs during hotplugging of the second display.
Other situations may also require this functionality.libwestonDRM/KMS backendhttps://gitlab.freedesktop.org/wayland/weston/issues/240Request for questions :) Good day :)2019-05-13T09:05:28ZGames Global ProjectRequest for questions :) Good day :)1. How to remove the standard panel in the weston?
2. How in the weston to manage hot keys / binders to assign, reassign key bindings, remove key bindings, run the application in autoload?