Re: Making Composite better for interactive apps

On Sat, Feb 3, 2018 at 9:23 PM, Keith Packard wrote: > (To be clear, what I'm proposing won't break anything that already > works -- the Auto List is entirely driven by the compositor, so if you > don't use it, you don't get this functionality.) > > But, yes, Compton wouldn't

Re: Making Composite better for interactive apps

On Sun, Feb 4, 2018 at 11:19 PM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> Ah, good point. So Compton wouldn't break anyway, at worst it couldn't >> use the feature reliably. > > Having any reasonable Compositing Manager not work is a

Re: Making Composite better for interactive apps

Giuseppe Bilotta writes: > Well, apparently Compton already has some issues with DRI3/Present already, > e.g. > https://bugs.freedesktop.org/show_bug.cgi?id=97916 but maybe that's > Compton not being reasonable (using the root window instead of the > typical

Re: Making Composite better for interactive apps

Giuseppe Bilotta writes: > Ah, good point. So Compton wouldn't break anyway, at worst it couldn't > use the feature reliably. Having any reasonable Compositing Manager not work is a sign that the design isn't quite right. > Actually I'm not sure 2) would work

Re: Making Composite better for interactive apps

On Mon, Feb 5, 2018 at 12:47 AM, Keith Packard wrote: > It's interesting to note > that we could have done the same thing for all of the redirected window > management requests in the core protocol, simplifying applications > tremendously... I'm not sure I follow. >> The

Re: Making Composite better for interactive apps

On Mon, Feb 5, 2018 at 2:17 AM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> I'm not sure I follow. > > Imagine if MapWindow blocked until the window was actually mapped by the > Window Manager. I'm not sure if this could be implemented

Re: Making Composite better for interactive apps

Giuseppe Bilotta writes: > I'm not sure I follow. Imagine if MapWindow blocked until the window was actually mapped by the Window Manager. > (Or their descendants). But aside from the restriction on which window > can be in the AutoList, my question was more along

[PATCH xrandr v4 5/5] xrandr.man: document the monitor manipulation options

--- man/xrandr.man | 23 +++ 1 file changed, 23 insertions(+) diff --git a/man/xrandr.man b/man/xrandr.man index 9f976ad..aa82724 100644 --- a/man/xrandr.man +++ b/man/xrandr.man @@ -72,6 +72,10 @@ xrandr \- primitive command line interface to RandR extension

[PATCH xrandr v4 4/5] xrandr: allow single value for --gamma

Similarly to --scale, accept a single value to be used for all three components, and refuse values with extra junk after the acceptable values. --- man/xrandr.man | 9 ++--- xrandr.c | 15 +++ 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/man/xrandr.man

[PATCH xrandr v4 3/5] xrandr.man: grammar tuning

Rephrase the --scale option paragraph to improve English and be more consistent in choice of plurals and tense. Also ensure that each sentence starts on a new line in the roff source. Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 11 ++- 1 file

[PATCH xrandr v4 0/5] xrandr: improve option parsing and documentation

Misc. patches to improve option parsing and documentation for xrandr. Allow single values to be given to --scale and --gamma, rejecting the option if valid values are followed by extra junk (e.g. 2x3a isn't accepted as a valid value for --scale). Minor improvements to the documentation are also

[PATCH xrandr v4 1/5] xrandr: allow a single value for --scale

This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5 Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 7 --- xrandr.c | 8 ++-- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/man/xrandr.man b/man/xrandr.man index

[PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing

We used to accept something like --scale 2x3junk as a valid input (scaling x by 2 and y by 3), even though this isn't really a valid scaling factor. Fix by making sure there is nothing after the parsed number(s). Signed-off-by: Giuseppe Bilotta --- xrandr.c | 5

Re: Making Composite better for interactive apps

Giuseppe Bilotta writes: > I'm not sure if this could be implemented without making the server > more susceptible to DOS attacks, though (basically the same issue I > see in the blocking AutoList geometry change notification). In that case, the Window Manager can

[PATCH xserver 0/3] Fix 'Xorg -configure'

As noted in https://bugs.freedesktop.org/100405, 'Xorg -configure' results in a fault. I fixed the source of that fault, and handled a couple of subsequent issues that manifested after fixing it. Jeff Smith (3): xfree86: Do not use uninitialized pointer during probe xfree86: Allocate

[PATCH xserver 1/3] xfree86: Do not use uninitialized pointer during probe

Commits b5dffbb and d75ffcd introduce code in xf86platformProbe() that references a member of xf86configptr. However, when using the "-configure" option, xf86configptr may not be initialized when xf86platformProbe() is called. Avoid referencing a member of xf86configptr if uninitialized.

[PATCH xserver 3/3] xfree86: Only call PreInit handler if it exists for device

DoConfigure() attempts to call the PreInit handler on a device without checking that the handler exists. Check that the PreInit handler exists for a device before attempting to call it. Signed-off-by: Jeff Smith --- hw/xfree86/common/xf86Configure.c | 3 ++- 1 file changed,

[PATCH xserver 2/3] xfree86: Allocate sufficienct space for dev2screen array

When the dev2screen is sized to xf86NumDrivers in DoConfigure(), subsequent code may attempt to write past the end of the array. Size the dev2screen array to nDevToConfig instead. Signed-off-by: Jeff Smith --- hw/xfree86/common/xf86Configure.c | 2 +- 1 file changed, 1