Re: Freenode fallout
On Friday, May 21st, 2021 at 1:49 AM, Lyude Paul wrote: > After considering Libera and OFTC as options, the board settled on > recommending OFTC. The primary reason for this is because OFTC is > associated with our parent foundation SPI, and has a long and well known > history of involvement with the open source community. As well, the > board believes OFTC's current Governance model is a lot more clear then > Libera's. I'd personally prefer Libera Chat. They don't yet have a published formal governance model, but I hope this will come soon. As the former Freenode staff, I trust them to make sure mistakes from the past won't be repeated. Apart from politics, Libera also offers a more modern feature set. This can ease daily usage, with features such as reliable authentication, account tracking, and many other IRC protocol improvements. OFTC has plans to eventually migrate to Solanum, but they don't have the time to do it for now. For reference, on OFTC: CAP LS 302 :kinetic.oftc.net CAP * LS :multi-prefix And on Libera: CAP LS 302 :ruthenium.libera.chat CAP * LS :account-notify away-notify chghost extended-join multi-prefix sasl=PLAIN,ECDSA-NIST256P-CHALLENGE,EXTERNAL tls userhost-in-names account-tag cap-notify echo-message solanum.chat/identify-msg solanum.chat/realhost ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Call for an EDID parsing library
On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula wrote: > On Thu, 08 Apr 2021, Simon Ser cont...@emersion.fr wrote: > > > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula > > jani.nik...@linux.intel.com wrote: > > > > > Perhaps that should be the takeaway; try to minimize parsed data > > > where the consumer needs to know whether it originated from DisplayID or > > > EDID? > > > > So an EDID/DisplayID abstraction layer? > > > > It sounds like only an EDID and DisplayID expert could come up with a > > sane API for that. Also some metadata will only be available in one > > format and not the other. > > Well, some of the data already comes from DisplayID extensions in the > EDID. > > My point is, if you parse displayid and edid into different structures > and APIs, what will the code bases using the library end up looking > like? Not pretty? Implementing the same conditionals all over the place? > Anyway. I feel like I'm derailing this a bit, and I really don't want > that to happen. I think DisplayID is a consideration that should not be > forgotten, but it's probably not the first priority here. I agree with the goal. I'm just saying that it considerably increases the complexity of the task. If you're just doing an EDID library, you can just expose the EDID specific bits with a sane API. If you're designing an abstraction layer, you need to have a good look at both APIs, try to come up with common data structures that fit both, and be aware of the upcoming spec changes to not be stuck with a bad API. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Call for an EDID parsing library
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula wrote: > Perhaps that should be the takeaway; try to minimize parsed data > where the consumer needs to know whether it originated from DisplayID or > EDID? So an EDID/DisplayID abstraction layer? It sounds like only an EDID and DisplayID expert could come up with a sane API for that. Also some metadata will only be available in one format and not the other. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Call for an EDID parsing library
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd definitely be interested in using such as library. A C API with no dependencies is pretty important from my point-of-view. I'd prefer if C++ was not used at all (and could almost be baited into doing the work if that were the case), but it seems that ship has sailed already. Simon ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] WIP : Add support for variable refresh rate in modesetting DDX
Hi, (Re-sending because I forgot to CC the list, sorry about that.) On Wednesday, June 10, 2020 2:05 PM, wrote: > In order for a window to be suitable for variable refresh it must have > the _VARIABLE_REFRESH property with a 32-bit CARDINAL value of 1. Why is this necessary? Also maybe [1] is relevant. Thanks, Simon [1]: https://lists.freedesktop.org/archives/dri-devel/2020-March/258940.html ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Monday, March 16, 2020 5:04 PM, Jason Ekstrand wrote: > Hopefully, that will provide some motivation for other compositors > (kwin, gnome-shell, etc.) because they now have a real user of it in > an upstream driver for a major desktop platform and not just a few > weston examples. However, someone is going to have to drive the > actual development in those compositors. I'd be very happy if more > people got involved, :-) FWIW, a wlroots pull request is in progress [0]. The plan is first to accept fence FDs from clients, then send them our fences as a second step. [0]: https://github.com/swaywm/wlroots/pull/2070 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Xwayland: fix output changes not getting applied in some, cases
[Paging wayland-devel@ for the protocol discussion at the end of this e-mail] On Monday, April 22, 2019 3:21 PM, Ferdi265 wrote: > On 22/04/2019 14:01, Roman Gilg wrote: > > On Mon, Apr 22, 2019 at 1:30 PM Ferdi265 theferdi...@gmail.com wrote: > > > Hello, > > > I investigated a bug I encountered while using the Sway Compositor and > > > traced it back to some behaviour in Xwayland: > > > The xdg_output and wl_output events are handled in such a way that > > > output changes (e.g. position) sometimes don't get applied if only > > > xdg_output is sent instead of both xdg_output and wl_output. (Sway does > > > this) > > > > This issue was something we noted in KWin as well and fixed it > > downstream by making sure the events get always sent together. > > More info here: https://phabricator.kde.org/D19253 > > Would a downstream fix work for you as well? Not saying it can't be > > fixed upstream in XWayland, but I haven't yet looked at your patch in > > detail and I just remember the output code in Xwayland being somewhat > > difficult, so maybe a downstream fix would be easier. > > The change to remove some information from the wl_output event and > instead rely only on xdg_output in wlroots was deliberate as it > simplifies the compositor code and might not even make much sense for > some types of compositors (e.g. 3D desktop systems). > > The reason the events now don't fire together is that no information in > wl_output actually changed, while the information in xdg_output did. > > the downstream discussion for this is here > https://github.com/swaywm/wlroots/issues/1610 > > I can't really speak for the whole wlroots / sway project, so I added > Simon Ser aka "emersion" as CC, who is one of the main developers of > sway and wlroots. > > Personally, I think Xwayland shouldn't attach too much meaning to when > these events happen, and if they happen together. They are separate > events after all, and should be treated this way. > > Assuming that this information is always updated at the same time or > even re-sending it without a change (e.g. changing the output position > in sway doesn't change any information in the wl_output event) just so > the events happen together just sounds backwards to me. I agree that Xwayland should be a good client and should handle xdg_output.done sent even when wl_output.done isn't sent. However I'm not sure this is the right fix: this patch breaks atomicity. For instance the first time the output is advertised to Xwayland, it will first update its internal state with the metadata from wl_output and then take into account xdg-output and apply a second update. This results in invalid intermediate state. I'm not sure how to fix it, the only idea I can come up with is to have a timer to debounce updates (yeah, it's not a good idea). [Below is the part for wayland-devel@] Wild idea: maybe xdg_output.done should never have existed, and xdg_output should have used the wl_output.done event to atomically submit state -- just like wl_surface.commit is used by add-on interfaces like xdg_surface. This would more-or-less result in the workaround Roman suggested on the server side, but it would be nice to formalize it if we want to go down this road. Thoughts? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xwayland: use wl_surface_damage_buffer
On Monday, November 5, 2018 3:24 PM, Pekka Paalanen wrote: > I don't think it's a good idea to break Xwayland completely on > compositors that don't implement wl_surface version 4 or greater. > > It would make sense to bind wl_compositor min(version, 4). This is intentional. I think it's reasonable to expect wl_compositor v4, it's pretty old (3 years old). For instance, compositors not implementing v4 have no damage tracking with EGL. I think it's worth it to require v4 rather than cluttering the codebase with version checks. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] xwayland: use wl_surface_damage_buffer
wl_surface_damage can be unoptimal on some compositors, damaging the whole
buffer instead of the provided region. wl_surface_damage_buffer is preferred.
Since xwayland doesn't set a surface offset, scale or transform, surface
damage is effectively equivalent to buffer damage.
Signed-off-by: Simon Ser
---
See
https://lists.freedesktop.org/archives/wayland-devel/2018-November/039608.html
hw/xwayland/xwayland-cursor.c | 12 ++--
hw/xwayland/xwayland-present.c | 6 +++---
hw/xwayland/xwayland.c | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
index cf8395f1d..98c7fd207 100644
--- a/hw/xwayland/xwayland-cursor.c
+++ b/hw/xwayland/xwayland-cursor.c
@@ -165,9 +165,9 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
xwl_seat->x_cursor->bits->yhot);
wl_surface_attach(xwl_cursor->surface,
xwl_shm_pixmap_get_wl_buffer(pixmap), 0, 0);
-wl_surface_damage(xwl_cursor->surface, 0, 0,
- xwl_seat->x_cursor->bits->width,
- xwl_seat->x_cursor->bits->height);
+wl_surface_damage_buffer(xwl_cursor->surface, 0, 0,
+ xwl_seat->x_cursor->bits->width,
+ xwl_seat->x_cursor->bits->height);
xwl_cursor->frame_cb = wl_surface_frame(xwl_cursor->surface);
wl_callback_add_listener(xwl_cursor->frame_cb, _listener,
xwl_cursor);
@@ -215,9 +215,9 @@ xwl_tablet_tool_set_cursor(struct xwl_tablet_tool
*xwl_tablet_tool)
xwl_seat->x_cursor->bits->yhot);
wl_surface_attach(xwl_cursor->surface,
xwl_shm_pixmap_get_wl_buffer(pixmap), 0, 0);
-wl_surface_damage(xwl_cursor->surface, 0, 0,
- xwl_seat->x_cursor->bits->width,
- xwl_seat->x_cursor->bits->height);
+wl_surface_damage_buffer(xwl_cursor->surface, 0, 0,
+ xwl_seat->x_cursor->bits->width,
+ xwl_seat->x_cursor->bits->height);
xwl_cursor->frame_cb = wl_surface_frame(xwl_cursor->surface);
wl_callback_add_listener(xwl_cursor->frame_cb, _listener,
xwl_cursor);
diff --git a/hw/xwayland/xwayland-present.c b/hw/xwayland/xwayland-present.c
index 792eaa69c..afd9e67a9 100644
--- a/hw/xwayland/xwayland-present.c
+++ b/hw/xwayland/xwayland-present.c
@@ -521,9 +521,9 @@ xwl_present_flip(WindowPtr present_window,
xwl_present_window);
}
-wl_surface_damage(xwl_window->surface, 0, 0,
- damage_box->x2 - damage_box->x1,
- damage_box->y2 - damage_box->y1);
+wl_surface_damage_buffer(xwl_window->surface, 0, 0,
+ damage_box->x2 - damage_box->x1,
+ damage_box->y2 - damage_box->y1);
wl_surface_commit(xwl_window->surface);
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 605c9f56b..76211ef4a 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -684,13 +684,13 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
*/
if (RegionNumRects(region) > 256) {
box = RegionExtents(region);
-wl_surface_damage(xwl_window->surface, box->x1, box->y1,
- box->x2 - box->x1, box->y2 - box->y1);
+wl_surface_damage_buffer(xwl_window->surface, box->x1, box->y1,
+ box->x2 - box->x1, box->y2 - box->y1);
} else {
box = RegionRects(region);
for (i = 0; i < RegionNumRects(region); i++, box++)
-wl_surface_damage(xwl_window->surface, box->x1, box->y1,
- box->x2 - box->x1, box->y2 - box->y1);
+wl_surface_damage_buffer(xwl_window->surface, box->x1, box->y1,
+ box->x2 - box->x1, box->y2 - box->y1);
}
xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
@@ -737,9 +737,9 @@ registry_global(void *data, struct wl_registry *registry,
uint32_t id,
{
struct xwl_screen *xwl_screen = data;
-if (strcmp(interface, "wl_compositor") == 0) {
+if (strcmp(interface, "wl_compositor") == 0 && version >= 4) {
xwl_screen->compositor =
-wl_registry_bind(registry, id, _compositor_interface, 1);
+wl_registry_bind(registry, id, _compositor_interface, 4);
}
else if (strcmp(interface, "wl_shm") == 0) {
xwl_screen->shm = wl_registry_bind(registry, id, _shm_interface, 1);
--
2.19.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2] xwayland: rotate logical size for RRMode
On July 16, 2018 8:50 AM, Olivier Fourdan wrote:
> Hi,
>
> Thanks for your follow up on that!
>
> On Fri, Jul 13, 2018 at 9:51 PM Simon Ser wrote:
> >
> > From: emersion
> >
> > The logical size is the size of the output in the global compositor
> > space. The mode width/height should be scaled as in the logical
> > size, but shouldn't be transformed. Thus we need to rotate back
> > the logical size to be able to use it as the mode width/height.
> >
> > This fixes issues with pointer input on transformed outputs.
> >
> > Signed-Off-By: Simon Ser
> > ---
> >
> > Changes from v1 to v2:
> > - Fixed rotation when xdg-output isn't available
> >
> > I've made sure this works on both rootston (with xdg-output) and
> > Weston (without xdg-output).
> >
> > hw/xwayland/xwayland-output.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> > index 379062549..0d2ec7890 100644
> > --- a/hw/xwayland/xwayland-output.c
> > +++ b/hw/xwayland/xwayland-output.c
> > @@ -213,6 +213,7 @@ apply_output_change(struct xwl_output *xwl_output)
> > {
> > struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
> > struct xwl_output *it;
> > +int mode_width, mode_height;
> > int width = 0, height = 0, has_this_output = 0;
> > RRModePtr randr_mode;
> > Bool need_rotate;
> > @@ -224,7 +225,16 @@ apply_output_change(struct xwl_output *xwl_output)
> > /* xdg-output sends output size in compositor space. so already
> > rotated */
> > need_rotate = (xwl_output->xdg_output == NULL);
> >
> > -randr_mode = xwayland_cvt(xwl_output->width, xwl_output->height,
> > +/* We need to rotate back the logical size for the mode */
> > +if (need_rotate || xwl_output->rotation & (RR_Rotate_0 |
> > RR_Rotate_180)) {
>
> But is it `need_rotate` or `!need_rotate` here?
>
> `need_rotate` being `TRUE` means we don't have xdg-output available,
> in which case we shouldn't have to do this. Basically, we need to
> revert to the original width/height only if we have xdg-output (which
> has already applied the rotation), so I reckon it should be
> `!need_rotate` here.
Yes, except this branch handles the "don't do anything" case: width = width,
height = height. The other branch is when we actually need to rotate.
This variable could probably be renamed to something more sensible (like
`is_logical_size` and invert conditions?).
> > +mode_width = xwl_output->width;
> > +mode_height = xwl_output->height;
> > +} else {
> > +mode_width = xwl_output->height;
> > +mode_height = xwl_output->width;
> > +}
>
> So if we use `(!need_rotate)`, this addition becomes completely
> similar to the code found in `output_get_new_size()` it might be
> interesting to move that to a small helper function, e.g.
> `output_get_transform_size()` that would return the swapped
> width/height depending on the output rotation, so we don't duplicate
> that small portion of code. Nit picking, I know :)
The problem is, `output_get_new_size` needs the logical size and we need the
mode size, so one is swapped and the other isn't. We could still factor those in
a separate function, but I'm afraid this will make things more complicated than
they already are.
> > +
> > +randr_mode = xwayland_cvt(mode_width, mode_height,
> >xwl_output->refresh / 1000.0, 0, 0);
> > RROutputSetModes(xwl_output->randr_output, _mode, 1, 1);
> > RRCrtcNotify(xwl_output->randr_crtc, randr_mode,
> > --
> > 2.18.0
>
> Also, this is something I noticed the hard way some time ago
> (completely unrelated to your patch, though), the width/height
> parameters for `output_get_new_size()` are inverted (`height, width`
> instead of `width, height` as usual) which is error prone (don't ask
> how I noticed...).
>
> I can't see a reason for this everywhere else in the code we use
> `width, height`, I reckon it would be great if we could fix that (in a
> separate patch) as well, while at it... Because things are already
> complicated enough that we don't need to add more confusion by
> changing the well established order of parameters just for the sake of
> it :)
Indeed, will do!
> Cheers,
> Olivier
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Xwayland DPI increases on hotplug
Hi all, Whenever I plug/unplug an output on my compositor, Xwayland's DPI value increases. I've noticed a bug a long time ago in wlroots, and realized I can reproduce in weston too. For instance, when starting `weston --xwayland` this is the DPI: > xdpyinfo | grep dots resolution:96x96 dots per inch When I plug an output: resolution:114x114 dots per inch When I unplug it: resolution:131x131 dots per inch And this is going crazy when the output is a virtual window and I resize it: resolution:-2147483648x-2147483648 dots per inch This is causing issues with some X11 clients (for instance dmenu). However, both the mode size and the physical size are still correct. Do you have any idea where this DPI value is coming from? Thanks, --- Simon Ser https://emersion.fr ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver v2] xwayland: rotate logical size for RRMode
From: emersion
The logical size is the size of the output in the global compositor
space. The mode width/height should be scaled as in the logical
size, but shouldn't be transformed. Thus we need to rotate back
the logical size to be able to use it as the mode width/height.
This fixes issues with pointer input on transformed outputs.
Signed-Off-By: Simon Ser
---
Changes from v1 to v2:
- Fixed rotation when xdg-output isn't available
I've made sure this works on both rootston (with xdg-output) and
Weston (without xdg-output).
hw/xwayland/xwayland-output.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 379062549..0d2ec7890 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -213,6 +213,7 @@ apply_output_change(struct xwl_output *xwl_output)
{
struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
struct xwl_output *it;
+int mode_width, mode_height;
int width = 0, height = 0, has_this_output = 0;
RRModePtr randr_mode;
Bool need_rotate;
@@ -224,7 +225,16 @@ apply_output_change(struct xwl_output *xwl_output)
/* xdg-output sends output size in compositor space. so already rotated */
need_rotate = (xwl_output->xdg_output == NULL);
-randr_mode = xwayland_cvt(xwl_output->width, xwl_output->height,
+/* We need to rotate back the logical size for the mode */
+if (need_rotate || xwl_output->rotation & (RR_Rotate_0 | RR_Rotate_180)) {
+mode_width = xwl_output->width;
+mode_height = xwl_output->height;
+} else {
+mode_width = xwl_output->height;
+mode_height = xwl_output->width;
+}
+
+randr_mode = xwayland_cvt(mode_width, mode_height,
xwl_output->refresh / 1000.0, 0, 0);
RROutputSetModes(xwl_output->randr_output, _mode, 1, 1);
RRCrtcNotify(xwl_output->randr_crtc, randr_mode,
--
2.18.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xwayland: rotate logical size for RRMode
On July 13, 2018 11:18 AM, Olivier Fourdan wrote:
> Hi,
>
> On Wed, Jul 11, 2018 at 9:22 AM Simon Ser wrote:
> >
> > From: emersion
> >
> > The logical size is the size of the output in the global compositor
> > space. The mode width/height should be scaled as in the logical
> > size, but shouldn't be transformed. Thus we need to rotate back
> > the logical size to be able to use it as the mode width/height.
> >
> > This fixes issues with pointer input on transformed outputs.
> >
> > Signed-Off-By: Simon Ser
> > ---
> > This supersedes my previous patch [1], and rotates the logical size
> > instead of using the raw wl_output mode (so that scaling still
> > works).
> >
> > [1]: https://lists.x.org/archives/xorg-devel/2018-July/057285.html
> >
> > hw/xwayland/xwayland-output.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> > index 379062549..26e055867 100644
> > --- a/hw/xwayland/xwayland-output.c
> > +++ b/hw/xwayland/xwayland-output.c
> > @@ -213,6 +213,7 @@ apply_output_change(struct xwl_output *xwl_output)
> > {
> > struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
> > struct xwl_output *it;
> > +int mode_width, mode_height;
> > int width = 0, height = 0, has_this_output = 0;
> > RRModePtr randr_mode;
> > Bool need_rotate;
> > @@ -224,7 +225,16 @@ apply_output_change(struct xwl_output *xwl_output)
> > /* xdg-output sends output size in compositor space. so already
> > rotated */
> > need_rotate = (xwl_output->xdg_output == NULL);
> >
> > -randr_mode = xwayland_cvt(xwl_output->width, xwl_output->height,
> > +/* We need to rotate back the logical size for the mode */
> > +if (xwl_output->rotation & (RR_Rotate_0 | RR_Rotate_180)) {
> > +mode_width = xwl_output->width;
> > +mode_height = xwl_output->height;
> > +} else {
> > +mode_width = xwl_output->height;
> > +mode_height = xwl_output->width;
> > +}
>
> But shouldn't this check `need_rotate` as well?
>
> I mean, we should not do this in the case of `xdg-output` not being available.
Ah, you're right. Will send a patch to fix that, and will make sure it
works in Weston (which doesn't implement xdg-output).
> > +
> > +randr_mode = xwayland_cvt(mode_width, mode_height,
> >xwl_output->refresh / 1000.0, 0, 0);
> > RROutputSetModes(xwl_output->randr_output, _mode, 1, 1);
> > RRCrtcNotify(xwl_output->randr_crtc, randr_mode,
> > --
>
> This is where I get surprised, because if I understand the problem,
> you where stating that the pointer events stopped working below a
> certain limit.
Yeah. Events per se still work, but the y axis gets stuck at half of
the screen (so clicking at the 3/4 of the screen will actually trigger
a click in the middle of the screen).
> Those are limited by the actual “screen size” as set by
> `update_desktop_dimensions()` at the end of `update_screen_size()`, I
> don't see how changing the size passed to compute the randr mode will
> help with the bug you're trying to address here...
The screen size is indeed correct, but there are two more pieces of
information: the mode size and the output logical size. It seems to me
that the logical size is computed by X11 from the mode size and output
transform (see my previous email [1]). I'm also not an X11 expert and
don't know how the logical size participates in input events handling,
but I do get bad input events with a wrong logical size and setting a
correct logical size fixes it.
[1]: https://lists.x.org/archives/xorg-devel/2018-July/057292.html
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xwayland: don't use logical size for RRMode
On July 10, 2018 8:44 AM, Olivier Fourdan wrote: > Yeap, that's what I meant, xdg-output would advertise the logical size > (i.e. appropriately scaled), so we want to pass RR the values provided > by xdg-output here, not those from wl_output. > > Basically, we do not need to keep or reuse the mode_width/height as > with your initial patch, we just need to compensate the rotation as > you said (as for the rationale behind this bug, mutter doesn't use > rotations, so I didn't notice it). Right. Just sent another patch which does that. I just thought it was weird to use the logical size for the mode, but it makes sense since X11 doesn't support scaling. > [unrelated, as an aside, it looks like in your example, the compositor > might not be sending the geometry, so we end up with 0 in the physical > size] Yes, that's intentional. When the physical size isn't available (e.g. when using projectors or virtual outputs) we just send zero. Do you think this is harmful? I like sending zero because it clearly says "this piece of information is not relevant in the current situation" instead of faking data. Maybe Xwayland should fake it and use a default 96 DPI in this case? I'm not aware of any X11 client that breaks because of this (yet). > Cheers, > Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] xwayland: rotate logical size for RRMode
From: emersion
The logical size is the size of the output in the global compositor
space. The mode width/height should be scaled as in the logical
size, but shouldn't be transformed. Thus we need to rotate back
the logical size to be able to use it as the mode width/height.
This fixes issues with pointer input on transformed outputs.
Signed-Off-By: Simon Ser
---
This supersedes my previous patch [1], and rotates the logical size
instead of using the raw wl_output mode (so that scaling still
works).
[1]: https://lists.x.org/archives/xorg-devel/2018-July/057285.html
hw/xwayland/xwayland-output.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 379062549..26e055867 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -213,6 +213,7 @@ apply_output_change(struct xwl_output *xwl_output)
{
struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
struct xwl_output *it;
+int mode_width, mode_height;
int width = 0, height = 0, has_this_output = 0;
RRModePtr randr_mode;
Bool need_rotate;
@@ -224,7 +225,16 @@ apply_output_change(struct xwl_output *xwl_output)
/* xdg-output sends output size in compositor space. so already rotated */
need_rotate = (xwl_output->xdg_output == NULL);
-randr_mode = xwayland_cvt(xwl_output->width, xwl_output->height,
+/* We need to rotate back the logical size for the mode */
+if (xwl_output->rotation & (RR_Rotate_0 | RR_Rotate_180)) {
+mode_width = xwl_output->width;
+mode_height = xwl_output->height;
+} else {
+mode_width = xwl_output->height;
+mode_height = xwl_output->width;
+}
+
+randr_mode = xwayland_cvt(mode_width, mode_height,
xwl_output->refresh / 1000.0, 0, 0);
RROutputSetModes(xwl_output->randr_output, _mode, 1, 1);
RRCrtcNotify(xwl_output->randr_crtc, randr_mode,
--
2.18.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xwayland: don't use logical size for RRMode
On July 9, 2018 3:42 PM, Olivier Fourdan wrote: > So, can you please elaborate exactly what this is supposed to fix and > how to reproduce the issue? I've configured my compositor with a 90 degree output rotation. Here are the values sent by my compositor, as received by xwayland: output_handle_mode 1600 850 xdg_output_handle_logical_size 850 1600 As far as I can tell this is correct. Without this patch, if I open for instance Firefox, pointer events are correctly handled if the pointer is in the top half of the screen, but when the pointer moves in the bottom part the Y axis coordinate gets stuck. Here's xrandr's output: Screen 0: minimum 320 x 200, current 850 x 1600, maximum 8192 x 8192 XWAYLAND0 connected 1600x848+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm 848x1600 59.95*+ This patch fixes this bug. Here's xrandr's output: Screen 0: minimum 320 x 200, current 850 x 1600, maximum 8192 x 8192 XWAYLAND0 connected 850x1600+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm 1600x850 59.92*+ Notice the difference between the logical geometry (850x1600+0+0) and the current mode (1600x850). I just noticed this patch breaks HiDPI outputs (xrandr advertises a 850x1600+0+0 logical geometry). We might want to use the logical size for RRMode, but compensate transformations. What do you think? Thanks, Simon ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] xwayland: don't use logical size for RRMode
The logical size is the size of the output in the global compositor
space. The mode width/height shouldn't be transformed and scaled.
This fixes issues with pointer input on transformed outputs.
Signed-Off-By: Simon Ser
---
hw/xwayland/xwayland-output.c | 9 ++---
hw/xwayland/xwayland.h| 3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 379062549..44fd5c26a 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -113,12 +113,15 @@ output_handle_mode(void *data, struct wl_output
*wl_output, uint32_t flags,
if (!(flags & WL_OUTPUT_MODE_CURRENT))
return;
+xwl_output->mode_width = width;
+xwl_output->mode_height = height;
+xwl_output->mode_refresh = refresh;
+
/* Apply the change from wl_output only if xdg-output is not supported */
if (!xwl_output->xdg_output) {
xwl_output->width = width;
xwl_output->height = height;
}
-xwl_output->refresh = refresh;
}
static inline void
@@ -224,8 +227,8 @@ apply_output_change(struct xwl_output *xwl_output)
/* xdg-output sends output size in compositor space. so already rotated */
need_rotate = (xwl_output->xdg_output == NULL);
-randr_mode = xwayland_cvt(xwl_output->width, xwl_output->height,
- xwl_output->refresh / 1000.0, 0, 0);
+randr_mode = xwayland_cvt(xwl_output->mode_width, xwl_output->mode_height,
+ xwl_output->mode_refresh / 1000.0, 0, 0);
RROutputSetModes(xwl_output->randr_output, _mode, 1, 1);
RRCrtcNotify(xwl_output->randr_crtc, randr_mode,
xwl_output->x, xwl_output->y,
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index d70ad54bf..66daf58de 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -368,7 +368,8 @@ struct xwl_output {
struct xwl_screen *xwl_screen;
RROutputPtr randr_output;
RRCrtcPtr randr_crtc;
-int32_t x, y, width, height, refresh;
+int32_t x, y, width, height;
+int32_t mode_width, mode_height, mode_refresh;
Rotation rotation;
Bool wl_output_done;
Bool xdg_output_done;
--
2.18.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
