Re: Request for feedback for my GSoC project to improve Present support in Xwayland

[Pekka Paalanen]

On Mon, 24 Jul 2017 04:07:11 +0200
Roman Gilg  wrote:

> Hi,
> 
> I'm working for my GSoC project on a better Present integration in
> Xwayland. This should improve performance as well as minimize tearing. My
> mentor is Daniel Stone and the starting point was my work on KWin and this
> bug report: https://bugs.freedesktop.org/show_bug.cgi?id=99702.
> 
> I'm writing this mail in order to get some feedback from the X.Org
> community regarding my current approach and the progress I've made so far.
> You can find my main working branch at
> https://github.com/subdiff/xserver/tree/presentInXwayland
> 
> I've tried to limit the changes to the Present code to a minimum. At the
> moment it should be able to flip Glamor/GBM Pixmaps of Present supporting
> clients to a Wayland surface for one full screen window without copies. The
> restriction of only one window, which is full screen, is in line with what
> is possible with the currently available functionality by the Present code
> in the Xserver.
> 
> I have tried to queue events on msc timings, but it's not really
> straightforward, since I think we need to read out some sort of Vblank
> counter from the Wayland server instead of the kernel. The frame callback
> is a candidate for that, but it needs at least in my KWin testing
> environment always a previous buffer commit to signal back. I create
> therefore dummy buffer commits, which then trigger the callback after every
> frame if there are events in the queue. This seems to work most of the
> times, but I've problems on window resizing. Apparently in these situations
> it's difficult to pick the right Pixmap and the associated Wayland buffer
> for the dummy commit. So for now I don't allow queuing events, which means
> that Pixmap flips are applied always immediately. What's your opinion? Is
> the construction with the frame callback as a msc counter and the dummy
> commits a bad idea in general or do you maybe know the answer why the
> window resizing is problematic in this context?

Hi,

the frame callback was never intended for "counting vblanks".
Compositors are encouraged to throttle down or completely stop frame
callbacks when the window cannot be seen. Also the definition of the
frame callback is "a good time to start drawing the next frame", which
intends for clients to have the maximum possible time available for
hitting the next deadline for screen. This is an arbitrary point in the
monitor refresh cycle depending on how the Wayland compositor is
scheduling its compositing.

Btw. I would advise against using the frame callback's argument for
anything serious. It is a timestamp in an undefined base and poorly
defined what it might correspond to, and may suffer from wraparound
issues.

Wayland Presentation-time is the extension intended for timing
feedback, and it allows to predict the future presentation times for a
few frames in advance if you can assume a constant frame rate.

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time

I believe there are still some gaps in how to reliably submit frames at
a rate lower than the output refresh rate.

Wayland Presentation-queue was an early companion to Presentation-time,
but did not make it in the protocol due to difficulties in defining it
and existing open issues. That extension would have allowed queueing
frames in the Wayland compositor based on target timestamp.

Another idea talked about a long time ago in relation to
Presentation-time was a vblank feedback stream, where every vblank (at
least the ones the compositor processed) would be signalled to
subscribed clients regardless of wl_surface updates, and without
explicit request for every event. It didn't raise enough interest at
the time.

In any case, Wayland aims for timestamp based presentation, not vblank
counting, because of outputs changing their frequencies (mode switch,
variable refresh rate monitors, ...). The feedback in Presentation-time
is ok for that, but using it for prediction is not guaranteed.
Presentation-queue would have improved the functionality a lot by
helping the Wayland compositor's frame scheduling.

Presentation-time does provide the MSC value though, if it exists.

I think we may need to clarify how Presentation-time should work with
wl_surface.commits that do not change the buffer nor apply damage. If
committed feedback request was guaranteed to deliver feedback
regardless of damage (I recall Weston might already work like this),
that would allow an easy way for a client to sync to the output refresh
cycle. The frame callback OTOH definitely should not be used for this.

Could you maybe start a discussion on wayland-devel@ about clarifying
Presentation-time on commits that do not cause a need to repaint in the
compositor?


Thanks,
pq


pgpsguolQSWGg.pgp
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: 

Re: Request for feedback for my GSoC project to improve Present support in Xwayland

[Daniel Stone]

Hi Pekka,

On 24 July 2017 at 08:48, Pekka Paalanen  wrote:
> Another idea talked about a long time ago in relation to
> Presentation-time was a vblank feedback stream, where every vblank (at
> least the ones the compositor processed) would be signalled to
> subscribed clients regardless of wl_surface updates, and without
> explicit request for every event. It didn't raise enough interest at
> the time.

It does exist, in Chromium's Wayland compositor:
https://chromium.googlesource.com/experimental/chromium/src/+/master/third_party/wayland-protocols/unstable/vsync-feedback/vsync-feedback-unstable-v1.xml

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

xserver bug consult

[q w]

Hi,

