- User Since
- Jan 13 2020, 1:29 AM (59 w, 6 d)
Jan 26 2021
I understand you. I was at this point when first using Wayland and discovered that I have to implement decorations myself.
- update libdecoration
- remove demo
- rebase master
Sep 12 2020
Aug 5 2020
Maybe I can clear up some misconceptions around the UI alpha channel to avoid confusion for future issues referring to this.
Jul 30 2020
Jul 22 2020
Jul 14 2020
get cursor theme and size via D-Bus
Jul 10 2020
As far as I know, a proper pointer wrapping-around is currently not possible with the protocols that are available.
fix surface access
Jul 8 2020
fix libdecoration dependency tracking in CMake
Jul 4 2020
Jun 23 2020
Jun 18 2020
Jun 16 2020
Jun 15 2020
add libdecoration to external source tree
remove 3D Viewport colour, set alpha as 1.0f
Jun 14 2020
I removed the actual workaround since Mesa 20.0.8 will soon be released to Ubuntu 20.04 (https://bugs.launchpad.net/mpv/+bug/1868520). This should fix the buffer format selection from the drier side.
Jun 12 2020
detect own toplevel surfaces
Jun 10 2020
Jun 4 2020
I added the colour setting for the 3D viewport again. Empirically, I determined that the 3D viewport background colour on X11+master is close to the square of the values in TH_BACK (57 vs 63). I could not figure out how to truly set the alpha channel to 1 for the viewport.
use 'TH_BACK' colour for 3D Viewport background
If there is no drawback from using this with Wayland on other GPUs (like performance issues or UI glitches), then I don't see why one would have this extra GPU driver detection :-)
Jun 1 2020
I am really against having different code branches for this and rather make sure that the behaviour is consistent over all GPUs and drivers. I think there is no downside of having this transparent+opaque setting for all GPUs.
Also, keep in mind that this issue is fixed upstream with Mesa 20.0.7, which eventually will make its way into Ubuntu.
May 30 2020
May 29 2020
The original issue (wrong buffer format selection on Intel Iris) has been fixed in Mesa 20.0.7 (https://www.mesa3d.org/relnotes/20.0.7.html). Ubuntu 20.04.2 will probably use this or a newer version. Do you want to wait until the fix has been released into Ubuntu, or do you want to merge this workaround now and revert later?
May 27 2020
May 26 2020
@Campbell Barton (campbellbarton) Would you insist on the GPU driver detection for enabling the workaround or can this go as is?
May 25 2020
May 24 2020
set opaque window only if alpha channel is used
Instead of painting the 3D view with a specific non-transparent colour, I now just made the entire Wayland window opaque.
May 21 2020
May 20 2020
May 18 2020
I changed this back to a single timer that is reseted whenever a key, that can repeat, is pressed.
May 15 2020
@Campbell Barton (campbellbarton) Is this viable as is (independent key repeats) or do you need to have the X11 behaviour where only the last pressed key can repeat?
set square of TH_BACK values
May 14 2020
All 2D UI elements in the general editor types (Shift + F1..F12) should be opaque now.
fix remaining UI elements, except 3D view
This is now implemented via a GHOST_TimerTask. For this, I also had to change to a non-blocking loop, which as a side effect solves the animation issue in https://developer.blender.org/T76720.
implement key repeat via timer
May 13 2020
The problem is basically that the event handling in GHOST_SystemWayland::processEvents by wl_display_dispatch blocks until new events have been received from the compositor. This is fine and efficient of the UI only has to respond to input events etc. but obviously does not work with animations or other input independent UI events.
May 12 2020
Can you open a dedicated "Task" with a list to reproduce this? I have a hunch of what is missing for that. At the moment, the process loop blocks until a new event has been received from the compositor.
May 10 2020
May 9 2020
I added a mutex to the GHOST_EventManager to synchronise the access to the event queue. This solves the issue with the NULL access.
mutex for event queue access
May 8 2020
May 7 2020
May 6 2020
fix code format
May 5 2020
I can reproduce this. The function xkb_map_gkey receives the XKB_KEY_exclam key, but there is no corresponding GHOST_TKey. It will, therefore, print unhandled key: 33 (XKB_KEY_exclam).
Regarding the modal/dialog windows: What is the semantic difference between being a child window and a dialog window?
May 4 2020
May 2 2020
May 1 2020
Apr 30 2020
style fix, rebase
Apr 29 2020
I removed the usage of STR_String and documented the unimplemented event handlers by citing from the official Wayland protocol documentation. This should provide enough information if this functionality needs to be added later.
update API, document event handlers
Apr 27 2020