Re: [PATCH xserver 08/10] xf86-video-modesetting: Create CONNECTOR_ID properties for outputs

[Keith Packard]

Adam Jackson  writes:

>> +if (name != BAD_RESOURCE) {
>> +err = RRConfigureOutputProperty(output->randr_output, name,
>> +FALSE, TRUE, TRUE,
>> +2, prop_range);
>
> There's no good reason to make this a range, is there?

Well, it's a fixed integer for each output, which can either be
considered an enumeration which can have only one value or a value in a
range. I picked 'range' because it didn't seem like this could be
considered an enumeration to me.

If you like the other option better, that'd be fine with me :-)

-- 
-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: Gradients are broken with glamor when RepeatReflect is set

[Jeffrey Smith]

On Mon, Jan 22, 2018 at 3:01 PM, Chris Wilson  wrote:
> Quoting Adam Jackson (2018-01-22 20:09:52)
>> On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
>> > Hi there,
>> >
>> > Glamor's gradient acceleration code is broken in case RepeatReflect is
>> > used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
>> > I've filed the bug report over a year ago, but except for a
>> > confirmation from Michel Dänzer nothing happend.
>> >
>> > Unfourntunatly I lack the expertise to fix it myself - however instead
>> > of leaving it broken forever, could we fall back to software for
>> > RepeatReflect.
>> > I guess slow is better than completly broken?
>>
>> Just want to note that this isn't forgotten. I got as far as testing
>> the reproducer with Xephyr and verifying glamor was wrong and fb was
>> right, but don't yet get what the RepeatReflect math is getting wrong.
>> I'll definitely have a fix for 1.20 one way or another, but that may
>> just be forcing a fallback.
>>
>> If anyone wanted to investigate this, I think this is the guilty
>> conditional:
>>
>> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296
>
> -t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0);
> +t = abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
>
> #include 
> #include 
>
> #define abs(t) fabs(t)
> #define fract(t) fmod((t), 1.0)
>
> static float repeat(float t)
> {
> return abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
> }
>
> int main(void)
> {
> float t;
>
> for (t = -3; t <= 3; t += .5)
> printf("%5.1f  ", t);
> printf("\n");
> for (t = -3; t <= 3; t += .5)
> printf("%5.1f  ", repeat(t));
> printf("\n");
> }
>
>  -3.0   -2.5   -2.0   -1.5   -1.0   -0.50.00.51.01.52.0   
>  2.53.0
>   1.00.50.00.51.00.50.00.51.00.50.0   
>  0.51.0
> -Chris

For comparison, I think it's worth noting that the current equation results in:

1.02.52.01.51.00.50.00.51.00.5
0.00.51.0
  ^   ^   ^

 -- Jeff

> ___
> 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: [PATCH xserver 00/10] Implement RandR 1.6 (leases and non-desktop)

[Adam Jackson]

On Thu, 2017-12-21 at 18:54 -0800, Keith Packard wrote:
> Here's the latest version of the DRM lease and non-desktop output code
> for the X server. This time, I've gone ahead and implemented a pile of
> tests for leases.
> 
> Changes since the last series:
> 
>  * Merged non-desktop and lease support into a single patch
>sequence. They have a dependency on reporting output connection
>status, so it's something of a pain to keep them separate.
> 
>  * Added RandR lease tests
> 
> Mesa support for the VK_EXT_acquire_xlib_display is waiting for this
> series to land.

Merged 1 2 5 and 7:

remote: E: failed to find patch for rev 
44d5f2eb8a2f92571698adec39ac569b71da5a1b.
remote: I: patch #194730 updated using rev 
a12485ed846b852ca14d17d1e58c8b0f2399e577.
remote: I: patch #192308 updated using rev 
29f79bedf2c80241ba4b482db6ead08a5709a982.
remote: E: failed to find patch for rev 
4d5aab66c052795c7f0381a3dfc7293c9a41e441.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   627dfc2f8..4d5aab66c  master -> master

4 and 6 are:

Reviewed-by: Adam Jackson 

3 and 8 would have my r-b too once the review feedback is addressed. 9
and 10 I think we can expect new versions of anyway, it sounded on IRC
like you'd found some bugs.

