Hi,
On 17 September 2016 at 08:21, Jasper St. Pierre wrote:
> Daniel suggested that timestamps *should* be on the same timebase.
> Currently, they are not. X11 server timestamps are
> CLOCK_MONOTONIC_COARSE-based and are calculated at delivery time, evdev
> timestamps are
On Fri, 16 Sep 2016 22:21:42 -0700
"Jasper St. Pierre" wrote:
> Hi,
>
> Based on my reading of the spec, writing an ICCCM-compliant WM *requires*
> blocking, since the behavior of an UnmapNotify depends on the attributes of
> a window. We cannot process any X11 events
Hi,
Based on my reading of the spec, writing an ICCCM-compliant WM *requires*
blocking, since the behavior of an UnmapNotify depends on the attributes of
a window. We cannot process any X11 events while we are retrieving the
attributes of a mapped window inside MapRequest.
If we want to modify
On Tue, 13 Sep 2016 12:04:14 -0400 (EDT)
Olivier Fourdan wrote:
> Hi Pekka,
>
> - Original Message -
> > Hi Olivier,
> >
> > I don't have any solution for you. The interactions between the Wayland
> > compositor and Xwayland are known to be very easily deadlockable
On Tue, 2016-09-13 at 06:13 -0400, Olivier Fourdan wrote:
> I tried to poll() the Wayland fd with a timeout prior to
> wl_display_flush() to make sure to wl_display_flush() only when
> writable, to see if that would help unblocking mutter waiting for its
> PropertyNotify event but that did not
Hi Pekka,
- Original Message -
> Hi Olivier,
>
> I don't have any solution for you. The interactions between the Wayland
> compositor and Xwayland are known to be very easily deadlockable IIRC. I
> believe the only thing you can do is ensure no such case can ever
> occur, which is very
Hi all
- Original Message -
> wl_display_flush() can fail with EAGAIN and Xwayland would make this a
> fatal error.
>
> Handle the usual EAGAIN and EINTR gracefully so that Xwayland doesn't
> die for so little.
Right, I am running out of ideas...
So the approach of using poll() to wait