Re: How to support mixed DPI in Xwayland?

[Adam Jackson]

On Thu, 2017-09-07 at 12:17 -0400, Olivier Fourdan wrote:

> But we dismissed that solution, having different X11 screens is not very
> practical, mutter does not support multiple screens for a start, and 
> things like drag'n drop, copy/paste, root properties, etc. all would
> become quite complicated very quickly when dealing with multiple screens...

metacity certainly used to support multiple screens, so having taken a
feature out and then thinking it too hard to put back in is perhaps a
self-inflicted injury.

One possibility could be to expose the hi- and lo-dpi root windows as
different _displays_, listening on different sockets, and rewriting
geometry depending which one you're on (while otherwise having the same
set of windows, properties, devices...). Keith wrote a pseudo-root
extension along similar lines long ago [1], though that didn't make any
effort at rescaling, just subsetting.

One other problem with rescaling is what to do if graphics commands
cross logical displays. If I GetImage from a hidpi window on a lodpi
client, who's going to do the downscaling?

Another possibility could be just running more than one Xwayland
server, each with different DPI configurations; the compositor is going
to handle final presentation anyway, so this requires many fewer server
changes. But, a window manager that can't even deal with multiple
screens is probably also going to have problems with multiple displays,
and the wayland half of its brain would need to handle proxying
clipboard and friends between both servers.

> The other solution would be to have the same screen, but have Xwayland to
> give different scaling conversions for root window size, screen size, events
> coordinates, etc. depending on the client, if it's HiDPI aware or not,
> some sort of a "hidden" screen.

Root window size is only ever sent during the initial connection
handshake, and the client extension libraries don't update it when the
root window is reconfigured [2]. So we have a bootstrapping problem:
how is the X server supposed to know which set of lies to give the
client when it connects? If you have multiple displays (either logical
views or whole processes) then you decide this when you connect, and
remote X apps [3] have an obvious way to pick the right one.

One more possibility would be bumping the X protocol itself so the
client can express this kind of preference in the connection handshake
[4]. Doing that requires that you upgrade your clients (or at least
your toolkits) to do additional setup before connecting, or use an API
other than XOpenDisplay.

It'll be a decent amount of work any way you slice it, tbh.

One thing I've never really been thrilled with about the Xwayland
design is that the wayland compositor wants also to be the X window
manager, and that all the related state about window position and
whatnot is just internal to the compositor. xwin and xquartz don't have
this problem, you can run twm as your window manager and still move
windows, but in xwayland that doesn't work because wayland refuses to
allow you to position your own window for (what I consider) essentially
religious reasons [5]. And as a result the compositor gets a lot more
complicated and you _still_ need to change the X server to get things
to work. What I'd have preferred is a wl_x11_interop protocol that
Xwayland could use to send this kind of advisory state, which mutter
could optionally only expose to Xwayland if it really wanted to be less
functional than X.

[1] - https://keithp.com/~keithp/talks/proot.tar.gz

[2] - Even if they did, because libX11 is some of 1988's finest
engineering, things like DisplayWidth() are just macros that
dereference fields in the Display*, so updating them dynamically would
be hoping that the compiler didn't optimize away multiple loads of the
same field, and that the toolkit/app haven't cached them anywhere. We
could try anyway, and maybe that'd be good enough for xterm...

[3] - Still a thing! But even neglecting that, you have to set $DISPLAY
to something to get apps to launch from the command line; gnome-shell
is not going to be the only thing that starts clients, so inspecting
.desktop files or the link map of the binary is not going to be
sufficient in general.

[4] - I think you could get away with simply adding more authentication
class data before you get to the MIT-MAGIC-COOKIE bit, and have that
class always succeed and just record client capabilities, rather than
trying to define version 11.1 of the protocol. Which is good, because
11.1 would require you to update libX11/libxcb to make it work, and
that'd make it tough to upscale that old copy of Netscape running on
your IRIX machine.

[5] - They'd be hints in any case, the wayland server is entirely free
to ignore them. They're already hints in X because windows are managed,
so that's not actually different.

- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: Why isn't Xwayland just a Wayland client?

[Joseph Burt]

Hi all,

On Wed, Sep 6, 2017 at 1:09 PM, Daniel Stone  wrote:
>
> I really wouldn't recommend doing this.