For the actual 1.6 enablement I've been using this for a merged
protocol repo:

https://cgit.freedesktop.org/~ajax/xorgproto

Which is Keith's "mergeproto" plus some packaging cleanups; if other
distribution/OS maintainers would like to take a look at that and make
sure it'll work for them, that would be much appreciated.

- ajax
___
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 08/10] xf86-video-modesetting: Create CONNECTOR_ID properties for outputs

[Adam Jackson]

On Thu, 2017-12-21 at 18:54 -0800, Keith Packard wrote:

> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 1ec232f70..ef3dba4cb 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -1509,6 +1509,30 @@ drmmode_output_create_resources(xf86OutputPtr output)
>  j++;
>  }
>  
> +/* Create CONNECTOR_ID property */
> +{
> +Atomname = MakeAtom("CONNECTOR_ID", 12, TRUE);
> +INT32   value = mode_output->connector_id;
> +INT32   prop_range[2] = { 0, 0x7fff };
> +
> +if (name != BAD_RESOURCE) {
> +err = RRConfigureOutputProperty(output->randr_output, name,
> +FALSE, TRUE, TRUE,
> +2, prop_range);

There's no good reason to make this a range, is there?

- ajax
___
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] xfree86: Remove broken RANDR disabling logic (v2)

[Keith Packard]

Adam Jackson  writes:

> -if (!xf86Info.disableRandR)
> +if (!rrGetScrPriv(xf86Screens[i]->pScreen))
>  xf86RandRInit(screenInfo.screens[scr_index]);

A comment here would help me understand this change; I assume we won't
generally hit this path, right?

-- 
-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: Gradients are broken with glamor when RepeatReflect is set

[Chris Wilson]

Quoting Adam Jackson (2018-01-22 20:09:52)
> On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
> > Hi there,
> > 
> > Glamor's gradient acceleration code is broken in case RepeatReflect is
> > used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
> > I've filed the bug report over a year ago, but except for a
> > confirmation from Michel Dänzer nothing happend.
> > 
> > Unfourntunatly I lack the expertise to fix it myself - however instead
> > of leaving it broken forever, could we fall back to software for
> > RepeatReflect.
> > I guess slow is better than completly broken?
> 
> Just want to note that this isn't forgotten. I got as far as testing
> the reproducer with Xephyr and verifying glamor was wrong and fb was
> right, but don't yet get what the RepeatReflect math is getting wrong.
> I'll definitely have a fix for 1.20 one way or another, but that may
> just be forcing a fallback.
> 
> If anyone wanted to investigate this, I think this is the guilty
> conditional:
> 
> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296

-t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0);
+t = abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);

#include 
#include 

#define abs(t) fabs(t)
#define fract(t) fmod((t), 1.0)

static float repeat(float t)
{
return abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
}

int main(void)
{
float t;

for (t = -3; t <= 3; t += .5)
printf("%5.1f  ", t);
printf("\n");
for (t = -3; t <= 3; t += .5)
printf("%5.1f  ", repeat(t));
printf("\n");
}

 -3.0   -2.5   -2.0   -1.5   -1.0   -0.50.00.51.01.52.0
2.53.0  
  1.00.50.00.51.00.50.00.51.00.50.0
0.51.0 
-Chris
___
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: Gradients are broken with glamor when RepeatReflect is set

[Adam Jackson]

On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
> Hi there,
> 
> Glamor's gradient acceleration code is broken in case RepeatReflect is
> used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
> I've filed the bug report over a year ago, but except for a
> confirmation from Michel Dänzer nothing happend.
> 
> Unfourntunatly I lack the expertise to fix it myself - however instead
> of leaving it broken forever, could we fall back to software for
> RepeatReflect.
> I guess slow is better than completly broken?

Just want to note that this isn't forgotten. I got as far as testing
the reproducer with Xephyr and verifying glamor was wrong and fb was
right, but don't yet get what the RepeatReflect math is getting wrong.
I'll definitely have a fix for 1.20 one way or another, but that may
just be forcing a fallback.

If anyone wanted to investigate this, I think this is the guilty
conditional:

https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296

- ajax
___
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: avoid a crash with empty window pixmaps

[Adam Jackson]