I am currently working on a project, and xserver is a dependency.

I encountered the bug in the link below:
 https://bugs.freedesktop.org/show_bug.cgi?id=100293

>From the comments, I can see that the code has been merged to main branch.
But the latest package 1.19.3 does not contain this fix.


Its kinda of urgent and block the project, So i clone the code to my local
machine, and wonder if I can build the package or binary myself.

For now, I can build the code sucessfully, but the binary Xorg does not
perform correctly. (no screen found, etc.).  I was wondering if you could
provide some tips on how to build the package and install it.


Thanks,
Qian Wang
___
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 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen

[Pali Rohár]

On Sunday 28 May 2017 23:33:59 Pali Rohár wrote:
> Explicitly document and make it clear that those options does not change
> DPI of some monitor output. Also state that these options have no useful
> meaning for multi-monitor configuration.
> 
> Signed-off-by: Pali Rohár 
> ---
>  man/xrandr.man |   14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/man/xrandr.man b/man/xrandr.man
> index 55ea5dd..fec4a1a 100644
> --- a/man/xrandr.man
> +++ b/man/xrandr.man
> @@ -226,14 +226,20 @@ fit within this size. When this option is not provided, 
> xrandr computes the
>  smallest screen size that will hold the set of configured outputs; this
>  option provides a way to override that behaviour.
>  .IP "\-\-fbmm \fIwidth\fPx\fIheight\fP"
> -Sets the reported values for the physical size of the screen. Normally,
> +Sets the reported values for the physical size of the whole X screen (not 
> particular
> +output!) which consists of all configured monitors. Physical size of the X 
> screen does
> +not have any meaning when two monitors with different DPI are configured. 
> Normally,
>  xrandr resets the reported physical size values to keep the DPI constant.
> -This overrides that computation.
> +This overrides that computation. This option should be calculated from DPI
> +value 96 as it not have any useful meaning for multi-monitor configuration.
>  .IP "\-\-dpi \fIdpi\fP"
>  .IP "\-\-dpi \fIfrom-output\fP"
> -This also sets the reported physical size values of the screen, it uses 
> either
> +This also sets the reported physical size values of the whole X screen (not 
> particular
> +output!) which consists of all configured monitors. Physical size of the X 
> screen does not
> +have any meaning when two monitors with different DPI are configured. This 
> option uses either
>  the specified DPI value, or the DPI of the given output, to compute an 
> appropriate
> -physical size using whatever pixel size will be set.
> +physical size using whatever pixel size will be set. This option should be 
> set to
> +default value 96 as it not have any useful meaning for multi-monitor 
> configuration.
>  .IP "\-\-newmode \fIname\fP \fImode\fP"
>  New modelines can be added to the server and then associated with outputs.
>  This option does the former. The \fImode\fP is specified using the ModeLine

PING, can somebody review this patch?

-- 
Pali Rohár
pali.ro...@gmail.com
___
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

Fwd: xserver bug consult

[q w]

Hi, I encountered the bug in the link below:
 https://bugs.freedesktop.org/show_bug.cgi?id=100293

Will the fix in the
coming package.1.19.4, if yes, when will it come out?

Thanks,
Qian Wang

-- Forwarded message --
From: Michel Dänzer 
Date: Mon, Jul 24, 2017 at 10:22 AM
Subject: Re: xserver bug consult
To: q w 


On 24/07/17 11:14 AM, q w wrote:
> Hi michel,
>
>
>
> I encountered the same problem described in this link:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100293
>
>
> Will the fix in the coming package.1.19.4, if yes, when will it come out?