On Thu, Sep 7, 2017 at 10:05 AM, Pekka Paalanen  wrote:
>
> I kind of wish I shared your optimism, but I'm thinking more of a death
> by a thousand papercuts kind of situation, not a single big failure
> point.
>
> I'd be screaming in delight and joy if someone proved it is possible to
> turn Xwayland into just a regular Wayland client that has no special
> privileges nor requires any nasty Wayland extensions.

Alright, I'm hearing a consensus of: worthwhile if possible, but
probably unpleasant, somewhere between fiddly and very painful. I'll
hack a bit at the problem and see how much it hurts.

Thank you all,
Joseph
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/6] libweston: Support multiple seats better

[Emil Velikov]

Hi nerdopolis,

I'm mostly an outsider here, so just sharing some observations.

On 6 September 2017 at 13:17, nerdopolis  wrote:
> I am resending as I messed up one of the commit messages, which resulted
> in a very long subject by mistake. These patches fix issues with Weston
> where it supports multiple seats better.
>
Please set your name in git config. I don't know what wayland's stance
is on real names vs nick, personally I think that using a real one
indicates the openness towards the project.

Apart from 4/6 none of the 5 other patches has any commit message. I
recommend reading this post [1] about the importance of one.

[1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html

> Firstly supporting automatically detecting the seat to use, by using the
> XDG_SEAT variable set by logind if the --seat option is not specified.
>
> And then improving the fbdev-backend to support the --seat option and
> not hard use seat0
>
> And then to not have weston try to use a TTY when it's not running
> on seat0, as only seat0 can have TTYs
>
> And also attempt to turn on a framebuffer device on, as many secondary
> video cards that support DRM/KMS, such as qemu's bochs, and udl start
> off powered off, and don't turn on the screens until the ioctl is sent
>
> Then finally, make the fbdev-backend detect the first framebuffer device
> assigned to the current seat with udev (I based that largely off of some
> of drm-backend)
>
Speaking of which ... some of this sounds like it should be part of
the respective patches.

HTH
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

How to support mixed DPI in Xwayland?

[Olivier Fourdan]

Hi all,

For quite some time now [1] we've been trying to figure out a way to have
mixed DPI, both non-HiDPI capable X11 clients (e.g. xterm) and HiDPI aware
X11 clients coexists on Xwayland.

Typically, the compositor would scale the surface for xterm when on a HiDPI
monitor, but would leave another HiDPI aware client's surface unscaled to
achieve best results (as the client is HiDPI aware).

Problem, when scaling up the client buffer, the Xwayland screen size needs
to be scaled down accordingly, so that a client wishing to size or locate
its toplevel window based on the output size gets the correct size and
location once the surface is mapped on screen by the compositor.

So, we need to advertise different screen sizes (via Width//HeightOfScreen(),
Xrandr, Xvidmode, whatever) to different clients, depending on whether or
not those clients are HiDPI capable.

During GUADEC, we had some discussions with Jonas and Carlos, involving
Peter as well trying to evaluate the level of insanity of the various
solutions being considered.

One solution was to have two different "Screens" (in X11 terms) coexisting,
with a new X11 extension in place so that HiDPI aware clients would connect
to a screen that advertise the HiDPI "version" of the screen whereas the
no-HiDPI aware would connect to a different screen of the same display.

But we dismissed that solution, having different X11 screens is not very
practical, mutter does not support multiple screens for a start, and 
things like drag'n drop, copy/paste, root properties, etc. all would
become quite complicated very quickly when dealing with multiple screens...

The other solution would be to have the same screen, but have Xwayland to
give different scaling conversions for root window size, screen size, events
coordinates, etc. depending on the client, if it's HiDPI aware or not,
some sort of a "hidden" screen.

Ajax, Keith, what's your take on such an approach, is that even doable based
on your knowledge of the Xserver internals? Or do you see any better/simpler
idea?

Cheers,
Olivier

[1] https://bugs.freedesktop.org/show_bug.cgi?id=93315
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xserver 2/2] xwayland: apply output scale to monitor resolution

[Olivier Fourdan]

Weston scales Xwayland surfaces by the output scale, meaning that an
X11 client mapping a window on size (W x H) will actually be:

   (W x size) x (H x size)

However, Xwayland ignores the output scale factor when advertising the
monitor size and resolution meaning that an X11 client trying to size
its window based on the Xrandr reported monitor size will end up with
the wrong size for any scale different from 1.