On Thu, 2018-01-18 at 11:41 +0100, Olivier Fourdan wrote:
> This is a rare occurrence of a crash in Xwayland for which I don't have
> the reproducing steps, just a core file.
> 
> The backtrace looks as follow:
> 
>   #0  raise () from /usr/lib64/libc.so.6
>   #1  abort () from /usr/lib64/libc.so.6
>   #2  OsAbort () at utils.c:1361
>   #3  AbortServer () at log.c:877
>   #4  FatalError () at log.c:1015
>   #5  OsSigHandler () at osinit.c:154
>   #6  
>   #7  xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162
>   #8  xwl_screen_post_damage () at xwayland.c:514
>   #9  block_handler () at xwayland.c:665
>   #10 BlockHandler () at dixutils.c:388
>   #11 WaitForSomething () at WaitFor.c:219
>   #12 Dispatch () at dispatch.c:422
>   #13 dix_main () at main.c:287
> 
> The crash is caused by dereferencing “xwl_pixmap->buffer” in
> xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL.
> 
> Reason for this is because the corresponding pixmap has a size of 0×0
> and no xwl_pixmap is created for pixmaps of size 0×0.

That can't really be the problem. X drawables are never 0x0.

- ajax
___
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] meson.build: Fix hw/xwin build when dependencies are installed in a non-default location

[Adam Jackson]

On Thu, 2018-01-18 at 12:54 -0800, Eric Anholt wrote:
> Jon Turney  writes:
> 
> > Signed-off-by: Jon Turney 
> 
> Reviewed-by: Eric Anholt 

remote: I: patch #198653 updated using rev 
2d29daf4c69385513a322002570ec2c41cfc838f.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   514d2c243..2d29daf4c  master -> master

- ajax
___
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

[PATCH xserver] xfree86: Remove broken RANDR disabling logic (v2)

[Adam Jackson]

The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.

Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.

v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.

Signed-off-by: Adam Jackson 
---
 hw/xfree86/common/xf86.h|  2 --
 hw/xfree86/common/xf86Config.c  | 12 
 hw/xfree86/common/xf86Globals.c |  2 --
 hw/xfree86/common/xf86Helper.c  |  7 ---
 hw/xfree86/common/xf86Init.c|  5 ++---
 hw/xfree86/common/xf86Mode.c|  6 +-
 hw/xfree86/common/xf86Privstr.h |  2 --
 hw/xfree86/modes/xf86Crtc.c |  3 ---
 8 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 1c2546894..5743f0cd4 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -305,8 +305,6 @@ extern _X_EXPORT Bool
 xf86GetModInDevEnabled(void);
 extern _X_EXPORT Bool
 xf86GetAllowMouseOpenFail(void);
-extern _X_EXPORT void
-xf86DisableRandR(void);
 extern _X_EXPORT CARD32
 xorgGetVersion(void);
 extern _X_EXPORT CARD32
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 053cac168..2f72c2f76 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -634,7 +634,6 @@ typedef enum {
 FLAG_XINERAMA,
 FLAG_LOG,
 FLAG_RENDER_COLORMAP_MODE,
-FLAG_RANDR,
 FLAG_IGNORE_ABI,
 FLAG_ALLOW_EMPTY_INPUT,
 FLAG_USE_DEFAULT_FONT_PATH,
@@ -683,8 +682,6 @@ static OptionInfoRec FlagOptions[] = {
  {0}, FALSE},
 {FLAG_RENDER_COLORMAP_MODE, "RenderColormapMode", OPTV_STRING,
  {0}, FALSE},
-{FLAG_RANDR, "RandR", OPTV_BOOLEAN,
- {0}, FALSE},
 {FLAG_IGNORE_ABI, "IgnoreABI", OPTV_BOOLEAN,
  {0}, FALSE},
 {FLAG_USE_DEFAULT_FONT_PATH, "UseDefaultFontPath", OPTV_BOOLEAN,
@@ -827,15 +824,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, 
XF86OptionPtr layoutopts)
 }
 }
 