If there is a 1.19.4, the fix will likely be included
(https://lists.x.org/archives/xorg-devel/2017-July/054135.html), but I
don't know if / when there will be a 1.19.4. You'd have to ask Adam
Jackson / the xorg-devel mailing list.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen

[walter harms]

documentation is a painful job, thx for doing this.

re,
 wh

Am 28.05.2017 23:33, schrieb Pali Rohár:
> Explicitly document and make it clear that those options does not change
> DPI of some monitor output. Also state that these options have no useful
> meaning for multi-monitor configuration.
> 
> Signed-off-by: Pali Rohár 
> ---
>  man/xrandr.man |   14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/man/xrandr.man b/man/xrandr.man
> index 55ea5dd..fec4a1a 100644
> --- a/man/xrandr.man
> +++ b/man/xrandr.man
> @@ -226,14 +226,20 @@ fit within this size. When this option is not provided, 
> xrandr computes the
>  smallest screen size that will hold the set of configured outputs; this
>  option provides a way to override that behaviour.
>  .IP "\-\-fbmm \fIwidth\fPx\fIheight\fP"
> -Sets the reported values for the physical size of the screen. Normally,
> +Sets the reported values for the physical size of the whole X screen (not 
> particular
> +output!) which consists of all configured monitors. Physical size of the X 
> screen does
> +not have any meaning when two monitors with different DPI are configured. 
> Normally,
>  xrandr resets the reported physical size values to keep the DPI constant.
> -This overrides that computation.
> +This overrides that computation. This option should be calculated from DPI
> +value 96 as it not have any useful meaning for multi-monitor configuration.
>  .IP "\-\-dpi \fIdpi\fP"
>  .IP "\-\-dpi \fIfrom-output\fP"
> -This also sets the reported physical size values of the screen, it uses 
> either
> +This also sets the reported physical size values of the whole X screen (not 
> particular
> +output!) which consists of all configured monitors. Physical size of the X 
> screen does not
> +have any meaning when two monitors with different DPI are configured. This 
> option uses either

No number needed:

"have any meaning when monitors with different DPI are configured."

>  the specified DPI value, or the DPI of the given output, to compute an 
> appropriate
> -physical size using whatever pixel size will be set.
> +physical size using whatever pixel size will be set. This option should be 
> set to
> +default value 96 as it not have any useful meaning for multi-monitor 
> configuration.

The "default value 96" is confusing me, perhaps a simple reordering may help:

physical size using whatever pixel size will be set (default 96 DPI). It does 
not have any useful
meaning for multi-monitor configuration.


>  .IP "\-\-newmode \fIname\fP \fImode\fP"
>  New modelines can be added to the server and then associated with outputs.
>  This option does the former. The \fImode\fP is specified using the ModeLine
___
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 v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen

[Pali Rohár]

Explicitly document and make it clear that those options do not change
DPI of some monitor output. Also state that these options have no useful
meaning for multi-monitor configuration.

Signed-off-by: Pali Rohár 
---
 man/xrandr.man |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/man/xrandr.man b/man/xrandr.man
index 65ccc2a..a5476d4 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -232,14 +232,20 @@ fit within this size. When this option is not provided, 
xrandr computes the
 smallest screen size that will hold the set of configured outputs; this
 option provides a way to override that behaviour.
 .IP "\-\-fbmm \fIwidth\fPx\fIheight\fP"
-Sets the reported values for the physical size of the screen. Normally,
+Sets the reported values for the physical size of the whole X screen (not 
particular
+output!) which consists of all configured monitors. Physical size of the X 
screen does
+not have any meaning when monitors with different DPI are configured. Normally,
 xrandr resets the reported physical size values to keep the DPI constant.
-This overrides that computation.
+This overrides that computation. This option should be calculated from DPI
+value 96 as it not have any useful meaning for multi-monitor configuration.
 .IP "\-\-dpi \fIdpi\fP"
 .IP "\-\-dpi \fIfrom-output\fP"
-This also sets the reported physical size values of the screen, it uses either
+This also sets the reported physical size values of the whole X screen (not 
particular
+output!) which consists of all configured monitors. Physical size of the X 
screen does not
+have any meaning when monitors with different DPI are configured. This option 
uses either
 the specified DPI value, or the DPI of the given output, to compute an 
appropriate
-physical size using whatever pixel size will be set.
+physical size using whatever pixel size will be set (default 96 DPI). It does 
not
+have any useful meaning for multi-monitor configuration.
 .IP "\-\-newmode \fIname\fP \fImode\fP"
 New modelines can be added to the server and then associated with outputs.
 This option does the former. The \fImode\fP is specified using the ModeLine
-- 
1.7.9.5

___
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 xinput] man: document an example for a set-prop call

[Peter Hutterer]

Because it's 99% of the use-cases people use libinput for these days.

Signed-off-by: Peter Hutterer 
---
 man/xinput.man | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/man/xinput.man b/man/xinput.man
index 87be8c7..b89fb01 100644
--- a/man/xinput.man
+++ b/man/xinput.man
@@ -87,7 +87,7 @@ instead.
 .B --set\-prop [\-\-type=\fIatom|float|int\fP] [\-\-format=\fI8|16|32\fP] 
\fIdevice\fP \fIproperty\fP \fIvalue\fP [...]
 Set the property to the given value(s).  If not specified, the format and type
 of the property are left as-is.  The arguments are interpreted according to the
-property type.
+property type. See Section \fICHANGING PROPERTIES\fP.
 .PP
 .TP 8
 .B --watch-props \fIdevice\fP
@@ -171,6 +171,13 @@ device.
 .PP
 \fIproperty\fP can be the property as a string or the Atom value.
 .PP
+.SH "CHANGING PROPERTIES"
+When xinput should modify an existing driver property value, it is
+sufficient to provide the device name and property name as string, followed
+by the new value(s) of the property. For example:
+.IP
+\fBxinput set-prop "my device" "my prop" 1 2 3\fB
+
 .SH "SEE ALSO"
 X(__miscmansuffix__), xset(__appmansuffix__), xrandr(__appmansuffix__)
 .SH COPYRIGHT
-- 
2.13.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