Downscale each output size by its output scale so that the reported
monitor resolution in both Xrandr and Xvidmode can be used as a size for
X11 clients (since those will be scaled up by the compositor).

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland-output.c | 8 ++--
 hw/xwayland/xwayland.h| 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index a504d2595..ee9a29f4a 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -113,8 +113,8 @@ output_handle_mode(void *data, struct wl_output *wl_output, 
uint32_t flags,
 
 /* 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->width = width / xwl_output->scale;
+xwl_output->height = height / xwl_output->scale;
 }
 xwl_output->refresh = refresh;
 }
@@ -268,6 +268,9 @@ output_handle_done(void *data, struct wl_output *wl_output)
 static void
 output_handle_scale(void *data, struct wl_output *wl_output, int32_t factor)
 {
+struct xwl_output *xwl_output = data;
+
+xwl_output->scale = factor;
 }
 
 static const struct wl_output_listener output_listener = {
@@ -339,6 +342,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
 snprintf(name, sizeof name, "XWAYLAND%d", serial++);
 
 xwl_output->xwl_screen = xwl_screen;
+xwl_output->scale = 1;
 xwl_output->randr_crtc = RRCrtcCreate(xwl_screen->screen, xwl_output);
 if (!xwl_output->randr_crtc) {
 ErrorF("Failed creating RandR CRTC\n");
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 510d65e3c..f0cec07da 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -265,7 +265,7 @@ 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, refresh, scale;
 Rotation rotation;
 Bool wl_output_done;
 Bool xdg_output_done;
-- 
2.13.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xserver 0/2] Add xdg-output support

[Olivier Fourdan]

Hi,

This is actually the 3rd iteration of the xdg-output support patch for
Xwayland.

Changes in this iteration include obvious bug fixes (like binding to the
correct interface actually helps...) and other more important fixes like
waiting for both wl_output and xdg-output done events before actually
applying the output logical size.

This was tested with the xdg-output patches in mutter from GNOME bug:

https://bugzilla.gnome.org/show_bug.cgi?id=787363

With fractional scaling, xrandr in Xwayland reports the logical size
whereas weston-info reports the wl_output size and rotation as expected.

As a corollary, using xdg-output in Xwayland allows us to take the
wl_output scale when computing the output size from Xwayland point of
view, so that it also works out of the box with weston and kwin. However,
merging this second patch in Xwayland without the support for xdg-output
in mutter would break mutter as the screen size would be wrong in
gnome-shell/mutter with Xwayland.

Cheers,
Olivier

Olivier Fourdan (2):
  xwayland: Add optional xdg-output support
  xwayland: apply output scale to monitor resolution

 configure.ac  |   2 +-
 hw/xwayland/Makefile.am   |   9 +++-
 hw/xwayland/meson.build   |   2 +
 hw/xwayland/xwayland-output.c | 123 ++
 hw/xwayland/xwayland.c|   5 ++
 hw/xwayland/xwayland.h|  10 +++-
 meson.build   |   2 +-
 7 files changed, 139 insertions(+), 14 deletions(-)

-- 
2.13.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v3 xserver 1/2] xwayland: Add optional xdg-output support

[Olivier Fourdan]

The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).

This was added in wayland-protocols 1.10.

Signed-off-by: Olivier Fourdan 
---
 configure.ac  |   2 +-
 hw/xwayland/Makefile.am   |   9 +++-
 hw/xwayland/meson.build   |   2 +
 hw/xwayland/xwayland-output.c | 119 ++
 hw/xwayland/xwayland.c|   5 ++
 hw/xwayland/xwayland.h|   8 +++
 meson.build   |   2 +-
 7 files changed, 134 insertions(+), 13 deletions(-)

diff --git a/configure.ac b/configure.ac
index eee1257a9..3f4206727 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2350,7 +2350,7 @@ AM_CONDITIONAL(XEPHYR, [test "x$KDRIVE" = xyes && test 
"x$XEPHYR" = xyes])
 
 dnl Xwayland DDX
 
-XWAYLANDMODULES="wayland-client >= 1.3.0 wayland-protocols >= 1.9 $LIBDRM 
epoxy"
+XWAYLANDMODULES="wayland-client >= 1.3.0 wayland-protocols >= 1.10 $LIBDRM 
epoxy"
 if test "x$XF86VIDMODE" = xyes; then
XWAYLANDMODULES="$XWAYLANDMODULES $VIDMODEPROTO"
 fi
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index eda49799e..7204591e3 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -59,7 +59,10 @@ Xwayland_built_sources +=
\
tablet-unstable-v2-client-protocol.h\
tablet-unstable-v2-protocol.c   \
xwayland-keyboard-grab-unstable-v1-protocol.c   \
-   xwayland-keyboard-grab-unstable-v1-client-protocol.h
+   xwayland-keyboard-grab-unstable-v1-client-protocol.h\
+   xdg-output-unstable-v1-protocol.c   \
+   xdg-output-unstable-v1-client-protocol.h
+
 
 nodist_Xwayland_SOURCES = $(Xwayland_built_sources)
 CLEANFILES = $(Xwayland_built_sources)
@@ -91,6 +94,10 @@ xwayland-keyboard-grab-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/uns
$(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
 xwayland-keyboard-grab-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
+xdg-output-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
+   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+xdg-output-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
+   $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 %-protocol.c : %.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index b619a66a7..658483aca 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -19,6 +19,7 @@ pointer_xml = join_paths(protodir, 'unstable', 
'pointer-constraints', 'pointer-c
 relative_xml = join_paths(protodir, 'unstable', 'relative-pointer', 
'relative-pointer-unstable-v1.xml')
 tablet_xml = join_paths(protodir, 'unstable', 'tablet', 
'tablet-unstable-v2.xml')
 kbgrab_xml = join_paths(protodir, 'unstable', 'xwayland-keyboard-grab', 
'xwayland-keyboard-grab-unstable-v1.xml')
+xdg_output_xml = join_paths(protodir, 'unstable', 'xdg-output', 
'xdg-output-unstable-v1.xml')
 
 client_header = generator(scanner,
 output : '@BASENAME@-client-protocol.h',
@@ -36,6 +37,7 @@ srcs += code.process(relative_xml)
 srcs += code.process(pointer_xml)
 srcs += code.process(tablet_xml)
 srcs += code.process(kbgrab_xml)
+srcs += code.process(xdg_output_xml)
 
 xwayland_glamor = []
 if gbm_dep.found()
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 460caaf56..a504d2595 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -93,9 +93,12 @@ output_handle_geometry(void *data, struct wl_output 
*wl_output, int x, int y,
 physical_width, physical_height);
 RROutputSetSubpixelOrder(xwl_output->randr_output,
  wl_subpixel_to_xrandr(subpixel));
-xwl_output->x = x;
-xwl_output->y = y;
 
+/* Apply the change from wl_output only if xdg-output is not supported */
+if (!xwl_output->xdg_output) {
+xwl_output->x = x;
+xwl_output->y = y;
+}
 xwl_output->rotation = wl_transform_to_xrandr(transform);
 }
 