-#ifdef RANDR
-xf86Info.disableRandR = FALSE;
-xf86Info.randRFrom = X_DEFAULT;
-if (xf86GetOptValBool(FlagOptions, FLAG_RANDR, )) {
-xf86Info.disableRandR = !value;
-xf86Info.randRFrom = X_CONFIG;
-}
-#endif
-
 #ifdef GLXEXT
 xf86Info.glxVisuals = XF86_GlxVisualsTypical;
 xf86Info.glxVisualsFrom = X_DEFAULT;
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 85efe3fc1..e890f05c2 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -117,8 +117,6 @@ xf86InfoRec xf86Info = {
 .miscModInDevEnabled = TRUE,
 .miscModInDevAllowNonLocal = FALSE,
 .pmFlag = TRUE,
-.disableRandR = FALSE,
-.randRFrom = X_DEFAULT,
 #if defined(CONFIG_HAL) || defined(CONFIG_UDEV) || defined(CONFIG_WSCONS)
 .forceInputDevices = FALSE,
 .autoAddDevices = TRUE,
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 393a7aa88..95a90ad88 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -1458,13 +1458,6 @@ xf86GetAllowMouseOpenFail(void)
 return xf86Info.allowMouseOpenFail;
 }
 
-void
-xf86DisableRandR(void)
-{
-xf86Info.disableRandR = TRUE;
-xf86Info.randRFrom = X_PROBED;
-}
-
 CARD32
 xf86GetModuleVersion(void *module)
 {
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 57b38d07e..cedfe7cc1 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -77,6 +77,7 @@
 #include "xf86Xinput.h"
 #include "xf86InPriv.h"
 #include "picturestr.h"
+#include "randrstr.h"
 
 #include "xf86Bus.h"
 #ifdef XSERVER_LIBPCIACCESS
@@ -810,10 +811,8 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char **argv)
 SubPixelUnknown);
 }
 #ifdef RANDR
-if (!xf86Info.disableRandR)
+if (!rrGetScrPriv(xf86Screens[i]->pScreen))
 xf86RandRInit(screenInfo.screens[scr_index]);
-xf86Msg(xf86Info.randRFrom, "RandR %s\n",
-xf86Info.disableRandR ? "disabled" : "enabled");
 #endif
 }
 
diff --git a/hw/xfree86/common/xf86Mode.c b/hw/xfree86/common/xf86Mode.c
index ceba87f78..40d09a9f4 100644
--- a/hw/xfree86/common/xf86Mode.c
+++ b/hw/xfree86/common/xf86Mode.c
@@ -1643,12 +1643,8 @@ xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr 
availModes,
 }
 
 /* Lookup each mode */
-#ifdef RANDR
-if 

Re: [PATCH xserver 1/2] meson: Enable SUN-DES-1 auth code

[Adam Jackson]

On Mon, 2018-01-22 at 15:27 +, Jon Turney wrote:

> Revised patch attached.

This introduces a warning on my Fedora 27 machine:

In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
 extern int bindresvport(int, struct sockaddr_in *);
^~~~
In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
 from ../os/rpcauth.c:47:
/usr/include/netinet/in.h:502:12: note: previous declaration of ‘bindresvport’ 
was here
 extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) __THROW;
^~~~

I'm going to assume this is just what you get when glibc still has the
rpc interfaces exposed, and hope it goes away later. In the meantime do
'meson configure -Dsecure-rpc=false' if it bothers you.

Merged, thanks:

remote: I: patch #199791 updated using rev 
514d2c243e01b114de304ea72226bbf8772b1b11.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   f72587ecc..514d2c243  master -> master

- ajax
___
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: [RFC xserver 1/1] xwayland: reduce over-damage

[Adam Jackson]

On Mon, 2018-01-22 at 14:51 +, Daniel Stone wrote:
>  Hi Pekka,
> 
> On 20 December 2017 at 11:18, Pekka Paalanen  wrote:
> > If an X11 app draws a little here, some there, and a tiny bit in the
> > opposite corner, using RegionExtents for the damage to be sent to the
> > Wayland compositor will cause massive over-damaging.
> > 
> > However, we cannot blindly send an arbitrary number of damage
> > rectangles, because there is a risk of overflowing the Wayland
> > connection. If that happens, it triggers an abort in libwayland-client.
> > 
> > Try to be more accurate with the damage by sending up to 500 rectangles
> > per window, and fall back to extents otherwise. The number is completely
> > arbitrary.
> 
> I might have said this on IRC, but 500 sails close enough to our
> request limit for comfort. I can't find the mail where I did the
> maths, but ISTR for damage requests, it's around the 6000-7000 mark.
> Pulling 256 as an equally arbitrary number out of the air (arguably
> even that number of TexSubImage requests represents a DoS), this is:
> Reviewed-by: Daniel Stone 

