in XWayland, dri3_send_open_reply() is called from a sync callback, so
there is a possibility that the client might be gone when we get to the
callback eventually, which leads to a crash in _XSERVTransSendFd() from
WriteFdToClient() .
Check if clientGone has been set in the sync callback handler
Hi Eric,
> > Not all compositors allow for customizing the Xwayland command line,
> > gnome-shell/mutter for example have the command line and path to
> > Xwayland binary hardcoded, which makes it harder for users to disable
> > glamor acceleration in Xwayland (glamor being used by default).
> >
Not all compositors allow for customizing the Xwayland command line,
gnome-shell/mutter for example have the command line and path to
Xwayland binary hardcoded, which makes it harder for users to disable
glamor acceleration in Xwayland (glamor being used by default).
Add an environment variable
On Wed, 1 Mar 2017 17:45:11 +0100
Olivier Fourdan wrote:
> Hi all,
>
> I am seeing quite a few Xwayland crashes related to glamor.
>
> Various issues, could be with glamor itself or with the drivers (like the
> issues I witness with nv30), whatever.
>
> To investigate
Hi Pekka,
> I understand the attractiveness of adding an override, bypassing the
> compositors like this. But, essentially it is just that: a
> configuration bypass.
True.
> I would prefer leaning towards just making the compositors more
> considerate about their Xwayland configuration. I
On Thu, 2 Mar 2017 05:47:10 -0500 (EST)
Olivier Fourdan wrote:
> Hi Pekka,
>
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.
>
> True.
>
> > I would prefer
Hi Jonas,
> > > I would prefer leaning towards just making the compositors more
> > > considerate about their Xwayland configuration. I believe the global
> > > trend is to move towards the compositor having all the configurability
> > > in itself, and all the other components having a single
On Thu, Mar 02, 2017 at 05:47:10AM -0500, Olivier Fourdan wrote:
> Hi Pekka,
>
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.
>
> True.
>
> > I would prefer leaning towards just
Adam Jackson writes:
> I assume this is meant in the same sense that The Onion is America's
> Finest News Source.
Not entirely? In reality, getting arcs to do anything like what the spec
suggested took a huge amount of time. With Bob's closed-form solution
for the quartic, it's
Adam Jackson writes:
> This could work if your layer was _completely_ trivial, or if you were
> extremely careful about unwinding your layer's state. Merely changing
> the wrapping convention isn't going to make it easy to, say, disable
> glamor on the fly.
This happens a lot
On Wed, 2017-03-01 at 15:20 -0800, Keith Packard wrote:
> > Adam Jackson writes:
>
> > So, way back in 946f664b, I removed a cache from the miarc code, with the
> > justification that arcs were rare and the performance improvement wasn't
> > worth it. I'd have been more right if
On Wed, 2017-03-01 at 15:16 -0800, Keith Packard wrote:
> > Adam Jackson writes:
> >
> > > For the real wrappers, I think we can start with some requirements:
> > >
> > > 1) Remove wrappers at any time.
> > >
> > > 2) Insert at the 'right place' in the chain, independent of
On Thu, 2017-03-02 at 13:20 -0800, Keith Packard wrote:
> > Adam Jackson writes:
> > The "call down" convention would need to know to scan ahead to find
> > the next non-null fptr for the slot either way, but that's not really
> > different from the current model where some slots
Adam Jackson writes:
> That means you have to save "your" index for every slot though.
My thinking is that each layer will get a static index that it uses, not
a dynamic one. Of course, the server would panic if two layers tried to
use the same index.
> I mean, I did grep for
14 matches
Mail list logo