@@ -108,18 +111,22 @@ output_handle_mode(void *data, struct wl_output 
*wl_output, uint32_t flags,
 if 

[weston 1/1] calibrator: Make mouse button optional

[Fabien Lahoudere]

When calibrating touchscreen with weston-calibrator, you can use the mouse to
click on the cross which is recorded as a touch event. This event is used to
compute the final calibration of the touchscreen which results in invalid
touchscreen calibration and broken touchscreen behaviour.

In order to avoid to use the mouse in weston-calibrator, we disable mouse
operation by default and add a parameter "--enable-mouse" to enable it.

Signed-off-by: Fabien Lahoudere 
---
 clients/calibrator.c | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/clients/calibrator.c b/clients/calibrator.c
index 04c1cfc..778c23c 100644
--- a/clients/calibrator.c
+++ b/clients/calibrator.c
@@ -24,12 +24,14 @@
 #include "config.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -218,7 +220,7 @@ redraw_handler(struct widget *widget, void *data)
 }
 
 static struct calibrator *
-calibrator_create(struct display *display)
+calibrator_create(struct display *display, bool enable_button)
 {
struct calibrator *calibrator;
 
@@ -233,7 +235,8 @@ calibrator_create(struct display *display)
 
calibrator->current_test = ARRAY_LENGTH(test_ratios) - 1;
 
-   widget_set_button_handler(calibrator->widget, button_handler);
+   if (enable_button)
+   widget_set_button_handler(calibrator->widget, button_handler);
widget_set_touch_down_handler(calibrator->widget, touch_handler);
widget_set_redraw_handler(calibrator->widget, redraw_handler);
 
@@ -250,13 +253,40 @@ calibrator_destroy(struct calibrator *calibrator)
free(calibrator);
 }
 