Changed the magic number to 256 and merged, thanks:

remote: E: failed to find patch for rev 
f72587ecc7e1dedfb20a999a0e600b83c06a1b29.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   a5e9bcad7..f72587ecc  master -> master

- ajax
___
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

[PATCH xwayland] xwayland: use RandR 1.2 interface (rev 2)

[Robert Mader]

This adds the RandR 1.2 interface to xwayland and allows modes
advertised by the compositor to be set in an undistructive manner.

With this patch, applications that try to set the resolution will usually
succeed and work while other apps using the same xwayland
instance are not affected at all.

The RandR 1.2 interface will be needed to implement fake-mode-setting and
already makes applications work much cleaner and predictive when a mode
was set.

This depends on https://patchwork.freedesktop.org/series/34628/
---
 hw/xwayland/xwayland-output.c | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 19d8e0c12..911b7a44c 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -411,12 +411,73 @@ xwl_randr_get_info(ScreenPtr pScreen, Rotation * 
rotations)
 return TRUE;
 }
 
+#ifdef RANDR_10_INTERFACE
 static Bool
 xwl_randr_set_config(ScreenPtr pScreen,
  Rotation rotation, int rate, RRScreenSizePtr pSize)
 {
 return FALSE;
 }
+#endif
+
+#if RANDR_12_INTERFACE
+static Bool
+xwl_randr_screen_set_size(ScreenPtr pScreen,
+  CARD16 width,
+  CARD16 height,
+  CARD32 mmWidth, CARD32 mmHeight)
+{
+return TRUE;
+}
+
+static Bool
+xwl_randr_crtc_set(ScreenPtr pScreen,
+   RRCrtcPtr crtc,
+   RRModePtr mode,
+   int x,
+   int y,
+   Rotation rotation,
+   int numOutputs, RROutputPtr * outputs)
+{
+RRCrtcChanged(crtc, TRUE);
+return TRUE;
+}
+
+static Bool
+xwl_randr_crtc_set_gamma(ScreenPtr pScreen, RRCrtcPtr crtc)
+{
+return TRUE;
+}
+
+static Bool
+xwl_randr_Crtc_get_gamma(ScreenPtr pScreen, RRCrtcPtr crtc)
+{
+return TRUE;
+}
+
+static Bool
+xwl_randr_output_set_property(ScreenPtr pScreen,
+  RROutputPtr output,
+  Atom property,
+  RRPropertyValuePtr value)
+{
+return TRUE;
+}
+
+static Bool
+xwl_output_validate_mode(ScreenPtr pScreen,
+ RROutputPtr output,
+ RRModePtr mode)
+{
+return TRUE;
+}
+
+static void
+xwl_randr_mode_destroy(ScreenPtr pScreen, RRModePtr mode)
+{
+return;
+}
+#endif
 
 Bool
 xwl_screen_init_output(struct xwl_screen *xwl_screen)
@@ -430,7 +491,20 @@ xwl_screen_init_output(struct xwl_screen *xwl_screen)
 
 rp = rrGetScrPriv(xwl_screen->screen);
 rp->rrGetInfo = xwl_randr_get_info;
+
+#if RANDR_10_INTERFACE
 rp->rrSetConfig = xwl_randr_set_config;
+#endif
+
+#if RANDR_12_INTERFACE
+rp->rrScreenSetSize = xwl_randr_screen_set_size;
+rp->rrCrtcSet = xwl_randr_crtc_set;
+rp->rrCrtcSetGamma = xwl_randr_crtc_set_gamma;
+rp->rrCrtcGetGamma = xwl_randr_Crtc_get_gamma;
+rp->rrOutputSetProperty = xwl_randr_output_set_property;
+rp->rrOutputValidateMode = xwl_output_validate_mode;
+rp->rrModeDestroy = xwl_randr_mode_destroy;
+#endif
 
 return TRUE;
 }
