Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

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

Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

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

Re: [PATCH xserver 0/3] Fix O(n*m) performance cliff in miarc

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

Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

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

Re: [PATCH xserver 0/3] Fix O(n*m) performance cliff in miarc

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

Re: [PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

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

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

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

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

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

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

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

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

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

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

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

[PATCH xserver v2] xwayland: add envvar XWAYLAND_NO_GLAMOR

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

Re: [PATCH xserver] xwayland: add envvar XWAYLAND_NO_GLAMOR

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). > >

[RFC PATCH xserver] xwayland: make sure client is not gone in sync callback

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