+static void
+help(const char *name)
+{
+   fprintf(stderr, "Usage: %s [args...]\n", name);
+   fprintf(stderr, "  -m, --enable-mouse   Enable mouse for testing 
the touchscreen\n");
+   fprintf(stderr, "  -h, --help  Display this help message\n");
+}
 
 int
 main(int argc, char *argv[])
 {
struct display *display;
struct calibrator *calibrator;
-
+   int c;
+   bool enable_mouse = 0;
+   struct option opts[] = {
+   { "enable-mouse", no_argument, NULL, 'm' },
+   { "help",no_argument,   NULL, 'h' },
+   { 0, 0, NULL,  0  }
+   };
+
+   while ((c = getopt_long(argc, argv, "mh", opts, NULL)) != -1) {
+   switch (c) {
+   case 'm':
+   enable_mouse = 1;
+   break;
+   case 'h':
+   help(argv[0]);
+   exit(EXIT_FAILURE);
+   default:
+   break;
+   }
+   }
+   
display = display_create(, argv);
 
if (display == NULL) {
@@ -264,7 +294,7 @@ main(int argc, char *argv[])
return -1;
}
 
-   calibrator = calibrator_create(display);
+   calibrator = calibrator_create(display, enable_mouse);
 
if (!calibrator)
return -1;
-- 
1.8.3.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Why isn't Xwayland just a Wayland client?

[Pekka Paalanen]

On Wed, 6 Sep 2017 21:05:33 +0200
Joseph Burt  wrote:

> On Wed, Sep 6, 2017 at 4:45 PM, Pekka Paalanen  wrote:
> > Popups (e.g. menus) in Wayland use protocol that provides the server
> > with:
> > - the relationship to the window which the popup is for, and
> > - the input event identity that triggered the popup.
> >
> > These are required on Wayland: the parent window is required for
> > positioning and stacking, and the input event identity determines
> > whether the popup is valid.
> >
> > X11 protocol does not necessarily provide these. On X11, the client
> > puts a window at x,y and makes an input grab. That's it.
> >
> > You would have to infer from x,y and the X11 window stack which X11
> > window might be the parent (if it even exists) and guess what input
> > event might have triggered the popup (there might not be any) to be
> > able to translate that into Wayland.
> >
> > Xwayland would also need to guess that the input grab is related to
> > showing the window to be able to combine the two actions into a popup
> > request on Wayland.
> >
> > I hope this gives you an idea why it is so hard to try to translate
> > window management from X11 to Wayland protocol. Writing an X11 window
> > manager is extremely painful to begin with, making one that can
> > translate into Wayland is much more painful because of the fundamental
> > design differences. The "out-of-band" design of putting an X11 WM in a
> > Wayland compositor and using X11 to manage X11 windows is the
> > compromise to get things working.  
> 
> You're absolutely right, X clients will never use Wayland's builtin
> popup and transient logic, and with all of X's quirks, there will
> always have to be an X server somewhere.

I really meant that Xwayland, the X server, *is* the translator. I
believed that I explained why it is extremely difficult to make
Xwayland internally translate X11 to Wayland without adding Xwayland
specific protocol extensions to Wayland. Doing so requires coding
heuristics and policy into Xwayland, which is something generally
avoided in X servers I believe.

Still, I don't claim it's impossible or should never be done, I'm just
saying it will be much harder to implement than the current situation
where people already have a working X11 WM in their project, and
perhaps requires a Wayland extension going against Wayland design
principles for the translating X server alone.

In the current model, all the violations to Wayland design principles
are internal implementation details of a Wayland compositor acting as
the X11 WM.

> Where does the whole construction fail if the little bit of XWM logic
> is in Xwayland? Going a little farther, I'm imagining toplevel X
> client windows, clients isolated or not, arranged in the (essentially
> arbitrary and virtual) X coordinate space such that none overlap, each
> corresponding with a wl_surface, with everything on top done by the X
> server and/or via subsurfaces. That leaves the little WM shim dealing
> with decoration if required, close, resize, and grabs. How the
> compositor positions or stacks is irrelevant.

I kind of wish I shared your optimism, but I'm thinking more of a death
by a thousand papercuts kind of situation, not a single big failure
point.

I'd be screaming in delight and joy if someone proved it is possible to
turn Xwayland into just a regular Wayland client that has no special
privileges nor requires any nasty Wayland extensions.


Thanks,
pq


pgpFfODZpZ4YN.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Why isn't Xwayland just a Wayland client?

[Joseph Burt]

On Thu, Sep 7, 2017 at 9:43 AM, Carsten Haitzler  wrote:
> It doesn't have to be specified in the protocol. It is what every compositor
> does because everyone agreed early on that CSD is the default. Weston did it
> then everyone else did it. To be compatible everyone stayed the same. They 
> have
> to. Kwin guys disagreed but they couldn't change the default (so they added
> more protocol to negotiate decorations).
>
> A compositor will NOT decorate windows unless as per above. It doesn't have to
> be put in protocol specs to be a hard fact of life in Wayland.

I take that as "all discussions of how or whether anything gets
decorated have nothing to do with the protocol." Sounds good to me.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Why isn't Xwayland just a Wayland client?

[The Rasterman]

On Thu, 7 Sep 2017 08:17:29 +0200 Joseph Burt  said:

> On Thu, Sep 7, 2017 at 1:17 AM, Carsten Haitzler  wrote:
> >
> > It is CSD in Wayland for Wayland clients, unless somehow compositor and
> > client negotiate something else. In the default case, if a client does not
> > decorate it will not get any decorations (titlebar and so on) at all.
> 
> IIRC that's not specified in the protocol, just what Weston does, and
> there's no negotiation protocol. Am I wrong? That might be a hole in
> Wayland, but not really related to Xwayland, so I guess off-topic
> here.

It doesn't have to be specified in the protocol. It is what every compositor
does because everyone agreed early on that CSD is the default. Weston did it
then everyone else did it. To be compatible everyone stayed the same. They have
to. Kwin guys disagreed but they couldn't change the default (so they added
more protocol to negotiate decorations).