-- 
2.14.3

___
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 1/2] meson: Enable SUN-DES-1 auth code

[Jon Turney]

On 19/01/2018 11:37, Jon Turney wrote:

On 18/01/2018 21:27, Adam Jackson wrote:

On Wed, 2018-01-17 at 19:02 +, Jon Turney wrote:

On 08/01/2018 20:50, Adam Jackson wrote:

---
   include/meson.build | 1 +
   meson_options.txt   | 1 +
   os/meson.build  | 4 
   3 files changed, 6 insertions(+)


After this, I needed something like the attached.


Eep, indeed you would. But I think we should actually prefer tirpc if
it's available, glibc's rpc code has been deprecated for years and I
believe the next Fedora release is going to try removing the headers
for it again.


I guess XTRANS_SECURE_RPC_FLAGS will also need adjusting to express that 
preference


I took a brief look at this: as far as I can tell, the only users of 
XTRANS_SECURE_RPC_FLAGS are xserver, xhost and xdm.


Of these, the only problem seems to be xdm, which uses getsecretkey(), 
which doesn't seem to be currently provided by libtirpc.


This is not something I can easily test, so I think I'll leave it alone :)


I'll see if I can revise this patch to prefer tirpc.


Revised patch attached.
From c4ac359e152eb8ea13f1c6d5894950563ab60b6b Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Wed, 17 Jan 2018 13:43:47 +
Subject: [PATCH xserver] meson: Use and prefer tirpc for Secure RPC
 authentication

---
 os/meson.build | 5 +
 1 file changed, 5 insertions(+)

diff --git a/os/meson.build b/os/meson.build
index 54124d32a..ff3a4615b 100644
--- a/os/meson.build
+++ b/os/meson.build
@@ -54,7 +54,11 @@ if get_option('xdmcp')
 srcs_os += 'xdmcp.c'
 endif
 
+rpc_dep = []
 if get_option('secure-rpc')
+# prefer libtirpc (if available), otherwise assume RPC functions are
+# provided by libc.
+rpc_dep = dependency('libtirpc', required: false)
 srcs_os += 'rpcauth.c'
 endif
 
@@ -73,6 +77,7 @@ libxserver_os = static_library('libxserver_os',
 common_dep,
 dl_dep,
 sha1_dep,
+rpc_dep,
 dependency('xau')
 ],
 link_with: libxlibc,
-- 
2.15.1

___
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: [RFC xserver 1/1] xwayland: reduce over-damage

[Daniel Stone]

 Hi Pekka,

On 20 December 2017 at 11:18, Pekka Paalanen  wrote:
> If an X11 app draws a little here, some there, and a tiny bit in the
> opposite corner, using RegionExtents for the damage to be sent to the
> Wayland compositor will cause massive over-damaging.
>
> However, we cannot blindly send an arbitrary number of damage
> rectangles, because there is a risk of overflowing the Wayland
> connection. If that happens, it triggers an abort in libwayland-client.
>
> Try to be more accurate with the damage by sending up to 500 rectangles
> per window, and fall back to extents otherwise. The number is completely
> arbitrary.

I might have said this on IRC, but 500 sails close enough to our
request limit for comfort. I can't find the mail where I did the
maths, but ISTR for damage requests, it's around the 6000-7000 mark.
Pulling 256 as an equally arbitrary number out of the air (arguably
even that number of TexSubImage requests represents a DoS), this is:
Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
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: [RFC xserver 1/1] xwayland: reduce over-damage

[Olivier Fourdan]

Hi Pekka,

On 22 January 2018 at 14:34, Pekka Paalanen 
wrote:

