Re: Window scaling (aka owner sizes)
Olivier Fourdan writes: > How do you plan to deal with this in your approach? Well, that's why I'm trying to get some help here... What we're trying to do here is replace some really ugly hacks that Valve has made outside of the server to get applications that depend on changing the video mode to make the application look reasonable. As changing video modes isn't a good idea in 2018, Valve has written a compositing manager which scales applications for output (which only works for scaling up), and then does pretty ugly things to get mouse input 'mostly working' -- grabbing the mouse and generating synthetic events for the application. Yikes! Oh, and it captures attempts to set video modes. The proposed hacks are already *way* better than that and make these applications work much better. There's still more to do, and I'll be working on those bits too (like redirecting video mode settings somehow). The root window size shouldn't be all that interesting to applications; they really need to know the monitor sizes and positions, and that information is available via RandR and Xinerama. So, I'm not all that concerned about root window size; applications relying on that are already broken. Ok, so to make this 'actually' work, I might have to scale not only the window size, but the window position as well -- and then I might actually have to scale *all* of the window sizes and positions for the specified application. Or, maybe we create a synthetic monitor and then pretend to applications that their windows appear there instead. > PS: When considering this for Xwayland, I ended up thinking that it > would be actually easier to have different X11 screens (i.e. :0.0, > :0.1, etc.) of different size for different scales for the X11 clients > ended up being scaled differently (which led me to > https://gitlab.freedesktop.org/ofourdan/xserver/tree/xwayland-multi-screen), > but that approach introduces a lot of complexity (the CM has to play > the proxy between all those X11 screens for things like copy/paste, > DnD, etc.) Yeah, X screens are probably not what you want. An X monitor might be reasonable; those are visible in RandR and Xinerama, but leave applications on the same screen. I didn't want to change the owner position of the windows, but I now wonder if that might not turn out ok? -- -keith signature.asc Description: PGP signature ___ 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] hw/xwin: Fix 'make distcheck'
On Mon, Aug 27, 2018 at 12:41:22PM +0100, Jon Turney wrote: > Add internal.h to SOURCES, omitted from 126c1cfa > > Signed-off-by: Jon Turney cd285922c..a9a5bd002 master -> master Cheers, Peter > --- > hw/xwin/winclipboard/Makefile.am | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/xwin/winclipboard/Makefile.am > b/hw/xwin/winclipboard/Makefile.am > index a1079aec6..bfd302413 100644 > --- a/hw/xwin/winclipboard/Makefile.am > +++ b/hw/xwin/winclipboard/Makefile.am > @@ -1,6 +1,7 @@ > noinst_LTLIBRARIES = libXWinclipboard.la > > libXWinclipboard_la_SOURCES = \ > + internal.h \ > winclipboard.h \ > textconv.c \ > thread.c \ > -- > 2.17.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 > ___ 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: Xorg-1.20.1 crashes when using glamor on top of llvmpipe
hi,
what version of mesa?
might be
https://cgit.freedesktop.org/mesa/mesa/commit/?id=9baff597ce021f7691187b0d1d1bbc16d07b13e1
Ray
On Thu, Aug 30, 2018, 5:00 PM Hans de Goede wrote:
> Hi,
>
> On 30-08-18 22:48, Hans de Goede wrote:
> > HI all,
> >
> > I've been debugging some strange crashes with Xorg-1.20.1 inside
> > a virtualbox guest and I can use some help with this.
> >
> > At first Xorg completely failed to start, running it under
> > gdbserver showed a backtrace pointing to a lazy symbol lookup
> > failure triggered by:
> >
> > drmmode_display.c:905:
> > return gbm_bo_get_stride(bo->gbm);
> >
> > Which is part of:
> >
> >
> > uint32_t
> > drmmode_bo_get_pitch(drmmode_bo *bo)
> > {
> > #ifdef GLAMOR_HAS_GBM
> > if (bo->gbm)
> > return gbm_bo_get_stride(bo->gbm);
> > #endif
> >
> > return bo->dumb->pitch;
> > }
> >
> > Strange enough a LD_PRELOAD of libgbm does not
> > fix this and libgbm already gets dragged in by
> > libglamor_egl.so so this should not be a problem.
> >
> > Still I tried this change:
> >
> > --- a/hw/xfree86/drivers/modesetting/Makefile.am
> > +++ b/hw/xfree86/drivers/modesetting/Makefile.am
> > @@ -39,7 +39,7 @@ AM_CPPFLAGS = \
> >
> > modesetting_drv_la_LTLIBRARIES = modesetting_drv.la
> > modesetting_drv_la_LDFLAGS = -module -avoid-version
> > -modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS)
> > +modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS) $(GBM_LIBS)
> > modesetting_drv_ladir = @moduledir@/drivers
> >
> > modesetting_drv_la_SOURCES = \
> >
> > And now Xorg will start, still very weird since the
> > exact same Xorg binaries work fine on Intel integrated
> > gfx where the gbm_bo_get_stride() call also happens ...
> >
> >
> > So with this "fix" it starts, but it crashes as soon as I resize the
> > vm-window and thus the screen gets resized:
> >
> > bt
> > #0 OsSigHandler (signo=11, sip=0x7ffc160ad2f0, unused=0x7ffc160ad1c0)
> > at osinit.c:114
> > #1
> > #2 miModifyPixmapHeader (pPixmap=0x28c4460, width=1920, height=992,
> depth=-1,
> > bitsPerPixel=-1, devKind=7680, pPixData=0x0) at miscrinit.c:64
> > #3 0x7fdc13d64471 in drmmode_xf86crtc_resize (scrn=0x21751f0,
> width=1920,
> > height=992) at drmmode_display.c:3166
> > #4 0x004bb9d8 in xf86RandR12ScreenSetSize (pScreen=0x23dc9b0,
> > width=1920, height=992, mmWidth=508, mmHeight=262) at
> xf86RandR12.c:698
> > #5 0x005092f0 in ProcRRSetScreenSize (client=0x29c6af0)
> > at rrscreen.c:289
> > #6 0x0043fcee in Dispatch () at dispatch.c:478
> >
> > And miscrinit.c:64 is hte "{" of:
> >
> > Bool
> > miModifyPixmapHeader(PixmapPtr pPixmap, int width, int height, int depth,
> > int bitsPerPixel, int devKind, void *pPixData)
> > {
> > if (!pPixmap)
> > return FALSE;
> >
> > Which is a strange place to crash. Even more weird after adding a
> > breakpoint a bit before drmmode_display.c:3166, I get a segfault
> > while stepping through earlier lines, pointing at SmartScheduleTimer()
> > and specifically again at the opening "{" as if something is wrong with
> > the stack and the stack cannot handle function calls being stacked one
> > level deeper.
> >
> > This makes me wonder if this is a stack depth/overflow issue, does the
> > xserver have code somewhere to limit its stacksize and could we be
> > hitting that ?
> >
> > Or maybe a bad interaction with gcc-s stack protection?
> >
> > This feels as if we are hitting a guard page at the end of the stack
> > here?
>
> One important thing which I only put in the subject, this happens
> when using glmamor with llvmpipe, something which is new in 1.20,
> older xservers never used glamor on llvmpipe. Things work fine
> if I disable glamor in a xorg.conf snippet.
>
> Arguably we should disable glamor when running on llvmpipe because
> of performance reasons, still these crashes should not happen.
>
> Regards,
>
> Hans
>
> ___
> 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
___
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: Xorg-1.20.1 crashes when using glamor on top of llvmpipe
Hi,
On 30-08-18 22:48, Hans de Goede wrote:
HI all,
I've been debugging some strange crashes with Xorg-1.20.1 inside
a virtualbox guest and I can use some help with this.
At first Xorg completely failed to start, running it under
gdbserver showed a backtrace pointing to a lazy symbol lookup
failure triggered by:
drmmode_display.c:905:
return gbm_bo_get_stride(bo->gbm);
Which is part of:
uint32_t
drmmode_bo_get_pitch(drmmode_bo *bo)
{
#ifdef GLAMOR_HAS_GBM
if (bo->gbm)
return gbm_bo_get_stride(bo->gbm);
#endif
return bo->dumb->pitch;
}
Strange enough a LD_PRELOAD of libgbm does not
fix this and libgbm already gets dragged in by
libglamor_egl.so so this should not be a problem.
Still I tried this change:
--- a/hw/xfree86/drivers/modesetting/Makefile.am
+++ b/hw/xfree86/drivers/modesetting/Makefile.am
@@ -39,7 +39,7 @@ AM_CPPFLAGS = \
modesetting_drv_la_LTLIBRARIES = modesetting_drv.la
modesetting_drv_la_LDFLAGS = -module -avoid-version
-modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS)
+modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS) $(GBM_LIBS)
modesetting_drv_ladir = @moduledir@/drivers
modesetting_drv_la_SOURCES = \
And now Xorg will start, still very weird since the
exact same Xorg binaries work fine on Intel integrated
gfx where the gbm_bo_get_stride() call also happens ...
So with this "fix" it starts, but it crashes as soon as I resize the
vm-window and thus the screen gets resized:
bt
#0 OsSigHandler (signo=11, sip=0x7ffc160ad2f0, unused=0x7ffc160ad1c0)
at osinit.c:114
#1
#2 miModifyPixmapHeader (pPixmap=0x28c4460, width=1920, height=992, depth=-1,
bitsPerPixel=-1, devKind=7680, pPixData=0x0) at miscrinit.c:64
#3 0x7fdc13d64471 in drmmode_xf86crtc_resize (scrn=0x21751f0, width=1920,
height=992) at drmmode_display.c:3166
#4 0x004bb9d8 in xf86RandR12ScreenSetSize (pScreen=0x23dc9b0,
width=1920, height=992, mmWidth=508, mmHeight=262) at xf86RandR12.c:698
#5 0x005092f0 in ProcRRSetScreenSize (client=0x29c6af0)
at rrscreen.c:289
#6 0x0043fcee in Dispatch () at dispatch.c:478
And miscrinit.c:64 is hte "{" of:
Bool
miModifyPixmapHeader(PixmapPtr pPixmap, int width, int height, int depth,
int bitsPerPixel, int devKind, void *pPixData)
{
if (!pPixmap)
return FALSE;
Which is a strange place to crash. Even more weird after adding a
breakpoint a bit before drmmode_display.c:3166, I get a segfault
while stepping through earlier lines, pointing at SmartScheduleTimer()
and specifically again at the opening "{" as if something is wrong with
the stack and the stack cannot handle function calls being stacked one
level deeper.
This makes me wonder if this is a stack depth/overflow issue, does the
xserver have code somewhere to limit its stacksize and could we be
hitting that ?
Or maybe a bad interaction with gcc-s stack protection?
This feels as if we are hitting a guard page at the end of the stack
here?
One important thing which I only put in the subject, this happens
when using glmamor with llvmpipe, something which is new in 1.20,
older xservers never used glamor on llvmpipe. Things work fine
if I disable glamor in a xorg.conf snippet.
Arguably we should disable glamor when running on llvmpipe because
of performance reasons, still these crashes should not happen.
Regards,
Hans
___
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
Xorg-1.20.1 crashes when using glamor on top of llvmpipe
HI all,
I've been debugging some strange crashes with Xorg-1.20.1 inside
a virtualbox guest and I can use some help with this.
At first Xorg completely failed to start, running it under
gdbserver showed a backtrace pointing to a lazy symbol lookup
failure triggered by:
drmmode_display.c:905:
return gbm_bo_get_stride(bo->gbm);
Which is part of:
uint32_t
drmmode_bo_get_pitch(drmmode_bo *bo)
{
#ifdef GLAMOR_HAS_GBM
if (bo->gbm)
return gbm_bo_get_stride(bo->gbm);
#endif
return bo->dumb->pitch;
}
Strange enough a LD_PRELOAD of libgbm does not
fix this and libgbm already gets dragged in by
libglamor_egl.so so this should not be a problem.
Still I tried this change:
--- a/hw/xfree86/drivers/modesetting/Makefile.am
+++ b/hw/xfree86/drivers/modesetting/Makefile.am
@@ -39,7 +39,7 @@ AM_CPPFLAGS = \
modesetting_drv_la_LTLIBRARIES = modesetting_drv.la
modesetting_drv_la_LDFLAGS = -module -avoid-version
-modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS)
+modesetting_drv_la_LIBADD = $(UDEV_LIBS) $(DRM_LIBS) $(GBM_LIBS)
modesetting_drv_ladir = @moduledir@/drivers
modesetting_drv_la_SOURCES = \
And now Xorg will start, still very weird since the
exact same Xorg binaries work fine on Intel integrated
gfx where the gbm_bo_get_stride() call also happens ...
So with this "fix" it starts, but it crashes as soon as I resize the
vm-window and thus the screen gets resized:
bt
#0 OsSigHandler (signo=11, sip=0x7ffc160ad2f0, unused=0x7ffc160ad1c0)
at osinit.c:114
#1
#2 miModifyPixmapHeader (pPixmap=0x28c4460, width=1920, height=992, depth=-1,
bitsPerPixel=-1, devKind=7680, pPixData=0x0) at miscrinit.c:64
#3 0x7fdc13d64471 in drmmode_xf86crtc_resize (scrn=0x21751f0, width=1920,
height=992) at drmmode_display.c:3166
#4 0x004bb9d8 in xf86RandR12ScreenSetSize (pScreen=0x23dc9b0,
width=1920, height=992, mmWidth=508, mmHeight=262) at xf86RandR12.c:698
#5 0x005092f0 in ProcRRSetScreenSize (client=0x29c6af0)
at rrscreen.c:289
#6 0x0043fcee in Dispatch () at dispatch.c:478
And miscrinit.c:64 is hte "{" of:
Bool
miModifyPixmapHeader(PixmapPtr pPixmap, int width, int height, int depth,
int bitsPerPixel, int devKind, void *pPixData)
{
if (!pPixmap)
return FALSE;
Which is a strange place to crash. Even more weird after adding a
breakpoint a bit before drmmode_display.c:3166, I get a segfault
while stepping through earlier lines, pointing at SmartScheduleTimer()
and specifically again at the opening "{" as if something is wrong with
the stack and the stack cannot handle function calls being stacked one
level deeper.
This makes me wonder if this is a stack depth/overflow issue, does the
xserver have code somewhere to limit its stacksize and could we be
hitting that ?
Or maybe a bad interaction with gcc-s stack protection?
This feels as if we are hitting a guard page at the end of the stack
here?
Regards,
Hans
___
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: Window scaling (aka owner sizes)
Hi Keith, On Mon, Aug 27, 2018 at 8:24 AM Keith Packard wrote: > > > I'm doing a bit of work to help support applications that want to run at > a small fixed size. The 'usual' way to make them visible on our modern > desktops is to flip video modes, but that means everything runs at low > resolution, plus you get the adventure of switching modes, which can > take a long time in complex monitor environments. > > https://keithp.com/blogs/window-scaling/ > > The basic plan is to make the size-as-seen-by-the-owner different from > the size seen by the rest of the system, and then to either have the > server scale the output or get the compositing manager to do it. > > This solves one of the main use cases for 'composite redirection' that I > talked about a long time ago and could never get to work. Restricting > the problem space to simple application scaling, instead of arbitrary > transformation, meant that I could place the input event scaling right > inside the X server, allowing it to be synchronous, instead of > attempting to have some external agent perform the transformation. > > When there's no compositing manager running, the window is placed into > automatic compositing mode and the X server performs the necessary > output scaling. > > When there is a compositing manager running, I've thought of three > possible ways to make it work: > > 1. The compositing manager can be extended to handle the scaling > operation. This seems like the best plan; just a single copy from > the native application size to the scanout buffer. > > 2. Alternatively, another window might be interposed between the scaled > client and the compositor to provide a place for the X server to do > the scaling; although that would naturally introduce a bunch more > expense and delay in the process. > > 3. It would also be possible to have the X server provide a scaled > version of the window pixmap to the compositing manager until it > advertised support for built-in scaling. Same rendering delay as > with an interposed window, but no changes required in the > environment, although a bit of work to be done in the X server. That > might be a good transition plan so that things didn't break when you > started a compositing manager without the required support. > > I'm wondering if there are others who would find this useful, and if > some of them might help get this into reasonable shape. Suggestions are > welcome! Much interesting indeed :) We've been considering something similar for Xwayland, scaling the window is relatively easy, but one possible issue with scaling the client window is the perception of the screen size from the client itself. Imagine the client is trying to size its window to match the screen or even output size, or tries to center its window on the current monitor. It does so based on the root window size or possibly the Xrandr information or even Xinerama, but since its window will be scaled afterwards, that computed size or position will end up being wrong. So that means that the screen size and xrandr info sent to the client depends on the client's window being scaled or not, eventually. Basically, the Xserver needs to lie to the client so that the client computes its window size/position right when mapped on screen. But things like DisplayWidth()/DisplayHeight() are defined as C macros in Xlib, to access the fields of the Screen sent when opening the connection with the Xserver, not something we can fix easily. Moreover, several properties from EWMH on the root window reflect the screen size (things like _NET_DESKTOP_GEOMETRY, _NET_WORKAREA) and are necessarily shared between all X11 clients (who share the same root window). How do you plan to deal with this in your approach? Cheers, Olivier PS: When considering this for Xwayland, I ended up thinking that it would be actually easier to have different X11 screens (i.e. :0.0, :0.1, etc.) of different size for different scales for the X11 clients ended up being scaled differently (which led me to https://gitlab.freedesktop.org/ofourdan/xserver/tree/xwayland-multi-screen), but that approach introduces a lot of complexity (the CM has to play the proxy between all those X11 screens for things like copy/paste, DnD, etc.) ___ 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: [Pixman] [BUG] SIGSEGV in sse2_fill
On 2018-08-29 9:14 p.m., Adam Jackson wrote: > continued from pixman@, original thread here: > > https://lists.freedesktop.org/archives/pixman/2018-August/004759.html Frédéric, can you attach the full corresponding Xorg log file? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ 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 wayland axis_discrete event
On Wed, Aug 15, 2018 at 08:54:25PM +1200, Scott Anderson wrote:
> On 6/08/18 6:09 PM, Scott Anderson wrote:
> > This prevents multiple scroll events happening for wayland compositors
> > which send axis values other than 10. For example, libinput will
> > typically return 15 for each scroll wheel step, and if a wayland
> > compositor sends those to xwayland without normalising them, 2 scroll
> > wheel steps will end up as 3 xorg scroll events. By listening for the
> > discrete_axis event, this will now correctly send only 2 xorg scroll
> > events.
> >
> > The wayland protocol gurantees that there will always be an axis event
> > following an axis_discrete event. However, it does not gurantee that
> > other events (including other axis_discrete+axis pairs) will not happen
> > in between them. So we must keep a list of outstanding axis_discrete
> > events.
> >
> > Signed-off-by: Scott Anderson
> > ---
> > hw/xwayland/xwayland-input.c | 41 +++-
> > hw/xwayland/xwayland.h | 1 +
> > 2 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> > index a602f0887..6fd3c416b 100644
> > --- a/hw/xwayland/xwayland-input.c
> > +++ b/hw/xwayland/xwayland-input.c
> > @@ -37,6 +37,12 @@
> > #include
> > #include "tablet-unstable-v2-client-protocol.h"
> > +struct axis_discrete_pending {
> > +struct xorg_list l;
> > +uint32_t axis;
> > +int32_t discrete;
> > +};
> > +
> > struct sync_pending {
> > struct xorg_list l;
> > DeviceIntPtr pending_dev;
> > @@ -565,6 +571,8 @@ pointer_handle_axis(void *data, struct wl_pointer
> > *pointer,
> > int index;
> > const int divisor = 10;
> > ValuatorMask mask;
> > +struct axis_discrete_pending *pending = NULL;
> > +struct axis_discrete_pending *iter;
> > switch (axis) {
> > case WL_POINTER_AXIS_VERTICAL_SCROLL:
> > @@ -577,8 +585,22 @@ pointer_handle_axis(void *data, struct wl_pointer
> > *pointer,
> > return;
> > }
> > +xorg_list_for_each_entry(iter, _seat->axis_discrete_pending, l) {
> > +if (iter->axis == axis) {
> > +pending = iter;
> > +break;
> > +}
> > +}
> > +
> > valuator_mask_zero();
> > -valuator_mask_set_double(, index, wl_fixed_to_double(value) /
> > divisor);
> > +
> > +if (pending) {
> > +valuator_mask_set(, index, pending->discrete);
> > +xorg_list_del(>l);
> > +free(pending);
> > +} else {
> > +valuator_mask_set_double(, index, wl_fixed_to_double(value) /
> > divisor);
> > +}
> > QueuePointerEvents(xwl_seat->pointer, MotionNotify, 0,
> > POINTER_RELATIVE, );
> > }
> > @@ -608,6 +630,16 @@ static void
> > pointer_handle_axis_discrete(void *data, struct wl_pointer *wl_pointer,
> >uint32_t axis, int32_t discrete)
> > {
> > +struct xwl_seat *xwl_seat = data;
> > +
> > +struct axis_discrete_pending *pending = malloc(sizeof *pending);
> > +if (!pending)
> > +return;
> > +
> > +pending->axis = axis;
> > +pending->discrete = discrete;
> > +
> > +xorg_list_add(>l, _seat->axis_discrete_pending);
> > }
> > static const struct wl_pointer_listener pointer_listener = {
> > @@ -1337,6 +1369,7 @@ create_input_device(struct xwl_screen *xwl_screen,
> > uint32_t id, uint32_t version
> > wl_array_init(_seat->keys);
> > xorg_list_init(_seat->touches);
> > +xorg_list_init(_seat->axis_discrete_pending);
> > xorg_list_init(_seat->sync_pending);
> > }
> > @@ -1345,6 +1378,7 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
> > {
> > struct xwl_touch *xwl_touch, *next_xwl_touch;
> > struct sync_pending *p, *npd;
> > +struct axis_discrete_pending *ad, *ad_next;
> > xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
> > _seat->touches, link_touch) {
> > @@ -1357,6 +1391,11 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
> > free (p);
> > }
> > +xorg_list_for_each_entry_safe(ad, ad_next,
> > _seat->axis_discrete_pending, l) {
> > +xorg_list_del(>l);
> > +free(ad);
> > +}
> > +
> > release_tablet_manager_seat(xwl_seat);
> > release_grab(xwl_seat);
> > diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> > index d70ad54bf..1a6e2f380 100644
> > --- a/hw/xwayland/xwayland.h
> > +++ b/hw/xwayland/xwayland.h
> > @@ -272,6 +272,7 @@ struct xwl_seat {
> > char *keymap;
> > struct wl_surface *keyboard_focus;
> > +struct xorg_list axis_discrete_pending;
> > struct xorg_list sync_pending;
> > struct xwl_pointer_warp_emulator *pointer_warp_emulator;
> >
>
> Ping.
sorry, this is pushed now.
f79e53685..cd285922c master -> master
Cheers,
Peter
___
xorg-devel@lists.x.org: X.Org development