A compositor will NOT decorate windows unless as per above. It doesn't have to
be put in protocol specs to be a hard fact of life in Wayland.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libinput 1.8.2

[Peter Hutterer]

libinput 1.8.2 is now available. Philip's two patches fix the build against
older kernel headers. The rest aren't anything specific to point out,
they're just fixes in various bits of libinput. The only change in
experience is that 2-slot touchpads (e.g. most Lenovos pre kernel 4.12) do
not support 3fg pinch anymore - instead we assume swipe for three fingers
which makes gestures a lot more reliable. And 3-finger swipe is much more
common than 3-finger pinch anyway.

Jussi Kukkonen (1):
  tools: Fix race in (autotools) install

Peter Hutterer (7):
  evdev: recover from a lost button count
  timer: if a timer is inactive, do not call the timer func
  timer: always restart the timer loop when we called one of them
  lid: disable all types but EV_SYN and EV_SW
  gestures: don't try to pinch for nfingers > slots
  test: add the gpio-keys device to the Makefile
  configure.ac: libinput 1.8.2

Philip Withnall (2):
  build: Add -Iinclude to libinput and its tools
  build: Add -Iinclude to unit tests

git tag: 1.8.2

https://www.freedesktop.org/software/libinput/libinput-1.8.2.tar.xz
MD5:  e94e9aa765da9533c23b80b440638de9  libinput-1.8.2.tar.xz
SHA1: 1c55462eb598b91c9c360f31170a408fb8d38d22  libinput-1.8.2.tar.xz
SHA256: 013518ee0adb2287e6e1f08412efba2137320738cadb5399b783738f04cbab38  
libinput-1.8.2.tar.xz
SHA512: 
555a7680cc8aaf62c5370a865f3aff0a933d42d94a3d8861c072666b02c9e1be45ea39de9a749a9575cdfb613b6150e412e18559d94d4919f21ca4680a3c76a7
  libinput-1.8.2.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.8.2.tar.xz.sig



signature.asc
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Why isn't Xwayland just a Wayland client?

[Joseph Burt]

On Thu, Sep 7, 2017 at 1:17 AM, Carsten Haitzler  wrote:
>
> It is CSD in Wayland for Wayland clients, unless somehow compositor and client
> negotiate something else. In the default case, if a client does not decorate 
> it
> will not get any decorations (titlebar and so on) at all.

IIRC that's not specified in the protocol, just what Weston does, and
there's no negotiation protocol. Am I wrong? That might be a hole in
Wayland, but not really related to Xwayland, so I guess off-topic
here.

Cheers,
Joseph
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel