wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2023-12-18T09:32:51Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/429Code null pointer dereference in event loop epoll2023-12-18T09:32:51ZKrzysztof BochmCode null pointer dereference in event loop epollIn sway i have encountered null pointer dereference at the line of code linked bellow, where the library tried to call an function at address 0x210 after creating a window
The buggy address is stored in `wl_event_source_interface` struc...In sway i have encountered null pointer dereference at the line of code linked bellow, where the library tried to call an function at address 0x210 after creating a window
The buggy address is stored in `wl_event_source_interface` struct, and it is never referenced in sway's or wlroots' repo therefor I'm reporting it here
The line of code: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/event-loop.c#L1048
Backtrace:
```
#0 0x0000000000000210 in ()
#1 0x00007f545ede8ae2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#2 0x00007f545ede92d7 in wl_display_run () at /usr/lib/libwayland-server.so.0
#3 0x0000556c01433af5 in ()
#4 0x00007f545ea93cd0 in () at /usr/lib/libc.so.6
#5 0x00007f545ea93d8a in __libc_start_main () at /usr/lib/libc.so.6
#6 0x0000556c01433fa5 in ()
```https://gitlab.freedesktop.org/wayland/wayland/-/issues/428User help with Xkb2023-12-19T16:37:07ZGg wpUser help with XkbHello, everyone ! I am helping to develop the [xkb-switch](https://github.com/grwlf/xkb-switch)(originally under X11) port for Wayland. We are faced with the problem of interacting with Xkb under Wayland. [Here](https://github.com/xkbcom...Hello, everyone ! I am helping to develop the [xkb-switch](https://github.com/grwlf/xkb-switch)(originally under X11) port for Wayland. We are faced with the problem of interacting with Xkb under Wayland. [Here](https://github.com/xkbcommon/libxkbcommon/issues/409) we were told that `libxkbcommon` does not have tools to change the keyboard layout. Therefore, I want to find out if there is a standard way in Wayanad to interact with Xkb and keyboard layout.https://gitlab.freedesktop.org/wayland/weston/-/issues/854Name struct owning field `owner`2024-02-06T11:29:28ZPekka Paalanenppaalanen@gmail.comName struct owning field `owner`In Weston, we have several `struct`s whose lifetime is strictly controlled by the associated `wl_resource`: the `struct` cannot out-live the resource, without exception.
I would propose to rename that `struct wl_resource *` field to `ow...In Weston, we have several `struct`s whose lifetime is strictly controlled by the associated `wl_resource`: the `struct` cannot out-live the resource, without exception.
I would propose to rename that `struct wl_resource *` field to `owner` to underline this invariant. A `struct` cannot exist with `owner == NULL`. It implies that `owner` is a back-pointer to an object with its own life time.
I think one can find these by grepping for `wl_resource_create` and inspecting the destructor recorded with `wl_resource_set_implementation()`. For example, `struct weston_surface` is not one, because it can exist without its `wl_resource`.
I feel we should start using this convention at least with new code, and apply it to more owners than just `wl_resource`s.https://gitlab.freedesktop.org/wayland/wayland/-/issues/427Just wanted to say thank you!2023-12-11T16:27:05ZMalte HJust wanted to say thank you!Hey Wayland project.
Its been a long time I use linux and always used X11.
Last week a third monitor arrived and made my laptop unfeasible to work with (fractional scaling wasnt even the issue for the low-performance it seemed).
Using zo...Hey Wayland project.
Its been a long time I use linux and always used X11.
Last week a third monitor arrived and made my laptop unfeasible to work with (fractional scaling wasnt even the issue for the low-performance it seemed).
Using zorin.os 16.3 it was easy to switch to Wayland and I must say: I am deeply impressed!
Everything runs just much faster, like faster than with a single screen even.
What I ignored for very long is that my X11 setup wasn't able to remember that I had two broken touchscreens (the screens are in use, but i deactived the broken touch input, since it was often locking my mouse jumping around).
Everytime I had to run the same keybinding after the laptop left hibernation (xinput --disable ..) and occasionally some mouse misbehavior was still occuring.
With Wayland: the config was just a bless to setup! (used https://askubuntu.com/questions/927022/how-can-i-disable-touchscreen-while-using-wayland)
and now I have both: perfect functionality and quick speed.
Thank you guys for continuing your mission to solve the Linux input-output mess, despite all barriers.
Thats it, closing this as off-topic right away to keep your board clean.https://gitlab.freedesktop.org/wayland/weston/-/issues/853Segfault on right-clicking weston-terminal2023-12-12T08:38:42ZŠimon GebauerSegfault on right-clicking weston-terminalRight click on weston-terminal or weston-editor when no physical keyboard is connected results in a segfault. Tested on weston 13.0.0 and 12.0.3. This also prevents the virtual keyboard from showing.
![Screenshot_20231211_121958](/uploa...Right click on weston-terminal or weston-editor when no physical keyboard is connected results in a segfault. Tested on weston 13.0.0 and 12.0.3. This also prevents the virtual keyboard from showing.
![Screenshot_20231211_121958](/uploads/9d24608d422dd90863251706354f6105/Screenshot_20231211_121958.png)
Issue is not present when even a dummy keyboard is assigned to the used seat.https://gitlab.freedesktop.org/wayland/weston/-/issues/852DRM deinit with error device2024-01-19T14:32:23Zzhou liangDRM deinit with error deviceHello team!
For multi-GPU hotplug, when one connector on a special card is disconnected, it will be detached from head. The following code should be called:
```
static void
drm_output_deinit(struct weston_output *base)
{
struct drm_ou...Hello team!
For multi-GPU hotplug, when one connector on a special card is disconnected, it will be detached from head. The following code should be called:
```
static void
drm_output_deinit(struct weston_output *base)
{
struct drm_output *output = to_drm_output(base);
struct drm_backend *b = output->backend;
struct drm_device *device = b->drm;
struct drm_pending_state *pending;
if (!b->compositor->shutting_down) {
pending = drm_pending_state_alloc(device);
drm_output_get_disable_state(pending, output);
drm_pending_state_apply_sync(pending);
}
if (b->compositor->renderer->type == WESTON_RENDERER_PIXMAN)
drm_output_fini_pixman(output);
else
drm_output_fini_egl(output);
drm_output_deinit_planes(output);
drm_output_detach_crtc(output);
if (output->hdr_output_metadata_blob_id) {
drmModeDestroyPropertyBlob(device->drm.fd,
output->hdr_output_metadata_blob_id);
output->hdr_output_metadata_blob_id = 0;
}
}
```
I think the `struct drm_device *device = b->drm;` is assigned as an error device, because the disconnected connector may
be belonged to a additional device, so always assign the `b->drm` to drm_device is a wrong code.
I think it should be change with:
```
struct drm_device *device = output->device;
```
Is this right?
Snow
Best regardshttps://gitlab.freedesktop.org/wayland/weston/-/issues/851update connector to wrong drm_device2024-01-19T14:33:52Zzhou liangupdate connector to wrong drm_deviceHello team!
Recently, I read the weston source code, and a possible error was found in a piece of code.
```
static void
drm_backend_update_connectors(struct drm_device *device,
struct udev_device *drm_device)
{
...
ass...Hello team!
Recently, I read the weston source code, and a possible error was found in a piece of code.
```
static void
drm_backend_update_connectors(struct drm_device *device,
struct udev_device *drm_device)
{
...
assert(head == NULL || writeback == NULL);
if (head) {
ret = drm_head_update_info(head, conn);
if (head->base.device_changed)
drm_head_log_info(head, "updated");
} else if (writeback) {
ret = drm_writeback_update_info(writeback, conn);
} else {
ret = drm_backend_add_connector(b->drm, conn, drm_device);
}
}
```
For the code `ret = drm_backend_add_connector(b->drm, conn, drm_device);`
If both the `head` and `writeback` are `NULL`, then it should be add connector from the drm device passed by the function, not the `b->drm` device, this is because the weston is support multi-GPU, so I think it should be changed with:
```
ret = drm_backend_add_connector(device, conn, drm_device);
```
Is this right?
Snow
Best regardshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/170Protocol lifetime and organization2023-12-11T13:05:39ZSebastian WickProtocol lifetime and organizationAs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/266 demonstrates, having multiple copies of one protocol is confusing enough that developers update the wrong version and reviewers don't catch the issue.
Prop...As https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/266 demonstrates, having multiple copies of one protocol is confusing enough that developers update the wrong version and reviewers don't catch the issue.
Proposal: Have exactly one copy of the protocol in the wayland-protocols repository and **move** them between the three directories `staging`, `stable`, `deprecated`.
Moving the files results in projects depending on wayland-protocols to include files which no longer exist. For projects which depend on the files to be installed in the system we can install the files to old locations at install time. For projects which depend on the files to exist in the source repository things get more complicated.
We could provide a new repository, called `wayland-protocols-static` (name pending) which uses CI to automatically install wayland-protocols to get the backwards-compatible directory and file structure, and commits the result to itself.
This requires breaking changes to projects which currently depend on the file location in the wayland-protocols repository. I therefor also propose to use this opportunity to break everything even more and remove the existing unstable directory and move the files either to staging or deprecated, and also delete files from staging and unstable which were promoted to stable.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/169Follow-up from "linux-dmabuf: sync changes from unstable to stable"2024-01-30T00:59:57ZPekka Paalanenppaalanen@gmail.comFollow-up from "linux-dmabuf: sync changes from unstable to stable"The following discussion from !266 should be addressed:
- [ ] @swick started a [discussion](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/266#note_2198933): (+1 comment)
> *sight* This is bad. Keeping a...The following discussion from !266 should be addressed:
- [ ] @swick started a [discussion](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/266#note_2198933): (+1 comment)
> *sight* This is bad. Keeping all the old protocol files around even confuses core contributors and escapes reviewers.
>
> Can we please again talk about this and somehow make sure we have exactly one copy of every protocol around? Maybe create a new repo which contains all the different versions?https://gitlab.freedesktop.org/wayland/wayland/-/issues/426Adding restrictions to global binding and resource creation.2024-01-29T11:17:02ZEduardo HopperdietzelAdding restrictions to global binding and resource creation.Hello,
I have noticed that there are several clients that bind multiple times to the same global, for example, to the same wl_output or wl_seat, or create more than one wl_pointer, wl_keyboard, or wl_touch from the same wl_seat. This ob...Hello,
I have noticed that there are several clients that bind multiple times to the same global, for example, to the same wl_output or wl_seat, or create more than one wl_pointer, wl_keyboard, or wl_touch from the same wl_seat. This obviously complicates several things on the compositor side and makes it less efficient, and from my point of view, it doesn't make much sense. Therefore, could we consider the option of specifying rules in the protocols to prevent clients from doing this and treat it as an error? Or is there any reason that I am unaware of for allowing this?
Regardshttps://gitlab.freedesktop.org/wayland/weston/-/issues/850Multi-GPU hot plug2024-01-19T14:36:49Zliang zhouMulti-GPU hot plugHi, team!
I have a device with three cards, and the connectors are as follows:
The first connector:
```
root@dev:/sys/class/drm/card3-LVDS-2# cat connector_id
37
```
The second connector:
```
root@dev:/sys/class/drm/card2-LVDS-1#...Hi, team!
I have a device with three cards, and the connectors are as follows:
The first connector:
```
root@dev:/sys/class/drm/card3-LVDS-2# cat connector_id
37
```
The second connector:
```
root@dev:/sys/class/drm/card2-LVDS-1# cat connector_id
37
```
The last one is HDMI:
```
root@dev:/sys/class/drm/card1-HDMI-A-1# cat connector_id
37
```
Currently we don't use the HDMI card in weston test, and I'm doing a test to disable one connector when the other display are working, when disabling one connector, the weston will free the frame-buffer associated to the connector that is disconnected, I check the source code of the weston, the connectors are all stored in one list, and find connector is use the connector_id as key, if the different connectors have the same connector id, then it will find a wrong connector.
```c
struct drm_head *
drm_head_find_by_connector(struct drm_backend *backend, uint32_t connector_id)
{
struct weston_head *base;
struct drm_head *head;
wl_list_for_each(base,
&backend->compositor->head_list, compositor_link)
{
head = to_drm_head(base);
if (!head)
continue;
if (head->connector.connector_id == connector_id)
return head;
}
return NULL;
}
```
BTW, I start weston with the following parameters:
```
ExecStart=/usr/bin/weston -Swayland-0 --debug --drm-device=card3 --additional-devices=card2 --use-pixman --flight-rec-scopes=
```
So I think the way drm_head_find_by_connector finds the connector is inappropriate in a multi-GPU situation.
Looking forward to your reply!
Snow
Best regardshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/168Request for New Wayland Protocol to Improve Window Taskbar Progress Features2023-12-05T01:03:15ZSnowNFRequest for New Wayland Protocol to Improve Window Taskbar Progress FeaturesHello everyone! The [Window Taskbar Progress PR](https://github.com/glfw/glfw/pull/2286) looks very well.
This pull request for GLFW introduces the following features:
- The `glfwSetWindowProgressIndicator()` function, which allows dis...Hello everyone! The [Window Taskbar Progress PR](https://github.com/glfw/glfw/pull/2286) looks very well.
This pull request for GLFW introduces the following features:
- The `glfwSetWindowProgressIndicator()` function, which allows displaying the progress of an action in the dock or taskbar.
- The `GLFW_PROGRESS_INDICATOR_DISABLED` value, which stops displaying the progress.
- The `GLFW_PROGRESS_INDICATOR_INDETERMINATE` value, which displays the progress in an indeterminate state. On Windows, this cycles the progress from 0% to 100% repeatedly.
- The `GLFW_PROGRESS_INDICATOR_NORMAL` value, which displays the user-defined progress status (0%-100%) on the taskbar.
- The `GLFW_PROGRESS_INDICATOR_ERROR` value, which displays an error progress.
- The `GLFW_PROGRESS_INDICATOR_PAUSED` value, which displays a paused progress.
Currently, on Linux, the [Unity LauncherAPI](https://wiki.ubuntu.com/Unity/LauncherAPI) is used via DBus. However, this API requires a valid application .desktop file with the same name as the executable. It seems that only KDE and the Unity desktop environment utilize this API.
If it would be possible to add a new protocol that could better implement these features?https://gitlab.freedesktop.org/wayland/weston/-/issues/847Weston Kiosk Shell chromium losing focus upon sad tab kill2024-01-19T14:19:11ZW Scott McKibbinWeston Kiosk Shell chromium losing focus upon sad tab killHello,
Working on a project which is launching a Weston Kisok Shell for a single chromium kiosk targeting a localhost webserver, running on imx8.
We are encountering an issue when chromium kills a "sad_tab". Seems as though this kills ...Hello,
Working on a project which is launching a Weston Kisok Shell for a single chromium kiosk targeting a localhost webserver, running on imx8.
We are encountering an issue when chromium kills a "sad_tab". Seems as though this kills and restarts the tab in the event of memory issues within chromium. When this happens, we lose focus on the chromium window and are no longer able to navigate with the keypad input setup for the kiosk.
Here is our config weston ini:
```ini
[core]
shell=kiosk-shell.so
idle-time=0
useg2d=0
xwayland=false
#use-g2d=1
[output]
name=HDMI-A-1
app-ids=chromium-browser (/home/root/.config/)
mode=71.00 1280 1328 1360 1440 800 803 809 823 +hsync +vsync
```
I thought adding the app id as capture from our chromium launch command would stop the focus from changing but it did not. I need to find a way to prevent the focus from leaving. We are able to restore focus by clicking but that is only because this is in the lab on a test machine with a keyboard/mouse hooked up, the real setup will only have a small keypad.
```sh
WAYLAND_DEBUG=1 chromium 2>&1 \
--no-sandbox \
--window-size=1920,1080 \
--start-fullscreen \
--kiosk \
--incognito \
--noerrdialogs \
--disable-translate \
--no-first-run \
--fast \
--fast-start \
--disable-infobars \
--disable-features=TranslateUI \
--disk-cache-dir=/dev/null \
--password-store=basic \
--in-process-gpu \
--touch-events \
--user-data-dir=/home/root/.config/ \
--disable-web-security \
http://127.0.0.1 | grep app
[4088792.203] -> xdg_toplevel@36.set_app_id("chromium-browser (/home/root/.config/)")
```
Any tips, tricks or advice you could give would be greatly appreciated.
Thankshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/167xdg-decoration: Support windows displaying content within the decoration2024-01-14T05:12:39ZNadia Pedersenxdg-decoration: Support windows displaying content within the decorationIt would be useful if applications were to optionally be able to draw their own content under/around the window decoration when server-side decorations are requested. This would allow replicating many of the actual uses of client side de...It would be useful if applications were to optionally be able to draw their own content under/around the window decoration when server-side decorations are requested. This would allow replicating many of the actual uses of client side decorations in UIs while also retaining part of the consistency provided by having the desktop environment draw the decorations.
The main use of this would likely be
* Web browsers - for putting tabs in the title bar, while retaining a native appearance for window controls
* Applications with "immersive" content like video players or games that may wish to hide the title bar on inactivity
(Example: QuickTime on macOS fades out the window decoration when its video controls aren't visible)
* Web/Electron-based applications that integrate the window controls into their user interface on macOS and Windows, but currently are unable to on Linux
(Example: Discord draws a custom title bar on Windows, and places the window controls above the server list on macOS)
* Applications with their own entirely custom drawing, such as those using minimal UI libraries like imgui, that may still want a more integrated look
Ideally this should enable applications to
* Request to have their surface drawn under the window decoration
* Request to hide (or change the opacity of, for fades?) the overlaid decoration entirely
* Request what style of decoration to draw
* Should the decoration have its background filled
* Should title text be shown
* Should additional items other than the main window controls be shown? (Like the leftmost window menu/stick button in KDE
* Should window buttons be shown
* Perhaps the application could request light/dark controls to properly contrast its user interface?
* Query the positions at which the window has controls drawn over it so the app's UI controls can dodge them
* Query or request a height for the title bar area, so controls will align correctly with the app's designated space for them in their UI
Advantages for app developers over purely client-side decorations:
* Provides a standardized way for applications to
* Unlike full CSD, window controls will still appear in a way that is themed and positioned consistently with the rest of the desktop no matter what framework the application uses (or doesn't) to draw itself
* Less work for the app developer, no need to reinvent rendering window controls in custom-drawn apps
* Hung applications will still have responsive window controls
Examples:
These are some of the styles of windows that would be possible with these features. Here I used screenshots of macOS because it makes doing these things relatively easy.
![image](/uploads/4a4787d429309864760eff0338874b33/image.png)
I don't know if this is out of scope for a server side decoration protocol, or a Wayland protocol in general, feel free to close this issue if that is the case, but I figured I'd suggest it because I think this is functionality that there is currently otherwise no good way to accomplish that a lot of apps on other platforms uses.https://gitlab.freedesktop.org/wayland/weston/-/issues/846ivi-shell: setting surface visibility to 0 does not prevent the content from ...2023-12-04T14:30:55ZAlexandru N. Oneaivi-shell: setting surface visibility to 0 does not prevent the content from being renderedI am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of th...I am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of this request on the controller side, for the moment, just sets the visibility of the respective `ivi_layout_surface` to `0` and calls `commit_changes`. I was expecting that after that, the content of the surface is no longer visible on the screen, but it is.
Am I missing something?https://gitlab.freedesktop.org/wayland/wayland/-/issues/425Monitor detection (multiple variable refresh rate monitors) causing AMDGPU cr...2023-11-27T11:44:07ZW olfickMonitor detection (multiple variable refresh rate monitors) causing AMDGPU crashesI believe this is a wayland specific bug as it occurs in both Gnome and KDE when running a Wayland session. If you still believe this is the compositor/arch, please let me know and help link the issue and/or redirect me. Apologies if thi...I believe this is a wayland specific bug as it occurs in both Gnome and KDE when running a Wayland session. If you still believe this is the compositor/arch, please let me know and help link the issue and/or redirect me. Apologies if this is a bit long winded (it's the only way I know). This has been an issue many times in the past I believe, but that was solved and this is now caused by something recent.
<details><summary>System info</summary>
---------------------------------<br/>
Most of this is not overly relevant, as I replicated the issue on live installations that do not have my settings/themes etc<br/><br/>
OS: Arch Linux<br/>
Kernel: x86_64 Linux 6.6.2-arch1-1<br/>
Uptime: 53m<br/>
Packages: 1287<br/>
Shell: zsh 5.9<br/>
Resolution: No X Server<br/>
DE: GNOME 45.1<br/>
WM: Mutter<br/>
WM Theme: Orchis-Green-Dark<br/>
GTK Theme: Orchis-Orange-Light [GTK2/3]<br/>
Icon Theme: BeautyLine<br/>
Font: Cantarell 11<br/>
Disk: 1.2T / 27T (5%)<br/>
CPU: AMD Ryzen 7 5800X3D 8-Core @ 16x 3.4GHz<br/>
GPU: AMD Radeon RX 7900 XT (gfx1100, LLVM 16.0.6, DRM 3.54, 6.6.2-arch1-1)<br/>
RAM: 4759MiB / 32019MiB<br/>
<br/>
Monitor 1:<br/>
ASUS TUF Gaming VG27AQL1A<br/>
Size: 27"<br/>
Refresh rate: 170Hz<br/>
<br/>
Monitor 2:<br/>
ASUS TUF Gaming VG35VQ<br/>
Size: 35"<br/>
Refresh rate: 100Hz<br/><br/>
---------------------------------<br/>
</details>
The detection of multiple variable-refresh-rate monitors is causing amdgpu, and subsequently the displays, to crash. It also struggles at the end of a session? It only occurs with multiple monitors and on a wayland session.
**Triggers that cause it**
- Turning the monitors off, then back on again.
- Changing refresh rate of the monitors.
- Booting the pc from sleep/hibernation.
- Logging out.
- Restarting
- Shutting down (Minor effect. The display just hangs for 5+ seconds after sending poweroff command before shutting down)
**Bug replications**
In order to ensure this was not a bug introduced by anything I had installed or customized incorrectly, I replicated this bug using live installation media. I only used Manjaro live media as I could not start an Ubuntu session in wayland from the live media. Of note, this does not occur in the Manjaro release from earlier this year (or before that), it has only appeared in the last couple of months.
- Manjaro-gnome release 22.0.4-230222 (Feb 22) : Does not occur
- Manjaro-gnome release 23.0.4-231015 (Oct 15) : Does occur
- Manjaro-kde release 23.0.4-231015 (Oct 15) : Does occur
- Arch Linux latest firmware/kernel as of Nov 27 : Does occur
**Other effects/notes of the bug**
I haven't been able to stably replicate the below, or they have occured on my system which I haven't been able to isolate from everything else.
- During a long session, the screen can start to lag and pause momentarily, especially using Brave (or other browsers?)
- After a long session, the shutdown script is spammed with [drm:dc_dmub_srv_cmd_run_list [amdgpu]] *ERROR* Error queueing DMUB command: status=2
- Dmesg also has the above amdgpu error consistently within it (I have attached the dmesg output)
- journalctl also displays how severe this amdgpu error is spamming (also attached. format: `journalctl -r | grep amdgpu`)
- After restoring from sleep (when it does succeed) and maybe logout+login again, moving the mouse over the border of the gnome screenshot frame box (into the box or out of it) will cause the display to have a 1 second delay with 100% consistency.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/166Pointer confinement: wrapping2024-03-24T16:28:41ZDallas StrousePointer confinement: wrappingCurrently, with pointer confinement, you can lock it to a specific position or set it to stay within a certain region. I'd like to propose that the region confinement portion be extended to be able to specify "wrapping" behavior.
zwp_c...Currently, with pointer confinement, you can lock it to a specific position or set it to stay within a certain region. I'd like to propose that the region confinement portion be extended to be able to specify "wrapping" behavior.
zwp_confined_pointer_v1 would gain two new requests, and two new events:
Requests:
- zwp_confined_pointer_v1::set_wrapping
- zwp_confined_pointer_v1::unset_wrapping
Events:
- zwp_confined_pointer_v1::wrapping
- zwp_confined_pointer_v1::not_wrapping
To explain how this would work, imagine you have a 10x10 window. You have a cursor at (0, 5), dead on the west side. You move it along the X axis, all the way to (10, 5), and the cursor *would* keep on going to be outside of that 10x10 window. Instead, if you set `set_wrapping`, you'd be able to define the behavior that it *should* end up at (0, 5) again, and it would wrap indefinitely.
Imagine if you had a grid of that 10x10 window, and wherever you went outside, you'd instead step right into the next window in that position. Here's some relevent example from a manga I was reading that used the same idea :)
![image](/uploads/4fb6d85966a06f710fce2eb02ba6a0aa/image.png) ![image](/uploads/9eef63dc6a733b559e6508c868a65da2/image.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/424Document that wl_display_connect() is not thread safe2023-11-26T02:56:33ZM. StoecklDocument that wl_display_connect() is not thread safeIf the environment variable WAYLAND_SOCKET is defined, `wl_display_connect()` can call the non-threadsafe `unsetenv()` and interfere with other threads calling `getenv()` at the same time.
The documentation for the function should warn ...If the environment variable WAYLAND_SOCKET is defined, `wl_display_connect()` can call the non-threadsafe `unsetenv()` and interfere with other threads calling `getenv()` at the same time.
The documentation for the function should warn about this.https://gitlab.freedesktop.org/wayland/wayland/-/issues/423protocol: Introduce a transparent region (proposal)2024-02-12T18:01:42ZRobert Maderprotocol: Introduce a transparent region (proposal)Just an idea I had in a feverish moment but I think is worthy discussing:
## Idea
Analogous to the opaque region: a hint about a region of a surface that's fully transparent and thus never needs to get drawn. Crucially: it never needs ...Just an idea I had in a feverish moment but I think is worthy discussing:
## Idea
Analogous to the opaque region: a hint about a region of a surface that's fully transparent and thus never needs to get drawn. Crucially: it never needs to get blended with underlying content.
The transparent region and the opaque region must not overlap, otherwise -> protocol error.
Setting a transparent region for a surface with an opaque / alpha-less format -> protocol error (or ignore?).
## Motivation
Opaque regions have proven to be crucial for good compositor performance, especially floating window desktop use-cases. Transparency has traditionally been less important as usually it's not expected that apps leave big parts of surfaces unused. There is, however, at least one class of increasingly popular patterns where this is the case: overlays or "hole punching". I.e. a subsurface with (usually imported) content below a rendered overlay surface.
From https://blog.gtk.org/2023/11/15/introducing-graphics-offload/ for visualization:
![bbb-below](/uploads/a05350c2ea5fcd96cd40a507565172a6/bbb-below.png)
So far this is mostly done in embedded environments where it's unlikely that the compositor would ever have to pay the price of blending on the GPU (using hw planes instead). Which maybe explains why this issue wasn't brought up before (at least I couldn't find any issue).
There are several recent developments that IMO make it worth to optimize the composited case more:
1. desktop environments are picking up the approach:
- way more cases where the GPU fallback is required
- current situation forcing implementations to add complex workarounds is tiresome (see further below)
2. color mangement / HDR:
- blending will become (potentially much) more expensive
- apps/toolkits will likely pick up the approach in order to show HDR content while keeping their rendering engines SDR (as previously seen on MacOS).
A transparent region hint would allow compositors to massively reduce or completely skip blending. In cases where surface is fully transparent compositors could skip a hw plane assignment (important in cases planes are rare, from the hardware or software side).
WDYT?
## Notes
Coincidentally such a hint would also provide solution(s) for https://gitlab.freedesktop.org/wayland/wayland/-/issues/266:
- apps like the video player example above wouldn't need to care about bringing the video surface to the foreground, the "main" surface that receives the frame callbacks would always stay on top.
- similarly, complex clients consisting of many subsurfaces could have an invisible "cover" surfaces for callback and input handling. Even the Firefox Wayland backend as shipped today could use this approach, putting the "content" subsurface below the toplevel one. The only reason it doesn't do so today is the blending overhead.
---
cc @mclasen @pq @daniels @swick @jadahlhttps://gitlab.freedesktop.org/wayland/weston/-/issues/844Mouse click event issue on rdp + chromium2023-11-23T09:16:13ZHimanshu BhavaniMouse click event issue on rdp + chromiumHi @mvlad weston rdp working fine at client and server side but when I run chromium browser I am not able to access chromium from client rdp desktop.
It is looks like mouse is hiding behind the chromium on rdp windows.
I have found this ...Hi @mvlad weston rdp working fine at client and server side but when I run chromium browser I am not able to access chromium from client rdp desktop.
It is looks like mouse is hiding behind the chromium on rdp windows.
I have found this type of issue is already open in here https://monorail-prod.appspot.com/p/chromium/issues/detail?id=1284377
Is there any solution for this ?
I am using weston version 10.