> On Wed, 20 Dec 2017 13:18:45 +0200
> Pekka Paalanen  wrote:
>
> > From: Pekka Paalanen 
> >
> > If an X11 app draws a little here, some there, and a tiny bit in the
> > opposite corner, using RegionExtents for the damage to be sent to the
> > Wayland compositor will cause massive over-damaging.
> >
> > However, we cannot blindly send an arbitrary number of damage
> > rectangles, because there is a risk of overflowing the Wayland
> > connection. If that happens, it triggers an abort in libwayland-client.
> >
> > Try to be more accurate with the damage by sending up to 500 rectangles
> > per window, and fall back to extents otherwise. The number is completely
> > arbitrary.
> >
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  hw/xwayland/xwayland.c | 18 +++---
> >  1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> > index c5a3ae7ae..383680d7a 100644
> > --- a/hw/xwayland/xwayland.c
> > +++ b/hw/xwayland/xwayland.c
> > @@ -629,6 +629,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
> >  BoxPtr box;
> >  struct wl_buffer *buffer;
> >  PixmapPtr pixmap;
> > +int i;
> >
> >  assert(!xwl_window->frame_callback);
> >
> > @@ -644,9 +645,20 @@ xwl_window_post_damage(struct xwl_window
> *xwl_window)
> >
> >  wl_surface_attach(xwl_window->surface, buffer, 0, 0);
> >
> > -box = RegionExtents(region);
> > -wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> > -box->x2 - box->x1, box->y2 - box->y1);
> > +/* Arbitrary limit to try to avoid flooding the Wayland
> > + * connection. If we flood it too much anyway, this could
> > + * abort in libwayland-client.
> > + */
> > +if (RegionNumRects(region) > 500) {
> > +box = RegionExtents(region);
> > +wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> > +  box->x2 - box->x1, box->y2 - box->y1);
> > +} else {
> > +box = RegionRects(region);
> > +for (i = 0; i < RegionNumRects(region); i++, box++)
> > +wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> > +  box->x2 - box->x1, box->y2 - box->y1);
> > +}
> >
> >  xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
> >  wl_callback_add_listener(xwl_window->frame_callback,
> _listener, xwl_window);
>
> Hi,
>
> should I invest the effort on a better algorithm than in this patch or
> would this be acceptable for landing?
>

Not sure which better algorithm you might have in mind here, but the
approach taken in your patch seems simple enough, do we have a rough idea
of the average number of rectangles we usually deal with here?

Cheers,
Olivier
___
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: [RFC xserver 1/1] xwayland: reduce over-damage

[Pekka Paalanen]

On Wed, 20 Dec 2017 13:18:45 +0200
Pekka Paalanen  wrote:

> From: Pekka Paalanen 
> 
> If an X11 app draws a little here, some there, and a tiny bit in the
> opposite corner, using RegionExtents for the damage to be sent to the
> Wayland compositor will cause massive over-damaging.
> 
> However, we cannot blindly send an arbitrary number of damage
> rectangles, because there is a risk of overflowing the Wayland
> connection. If that happens, it triggers an abort in libwayland-client.
> 
> Try to be more accurate with the damage by sending up to 500 rectangles
> per window, and fall back to extents otherwise. The number is completely
> arbitrary.
> 
> Signed-off-by: Pekka Paalanen 
> ---
>  hw/xwayland/xwayland.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index c5a3ae7ae..383680d7a 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -629,6 +629,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
>  BoxPtr box;
>  struct wl_buffer *buffer;
>  PixmapPtr pixmap;
> +int i;
>  
>  assert(!xwl_window->frame_callback);
>  
> @@ -644,9 +645,20 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
>  
>  wl_surface_attach(xwl_window->surface, buffer, 0, 0);
>  
> -box = RegionExtents(region);
> -wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> -box->x2 - box->x1, box->y2 - box->y1);
> +/* Arbitrary limit to try to avoid flooding the Wayland
> + * connection. If we flood it too much anyway, this could
> + * abort in libwayland-client.
> + */
> +if (RegionNumRects(region) > 500) {
> +box = RegionExtents(region);
> +wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> +  box->x2 - box->x1, box->y2 - box->y1);
> +} else {
> +box = RegionRects(region);
> +for (i = 0; i < RegionNumRects(region); i++, box++)
> +wl_surface_damage(xwl_window->surface, box->x1, box->y1,
> +  box->x2 - box->x1, box->y2 - box->y1);
> +}
>  
>  xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
>  wl_callback_add_listener(xwl_window->frame_callback, _listener, 
> xwl_window);

Hi,

should I invest the effort on a better algorithm than in this patch or
would this be acceptable for landing?


Thanks,
pq
___
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