xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2024-02-20T18:00:58Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1640Xwayland rootful: clipboard sync2024-02-20T18:00:58ZRussell GreeneXwayland rootful: clipboard syncXWayland rootful has been fantastic for running applications that have more complex windowing than rootless Xwayland can handle, at least in my compositor (in my case AMD Vivado), but the primary pain point is the clipboard, I have to us...XWayland rootful has been fantastic for running applications that have more complex windowing than rootless Xwayland can handle, at least in my compositor (in my case AMD Vivado), but the primary pain point is the clipboard, I have to use combinations of xclip and wl-copy to manually move keyboard contents around.
Would it be possible to have a XWayland rootful flag to have it use the wayland clipboard, or is this out of scope for Xwayland?
I also found https://github.com/dnut/clipboard-sync, but it doesn't really seem to work properly. If tools like that are the answer here, I'm happy to open an issue there and try to figure out why it's not working for my setup.
Thanks!https://gitlab.freedesktop.org/xorg/xserver/-/issues/1620Xwayland: Support attaching multiple rootful windows to the same rootful inst...2024-02-04T01:32:50ZBrodie RobertsonXwayland: Support attaching multiple rootful windows to the same rootful instanceWhilst it's easy enough enough to spawn a single Xwayland rootful instance, `Xwayland :12` for example.
And then running a desktop inside of it with `DISPLAY=:12 awesome`
This comes with the limitation of Xwayland only seeing a single ...Whilst it's easy enough enough to spawn a single Xwayland rootful instance, `Xwayland :12` for example.
And then running a desktop inside of it with `DISPLAY=:12 awesome`
This comes with the limitation of Xwayland only seeing a single display, if possible I would like to see a way to attach multiple rootful windows to the same instance allowing me to effectively emulate a multi-monitor X11 environment. If combined with the recently added [-output option](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1212 "xwayland: add an `-output` command line option for placing Xwayland rootful fullscreen") to set the display you'd like the rootful window to spawn on this would allow a user to run a legacy X11 environment on top of a lightweight Wayland compositor whilst still retaining the ability to use multiple monitors.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1544glamor poorly accelerates the geometry requests2023-05-03T17:55:26ZAdam Jacksonajax@nwnk.netglamor poorly accelerates the geometry requestsBy "geometry" here I mean lines arcs and polygons. There are a few cutouts for axis-aligned zero-width lines and the like, but the general cases all fall down to `mi`'s span path, which is like "eh" efficient for lines and polys but brut...By "geometry" here I mean lines arcs and polygons. There are a few cutouts for axis-aligned zero-width lines and the like, but the general cases all fall down to `mi`'s span path, which is like "eh" efficient for lines and polys but brutally slow for arcs.
You'd like to move that math to the GPU side, and ideally keep within the GLES2 target feature set. One thing GLES2 does have is `discard`. Think about a wide line: draw a tri fan that covers the line with a ~1 pixel border, hit test inside the fragment shader and `discard` if the X primitive shouldn't touch that pixel, otherwise fill as usual. You waste a few fragment shader invocations but those are cheap and CPU time is not. Arcs are the hard case, hit testing isn't trivial and you'd like to emit a somewhat-optimal tri fan covering the arc rather than just resort to axis-aligned rectangle and a _lot_ of `discard`s.
The other hard part of this is join and cap styles and self-intersection and all that other fluff. Ideally the `mi` code would have a clean separation between decomposing those style rules into other truly primitive geometry requests, and decomposing primitives into spans. But it probably doesn't (I no longer remember and am not about to look), and refactoring all of `mi` is a much larger task, so complicated GC state will likely still hit the span code; oh well.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1428RFE: XGE generic event channels2023-02-02T17:39:01ZAdam Jacksonajax@nwnk.netRFE: XGE generic event channelsThe Present extension makes the notable improvement that events are selected and delivered relative to an `EVENTID` type - "event channel" might be a better name. This allows for multiple subsystems within a process to receive a copy of ...The Present extension makes the notable improvement that events are selected and delivered relative to an `EVENTID` type - "event channel" might be a better name. This allows for multiple subsystems within a process to receive a copy of any given event, without affecting other subsystems or needing to rely on a client-side convention for event queue interest. (Well. Kinda. It bakes that convention into libxcb as "special events". Whatever.)
Unfortunately it stops there, and it doesn't really belong there. Event channels ought to be an XGE extension concept, and they should be able to encapsulate arbitrary core or extension events. This could massively improve life on the client side. A few examples off the top of my head:
- Multiple readers could listen for `ConfigureNotify` on the root window, or corresponding RANDR events, and all would get notified
- llvmpipe would be able to use the `send_event=True` version of `ShmPutImage` to increase parallelism
- libX11 could potentially internally redirect event selection to its own private channel, which might finally solve the "who owns the event queue" problem when mixing xcb and xlib in one processhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1037Support HDR2020-06-03T15:56:00ZromulasrySupport HDRWhen will you support HDR?When will you support HDR?https://gitlab.freedesktop.org/xorg/xserver/-/issues/863glamor, but for vulkan2019-07-26T09:40:24ZAdam Jacksonajax@nwnk.netglamor, but for vulkanGL's awesome, but a bit heavyweight. It would be cool to have a Vulkan-based acceleration backend instead. Ideally the GLSL would be shared between the two as far as possible.GL's awesome, but a bit heavyweight. It would be cool to have a Vulkan-based acceleration backend instead. Ideally the GLSL would be shared between the two as far as possible.https://gitlab.freedesktop.org/xorg/xserver/-/issues/849RFE: Xwayland: reconnect to the compositor if the connection was destroyed.2019-07-17T07:30:20ZTwaik YontRFE: Xwayland: reconnect to the compositor if the connection was destroyed.Hi. I want to request this feature because Xwayland can be used with proxy compositor (my case). In my case proxy means compositor just shows toplevel surface which Xwayland requests in non-rootleess mode and shows it on the screen and s...Hi. I want to request this feature because Xwayland can be used with proxy compositor (my case). In my case proxy means compositor just shows toplevel surface which Xwayland requests in non-rootleess mode and shows it on the screen and sends input/resolution change events. Is it possible?https://gitlab.freedesktop.org/xorg/xserver/-/issues/725Some X11 clients can grab mouse and keyboard which make impossible to work wi...2021-02-05T12:01:42ZBugzilla Migration UserSome X11 clients can grab mouse and keyboard which make impossible to work with another X11 clients## Submitted by Mikhail Gavrilov `@Mikhail`
Assigned to **Wayland bug list**
**[Link to original bug (#107358)](https://bugs.freedesktop.org/show_bug.cgi?id=107358)**
## Description
When I launching the game "A Story of a Band" mo...## Submitted by Mikhail Gavrilov `@Mikhail`
Assigned to **Wayland bug list**
**[Link to original bug (#107358)](https://bugs.freedesktop.org/show_bug.cgi?id=107358)**
## Description
When I launching the game "A Story of a Band" mouse control stop working in all XWayland applications
Here this game: https://store.steampowered.com/app/856450/
If you want I can make gift for helping fix this issue if you add me as friend in steam store.
$ inxi -bM
System: Host: localhost.localdomain Kernel: 4.18.0-0.rc5.git4.1.fc29.x86_64 x86_64 bits: 64
Desktop: Gnome 3.29.4 Distro: Fedora release 29 (Rawhide)
Machine: Type: Desktop System: Gigabyte product: Z87M-D3H v: N/A serial: `<root required>`
Mobo: Gigabyte model: Z87M-D3H serial: `<root required>` UEFI: American Megatrends v: F11
date: 08/12/2014
CPU: Quad Core: Intel Core i7-4770 type: MT MCP speed: 3762 MHz min/max: 800/3900 MHz
Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] driver: amdgpu v: kernel
Display: wayland server: Fedora Project X.org 11.0 driver: fbdev,modesetting,vesa
resolution: 3840x2160~60Hz
OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.26.0 4.18.0-0.rc5.git4.1.fc29.x86_64 LLVM 6.0.1)
v: 4.5 Mesa 18.1.4
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.77 TiB used: 4.16 TiB (28.2%)
Info: Processes: 495 Uptime: 15h 17m Memory: 31.29 GiB used: 26.83 GiB (85.7%) Shell: bash inxi: 3.0.18
$ rpm -q xorg-x11-server-Xwayland
xorg-x11-server-Xwayland-1.20.0-5.fc29.x86_64https://gitlab.freedesktop.org/xorg/xserver/-/issues/704Screen size cannot rely on wl_output scale and geometry2021-02-15T08:54:02ZBugzilla Migration UserScreen size cannot rely on wl_output scale and geometry## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#101436)](https://bugs.freedesktop.org/show_bug.cgi?id=101436)**
## Description
Currently, Xwayland will configure its screen and moni...## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#101436)](https://bugs.freedesktop.org/show_bug.cgi?id=101436)**
## Description
Currently, Xwayland will configure its screen and monitors given the wl_output's it sees being advertised.
It uses the dimensions of the current mode, together with its x/y coordinate, where each wl_output is treated as a separate monitor. The wl_output.scale event is completely ignored.
In practice, the actual screen size and monitor sizes that Xwayland should have, may thus be something else.
Some examples:
* A compositor may advertise a wl_output with scale 2, and have a logical pixel coordinate space it places windows on where the content wl_output region is also scaled by 2. Here Xwayland should treat a 1024x768 wl_output with scale 2 as 512x384 large internal monitor.
* A compositor may advertise a wl_output with scale 2 in the same way as above, but in fact its logical representation of the output scaled with a fractional scale, which is not advertised at all. In this case, Xwayland has no way to know the expected screen and monitor size.
* A compositor may advertise a wl_output with scale 2, but its logical coordinate space is always identical to the physical pixel coordinate space, meaning Xwayland should as it does now completely ignore the wl_output scale.
To solve this, we need to introduce a protocol (Xwayland specific or not) that communicates the logical geometry of each wl_output.