Re: [PATCH] modesetting: Update props for dynamically added outputs

[Michel Dänzer]

On 2019-08-20 6:01 p.m., Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Dynamically added outputs should have their properties
> properly updated as well. Otherwise we're left with an output
> with many of its propeties not exposed.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index e0d7cfb5c708..f621df52f3f7 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -3003,8 +3003,14 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr 
> drmmode, drmModeResPtr mode_r
>  "DPMS");
>  }
>  
> -if (dynamic)
> +if (dynamic) {
>  output->randr_output = RROutputCreate(xf86ScrnToScreen(pScrn), 
> output->name, strlen(output->name), output);
> +if (output->randr_output) {
> +drmmode_output_create_resources(output);
> +RRPostPendingProperties(output->randr_output);
> +}
> +}
> +
>  return 1;
>  
>   out_free_encoders:
> 

Reviewed-by: Michel Dänzer 


P.S. xserver patches are now being reviewed as GitLab merge requests:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests

-- 
Earthling Michel Dänzer   |   https://redhat.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

[PATCH] modesetting: Update props for dynamically added outputs

[Ville Syrjala]

From: Ville Syrjälä 

Dynamically added outputs should have their properties
properly updated as well. Otherwise we're left with an output
with many of its propeties not exposed.

Signed-off-by: Ville Syrjälä 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index e0d7cfb5c708..f621df52f3f7 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -3003,8 +3003,14 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr 
drmmode, drmModeResPtr mode_r
 "DPMS");
 }
 
-if (dynamic)
+if (dynamic) {
 output->randr_output = RROutputCreate(xf86ScrnToScreen(pScrn), 
output->name, strlen(output->name), output);
+if (output->randr_output) {
+drmmode_output_create_resources(output);
+RRPostPendingProperties(output->randr_output);
+}
+}
+
 return 1;
 
  out_free_encoders:
-- 
2.21.0

___
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

update

[walter harms]

hi,
es gab ein update für inno.x auf der 183.121.
Sichbar vor allem ist das es nun ein startscript gibt (inno.sh)
das aus/an schalten der sonde erfolgt nun extern im script *immer*
wenn sich das programm beendet hat.

re,
 wh
___
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 xorgproto] Update URLs for protocol specs to use xorgproto repo now

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
 randrproto.txt | 2 +-
 specs/XI2proto.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/randrproto.txt b/randrproto.txt
index faafc4c..88f06cc 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -3427,4 +3427,4 @@ Bibliography
 
 [RENDER]
Packard, Keith, "The X Rendering Extension", work in progress,
-   http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
+   
https://gitlab.freedesktop.org/xorg/proto/xorgproto/raw/master/renderproto.txt
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 697dd89..440b0d0 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -574,7 +574,7 @@ that pointer's direction, the movement of the pointer is 
clamped to the x or
 y coordinate of the barrier, whichever applies. For a description of pointer
 barriers and barrier creation and destruction see the XFixes protocol
 specification v 5.0 or later.
-http://cgit.freedesktop.org/xorg/proto/fixesproto/plain/fixesproto.txt
+https://gitlab.freedesktop.org/xorg/proto/xorgproto/raw/master/fixesproto.txt
 
 A pointer hitting a blocking barrier creates a new barrier event sequence,
 identified by a unique event ID. A new event ID is assigned when the pointer
-- 
2.15.2

___
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 xorg-docs 1/4] Update docs for gitlab migration

[Alan Coopersmith]

On 11/19/18 07:05 AM, Adam Jackson wrote:

On Sat, 2018-11-17 at 14:46 -0800, Alan Coopersmith wrote:


  in future releases.   More details on patch submission and review
  process are available on the
-http://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
+https://www.x.org/wiki/Development/Documentation/SubmittingPatches;>


I've updated this wiki page to talk about gitlab first, and moved the
email-based workflow to the end.


Thanks!  (And thanks for the reviews of this series.)

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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 xorg-docs 1/4] Update docs for gitlab migration

[Adam Jackson]

On Sat, 2018-11-17 at 14:46 -0800, Alan Coopersmith wrote:

> diff --git a/general/README.xml b/general/README.xml
> index 7446fa0..b7fe484 100644
> --- a/general/README.xml
> +++ b/general/README.xml
> @@ -243,13 +243,12 @@ page.
>  
>  
>  If you have any new work or enhancements/bug fixes for existing work,
> -please send them as git format patches to
> -xorg-de...@lists.freedesktop.org or to our
> -https://bugs.freedesktop.org/;>bug tracking system
> -using the xorg component.  This will help ensure that they are included
> +please submit them via
> +https://gitlab.freedesktop.org/xorg;>the gitlab.freedesktop.org 
> code management system.
> +This will help ensure that they are included
>  in future releases.   More details on patch submission and review
>  process are available on the
> - url="http://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
> + url="https://www.x.org/wiki/Development/Documentation/SubmittingPatches;>

I've updated this wiki page to talk about gitlab first, and moved the
email-based workflow to the end.

Series is:

Reviewed-by: Adam Jackson 

- 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 xorg-docs 2/4] Update configure.ac for gitlab migration

[Alan Coopersmith]

On 11/17/18 02:46 PM, Alan Coopersmith wrote:

Signed-off-by: Alan Coopersmith 
---
  configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 80d7307..de17002 100644
--- a/configure.ac
+++ b/configure.ac
@@ -24,7 +24,7 @@ dnl  Process this file with autoconf to create configure.
  AC_PREREQ([2.60])
  AC_INIT([xorg-docs],
  [1.7.1],
-[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
+[https://gitlab.freedesktop.org/xorg/doc/xorg-docs/issues],
  [xorg-docs])
  AC_CONFIG_SRCDIR([Makefile.am])
  



I expect we'll make the equivalent change to all our repos, this is just
the one I was working on when I realized that we needed it.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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 xorg-docs 1/4] Update docs for gitlab migration

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
 general/README.xml| 15 +++
 general/ReleaseNotes.xml  | 14 ++
 general/platforms/Solaris.xml |  3 +--
 man/XOrgFoundation.man|  4 ++--
 registry  |  2 +-
 5 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/general/README.xml b/general/README.xml
index 7446fa0..b7fe484 100644
--- a/general/README.xml
+++ b/general/README.xml
@@ -243,13 +243,12 @@ page.
 
 
 If you have any new work or enhancements/bug fixes for existing work,
-please send them as git format patches to
-xorg-de...@lists.freedesktop.org or to our
-https://bugs.freedesktop.org/;>bug tracking system
-using the xorg component.  This will help ensure that they are included
+please submit them via
+https://gitlab.freedesktop.org/xorg;>the gitlab.freedesktop.org 
code management system.
+This will help ensure that they are included
 in future releases.   More details on patch submission and review
 process are available on the
-http://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
+https://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
 SubmittingPatches page of the X.Org wiki.
 
 
@@ -309,7 +308,7 @@ build system and modular code base.
 The X source code for this and all releases/snapshots as well as
 development versions can also be accessed via the Freedesktop.org git
 repository.  It's also possible to browse the http://cgit.freedesktop.org/xorg/;
+url="https://gitlab.freedesktop.org/xorg/;
 >freedesktop git repository.
 
@@ -327,8 +326,8 @@ To check out the latest development version, don't specify 
any tag.
 
 
 Bugs should be reported to freedesktop.org's https://bugs.freedesktop.org/;>bug tracking system
-using the xorg component.  Before
+url="https://gitlab.freedesktop.org/xorg/;>code management system.
+Before
 reporting bugs, please check the server log file, which can be found at
 /var/log/Xorg.0.log on most platforms.  If you can't
 resolve the problem yourself, send the entire log file with your bug report but
diff --git a/general/ReleaseNotes.xml b/general/ReleaseNotes.xml
index 0b0c913..0aa9ee1 100644
--- a/general/ReleaseNotes.xml
+++ b/general/ReleaseNotes.xml
@@ -86,11 +86,9 @@
 
 
 
-  We encourage you to report bugs using
-  freedesktop.org's https://bugs.freedesktop.org/;>
-   bug tracking system using the xorg product, and to
-  submit bug fixes and enhancements to
-  xorg-devel@lists.x.org.
+  We encourage you to report bugs, and to
+  submit bug fixes and enhancements via
+https://gitlab.freedesktop.org/xorg;>the gitlab.freedesktop.org 
code management system.
   More details on patch submission and review process are available on the
   http://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
@@ -1030,8 +1028,8 @@ 
url="http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html;
 turn these selected warnings into errors by adding
 --disable-selective-werror to the configure command
 for the affected module.   If that is necessary for any X.Org modules,
-please report a bug in the xorg product on
-https://bugs.freedesktop.org/; />.
+please report a bug in the project for that module on
+https://gitlab.freedesktop.org/xorg; />.
   
 
   
@@ -1346,7 +1344,7 @@ 
url="http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html;
   This section lists the credits for the X11R release.
   For a more detailed breakdown, refer to the ChangeLog file in
   the source tree for each module, the history in http://cgit.freedesktop.org/xorg/;>the xorg product in
+   url="https://gitlab.freedesktop.org/xorg;>the xorg projects in
freedesktop.org's git repositories or the
   'git log' information for individual source files.
 
diff --git a/general/platforms/Solaris.xml b/general/platforms/Solaris.xml
index dfd2106..953e733 100644
--- a/general/platforms/Solaris.xml
+++ b/general/platforms/Solaris.xml
@@ -165,8 +165,7 @@ Xqueue is NOT supported 
under Solaris.
 
 
 Bug reports should be reported at
-http://bugs.freedesktop.org/;> using the
-xorg product or sent to x...@lists.freedesktop.org.
+https://gitlab.freedesktop.org/xorg; />.
 
 
 
diff --git a/man/XOrgFoundation.man b/man/XOrgFoundation.man
index 0ed0779..13d7da7 100644
--- a/man/XOrgFoundation.man
+++ b/man/XOrgFoundation.man
@@ -52,6 +52,6 @@ The X.Org Foundation's web site is http://www.x.org/
 .PP
 The X.Org Foundation's public ftp site is ftp://ftp.x.org/
 .PP
-Information about the X.Org Foundation git repository is on the
-X.Org web site at http://www.x.org/wiki/Development/git
+The X.Org Foundation's public source repositories are at
+https://gitlab.freedesktop.org/xorg
 .fi
diff --git a/registry b/registry
index 4c332ed..81c28f9 100644
--- a/registry
+++ b/registry
@@ -21,7 +21,7 @@ Please allow up to 4 weeks for a formal response to 
registration and 

[PATCH xorg-docs 3/4] Update MAINTAINERS for gitlab migration

[Alan Coopersmith]

Replace dozens of links to wiki.x.org with gitlab project links
Change status to "Deactivated" for projects marked "Archived" in gitlab

Signed-off-by: Alan Coopersmith 
---
 MAINTAINERS | 218 ++--
 1 file changed, 109 insertions(+), 109 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5316057..b09dd1f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -46,14 +46,14 @@ DRM library
 P: Adam Jackson
 M: a...@nwnk.net
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/mesa/drm
 S: Maintained
 
 PCI Access Library
 P: Ian Romanick
 M: ?
 L: xorg-devel@lists.x.org
-W: http://wiki.freedesktop.org/wiki/PciRework
+W: https://gitlab.freedesktop.org/xorg/lib/libpciaccess
 S: Supported
 
 X.Org apps
@@ -81,63 +81,63 @@ xauth
 P: Dr. Tilmann Bubeck
 M: t.bub...@reinform.de
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xauth
 S: Maintained
 
 xbiff
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xbiff
 S: Maintained
 
 xcalc 
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xcalc
 S: Maintained
 
 xclock
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xclock
 S: Maintained
 
 xconsole
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xconsole
 S: Maintained
 
 xdm
 P: Alan Coopersmith
 M: alan.coopersm...@oracle.com
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xdm
 S: Maintained
 
 xedit
 P: Paulo César Pereira de Andrade
 M: p...@mandriva.com.br
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xedit
 S: Maintained
 
 xinput
 P: Peter Hutterer
 M: peter.hutte...@who-t.net
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xinput
 S: Maintained
 
 xkbcomp
 P: Daniel Stone
 M: dan...@fooishbar.org
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xkbcomp
 S: Maintained
 S: XKB being overhauled
 S: Please contact Daniel if you're planning to work on this
@@ -146,21 +146,21 @@ xload
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xload
 S: Maintained
 
 xman 
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xman
 S: Maintained
 
 xmessage
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xmessage
 S: Maintained
 
 xmh
@@ -176,14 +176,14 @@ xsetroot
 P: Matthieu Herrb
 M: matthieu.he...@laas.fr
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app/xsetroot
 S: Maintained
 
 all others
 P: ?
 M: xorg-devel@lists.x.org
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/app
 S: Unmaintained
 
 X.Org libraries
@@ -204,7 +204,7 @@ X11, Xcomposite, Xcursor, Xdamage, Xfixes, Xrandr, Xrender
 P: Keith Packard
 M: keith.pack...@intel.com
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/lib
 S: Maintained
 
 Xdmcp
@@ -228,14 +228,14 @@ Xi
 P: Peter Hutterer
 M: peter.hutte...@who-t.net
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/lib/libxi
 S: Maintained
 
 xkbfile
 P: Daniel Stone
 M: dan...@fooishbar.org
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
+W: https://gitlab.freedesktop.org/xorg/lib/libxkbfile
 S: Maintained
 S: XKB being overhauled
 S: Please contact Daniel if you're planning to work on this
@@ -283,7 +283,7 @@ xtrans
 P:  Bill Crawford
 M:  billcrawford1...@gmail.com
 L:  xorg-devel@lists.x.org
-W:  http://wiki.x.org
+W:  https://gitlab.freedesktop.org/xorg/lib/libxtrans
 S:  Maintained
 
 X.Org core
@@ -409,8 +409,8 @@ P:  Drew Parsons
 P: Felix Schulte
 M: ?
 L: xorg-devel@lists.x.org
-W: http://wiki.x.org
-S: Maintained
+W: https://gitlab.freedesktop.org/xorg/xserver-xprint
+S: Deactivated
 
 X.Org OS ports
 

[PATCH xorg-docs 0/4] Update docs for gitlab migration & http->https

[Alan Coopersmith]

This series is also covered by
https://gitlab.freedesktop.org/xorg/doc/xorg-docs/merge_requests/1
but email still seems to get more attention than merge requests on
the less active repos.

[PATCH xorg-docs 1/4] Update docs for gitlab migration
[PATCH xorg-docs 2/4] Update configure.ac for gitlab migration
[PATCH xorg-docs 3/4] Update MAINTAINERS for gitlab migration
[PATCH xorg-docs 4/4] Mass http -> https replacement where

There are still plenty of other things to update in MAINTAINERS,
like entries for Keith using his intel.com email, or changing
the xf86-video-nv driver to a state other than "Maintained", but
I'm leaving those as an exercise for others at this point.

(There's also some other things I see in the docs to cleanup before
 doing a release, but that's a project for another day, while this
 batch is ready to go.)

-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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 xorg-docs 2/4] Update configure.ac for gitlab migration

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 80d7307..de17002 100644
--- a/configure.ac
+++ b/configure.ac
@@ -24,7 +24,7 @@ dnl  Process this file with autoconf to create configure.
 AC_PREREQ([2.60])
 AC_INIT([xorg-docs],
 [1.7.1],
-[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
+[https://gitlab.freedesktop.org/xorg/doc/xorg-docs/issues],
 [xorg-docs])
 AC_CONFIG_SRCDIR([Makefile.am])
 
-- 
2.15.2

___
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/xcursorgen v3] Update README for gitlab migration

[Keith Packard]

Alan Coopersmith  writes:

> On 11/13/18 05:13 PM, Ray Strode wrote:
>> hi,
>> 
>> On Tue, Nov 13, 2018, 7:57 PM Alan Coopersmith >  wrote:
>> 
>> Anyone have a preference?   Shipping README.md seems easier - will it 
>> cause
>> problems for any distros or packagers?
>> 
>> i think README.md is the right way to go.  presumably any packaging 
>> challenges 
>> have been ironed out by now considering how widespread gitlab/github is now.
>
> Since Keith objected to git committing symlinks, I'll go ahead with

Yeah, it just seems like a bad idea somehow...

>   EXTRA_DIST += README.md
> when checking these in and leave anything fancier for someone else to
> tackle in the future.

Sounds like a fine plan to me. Thanks for taking care of this.

-- 
-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: [PATCH app/xcursorgen v3] Update README for gitlab migration

[Alan Coopersmith]

On 11/13/18 05:13 PM, Ray Strode wrote:

hi,

On Tue, Nov 13, 2018, 7:57 PM Alan Coopersmith  wrote:


Anyone have a preference?   Shipping README.md seems easier - will it cause
problems for any distros or packagers?

i think README.md is the right way to go.  presumably any packaging challenges 
have been ironed out by now considering how widespread gitlab/github is now.


Since Keith objected to git committing symlinks, I'll go ahead with
EXTRA_DIST += README.md
when checking these in and leave anything fancier for someone else to
tackle in the future.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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/xcursorgen v3] Update README for gitlab migration

[Alan Coopersmith]

On 11/13/18 08:50 PM, Keith Packard wrote:

Alan Coopersmith  writes:


3rd choice - this seems to work for me, shipping a file named README in the
tarball without any Makefile modifications:


Yikes! Scary git-fu!

Maybe we can see if cmark-gfm is available? That's the github fork that
parses more useful common mark syntax files, which should be starting to
show up in distros (it's in Debian at least).

 $ cmark-gfm --to plaintext README.md > README

if we actually want to generate a plaintext README file? Until then,
just copy it?


Perhaps if any modules have complex markup in their README's in the future
they can do that.   Right now, the README.md is perfectly readable as plain
text without any scripting:

%  cat README.md
xcursorgen prepares X11 cursor sets for use with libXcursor.

All questions regarding this software should be directed at the
Xorg mailing list:

  https://lists.x.org/mailman/listinfo/xorg

The master development code repository can be found at:

  https://gitlab.freedesktop.org/xorg/app/xcursorgen

Please submit bug reports and requests to merge patches there.

For patch submission instructions, see:

  https://www.x.org/wiki/Development/Documentation/SubmittingPatches

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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/xcursorgen v3] Update README for gitlab migration

[Matthieu Herrb]

On Tue, Nov 13, 2018 at 08:50:11PM -0800, Keith Packard wrote:
> Alan Coopersmith  writes:
> 
> > 3rd choice - this seems to work for me, shipping a file named README in the
> > tarball without any Makefile modifications:
> 
> Yikes! Scary git-fu!
> 
> Maybe we can see if cmark-gfm is available? That's the github fork that
> parses more useful common mark syntax files, which should be starting to
> show up in distros (it's in Debian at least).
> 
> $ cmark-gfm --to plaintext README.md > README

I'd prefer avoiding depending on tools that aren't widely available
yet to make release. I can't find it on Ubuntu LTS. (There is the
original cmark in OpenBSD ports but I didn't find it on Ubuntu LTS
either).

> 
> if we actually want to generate a plaintext README file? Until then,
> just copy it?

I prefer to just ship README.md alone. As Ray say people are used to
that now.
-- 
Matthieu Herrb


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: [PATCH app/xcursorgen v3] Update README for gitlab migration

[Keith Packard]

Alan Coopersmith  writes:

> 3rd choice - this seems to work for me, shipping a file named README in the
> tarball without any Makefile modifications:

Yikes! Scary git-fu!

Maybe we can see if cmark-gfm is available? That's the github fork that
parses more useful common mark syntax files, which should be starting to
show up in distros (it's in Debian at least).

$ cmark-gfm --to plaintext README.md > README

if we actually want to generate a plaintext README file? Until then,
just copy it?

-- 
-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: [PATCH app/xcursorgen v3] Update README for gitlab migration

[Ray Strode]

hi,

On Tue, Nov 13, 2018, 7:57 PM Alan Coopersmith  Anyone have a preference?   Shipping README.md seems easier - will it cause
> problems for any distros or packagers?
>
i think README.md is the right way to go.  presumably any packaging
challenges have been ironed out by now considering how widespread
gitlab/github is now.

Ray
___
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/xcursorgen v3] Update README for gitlab migration

[Alan Coopersmith]

On 11/13/18 04:57 PM, Alan Coopersmith wrote:

On 11/13/18 05:41 AM, Julien Cristau wrote:

LGTM.  Thanks Alan!


Thanks to you, Peter, & Ray for reviews.   I merged this, and thought
"Okay, time to cut a new release."  And then I found the mistake.

automake automatically includes a file named "README" in the tarball.
It does not include a file named "README.md".

So, we seem to have two choices:

1) Ship with README.md:
 Just add "EXTRA_DIST = README.md" to Makefile.am in every component.
.
2) Ship with README:
    Follow our pattern with Changelog & INSTALL files and add a macro
    to xorg-macros.m4 to define a makefile macro such as:
 README_CMD = cp -f $(top_srcdir)/README.md $(top_srcdir)/README
    and in Makefile.am in every component:

+README:
+    $(README_CMD)
+
-dist-hook: ChangeLog INSTALL
+dist-hook: ChangeLog INSTALL README


Anyone have a preference?   Shipping README.md seems easier - will it cause
problems for any distros or packagers?


3rd choice - this seems to work for me, shipping a file named README in the
tarball without any Makefile modifications:

% ln -s README.md README
% git add README
% git commit -m 'ln -s README.md README'

Is checking symlinks into git going to break Windows or any other platforms?

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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/xcursorgen v3] Update README for gitlab migration

[Alan Coopersmith]

On 11/13/18 05:41 AM, Julien Cristau wrote:

LGTM.  Thanks Alan!


Thanks to you, Peter, & Ray for reviews.   I merged this, and thought
"Okay, time to cut a new release."  And then I found the mistake.

automake automatically includes a file named "README" in the tarball.
It does not include a file named "README.md".

So, we seem to have two choices:

1) Ship with README.md:
Just add "EXTRA_DIST = README.md" to Makefile.am in every component.
.
2) Ship with README:
   Follow our pattern with Changelog & INSTALL files and add a macro
   to xorg-macros.m4 to define a makefile macro such as:
README_CMD = cp -f $(top_srcdir)/README.md $(top_srcdir)/README
   and in Makefile.am in every component:

+README:
+   $(README_CMD)
+
-dist-hook: ChangeLog INSTALL
+dist-hook: ChangeLog INSTALL README


Anyone have a preference?   Shipping README.md seems easier - will it cause
problems for any distros or packagers?

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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/xcursorgen v3] Update README for gitlab migration

[Peter Hutterer]

On Mon, Nov 12, 2018 at 11:55:18AM -0800, Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith 

Reviewed-by: Peter Hutterer 
> ---
> 
> v2: Moved to README.md and reduced whitespace in front of URLs so that
>  gitlab renders them as links instead of code fragements - see
>  https://gitlab.freedesktop.org/alanc/xcursorgen for formatted view
> Restored link to Submitting Patches page so that we have a place to
>  provide instructions on how we use gitlab.
> Removed GitPage link.
> Changed mailman link from fd.o to x.org URL
> v3: Change remaining http URLs to https
> 
>  README| 25 -
>  README.md | 17 +
>  2 files changed, 17 insertions(+), 25 deletions(-)
>  delete mode 100644 README
>  create mode 100644 README.md
> 
> diff --git a/README b/README
> deleted file mode 100644
> index 6e46f96..000
> --- a/README
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -xcursorgen prepares X11 cursor sets for use with libXcursor.
> -
> -All questions regarding this software should be directed at the
> -Xorg mailing list:
> -
> -http://lists.freedesktop.org/mailman/listinfo/xorg
> -
> -Please submit bug reports to the Xorg bugzilla:
> -
> -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
> -
> -The master development code repository can be found at:
> -
> -git://anongit.freedesktop.org/git/xorg/app/xcursorgen
> -
> -http://cgit.freedesktop.org/xorg/app/xcursorgen
> -
> -For patch submission instructions, see:
> -
> - http://www.x.org/wiki/Development/Documentation/SubmittingPatches
> -
> -For more information on the git code manager, see:
> -
> -http://wiki.x.org/wiki/GitPage
> -
> diff --git a/README.md b/README.md
> new file mode 100644
> index 000..a935f4e
> --- /dev/null
> +++ b/README.md
> @@ -0,0 +1,17 @@
> +xcursorgen prepares X11 cursor sets for use with libXcursor.
> +
> +All questions regarding this software should be directed at the
> +Xorg mailing list:
> +
> +  https://lists.x.org/mailman/listinfo/xorg
> +
> +The master development code repository can be found at:
> +
> +  https://gitlab.freedesktop.org/xorg/app/xcursorgen
> +
> +Please submit bug reports and requests to merge patches there.
> +
> +For patch submission instructions, see:
> +
> +  https://www.x.org/wiki/Development/Documentation/SubmittingPatches
> +
> -- 
> 2.15.2
> 
> ___
> 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

[PATCH app/xcursorgen v3] Update README for gitlab migration

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---

v2: Moved to README.md and reduced whitespace in front of URLs so that
 gitlab renders them as links instead of code fragements - see
 https://gitlab.freedesktop.org/alanc/xcursorgen for formatted view
Restored link to Submitting Patches page so that we have a place to
 provide instructions on how we use gitlab.
Removed GitPage link.
Changed mailman link from fd.o to x.org URL
v3: Change remaining http URLs to https

 README| 25 -
 README.md | 17 +
 2 files changed, 17 insertions(+), 25 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md

diff --git a/README b/README
deleted file mode 100644
index 6e46f96..000
--- a/README
+++ /dev/null
@@ -1,25 +0,0 @@
-xcursorgen prepares X11 cursor sets for use with libXcursor.
-
-All questions regarding this software should be directed at the
-Xorg mailing list:
-
-http://lists.freedesktop.org/mailman/listinfo/xorg
-
-Please submit bug reports to the Xorg bugzilla:
-
-https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
-
-The master development code repository can be found at:
-
-git://anongit.freedesktop.org/git/xorg/app/xcursorgen
-
-http://cgit.freedesktop.org/xorg/app/xcursorgen
-
-For patch submission instructions, see:
-
-   http://www.x.org/wiki/Development/Documentation/SubmittingPatches
-
-For more information on the git code manager, see:
-
-http://wiki.x.org/wiki/GitPage
-
diff --git a/README.md b/README.md
new file mode 100644
index 000..a935f4e
--- /dev/null
+++ b/README.md
@@ -0,0 +1,17 @@
+xcursorgen prepares X11 cursor sets for use with libXcursor.
+
+All questions regarding this software should be directed at the
+Xorg mailing list:
+
+  https://lists.x.org/mailman/listinfo/xorg
+
+The master development code repository can be found at:
+
+  https://gitlab.freedesktop.org/xorg/app/xcursorgen
+
+Please submit bug reports and requests to merge patches there.
+
+For patch submission instructions, see:
+
+  https://www.x.org/wiki/Development/Documentation/SubmittingPatches
+
-- 
2.15.2

___
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 app/xcursorgen v2] Update README for gitlab migration

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
v2: Moved to README.md and reduced whitespace in front of URLs so that
 gitlab renders them as links instead of code fragements - see
 https://gitlab.freedesktop.org/alanc/xcursorgen for formatted view
Restored link to Submitting Patches page so that we have a place to
 provide instructions on how we use gitlab.
Removed GitPage link.
Changed mailman link from fd.o to x.org URL

 README| 25 -
 README.md | 17 +
 2 files changed, 17 insertions(+), 25 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md

diff --git a/README b/README
deleted file mode 100644
index 6e46f96..000
--- a/README
+++ /dev/null
@@ -1,25 +0,0 @@
-xcursorgen prepares X11 cursor sets for use with libXcursor.
-
-All questions regarding this software should be directed at the
-Xorg mailing list:
-
-http://lists.freedesktop.org/mailman/listinfo/xorg
-
-Please submit bug reports to the Xorg bugzilla:
-
-https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
-
-The master development code repository can be found at:
-
-git://anongit.freedesktop.org/git/xorg/app/xcursorgen
-
-http://cgit.freedesktop.org/xorg/app/xcursorgen
-
-For patch submission instructions, see:
-
-   http://www.x.org/wiki/Development/Documentation/SubmittingPatches
-
-For more information on the git code manager, see:
-
-http://wiki.x.org/wiki/GitPage
-
diff --git a/README.md b/README.md
new file mode 100644
index 000..8f5
--- /dev/null
+++ b/README.md
@@ -0,0 +1,17 @@
+xcursorgen prepares X11 cursor sets for use with libXcursor.
+
+All questions regarding this software should be directed at the
+Xorg mailing list:
+
+  http://lists.x.org/mailman/listinfo/xorg
+
+The master development code repository can be found at:
+
+  https://gitlab.freedesktop.org/xorg/app/xcursorgen
+
+Please submit bug reports and requests to merge patches there.
+
+For patch submission instructions, see:
+
+  http://www.x.org/wiki/Development/Documentation/SubmittingPatches
+
-- 
2.15.2

___
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/xcursorgen] Update README for gitlab migration

[Ray Strode]

hi,

On Mon, Oct 1, 2018, 1:11 PM Alan Coopersmith 
wrote:

> Does anyone have feedback on changing our README's like this?

it should probably be renamed README.md so it shows up in the gitlab view
better.

Ray
___
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/xcursorgen] Update README for gitlab migration

[Peter Hutterer]

On Mon, Oct 01, 2018 at 10:11:07AM -0700, Alan Coopersmith wrote:
> Does anyone have feedback on changing our README's like this?   While I
> sent this out as a patch to a specific repo, I figured once we have
> an agreed upon template, we'd apply it to all of the repos.

oh well, if you ask... :)

> On 09/22/18 12:11 PM, Alan Coopersmith wrote:
> > Signed-off-by: Alan Coopersmith 
> > ---
> >   README | 12 ++--
> >   1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/README b/README
> > index 6e46f96..f830ada 100644
> > --- a/README
> > +++ b/README
> > @@ -1,25 +1,17 @@
> >   xcursorgen prepares X11 cursor sets for use with libXcursor.
> >   All questions regarding this software should be directed at the
> >   Xorg mailing list:
> >   http://lists.freedesktop.org/mailman/listinfo/xorg
> > -Please submit bug reports to the Xorg bugzilla:
> > -
> > -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
> > -
> >   The master development code repository can be found at:
> > -git://anongit.freedesktop.org/git/xorg/app/xcursorgen
> > -
> > -http://cgit.freedesktop.org/xorg/app/xcursorgen
> > -
> > -For patch submission instructions, see:
> > +https://gitlab.freedesktop.org/xorg/app/xcursorgen
> > -   http://www.x.org/wiki/Development/Documentation/SubmittingPatches

IMO we (i.e. not me but someone else) should update that URL for the
glorious gitlab-enabled present and leave it in the README


> > +Please submit bug reports and requests to merge patches there.
> >   For more information on the git code manager, see:
> >   http://wiki.x.org/wiki/GitPage

this link needs to go and possibly merged into the SubmittingPatches page
(which could be renamed, because why not) 

Cheers,
   Peter
___
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/xcursorgen] Update README for gitlab migration

[Alan Coopersmith]

Does anyone have feedback on changing our README's like this?   While I
sent this out as a patch to a specific repo, I figured once we have
an agreed upon template, we'd apply it to all of the repos.

-alan-

On 09/22/18 12:11 PM, Alan Coopersmith wrote:

Signed-off-by: Alan Coopersmith 
---
  README | 12 ++--
  1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 6e46f96..f830ada 100644
--- a/README
+++ b/README
@@ -1,25 +1,17 @@
  xcursorgen prepares X11 cursor sets for use with libXcursor.
  
  All questions regarding this software should be directed at the

  Xorg mailing list:
  
  http://lists.freedesktop.org/mailman/listinfo/xorg
  
-Please submit bug reports to the Xorg bugzilla:

-
-https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
-
  The master development code repository can be found at:
  
-git://anongit.freedesktop.org/git/xorg/app/xcursorgen

-
-http://cgit.freedesktop.org/xorg/app/xcursorgen
-
-For patch submission instructions, see:
+https://gitlab.freedesktop.org/xorg/app/xcursorgen
  
-	http://www.x.org/wiki/Development/Documentation/SubmittingPatches

+Please submit bug reports and requests to merge patches there.
  
  For more information on the git code manager, see:
  
  http://wiki.x.org/wiki/GitPage
  




--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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 2/2] xwayland: update Xwayland present window on reparent

[Olivier Fourdan]

When reparenting a window, the Xwayland present window either on the
prior parent or on the new parent may need to be updated:

1. If the window is flipping, clear the present window on its old
   parent.
2. If the new parent has no flipping already, set its flipping window to
   the reparented window.

Install new ReparentWindow hooks in Xwayland to handle those cases.

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland-present.c | 16 
 hw/xwayland/xwayland.c | 23 +++
 hw/xwayland/xwayland.h |  2 ++
 3 files changed, 41 insertions(+)

diff --git a/hw/xwayland/xwayland-present.c b/hw/xwayland/xwayland-present.c
index 316e04443..f54fe2ac4 100644
--- a/hw/xwayland/xwayland-present.c
+++ b/hw/xwayland/xwayland-present.c
@@ -558,3 +558,19 @@ xwl_present_init(ScreenPtr screen)
 
 return present_wnmd_screen_init(screen, _present_info);
 }
+
+void
+xwl_present_reparent_window(WindowPtr pWin, WindowPtr pPriorParent)
+{
+struct xwl_window *xwl_window;
+
+/* If the window is flipping, clear the present window on its old parent */
+xwl_window = xwl_window_from_window(pPriorParent);
+if (xwl_present_is_flipping(pWin, xwl_window))
+xwl_window->present_window = NULL;
+
+/* If the new parent window has no child flipping, update its 
present_window */
+xwl_window = xwl_window_from_window(pWin->parent);
+if (xwl_window && xwl_window->present_window == NULL)
+xwl_window->present_window = pWin;
+}
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 96b4db18c..345b62f59 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -660,6 +660,26 @@ xwl_destroy_window(WindowPtr window)
 return ret;
 }
 
+static void
+xwl_reparent_window(WindowPtr pWin, WindowPtr pPriorParent)
+{
+ScreenPtr screen = pWin->drawable.pScreen;
+struct xwl_screen *xwl_screen = xwl_screen_get(screen);
+
+#ifdef GLAMOR_HAS_GBM
+if (xwl_screen->present)
+xwl_present_reparent_window(pWin, pPriorParent);
+#endif
+
+/* Chain up with previous ReparentWindow, if any */
+if (xwl_screen->ReparentWindow) {
+screen->ReparentWindow = xwl_screen->ReparentWindow;
+(*screen->ReparentWindow) (pWin, pPriorParent);
+xwl_screen->ReparentWindow = screen->ReparentWindow;
+screen->ReparentWindow = xwl_reparent_window;
+}
+}
+
 static void
 xwl_window_post_damage(struct xwl_window *xwl_window)
 {
@@ -1109,6 +1129,9 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 xwl_screen->CloseScreen = pScreen->CloseScreen;
 pScreen->CloseScreen = xwl_close_screen;
 
+xwl_screen->ReparentWindow = pScreen->ReparentWindow;
+pScreen->ReparentWindow = xwl_reparent_window;
+
 pScreen->CursorWarpedTo = xwl_cursor_warped_to;
 pScreen->CursorConfinedTo = xwl_cursor_confined_to;
 
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 67819e178..a7c7f2aee 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -132,6 +132,7 @@ struct xwl_screen {
 RealizeWindowProcPtr RealizeWindow;
 UnrealizeWindowProcPtr UnrealizeWindow;
 DestroyWindowProcPtr DestroyWindow;
+ReparentWindowProcPtr ReparentWindow;
 XYToWindowProcPtr XYToWindow;
 
 struct xorg_list output_list;
@@ -451,6 +452,7 @@ void xwl_glamor_egl_make_current(struct xwl_screen 
*xwl_screen);
 #ifdef GLAMOR_HAS_GBM
 Bool xwl_present_init(ScreenPtr screen);
 void xwl_present_cleanup(WindowPtr window);
+void xwl_present_reparent_window(WindowPtr pWin, WindowPtr pPriorParent);
 #endif /* GLAMOR_HAS_GBM */
 
 #ifdef XV
-- 
2.19.0

___
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 app/xcursorgen] Update README for gitlab migration

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
 README | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 6e46f96..f830ada 100644
--- a/README
+++ b/README
@@ -1,25 +1,17 @@
 xcursorgen prepares X11 cursor sets for use with libXcursor.
 
 All questions regarding this software should be directed at the
 Xorg mailing list:
 
 http://lists.freedesktop.org/mailman/listinfo/xorg
 
-Please submit bug reports to the Xorg bugzilla:
-
-https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
-
 The master development code repository can be found at:
 
-git://anongit.freedesktop.org/git/xorg/app/xcursorgen
-
-http://cgit.freedesktop.org/xorg/app/xcursorgen
-
-For patch submission instructions, see:
+https://gitlab.freedesktop.org/xorg/app/xcursorgen
 
-   http://www.x.org/wiki/Development/Documentation/SubmittingPatches
+Please submit bug reports and requests to merge patches there.
 
 For more information on the git code manager, see:
 
 http://wiki.x.org/wiki/GitPage
 
-- 
2.15.2

___
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: gitlab group permissions update

[Emil Velikov]

Hi Adan,

On 20 August 2018 at 20:17, Adam Jackson  wrote:
> gitlab groups are recursive, which means if you are a member of the
> 'xorg' group, your permission level for every project in that group is
> at least as high as your permission at the top level. Most of the
> existing accounts were set as Maintainer, at which level you can do
> things like read and set the secret tokens used for web API
> integrations, which is maybe a little too permissive in general.
>
> I've bumped most people down to Developer, which is still enough to do
> things like close issues and merge MRs. The difference is essentially
> that Maintainers can modify the gitlab environment of a project, in
> addition to just the project's content like a Developer. If you need
> higher access for your subprojects, give a shout.
>
That solves some confusion, as the notification email came.
I'm 100% behind the reason, although a suggestion for the future:

I wonder about having this in gitlab/bugzilla issue tracking with
follow-up action/commit.
It serves as a nice example of transparent/open-source development
{admin really} model.

That said, I'm not 100% sure if permission changes are tracked - git
or otherwise.

HTH
Emil
___
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

gitlab group permissions update

[Adam Jackson]

gitlab groups are recursive, which means if you are a member of the
'xorg' group, your permission level for every project in that group is
at least as high as your permission at the top level. Most of the
existing accounts were set as Maintainer, at which level you can do
things like read and set the secret tokens used for web API
integrations, which is maybe a little too permissive in general.

I've bumped most people down to Developer, which is still enough to do
things like close issues and merge MRs. The difference is essentially
that Maintainers can modify the gitlab environment of a project, in
addition to just the project's content like a Developer. If you need
higher access for your subprojects, give a shout.

- 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 modular] xorg.modules: Update to use meson for the xserver.

[Eric Anholt]

I'm proposing a patch to delete autotools, so try to make sure jhbuild
keeps working.
---
 xorg.modules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xorg.modules b/xorg.modules
index 3db392aa358d..638e88daefa4 100644
--- a/xorg.modules
+++ b/xorg.modules
@@ -1571,7 +1571,7 @@
   
 
   
-  
+  
 
 
@@ -1598,7 +1598,7 @@
   
   
 
-  
+  
 
   
   
-- 
2.18.0

___
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: gitlab migration (including account update plans, please read)

[Adam Jackson]

On Wed, 2018-08-01 at 14:38 +0200, Guillem Jover wrote:

> It would be nice if the xorg.modules (from modular) got updated too, so
> that some of this could be automated locally. :)

My goodness, we have written this down so many slightly different ways.
I've pushed some updates that I hope are right since I don't know of
anything actually using that file, let me know if anything looks wrong
or you need more.

- 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: gitlab migration (including account update plans, please read)

[Guillem Jover]

On Sun, 2018-07-29 at 21:49:44 +0100, Daniel Stone wrote:
> On Sun, 29 Jul 2018 at 16:53, Alan Coopersmith
>  wrote:
> > On 07/29/18 03:07 AM, Daniel Stone wrote:
> > > This took a little longer than hoped, but all the repos have now been 
> > > moved.

Great! :)

> > I updated all my local clones with:
> >
> > git remote set-url origin `git remote get-url origin | sed \
> >'s%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'`
> >
> > but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck,
> > and app/x11perf.
> >
> > Did something go wrong with them?   I don't see them in the web ui at
> > https://gitlab.freedesktop.org/xorg/app either.
> 
> Not wrong as such, just moved. These are the modules which (as
> requested) changed relative path during the migration:
> xorg/app/bdftopcf -> xorg/util/bdftopcf
> xorg/app/rendercheck -> xorg/test/rendercheck
> xorg/app/x11perf -> xorg/test/x11perf
> xorg/app/xtsttopng -> xorg/test/xtsttopng
> xorg/driver/glamor -> xorg/driver/glamor-history
> xorg/xprint -> xorg/xserver-xprint
> avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo
> glitz -> xorg/driver/glitz-history
> 
> If you try to fetch from the old URL it will still work, and if you
> try to push to the old URL it will tell you the correct new URL to
> use.
> 
> > I also got the same error from xf86-video-nouveau, xf86-video-openchrome,
> > libvdpau, and xcb/* but I'm assuming that was my script going too far and
> > those projects not migrating yet.
> 
> Right, exactly. Nothing under a non-xorg/ path has yet moved.

It would be nice if the xorg.modules (from modular) got updated too, so
that some of this could be automated locally. :)

Thanks,
Guillem
___
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/fonttosfnt 2/5] README: update repository URL to gitlab

[Adam Jackson]

On Tue, 2018-07-31 at 11:53 +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
>  README | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Adam Jackson 

And a pre-emptive r-b for the same change to every other repo, I
suppose. I can script that, if nobody beats me to it.

- 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 app/fonttosfnt 2/5] README: update repository URL to gitlab

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 README | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/README b/README
index 58f1062..fa3ad08 100644
--- a/README
+++ b/README
@@ -12,9 +12,7 @@ Please submit bug reports to the Xorg bugzilla:
 
 The master development code repository can be found at:
 
-git://anongit.freedesktop.org/git/xorg/app/fonttosfnt
-
-http://cgit.freedesktop.org/xorg/app/fonttosfnt
+https://gitlab.freedesktop.org/xorg/app/fonttosfnt.git
 
 For patch submission instructions, see:
 
-- 
2.17.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: gitlab migration (including account update plans, please read)

[Alan Coopersmith]

On 07/29/18 01:49 PM, Daniel Stone wrote:

Not wrong as such, just moved. These are the modules which (as
requested) changed relative path during the migration:
xorg/app/bdftopcf -> xorg/util/bdftopcf
xorg/app/rendercheck -> xorg/test/rendercheck
xorg/app/x11perf -> xorg/test/x11perf
xorg/app/xtsttopng -> xorg/test/xtsttopng
xorg/driver/glamor -> xorg/driver/glamor-history
xorg/xprint -> xorg/xserver-xprint
avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo
glitz -> xorg/driver/glitz-history


Ah, thanks - I didn't realize stuff was moving around - things work when
given the right path.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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: gitlab migration (including account update plans, please read)

[Daniel Stone]

Hi Alan,

On Sun, 29 Jul 2018 at 16:53, Alan Coopersmith
 wrote:
> On 07/29/18 03:07 AM, Daniel Stone wrote:
> > This took a little longer than hoped, but all the repos have now been moved.
>
> Huge thanks for doing this.
>
> I updated all my local clones with:
>
> git remote set-url origin `git remote get-url origin | sed \
>'s%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'`
>
> but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck,
> and app/x11perf.
>
> Did something go wrong with them?   I don't see them in the web ui at
> https://gitlab.freedesktop.org/xorg/app either.

Not wrong as such, just moved. These are the modules which (as
requested) changed relative path during the migration:
xorg/app/bdftopcf -> xorg/util/bdftopcf
xorg/app/rendercheck -> xorg/test/rendercheck
xorg/app/x11perf -> xorg/test/x11perf
xorg/app/xtsttopng -> xorg/test/xtsttopng
xorg/driver/glamor -> xorg/driver/glamor-history
xorg/xprint -> xorg/xserver-xprint
avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo
glitz -> xorg/driver/glitz-history

If you try to fetch from the old URL it will still work, and if you
try to push to the old URL it will tell you the correct new URL to
use.

> I also got the same error from xf86-video-nouveau, xf86-video-openchrome,
> libvdpau, and xcb/* but I'm assuming that was my script going too far and
> those projects not migrating yet.

Right, exactly. Nothing under a non-xorg/ path has yet moved.

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: gitlab migration (including account update plans, please read)

[Alan Coopersmith]

On 07/29/18 03:07 AM, Daniel Stone wrote:

Hi,

On Mon, 23 Jul 2018 at 16:24, Adam Jackson  wrote:

My earlier assertion about the git url not being changed is only true
for pulls. For pushes, you will indeed need to update the remote to the
new URL:

$ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver

Repo moves will be (early) this week. BZ moves for the more boring
components (protocol, libs, apps, deprecated/abandoned stuff) will
follow shortly thereafter.


This took a little longer than hoped, but all the repos have now been moved.


Huge thanks for doing this.

I updated all my local clones with:

git remote set-url origin `git remote get-url origin | sed \
  's%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'`

but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck,
and app/x11perf.

Did something go wrong with them?   I don't see them in the web ui at
https://gitlab.freedesktop.org/xorg/app either.

I also got the same error from xf86-video-nouveau, xf86-video-openchrome,
libvdpau, and xcb/* but I'm assuming that was my script going too far and
those projects not migrating yet.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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: gitlab migration (including account update plans, please read)

[Daniel Stone]

Hi,

On Mon, 23 Jul 2018 at 16:24, Adam Jackson  wrote:
> My earlier assertion about the git url not being changed is only true
> for pulls. For pushes, you will indeed need to update the remote to the
> new URL:
>
> $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver
>
> Repo moves will be (early) this week. BZ moves for the more boring
> components (protocol, libs, apps, deprecated/abandoned stuff) will
> follow shortly thereafter.

This took a little longer than hoped, but all the repos have now been moved.

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: [PATCH xserver 5/7] dix: Update window state based on paintable not viewable

[Keith Packard]

Adam Jackson  writes:

> Signed-off-by: Adam Jackson 

Yeah, this all looks reasonable.

> +if (wasPaintable && anyMarked) {
> +if (pLayerWin->parent == pWin)
> +(*pScreen->MarkWindow) (pWin);
> +else {
> +WindowPtr ptmp;

Argh. Please make the logic fix separate from this semantic change; I
don't want to try and figure out if the following code is different by
eye.

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

[PATCH xserver 5/7] dix: Update window state based on paintable not viewable

[Adam Jackson]

Signed-off-by: Adam Jackson 
---
 dix/window.c | 69 
 1 file changed, 32 insertions(+), 37 deletions(-)

diff --git a/dix/window.c b/dix/window.c
index ea3920c869..55290577d9 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -1589,7 +1589,7 @@ ChangeWindowAttributes(WindowPtr pWin, Mask vmask, XID 
*vlist, ClientPtr client)
for the tile to be rotated, and the correct function selected.
  */
 if (((vmaskCopy & (CWBorderPixel | CWBorderPixmap)) || borderRelative)
-&& pWin->viewable && HasBorder(pWin)) {
+&& pWin->paintable && HasBorder(pWin)) {
 RegionRec exposed;
 
 RegionNull();
@@ -2163,7 +2163,7 @@ ReflectStackChange(WindowPtr pWin, WindowPtr pSib, VTKind 
kind)
 {
 /* Note that pSib might be NULL */
 
-Bool WasViewable = (Bool) pWin->viewable;
+Bool WasPaintable = (Bool) pWin->paintable;
 Bool anyMarked;
 WindowPtr pFirstChange;
 WindowPtr pLayerWin;
@@ -2175,7 +2175,7 @@ ReflectStackChange(WindowPtr pWin, WindowPtr pSib, VTKind 
kind)
 
 pFirstChange = MoveWindowInStack(pWin, pSib);
 
-if (WasViewable) {
+if (WasPaintable) {
 anyMarked = (*pScreen->MarkOverlappedWindows) (pWin, pFirstChange,
);
 if (pLayerWin != pWin)
@@ -2614,7 +2614,7 @@ RealizeTree(WindowPtr pWin)
 pChild = pWin;
 while (1) {
 if (pChild->mapped) {
-pChild->realized = TRUE;
+pChild->realized = pChild->parent->realized;
 pChild->viewable = (pChild->drawable.class == InputOutput);
 pChild->paintable = (pChild->drawable.class == InputOutput);
 (*Realize) (pChild);
@@ -2692,7 +2692,7 @@ MapWindow(WindowPtr pWin, ClientPtr client)
 if (SubStrSend(pWin, pParent))
 DeliverMapNotify(pWin);
 
-if (!pParent->realized)
+if (!pParent->realized && !pParent->paintable)
 return Success;
 RealizeTree(pWin);
 if (pWin->viewable) {
@@ -2763,7 +2763,7 @@ MapSubwindows(WindowPtr pParent, ClientPtr client)
 
 if (!pFirstMapped)
 pFirstMapped = pWin;
-if (pParent->realized) {
+if (pParent->realized || pParent->paintable) {
 RealizeTree(pWin);
 if (pWin->viewable) {
 anyMarked |= (*pScreen->MarkOverlappedWindows) (pWin, pWin,
@@ -2861,7 +2861,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
 {
 WindowPtr pParent;
 Bool wasRealized = (Bool) pWin->realized;
-Bool wasViewable = (Bool) pWin->viewable;
+Bool wasPaintable = pWin->paintable;
 ScreenPtr pScreen = pWin->drawable.pScreen;
 WindowPtr pLayerWin = pWin;
 
@@ -2869,7 +2869,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
 return Success;
 if (SubStrSend(pWin, pParent))
 DeliverUnmapNotify(pWin, fromConfigure);
-if (wasViewable && !fromConfigure) {
+if (wasPaintable && !fromConfigure) {
 pWin->valdata = UnmapValData;
 (*pScreen->MarkOverlappedWindows) (pWin, pWin->nextSib, );
 (*pScreen->MarkWindow) (pLayerWin->parent);
@@ -2877,13 +2877,11 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
 pWin->mapped = FALSE;
 if (wasRealized)
 UnrealizeTree(pWin, fromConfigure);
-if (wasViewable) {
-if (!fromConfigure) {
-(*pScreen->ValidateTree) (pLayerWin->parent, pWin, VTUnmap);
-(*pScreen->HandleExposures) (pLayerWin->parent);
-if (pScreen->PostValidateTree)
-(*pScreen->PostValidateTree) (pLayerWin->parent, pWin, 
VTUnmap);
-}
+if (wasPaintable && !fromConfigure) {
+(*pScreen->ValidateTree) (pLayerWin->parent, pWin, VTUnmap);
+(*pScreen->HandleExposures) (pLayerWin->parent);
+if (pScreen->PostValidateTree)
+(*pScreen->PostValidateTree) (pLayerWin->parent, pWin, VTUnmap);
 }
 if (wasRealized && !fromConfigure) {
 WindowsRestructured();
@@ -2903,7 +2901,7 @@ UnmapSubwindows(WindowPtr pWin)
 {
 WindowPtr pChild, pHead;
 Bool wasRealized = (Bool) pWin->realized;
-Bool wasViewable = (Bool) pWin->viewable;
+Bool wasPaintable = pWin->paintable;
 Bool anyMarked = FALSE;
 Mask parentNotify;
 WindowPtr pLayerWin = NULL;
@@ -2914,7 +2912,7 @@ UnmapSubwindows(WindowPtr pWin)
 parentNotify = SubSend(pWin);
 pHead = RealChildHead(pWin);
 
-if (wasViewable)
+if (wasPaintable)
 pLayerWin = (*pScreen->GetLayerWindow) (pWin);
 
 for (pChild = pWin->lastChild; pChild != pHead; pChild = pChild->prevSib) {
@@ -2930,31 +2928,28 @@ UnmapSubwindows(WindowPtr pWin)
 UnrealizeTree(pChild, FALSE);
 }
 }
-if (wasViewable) {
-if (anyMarked) {
-if (pLayerWin->parent == pWin)
-(*pScreen->MarkWindow) (pWin);
-else {
-WindowPtr 

Re: gitlab migration (including account update plans, please read)

[Adam Jackson]

On Mon, 2018-07-23 at 11:23 -0400, Adam Jackson wrote:

> Nobody did, so, this is done now.
> 
> My earlier assertion about the git url not being changed is only true
> for pulls. For pushes, you will indeed need to update the remote to the
> new URL:
> 
> $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver
> 
> Repo moves will be (early) this week. BZ moves for the more boring
> components (protocol, libs, apps, deprecated/abandoned stuff) will
> follow shortly thereafter.

For detailed migration progress beyond the repo moves, please follow:

https://gitlab.freedesktop.org/xorg/meta/issues/1

- 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: gitlab migration (including account update plans, please read)

[Adam Jackson]

On Mon, 2018-07-09 at 14:30 -0400, Adam Jackson wrote:

> Currently the xorg group in gitlab is derived from the pre-existing
> freedesktop LDAP group. This is a bit excessive, there's over 250
> people in the group in total and not even a fifth of those are
> regularly active. If you're both a group member and a project member
> the highest privilege level is used; currently, this would mean all of
> these accounts are maintainers for every project.
> 
> That's not _different_ from the current state of affairs, but since we
> now have the easy ability to delegate access control per-project, we
> should take the opportunity to prune the list of xorg group
> members. These accounts will still exist in gitlab, and if the
> contributor returns they are welcome to rejoin. As a totally arbitrary
> cutoff I'd suggest pruning anyone who hasn't had an Author or Commit
> credit in git in the last, say, three years.
> 
> If you want a differently arbitrary cutoff, or have other feedback,
> please speak up.

Nobody did, so, this is done now.

My earlier assertion about the git url not being changed is only true
for pulls. For pushes, you will indeed need to update the remote to the
new URL:

$ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver

Repo moves will be (early) this week. BZ moves for the more boring
components (protocol, libs, apps, deprecated/abandoned stuff) will
follow shortly thereafter.

- 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: gitlab migration (including account update plans, please read)

[Adam Jackson]

On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote:

> For the first step, I'd like to propose moving the x server git
> repository to gitlab in the coming week, with the switch-over happening
> on the morning of July 9.

This is now done:

https://gitlab.freedesktop.org/xorg/xserver

The old git URLs still work, so this change should be transparent for
existing checkouts. We'll be moving more repositories over the coming
weeks.

Currently the xorg group in gitlab is derived from the pre-existing
freedesktop LDAP group. This is a bit excessive, there's over 250
people in the group in total and not even a fifth of those are
regularly active. If you're both a group member and a project member
the highest privilege level is used; currently, this would mean all of
these accounts are maintainers for every project.

That's not _different_ from the current state of affairs, but since we
now have the easy ability to delegate access control per-project, we
should take the opportunity to prune the list of xorg group
members. These accounts will still exist in gitlab, and if the
contributor returns they are welcome to rejoin. As a totally arbitrary
cutoff I'd suggest pruning anyone who hasn't had an Author or Commit
credit in git in the last, say, three years.

If you want a differently arbitrary cutoff, or have other feedback,
please speak up.

- 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: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

* Michel Dänzer  [180706 07:48]:
> On 2018-07-05 05:42 PM, Tony Lindgren wrote:
> > Hi,
> > 
> > * Michel Dänzer  [180705 14:21]:
> >>
> >> This uses the same damage region for all framebuffers, which is
> >> generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
> >> offset, rotation and reflection need to be taken into account for that.
> > 
> > Hmm OK. I thought we just need to refresh it we have
> > rotate_fb_id.
> > 
> > Unfortunately I have no idea what the check here might be
> > for the variables above.. Sounds like it might leave out
> > some pointless updates though :) Care to describe a bit
> > more or ideally even provide a patch to test?
> 
> The simplest solution is probably to use separate damage records
> attached to the per-CRTC rotation pixmaps.

Sorry but I still have no idea what needs to be checked
with rotate_fb_id and rotation pixmaps before updating
the display..

Regards,

Tony
___
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: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Michel Dänzer]

On 2018-07-05 05:42 PM, Tony Lindgren wrote:
> Hi,
> 
> * Michel Dänzer  [180705 14:21]:
>>
>> This uses the same damage region for all framebuffers, which is
>> generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
>> offset, rotation and reflection need to be taken into account for that.
> 
> Hmm OK. I thought we just need to refresh it we have
> rotate_fb_id.
> 
> Unfortunately I have no idea what the check here might be
> for the variables above.. Sounds like it might leave out
> some pointless updates though :) Care to describe a bit
> more or ideally even provide a patch to test?

The simplest solution is probably to use separate damage records
attached to the per-CRTC rotation pixmaps.


-- 
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: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

Hi,

* Michel Dänzer  [180705 14:21]:
> 
> This uses the same damage region for all framebuffers, which is
> generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
> offset, rotation and reflection need to be taken into account for that.

Hmm OK. I thought we just need to refresh it we have
rotate_fb_id.

Unfortunately I have no idea what the check here might be
for the variables above.. Sounds like it might leave out
some pointless updates though :) Care to describe a bit
more or ideally even provide a patch to test?

Regards,

Tony
___
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: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Michel Dänzer]

On 2018-07-05 11:27 AM, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> 
> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
> 
> Let's fix this issue by going through all the displays.
> 
> Cc: Hans De Goede 
> Cc: Jason Ekstrand 
> Cc: Keith Packard 
> Cc: Laurent Pinchart 
> Cc: Lyude Paul 
> Cc: Sebastian Reichel 
> Cc: Tomi Valkeinen 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Here's this one resent with proper patch description, sorry
> for the delays sending it out.
> 
> ---
> 
>  hw/xfree86/drivers/modesetting/driver.c | 41 +++--
>  1 file changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -531,12 +531,11 @@ dispatch_dirty_region(ScrnInfoPtr scrn,
>  }
>  
>  static void
> -dispatch_dirty(ScreenPtr pScreen)
> +dispatch_dirty_fb_id(ScreenPtr pScreen, int fb_id)
>  {
>  ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
>  modesettingPtr ms = modesettingPTR(scrn);
>  PixmapPtr pixmap = pScreen->GetScreenPixmap(pScreen);
> -int fb_id = ms->drmmode.fb_id;
>  int ret;
>  
>  ret = dispatch_dirty_region(scrn, pixmap, ms->damage, fb_id);
> @@ -547,7 +546,43 @@ dispatch_dirty(ScreenPtr pScreen)
>  ms->damage = NULL;
>  xf86DrvMsg(scrn->scrnIndex, X_INFO,
> "Disabling kernel dirty updates, not required.\n");
> -return;
> +}
> +}
> +
> +static void
> +dispatch_dirty(ScreenPtr pScreen)
> +{
> +ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
> +modesettingPtr ms = modesettingPTR(scrn);
> +modesettingEntPtr ms_ent = ms_ent_priv(scrn);
> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
> +xf86CrtcPtr crtc;
> +drmmode_crtc_private_ptr drmmode_crtc;
> +unsigned int mask;
> +
> +mask = ms_ent->assigned_crtcs;
> +
> +while (mask) {
> +int i, fb_id = 0;
> +
> +i = ffs(mask) - 1;
> +
> +crtc = xf86_config->crtc[i];
> +if (!ms_crtc_on(crtc))
> +goto skip;
> +
> +drmmode_crtc = crtc->driver_private;
> +
> +if (drmmode_crtc->rotate_fb_id)
> +fb_id = drmmode_crtc->rotate_fb_id;
> +else
> +fb_id = ms->drmmode.fb_id;
> +
> +if (fb_id)
> +dispatch_dirty_fb_id(pScreen, fb_id);
> +
> +skip:
> +mask &= ~(1 << i);
>  }
>  }
>  
> 

This uses the same damage region for all framebuffers, which is
generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
offset, rotation and reflection need to be taken into account for that.


-- 
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: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Thu, 2018-07-05 at 02:27 -0700, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> 
> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
> 
> Let's fix this issue by going through all the displays.
> 
> Cc: Hans De Goede 
> Cc: Jason Ekstrand 
> Cc: Keith Packard 
> Cc: Laurent Pinchart 
> Cc: Lyude Paul 
> Cc: Sebastian Reichel 
> Cc: Tomi Valkeinen 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Here's this one resent with proper patch description, sorry
> for the delays sending it out.
> 
> ---
> 
>  hw/xfree86/drivers/modesetting/driver.c | 41 +++--
>  1 file changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/driver.c
> b/hw/xfree86/drivers/modesetting/driver.c
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -531,12 +531,11 @@ dispatch_dirty_region(ScrnInfoPtr scrn,
>  }
>  
>  static void
> -dispatch_dirty(ScreenPtr pScreen)
> +dispatch_dirty_fb_id(ScreenPtr pScreen, int fb_id)
>  {
>  ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
>  modesettingPtr ms = modesettingPTR(scrn);
>  PixmapPtr pixmap = pScreen->GetScreenPixmap(pScreen);
> -int fb_id = ms->drmmode.fb_id;
>  int ret;
>  
>  ret = dispatch_dirty_region(scrn, pixmap, ms->damage, fb_id);
> @@ -547,7 +546,43 @@ dispatch_dirty(ScreenPtr pScreen)
>  ms->damage = NULL;
>  xf86DrvMsg(scrn->scrnIndex, X_INFO,
> "Disabling kernel dirty updates, not required.\n");
> -return;
> +}
> +}
> +
> +static void
> +dispatch_dirty(ScreenPtr pScreen)
> +{
> +ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
> +modesettingPtr ms = modesettingPTR(scrn);
> +modesettingEntPtr ms_ent = ms_ent_priv(scrn);
> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
> +xf86CrtcPtr crtc;
> +drmmode_crtc_private_ptr drmmode_crtc;
> +unsigned int mask;
> +
> +mask = ms_ent->assigned_crtcs;
> +
> +while (mask) {
> +int i, fb_id = 0;
> +
> +i = ffs(mask) - 1;
> +
> +crtc = xf86_config->crtc[i];
> +if (!ms_crtc_on(crtc))
> +goto skip;
> +
> +drmmode_crtc = crtc->driver_private;
> +
> +if (drmmode_crtc->rotate_fb_id)
> +fb_id = drmmode_crtc->rotate_fb_id;
> +else
> +fb_id = ms->drmmode.fb_id;
> +
> +if (fb_id)
> +dispatch_dirty_fb_id(pScreen, fb_id);
> +
> +skip:
> +mask &= ~(1 << i);
>  }
>  }
>  
-- 
Cheers,
Lyude Paul
___
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

[PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

Looks like drmModeDirtyFB() stopped working at some point and we now
call it with fb_id of zero for rotated displays. This will stop displays
relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.

This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
support for using RandR shadow buffers") that inroduced rotate_fb_id.

Let's fix this issue by going through all the displays.

Cc: Hans De Goede 
Cc: Jason Ekstrand 
Cc: Keith Packard 
Cc: Laurent Pinchart 
Cc: Lyude Paul 
Cc: Sebastian Reichel 
Cc: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
---

Here's this one resent with proper patch description, sorry
for the delays sending it out.

---

 hw/xfree86/drivers/modesetting/driver.c | 41 +++--
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -531,12 +531,11 @@ dispatch_dirty_region(ScrnInfoPtr scrn,
 }
 
 static void
-dispatch_dirty(ScreenPtr pScreen)
+dispatch_dirty_fb_id(ScreenPtr pScreen, int fb_id)
 {
 ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
 modesettingPtr ms = modesettingPTR(scrn);
 PixmapPtr pixmap = pScreen->GetScreenPixmap(pScreen);
-int fb_id = ms->drmmode.fb_id;
 int ret;
 
 ret = dispatch_dirty_region(scrn, pixmap, ms->damage, fb_id);
@@ -547,7 +546,43 @@ dispatch_dirty(ScreenPtr pScreen)
 ms->damage = NULL;
 xf86DrvMsg(scrn->scrnIndex, X_INFO,
"Disabling kernel dirty updates, not required.\n");
-return;
+}
+}
+
+static void
+dispatch_dirty(ScreenPtr pScreen)
+{
+ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
+modesettingPtr ms = modesettingPTR(scrn);
+modesettingEntPtr ms_ent = ms_ent_priv(scrn);
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+xf86CrtcPtr crtc;
+drmmode_crtc_private_ptr drmmode_crtc;
+unsigned int mask;
+
+mask = ms_ent->assigned_crtcs;
+
+while (mask) {
+int i, fb_id = 0;
+
+i = ffs(mask) - 1;
+
+crtc = xf86_config->crtc[i];
+if (!ms_crtc_on(crtc))
+goto skip;
+
+drmmode_crtc = crtc->driver_private;
+
+if (drmmode_crtc->rotate_fb_id)
+fb_id = drmmode_crtc->rotate_fb_id;
+else
+fb_id = ms->drmmode.fb_id;
+
+if (fb_id)
+dispatch_dirty_fb_id(pScreen, fb_id);
+
+skip:
+mask &= ~(1 << i);
 }
 }
 
-- 
2.17.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: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

[Lyude Paul]

yes if you wouldn't mind, after that I'll add it to the modesetting pull

On Fri, 2018-06-22 at 00:28 -0700, Tony Lindgren wrote:
> * Lyude Paul  [180621 22:55]:
> > Hey, was a patch updated re: Keith's comments ever posted for this? Was
> > going
> > to review this, but I can't find any versions of this patch other than
> > this
> > one
> 
> You got the second version already, that's patchworks:
> 
> https://patchwork.freedesktop.org/patch/203834/
> 
> Looks like it's missing the description, do you want
> me to resend it with the description below?
> 
> Regards,
> 
> Tony
> 
> > On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote:
> > > Looks like drmModeDirtyFB() stopped working at some point and we now
> > > call it with fb_id of zero for rotated displays. This will stop displays
> > > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> > > 
> > > This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> > > support for using RandR shadow buffers") that inroduced rotate_fb_id.
> > > 
> > > Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> > > reset it back to zero after we're done with the rotation.
> > > 
> > > After the fix we then call drmModeDirtyFB() we then have the
> > > following fb_id changes:
> > > 
> > > $ startx
> > > drmmode_get_default_bpp: fb_id: 51
> > > drmmode_get_default_bpp: cleared fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_set_mode_major: drmmode->fb_id: 52
> > > dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
> > > ...
> > > 
> > > $ xrandr --output DSI-1 --rotate right
> > > drmmode_xf86crtc_resize: cleared old_fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
> > > dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
> > > ...
> > > 
> > > $ xrandr --output DSI-1 --rotate normal
> > > drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_set_mode_major: drmmode->fb_id: 51
> > > dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
> > > ...
> > > 
> > > Cc: Hans De Goede 
> > > Cc: Jason Ekstrand 
> > > Cc: Laurent Pinchart 
> > > Cc: Sebastian Reichel 
> > > Cc: Tomi Valkeinen 
> > > Signed-off-by: Tony Lindgren 
> > > ---
> > >  hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
> > >  hw/xfree86/drivers/modesetting/drmmode_display.h |  1 +
> > >  2 files changed, 11 insertions(+)
> > > 
> > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > @@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int
> > > width,
> > > int height)
> > >  return NULL;
> > >  }
> > >  
> > > +/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
> > > +if (!drmmode->fb_id) {
> > > +drmmode->fb_id = drmmode_crtc->rotate_fb_id;
> > > +drmmode_crtc->reset_fb_id = TRUE;
> > > +}
> > > +
> > >  #ifdef GLAMOR_HAS_GBM
> > >  if (drmmode->gbm)
> > >  return drmmode_crtc->rotate_bo.gbm;
> > > @@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc,
> > > PixmapPtr
> > > rotate_pixmap, void *data)
> > >  
> > >  if (data) {
> > >  drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
> > > +if (drmmode_crtc->reset_fb_id &&
> > > +drmmode->fb_id == drmmode_crtc->rotate_fb_id)
> > > +drmmode->fb_id = 0;
> > > +drmmode_crtc->reset_fb_id = FALSE;
> > >  drmmode_crtc->rotate_fb_id = 0;
> > >  
> > >  drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > --- a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > @@ -98,6 +98,7 @@ typedef struct {
> > >  
> > >  drmmode_bo rotate_bo;
> > >  unsigned rotate_fb_id;
> > > +Bool reset_fb_id;
> > >  
> > >  PixmapPtr prime_pixmap;
> > >  PixmapPtr prime_pixmap_back;
> > 
> > -- 
> > Cheers,
> > Lyude Paul
-- 
Cheers,
Lyude Paul
___
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] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

* Lyude Paul  [180621 22:55]:
> Hey, was a patch updated re: Keith's comments ever posted for this? Was going
> to review this, but I can't find any versions of this patch other than this
> one

You got the second version already, that's patchworks:

https://patchwork.freedesktop.org/patch/203834/

Looks like it's missing the description, do you want
me to resend it with the description below?

Regards,

Tony

> On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote:
> > Looks like drmModeDirtyFB() stopped working at some point and we now
> > call it with fb_id of zero for rotated displays. This will stop displays
> > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> > 
> > This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> > support for using RandR shadow buffers") that inroduced rotate_fb_id.
> > 
> > Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> > reset it back to zero after we're done with the rotation.
> > 
> > After the fix we then call drmModeDirtyFB() we then have the
> > following fb_id changes:
> > 
> > $ startx
> > drmmode_get_default_bpp: fb_id: 51
> > drmmode_get_default_bpp: cleared fb_id
> > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > drmmode_set_mode_major: drmmode->fb_id: 52
> > dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
> > ...
> > 
> > $ xrandr --output DSI-1 --rotate right
> > drmmode_xf86crtc_resize: cleared old_fb_id
> > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
> > dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
> > ...
> > 
> > $ xrandr --output DSI-1 --rotate normal
> > drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
> > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > drmmode_set_mode_major: drmmode->fb_id: 51
> > dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
> > ...
> > 
> > Cc: Hans De Goede 
> > Cc: Jason Ekstrand 
> > Cc: Laurent Pinchart 
> > Cc: Sebastian Reichel 
> > Cc: Tomi Valkeinen 
> > Signed-off-by: Tony Lindgren 
> > ---
> >  hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
> >  hw/xfree86/drivers/modesetting/drmmode_display.h |  1 +
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > @@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int width,
> > int height)
> >  return NULL;
> >  }
> >  
> > +/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
> > +if (!drmmode->fb_id) {
> > +drmmode->fb_id = drmmode_crtc->rotate_fb_id;
> > +drmmode_crtc->reset_fb_id = TRUE;
> > +}
> > +
> >  #ifdef GLAMOR_HAS_GBM
> >  if (drmmode->gbm)
> >  return drmmode_crtc->rotate_bo.gbm;
> > @@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr
> > rotate_pixmap, void *data)
> >  
> >  if (data) {
> >  drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
> > +if (drmmode_crtc->reset_fb_id &&
> > +drmmode->fb_id == drmmode_crtc->rotate_fb_id)
> > +drmmode->fb_id = 0;
> > +drmmode_crtc->reset_fb_id = FALSE;
> >  drmmode_crtc->rotate_fb_id = 0;
> >  
> >  drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > --- a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > @@ -98,6 +98,7 @@ typedef struct {
> >  
> >  drmmode_bo rotate_bo;
> >  unsigned rotate_fb_id;
> > +Bool reset_fb_id;
> >  
> >  PixmapPtr prime_pixmap;
> >  PixmapPtr prime_pixmap_back;
> -- 
> Cheers,
>   Lyude Paul
___
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] modesetting: Update fb_id from shadow allocate and destroy if not set

[Lyude Paul]

Hey, was a patch updated re: Keith's comments ever posted for this? Was going
to review this, but I can't find any versions of this patch other than this
one

On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> 
> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
> 
> Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> reset it back to zero after we're done with the rotation.
> 
> After the fix we then call drmModeDirtyFB() we then have the
> following fb_id changes:
> 
> $ startx
> drmmode_get_default_bpp: fb_id: 51
> drmmode_get_default_bpp: cleared fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_set_mode_major: drmmode->fb_id: 52
> dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
> ...
> 
> $ xrandr --output DSI-1 --rotate right
> drmmode_xf86crtc_resize: cleared old_fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
> dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
> ...
> 
> $ xrandr --output DSI-1 --rotate normal
> drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_set_mode_major: drmmode->fb_id: 51
> dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
> ...
> 
> Cc: Hans De Goede 
> Cc: Jason Ekstrand 
> Cc: Laurent Pinchart 
> Cc: Sebastian Reichel 
> Cc: Tomi Valkeinen 
> Signed-off-by: Tony Lindgren 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
>  hw/xfree86/drivers/modesetting/drmmode_display.h |  1 +
>  2 files changed, 11 insertions(+)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int width,
> int height)
>  return NULL;
>  }
>  
> +/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
> +if (!drmmode->fb_id) {
> +drmmode->fb_id = drmmode_crtc->rotate_fb_id;
> +drmmode_crtc->reset_fb_id = TRUE;
> +}
> +
>  #ifdef GLAMOR_HAS_GBM
>  if (drmmode->gbm)
>  return drmmode_crtc->rotate_bo.gbm;
> @@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr
> rotate_pixmap, void *data)
>  
>  if (data) {
>  drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
> +if (drmmode_crtc->reset_fb_id &&
> +drmmode->fb_id == drmmode_crtc->rotate_fb_id)
> +drmmode->fb_id = 0;
> +drmmode_crtc->reset_fb_id = FALSE;
>  drmmode_crtc->rotate_fb_id = 0;
>  
>  drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> b/hw/xfree86/drivers/modesetting/drmmode_display.h
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.h
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
> @@ -98,6 +98,7 @@ typedef struct {
>  
>  drmmode_bo rotate_bo;
>  unsigned rotate_fb_id;
> +Bool reset_fb_id;
>  
>  PixmapPtr prime_pixmap;
>  PixmapPtr prime_pixmap_back;
-- 
Cheers,
Lyude Paul
___
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] hw/xwin: Update for glxvnd

[Adam Jackson]

On Fri, 2018-02-16 at 16:44 +, Jon Turney wrote:
> - Link with libglxvnd in meson.build
> - Call xorgGlxCreateVendor() like all other DDX

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #205278 updated using rev 
6f9d29040cd9f4723a2e6c1e5d2ec8104efc0710.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   500cc4a02..6f9d29040  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] hw/xwin: Update for glxvnd

[Jon Turney]

- Link with libglxvnd in meson.build
- Call xorgGlxCreateVendor() like all other DDX

Signed-off-by: Jon Turney 
---
 hw/xwin/InitOutput.c | 2 ++
 hw/xwin/meson.build  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/hw/xwin/InitOutput.c b/hw/xwin/InitOutput.c
index ef19f7941..9560c5684 100644
--- a/hw/xwin/InitOutput.c
+++ b/hw/xwin/InitOutput.c
@@ -1012,6 +1012,8 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char 
*argv[])
 }
 }
 
+xorgGlxCreateVendor();
+
 /* Generate a cookie used by internal clients for authorization */
 if (g_fXdmcpEnabled || g_fAuthEnabled)
 winGenerateAuthorization();
diff --git a/hw/xwin/meson.build b/hw/xwin/meson.build
index 87fa6c5cb..bee4a46a4 100644
--- a/hw/xwin/meson.build
+++ b/hw/xwin/meson.build
@@ -149,6 +149,7 @@ executable(
 libxserver_fb,
 libxserver,
 libxserver_glx,
+libglxvnd,
 libxserver_xkb_stubs,
 libxserver_miext_shadow,
 libxserver_pseudoramix,
-- 
2.16.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: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

* Keith Packard  [180203 20:33]:
> I think the right place to fix this is in dispatch_dirty_regions, which
> should be walking the set of active CTRCs and damaging the appropriate
> fb_id for each one?

So is the following test patch at all along the lines you were
thinking?

I wonder if we should also have drmmode_crtc->rotate_dirty_enabled
in addition to ms->dirty_enabled so we we could stop the ioctl
on per *fb_id basis if not needed?

Or maybe we could have drmmode_crtc->current_fb_id that would
just get overwritten by drmModeAddFB() or some other logic?

Regards,

Tony

8< --
diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -531,12 +531,11 @@ dispatch_dirty_region(ScrnInfoPtr scrn,
 }
 
 static void
-dispatch_dirty(ScreenPtr pScreen)
+dispatch_dirty_fb_id(ScreenPtr pScreen, int fb_id)
 {
 ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
 modesettingPtr ms = modesettingPTR(scrn);
 PixmapPtr pixmap = pScreen->GetScreenPixmap(pScreen);
-int fb_id = ms->drmmode.fb_id;
 int ret;
 
 ret = dispatch_dirty_region(scrn, pixmap, ms->damage, fb_id);
@@ -547,7 +546,43 @@ dispatch_dirty(ScreenPtr pScreen)
 ms->damage = NULL;
 xf86DrvMsg(scrn->scrnIndex, X_INFO,
"Disabling kernel dirty updates, not required.\n");
-return;
+}
+}
+
+static void
+dispatch_dirty(ScreenPtr pScreen)
+{
+ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
+modesettingPtr ms = modesettingPTR(scrn);
+modesettingEntPtr ms_ent = ms_ent_priv(scrn);
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+xf86CrtcPtr crtc;
+drmmode_crtc_private_ptr drmmode_crtc;
+unsigned int mask;
+
+mask = ms_ent->assigned_crtcs;
+
+while (mask) {
+int i, fb_id = 0;
+
+i = ffs(mask) - 1;
+
+crtc = xf86_config->crtc[i];
+if (!ms_crtc_on(crtc))
+goto skip;
+
+drmmode_crtc = crtc->driver_private;
+
+if (drmmode_crtc->rotate_fb_id)
+fb_id = drmmode_crtc->rotate_fb_id;
+else
+fb_id = ms->drmmode.fb_id;
+
+if (fb_id)
+dispatch_dirty_fb_id(pScreen, fb_id);
+
+skip:
+mask &= ~(1 << i);
 }
 }
 
-- 
2.16.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: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

Hi,

* Keith Packard  [180203 20:33]:
> Tony Lindgren  writes:
> 
> > Looks like drmModeDirtyFB() stopped working at some point and we now
> > call it with fb_id of zero for rotated displays. This will stop displays
> > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> 
> This bug just breaks rotated displays, right?

Yes it only happens after rotating the LCD.

> > This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> > support for using RandR shadow buffers") that inroduced rotate_fb_id.
> >
> > Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> > reset it back to zero after we're done with the rotation.
> 
> I think this fix assumes that there is only one CRTC running; if you've
> got two, one scanning from the regular fb_id and the other from a
> rotated fb_id, then you want to dirty each separately.

Hmm yes I noticed we're doing dirtyfb flushes also on the HDMI
on the same device in addition to the LCD, which seems unnecessary.

> I think the right place to fix this is in dispatch_dirty_regions, which
> should be walking the set of active CTRCs and damaging the appropriate
> fb_id for each one?

OK, Jason, any comments on this?

Regards,

Tony

___
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] modesetting: Update fb_id from shadow allocate and destroy if not set

[Tony Lindgren]

Looks like drmModeDirtyFB() stopped working at some point and we now
call it with fb_id of zero for rotated displays. This will stop displays
relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.

This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
support for using RandR shadow buffers") that inroduced rotate_fb_id.

Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
reset it back to zero after we're done with the rotation.

After the fix we then call drmModeDirtyFB() we then have the
following fb_id changes:

$ startx
drmmode_get_default_bpp: fb_id: 51
drmmode_get_default_bpp: cleared fb_id
dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
drmmode_set_mode_major: drmmode->fb_id: 52
dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
...

$ xrandr --output DSI-1 --rotate right
drmmode_xf86crtc_resize: cleared old_fb_id
dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
...

$ xrandr --output DSI-1 --rotate normal
drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
drmmode_set_mode_major: drmmode->fb_id: 51
dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
...

Cc: Hans De Goede 
Cc: Jason Ekstrand 
Cc: Laurent Pinchart 
Cc: Sebastian Reichel 
Cc: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
 hw/xfree86/drivers/modesetting/drmmode_display.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int width, int 
height)
 return NULL;
 }
 
+/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
+if (!drmmode->fb_id) {
+drmmode->fb_id = drmmode_crtc->rotate_fb_id;
+drmmode_crtc->reset_fb_id = TRUE;
+}
+
 #ifdef GLAMOR_HAS_GBM
 if (drmmode->gbm)
 return drmmode_crtc->rotate_bo.gbm;
@@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr 
rotate_pixmap, void *data)
 
 if (data) {
 drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
+if (drmmode_crtc->reset_fb_id &&
+drmmode->fb_id == drmmode_crtc->rotate_fb_id)
+drmmode->fb_id = 0;
+drmmode_crtc->reset_fb_id = FALSE;
 drmmode_crtc->rotate_fb_id = 0;
 
 drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -98,6 +98,7 @@ typedef struct {
 
 drmmode_bo rotate_bo;
 unsigned rotate_fb_id;
+Bool reset_fb_id;
 
 PixmapPtr prime_pixmap;
 PixmapPtr prime_pixmap_back;
-- 
2.16.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: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

[Keith Packard]

Tony Lindgren  writes:

> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.

This bug just breaks rotated displays, right?

> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
>
> Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> reset it back to zero after we're done with the rotation.

I think this fix assumes that there is only one CRTC running; if you've
got two, one scanning from the regular fb_id and the other from a
rotated fb_id, then you want to dirty each separately.

I think the right place to fix this is in dispatch_dirty_regions, which
should be walking the set of active CTRCs and damaging the appropriate
fb_id for each one?

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

[PATCH xserver 02/10] xf86-video-modesetting: Update property values at detect and uevent time

[Keith Packard]

We were updating the link-status property when a uevent came in, but
we also want to update the non-desktop property, and potentially
others as well. We also want to check at detect time in case we don't
get a hotplug event.

This patch updates every property provided by the kernel, sending
changes to DIX so it can track things as well.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 111 ++-
 1 file changed, 86 insertions(+), 25 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 5b8e4fa1b..9c3856378 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1132,6 +1132,67 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr 
drmmode, drmModeResPtr mode_res
 return 1;
 }
 
+/*
+ * Update all of the property values for an output
+ */
+static void
+drmmode_output_update_properties(xf86OutputPtr output)
+{
+drmmode_output_private_ptr drmmode_output = output->driver_private;
+int i, j, k;
+int err;
+drmModeConnectorPtr koutput;
+
+/* Use the most recently fetched values from the kernel */
+koutput = drmmode_output->mode_output;
+
+if (!koutput)
+return;
+
+for (i = 0; i < drmmode_output->num_props; i++) {
+drmmode_prop_ptr p = _output->props[i];
+
+for (j = 0; koutput && j < koutput->count_props; j++) {
+if (koutput->props[j] == p->mode_prop->prop_id) {
+
+/* Check to see if the property value has changed */
+if (koutput->prop_values[j] != p->value) {
+
+p->value = koutput->prop_values[j];
+
+if (p->mode_prop->flags & DRM_MODE_PROP_RANGE) {
+INT32 value = p->value;
+
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_INTEGER, 32, 
PropModeReplace, 1,
+ , FALSE, TRUE);
+
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, %d\n", 
err);
+}
+}
+else if (p->mode_prop->flags & DRM_MODE_PROP_ENUM) {
+for (k = 0; k < p->mode_prop->count_enums; k++)
+if (p->mode_prop->enums[k].value == p->value)
+break;
+if (k < p->mode_prop->count_enums) {
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_ATOM, 32, 
PropModeReplace, 1,
+ >atoms[k + 1], 
FALSE, TRUE);
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, 
%d\n", err);
+}
+}
+}
+}
+break;
+}
+}
+}
+}
+
 static xf86OutputStatus
 drmmode_output_detect(xf86OutputPtr output)
 {
@@ -1147,11 +1208,14 @@ drmmode_output_detect(xf86OutputPtr output)
 
 drmmode_output->mode_output =
 drmModeGetConnector(drmmode->fd, drmmode_output->output_id);
+
 if (!drmmode_output->mode_output) {
 drmmode_output->output_id = -1;
 return XF86OutputStatusDisconnected;
 }
 
+drmmode_output_update_properties(output);
+
 switch (drmmode_output->mode_output->connection) {
 case DRM_MODE_CONNECTED:
 status = XF86OutputStatusConnected;
@@ -2244,38 +2308,35 @@ drmmode_handle_uevents(int fd, void *closure)
  */
 for (i = 0; i < config->num_output; i++) {
 xf86OutputPtr output = config->output[i];
-xf86CrtcPtr crtc = output->crtc;
 drmmode_output_private_ptr drmmode_output = output->driver_private;
-uint32_t con_id, idx;
-drmModeConnectorPtr koutput;
 
-if (crtc == NULL || drmmode_output->mode_output == NULL)
-continue;
+drmmode_output_detect(output);
 
-con_id = drmmode_output->mode_output->connector_id;
 /* Get an updated view of the properties for the current connector and
  * look for the link-status property
  */
-koutput = drmModeGetConnectorCurrent(drmmode->fd, con_id);
-if (!koutput)
-continue;
-
-idx = koutput_get_prop_idx(drmmode->fd, kou

Re: [PATCH xserver] xf86-video-modesetting: Update all property values at uevent time

[Keith Packard]

Keith Packard <kei...@keithp.com> writes:

> We were updating the link-status property when a uevent came in, but
> we also want to update the non-desktop property, and potentially
> others as well. This patch just updates every property provided by the
> kernel, sending changes to DIX so it can track things as well.

This patch has been replaced by one of the 5 in the non-desktop series I
just sent out.

Please ignore this and go look at those instead :-)

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

[PATCH xserver 1/5] xf86-video-modesetting: Update property values at detect and uevent time

[Keith Packard]

We were updating the link-status property when a uevent came in, but
we also want to update the non-desktop property, and potentially
others as well. We also want to check at detect time in case we don't
get a hotplug event.

This patch updates every property provided by the kernel, sending
changes to DIX so it can track things as well.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 115 ++-
 1 file changed, 90 insertions(+), 25 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index a51722b58..e10ba69f0 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1136,6 +1136,71 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr 
drmmode, drmModeResPtr mode_res
 return 1;
 }
 
+/*
+ * Update all of the property values for an output
+ */
+static void
+drmmode_output_update_properties(xf86OutputPtr output)
+{
+drmmode_output_private_ptr drmmode_output = output->driver_private;
+int i, j, k;
+int err;
+drmModeConnectorPtr koutput;
+
+/* Use the most recently fetched values from the kernel */
+koutput = drmmode_output->mode_output;
+
+if (!koutput)
+return;
+
+printf("output %s\n", output->name);
+
+for (i = 0; i < drmmode_output->num_props; i++) {
+drmmode_prop_ptr p = _output->props[i];
+
+for (j = 0; koutput && j < koutput->count_props; j++) {
+if (koutput->props[j] == p->mode_prop->prop_id) {
+
+printf("\t%s %ld -> %ld\n", p->mode_prop->name, p->value, 
koutput->prop_values[j]);
+
+/* Check to see if the property value has changed */
+if (koutput->prop_values[j] != p->value) {
+
+p->value = koutput->prop_values[j];
+
+if (p->mode_prop->flags & DRM_MODE_PROP_RANGE) {
+INT32 value = p->value;
+
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_INTEGER, 32, 
PropModeReplace, 1,
+ , FALSE, TRUE);
+
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, %d\n", 
err);
+}
+}
+else if (p->mode_prop->flags & DRM_MODE_PROP_ENUM) {
+for (k = 0; k < p->mode_prop->count_enums; k++)
+if (p->mode_prop->enums[k].value == p->value)
+break;
+if (k < p->mode_prop->count_enums) {
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_ATOM, 32, 
PropModeReplace, 1,
+ >atoms[k + 1], 
FALSE, TRUE);
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, 
%d\n", err);
+}
+}
+}
+}
+break;
+}
+}
+}
+}
+
 static xf86OutputStatus
 drmmode_output_detect(xf86OutputPtr output)
 {
@@ -1151,11 +1216,14 @@ drmmode_output_detect(xf86OutputPtr output)
 
 drmmode_output->mode_output =
 drmModeGetConnector(drmmode->fd, drmmode_output->output_id);
+
 if (!drmmode_output->mode_output) {
 drmmode_output->output_id = -1;
 return XF86OutputStatusDisconnected;
 }
 
+drmmode_output_update_properties(output);
+
 switch (drmmode_output->mode_output->connection) {
 case DRM_MODE_CONNECTED:
 status = XF86OutputStatusConnected;
@@ -2248,38 +2316,35 @@ drmmode_handle_uevents(int fd, void *closure)
  */
 for (i = 0; i < config->num_output; i++) {
 xf86OutputPtr output = config->output[i];
-xf86CrtcPtr crtc = output->crtc;
 drmmode_output_private_ptr drmmode_output = output->driver_private;
-uint32_t con_id, idx;
-drmModeConnectorPtr koutput;
 
-if (crtc == NULL || drmmode_output->mode_output == NULL)
-continue;
+drmmode_output_detect(output);
 
-con_id = drmmode_output->mode_output->connector_id;
 /* Get an updated view of the properties for the current connector and
  * look for the link-status property

[PATCH xserver] xf86-video-modesetting: Update all property values at uevent time

[Keith Packard]

We were updating the link-status property when a uevent came in, but
we also want to update the non-desktop property, and potentially
others as well. This patch just updates every property provided by the
kernel, sending changes to DIX so it can track things as well.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 117 ++-
 1 file changed, 92 insertions(+), 25 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index a51722b58..52b8e4a53 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -2213,6 +2213,76 @@ drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr 
pScrn)
 return TRUE;
 }
 
+/*
+ * Update all of the property values for an output
+ */
+static void
+drmmode_output_update_properties(xf86OutputPtr output)
+{
+drmmode_output_private_ptr drmmode_output = output->driver_private;
+drmmode_ptr drmmode = drmmode_output->drmmode;
+int i, j, k;
+int err;
+
+drmModeConnectorPtr koutput;
+
+if (drmmode_output->mode_output == NULL)
+return;
+
+/* Get an updated view of the properties for the current connector and
+ * update the server's copy of them.
+ */
+koutput = drmModeGetConnector(drmmode->fd,
+  drmmode_output->mode_output->connector_id);
+
+if (!koutput)
+return;
+
+for (i = 0; i < drmmode_output->num_props; i++) {
+drmmode_prop_ptr p = _output->props[i];
+
+for (j = 0; koutput && j < koutput->count_props; j++) {
+if (koutput->props[j] == p->mode_prop->prop_id) {
+
+/* Check to see if the property value has changed */
+if (koutput->prop_values[j] != p->value) {
+
+p->value = koutput->prop_values[j];
+
+if (p->mode_prop->flags & DRM_MODE_PROP_RANGE) {
+INT32 value = p->value;
+
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_INTEGER, 32, 
PropModeReplace, 1,
+ , FALSE, TRUE);
+
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, %d\n", 
err);
+}
+}
+else if (p->mode_prop->flags & DRM_MODE_PROP_ENUM) {
+for (k = 0; k < p->mode_prop->count_enums; k++)
+if (p->mode_prop->enums[k].value == p->value)
+break;
+if (k < p->mode_prop->count_enums) {
+err = RRChangeOutputProperty(output->randr_output, 
p->atoms[0],
+ XA_ATOM, 32, 
PropModeReplace, 1,
+ >atoms[k + 1], 
FALSE, TRUE);
+if (err != 0) {
+xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+   "RRChangeOutputProperty error, 
%d\n", err);
+}
+}
+}
+}
+break;
+}
+}
+}
+drmModeFreeConnector(koutput);
+}
+
 #ifdef CONFIG_UDEV_KMS
 
 #define DRM_MODE_LINK_STATUS_GOOD   0
@@ -2248,38 +2318,35 @@ drmmode_handle_uevents(int fd, void *closure)
  */
 for (i = 0; i < config->num_output; i++) {
 xf86OutputPtr output = config->output[i];
-xf86CrtcPtr crtc = output->crtc;
 drmmode_output_private_ptr drmmode_output = output->driver_private;
-uint32_t con_id, idx;
-drmModeConnectorPtr koutput;
 
-if (crtc == NULL || drmmode_output->mode_output == NULL)
-continue;
+drmmode_output_update_properties(output);
 
-con_id = drmmode_output->mode_output->connector_id;
 /* Get an updated view of the properties for the current connector and
  * look for the link-status property
  */
-koutput = drmModeGetConnectorCurrent(drmmode->fd, con_id);
-if (!koutput)
-continue;
-
-idx = koutput_get_prop_idx(drmmode->fd, koutput,
-DRM_MODE_PROP_ENUM, "link-status");
-
-if ((idx > -1) &&
-(koutput->prop_values[idx] == DRM_MODE_LINK_STATUS_BAD)) {
-/* the connector got a link failure, re-set the current mode */
-drmmode

Re: [PATCH:macros] Update check for manpage section numbers to not rely on Solaris version

[Matthieu Herrb]

On Sat, Nov 04, 2017 at 05:33:56PM -0700, Alan Coopersmith wrote:
> Check for a specific file instead of a specific set of versions from
> uname, to cope with manpage section alignment coming to 11.4 instead
> of 12.0.
> 
> Signed-off-by: Alan Coopersmith 

Hi,

I can't test it anymore, but it looks good to me.

Reviewed-by: Matthieu Herrb 

> ---
>  xorg-macros.m4.in | 31 +++
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
> index 7935426..efce888 100644
> --- a/xorg-macros.m4.in
> +++ b/xorg-macros.m4.in
> @@ -114,6 +114,17 @@ AC_DEFUN([XORG_MANPAGE_SECTIONS],[
>  AC_REQUIRE([AC_CANONICAL_HOST])
>  AC_REQUIRE([AC_PROG_SED])
>  
> +case $host_os in
> +solaris*)
> +# Solaris 2.0 - 11.3 use SysV man page section numbers, so we
> +# check for a man page file found in later versions that use
> +# traditional section numbers instead
> +AC_CHECK_FILE([/usr/share/man/man7/attributes.7],
> +[SYSV_MAN_SECTIONS=false], [SYSV_MAN_SECTIONS=true])
> +;;
> +*) SYSV_MAN_SECTIONS=false ;;
> +esac
> +
>  if test x$APP_MAN_SUFFIX = x; then
>  APP_MAN_SUFFIX=1
>  fi
> @@ -129,9 +140,8 @@ if test x$LIB_MAN_DIR = x; then
>  fi
>  
>  if test x$FILE_MAN_SUFFIX = x; then
> -case $host_os in
> - # Solaris 2.0 - 11 use SysV man page sections
> - solaris2.?|solaris2.1[[01]])FILE_MAN_SUFFIX=4  ;;
> +case $SYSV_MAN_SECTIONS in
> + true)   FILE_MAN_SUFFIX=4  ;;
>   *)  FILE_MAN_SUFFIX=5  ;;
>  esac
>  fi
> @@ -140,9 +150,8 @@ if test x$FILE_MAN_DIR = x; then
>  fi
>  
>  if test x$MISC_MAN_SUFFIX = x; then
> -case $host_os in
> - # Solaris 2.0 - 11 use SysV man page sections
> - solaris2.?|solaris2.1[[01]])MISC_MAN_SUFFIX=5  ;;
> +case $SYSV_MAN_SECTIONS in
> + true)   MISC_MAN_SUFFIX=5  ;;
>   *)  MISC_MAN_SUFFIX=7  ;;
>  esac
>  fi
> @@ -151,9 +160,8 @@ if test x$MISC_MAN_DIR = x; then
>  fi
>  
>  if test x$DRIVER_MAN_SUFFIX = x; then
> -case $host_os in
> - # Solaris 2.0 - 11 use SysV man page sections
> - solaris2.?|solaris2.1[[01]])DRIVER_MAN_SUFFIX=7  ;;
> +case $SYSV_MAN_SECTIONS in
> + true)   DRIVER_MAN_SUFFIX=7  ;;
>   *)  DRIVER_MAN_SUFFIX=4  ;;
>  esac
>  fi
> @@ -162,9 +170,8 @@ if test x$DRIVER_MAN_DIR = x; then
>  fi
>  
>  if test x$ADMIN_MAN_SUFFIX = x; then
> -case $host_os in
> - # Solaris 2.0 - 11 use SysV man page sections
> - solaris2.?|solaris2.1[[01]])ADMIN_MAN_SUFFIX=1m ;;
> +case $SYSV_MAN_SECTIONS in
> + true)   ADMIN_MAN_SUFFIX=1m ;;
>   *)  ADMIN_MAN_SUFFIX=8  ;;
>  esac
>  fi
> -- 
> 2.13.0
> 
> ___
> 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

-- 
Matthieu Herrb


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

[PATCH:macros] Update check for manpage section numbers to not rely on Solaris version

[Alan Coopersmith]

Check for a specific file instead of a specific set of versions from
uname, to cope with manpage section alignment coming to 11.4 instead
of 12.0.

Signed-off-by: Alan Coopersmith 
---
 xorg-macros.m4.in | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index 7935426..efce888 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -114,6 +114,17 @@ AC_DEFUN([XORG_MANPAGE_SECTIONS],[
 AC_REQUIRE([AC_CANONICAL_HOST])
 AC_REQUIRE([AC_PROG_SED])
 
+case $host_os in
+solaris*)
+# Solaris 2.0 - 11.3 use SysV man page section numbers, so we
+# check for a man page file found in later versions that use
+# traditional section numbers instead
+AC_CHECK_FILE([/usr/share/man/man7/attributes.7],
+[SYSV_MAN_SECTIONS=false], [SYSV_MAN_SECTIONS=true])
+;;
+*) SYSV_MAN_SECTIONS=false ;;
+esac
+
 if test x$APP_MAN_SUFFIX = x; then
 APP_MAN_SUFFIX=1
 fi
@@ -129,9 +140,8 @@ if test x$LIB_MAN_DIR = x; then
 fi
 
 if test x$FILE_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])FILE_MAN_SUFFIX=4  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   FILE_MAN_SUFFIX=4  ;;
*)  FILE_MAN_SUFFIX=5  ;;
 esac
 fi
@@ -140,9 +150,8 @@ if test x$FILE_MAN_DIR = x; then
 fi
 
 if test x$MISC_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])MISC_MAN_SUFFIX=5  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   MISC_MAN_SUFFIX=5  ;;
*)  MISC_MAN_SUFFIX=7  ;;
 esac
 fi
@@ -151,9 +160,8 @@ if test x$MISC_MAN_DIR = x; then
 fi
 
 if test x$DRIVER_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])DRIVER_MAN_SUFFIX=7  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   DRIVER_MAN_SUFFIX=7  ;;
*)  DRIVER_MAN_SUFFIX=4  ;;
 esac
 fi
@@ -162,9 +170,8 @@ if test x$DRIVER_MAN_DIR = x; then
 fi
 
 if test x$ADMIN_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])ADMIN_MAN_SUFFIX=1m ;;
+case $SYSV_MAN_SECTIONS in
+   true)   ADMIN_MAN_SUFFIX=1m ;;
*)  ADMIN_MAN_SUFFIX=8  ;;
 esac
 fi
-- 
2.13.0

___
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: Update PCI IDs for next xserver release

[Olivier Fourdan]

Hi Mark,

> Please include the following commit in the next xserver release:
> 
> abb031e731f5c159add1b3351de9c4bb121bf00a
> dri2: Sync i965_pci_ids.h from Mesa.
> 
> The ids are needed for us to test new systems with xorg.

You actually need 2 commits on server-1.19-branch:

  abb031e73 dri2: Sync i965_pci_ids.h from Mesa.
  368f60d46 dri2: Sync i965_pci_ids.h from Mesa.

To bring 1.19 to the same point as master.

I'll add both to my (next) pull request.

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

Update PCI IDs for next xserver release

[Mark Janes]

Please include the following commit in the next xserver release:

abb031e731f5c159add1b3351de9c4bb121bf00a
dri2: Sync i965_pci_ids.h from Mesa.

The ids are needed for us to test new systems with xorg.

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

[PATCHv3 02/12] edid-decode: update Audio Block with CEA-861.2

[Hans Verkuil]

From: Hans Verkuil 

Add support for extended audio formats and report the format
specific information.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 51 ---
 1 file changed, 44 insertions(+), 7 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 0c93d104..c5de5f6e 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1017,6 +1017,24 @@ do_checksum(unsigned char *x, size_t len)
 
 /* CEA extension */
 
+static const char *
+audio_ext_format(unsigned char x)
+{
+switch (x) {
+case 4: return "MPEG-4 HE AAC";
+case 5: return "MPEG-4 HE AAC v2";
+case 6: return "MPEG-4 AAC LC";
+case 7: return "DRA";
+case 8: return "MPEG-4 HE AAC + MPEG Surround";
+case 10: return "MPEG-4 AAC + MPEG Surround";
+case 11: return "MPEG-H 3D Audio";
+case 12: return "AC-4";
+case 13: return "L-PCM 3D Audio";
+default: return "RESERVED";
+}
+return "BROKEN"; /* can't happen */
+}
+
 static const char *
 audio_format(unsigned char x)
 {
@@ -1044,7 +1062,7 @@ audio_format(unsigned char x)
 static void
 cea_audio_block(unsigned char *x)
 {
-int i, format;
+int i, format, ext_format = 0;
 int length = x[0] & 0x1f;
 
 if (length % 3) {
@@ -1055,9 +1073,18 @@ cea_audio_block(unsigned char *x)
 
 for (i = 1; i < length; i += 3) {
format = (x[i] & 0x78) >> 3;
-   printf("%s, max channels %d\n", audio_format(format),
-  (x[i] & 0x07)+1);
-   printf("Supported sample rates (kHz):%s%s%s%s%s%s%s\n",
+   ext_format = (x[i + 2] & 0xf8) >> 3;
+   if (format != 15)
+   printf("%s, max channels %d\n", audio_format(format),
+  (x[i] & 0x07)+1);
+   else if (ext_format == 13)
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (((x[i + 1] & 0x80) >> 3) | ((x[i] & 0x80) >> 4) |
+   (x[i] & 0x07))+1);
+   else
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (x[i] & 0x07)+1);
+   printf("  Supported sample rates (kHz):%s%s%s%s%s%s%s\n",
   (x[i+1] & 0x40) ? " 192" : "",
   (x[i+1] & 0x20) ? " 176.4" : "",
   (x[i+1] & 0x10) ? " 96" : "",
@@ -1065,13 +1092,23 @@ cea_audio_block(unsigned char *x)
   (x[i+1] & 0x04) ? " 48" : "",
   (x[i+1] & 0x02) ? " 44.1" : "",
   (x[i+1] & 0x01) ? " 32" : "");
-   if (format == 1) {
-   printf("Supported sample sizes (bits):%s%s%s\n",
+   if (format == 1 || ext_format == 13) {
+   printf("  Supported sample sizes (bits):%s%s%s\n",
  (x[i+2] & 0x04) ? " 24" : "",
  (x[i+2] & 0x02) ? " 20" : "",
  (x[i+2] & 0x01) ? " 16" : "");
} else if (format <= 8) {
-   printf("Maximum bit rate: %d kHz\n", x[i+2] * 8);
+   printf("  Maximum bit rate: %d kHz\n", x[i+2] * 8);
+   } else if (format == 14) {
+   printf("  Profile: %d\n", x[i+2] & 7);
+   } else if ((ext_format >= 4 && ext_format <= 6) ||
+  ext_format == 8 || ext_format == 10) {
+   printf("  AAC audio frame lengths:%s%s\n",
+  (x[i+2] & 4) ? " 1024_TL" : "",
+  (x[i+2] & 2) ? " 960_TL" : "");
+   if (ext_format >= 8 && (x[i+2] & 1))
+   printf("  Supports %s signaled MPEG Surround data\n",
+  (x[i+2] & 1) ? "implicitly and explicitly" : "only 
implicitly");
}
 }
 }
-- 
2.14.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

[PATCHv3 03/12] edid-decode: update Speaker Allocation data block

[Hans Verkuil]

From: Hans Verkuil 

More bits are now in use, implement support for those.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index c5de5f6e..8d47a5fc 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1615,17 +1615,26 @@ static struct field *vcdb_fields[] = {
 };
 
 static const char *sadb_map[] = {
-"FL/FR",
-"LFE",
-"FC",
-"RL/RR",
-"RC",
-"FLC/FRC",
-"RLC/RRC",
-"FLW/FRW",
-"FLH/FRH",
-"TC",
-"FCH",
+"FL/FR - Front Left/Right",
+"LFE - Low Frequency Effects",
+"FC - Front Center",
+"BL/BR - Back Left/Right",
+"BC - Back Center",
+"FLC/FRC - Front Left/Right of Center",
+"RLC/RRC - Rear Left/Right of Center",
+"FLW/FRW - Front Left/Right Wide",
+"TpFL/TpFH - Top Front Left/Right",
+"TpC - Top Center",
+"TpFC - Top Front Center",
+"LS/RS - Left/Right Surround",
+"LFE2 - Low Frequency Effects 2",
+"TpBC - Top Back Center",
+"SiL/SiR - Side Left/Right",
+"TpSiL/TpSiR - Top Side Left/Right",
+"TpBL/TpBR - Top Back Left/Right",
+"BtFC - Bottom Front Center",
+"BtFL/BtBR - Bottom Front Left/Right",
+"TpLS/TpRS - Top Left/Right Surround",
 };
 
 static void
@@ -1635,16 +1644,14 @@ cea_sadb(unsigned char *x)
 int i;
 
 if (length >= 3) {
-   uint16_t sad = ((x[2] << 8) | x[1]);
+   uint32_t sad = ((x[3] << 16) | (x[2] << 8) | x[1]);
 
-   printf("Speaker map:");
+   printf("Speaker map:\n");
 
for (i = 0; i < ARRAY_SIZE(sadb_map); i++) {
if ((sad >> i) & 1)
-   printf(" %s", sadb_map[i]);
+   printf("  %s\n", sadb_map[i]);
}
-
-   printf("\n");
 }
 }
 
-- 
2.14.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

[PATCHv2 2/8] edid-decode: update Audio Block with CEA-861.2

[Hans Verkuil]

From: Hans Verkuil 

Add support for extended audio formats and report the format
specific information.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 51 ---
 1 file changed, 44 insertions(+), 7 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 0c93d104..c5de5f6e 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1017,6 +1017,24 @@ do_checksum(unsigned char *x, size_t len)
 
 /* CEA extension */
 
+static const char *
+audio_ext_format(unsigned char x)
+{
+switch (x) {
+case 4: return "MPEG-4 HE AAC";
+case 5: return "MPEG-4 HE AAC v2";
+case 6: return "MPEG-4 AAC LC";
+case 7: return "DRA";
+case 8: return "MPEG-4 HE AAC + MPEG Surround";
+case 10: return "MPEG-4 AAC + MPEG Surround";
+case 11: return "MPEG-H 3D Audio";
+case 12: return "AC-4";
+case 13: return "L-PCM 3D Audio";
+default: return "RESERVED";
+}
+return "BROKEN"; /* can't happen */
+}
+
 static const char *
 audio_format(unsigned char x)
 {
@@ -1044,7 +1062,7 @@ audio_format(unsigned char x)
 static void
 cea_audio_block(unsigned char *x)
 {
-int i, format;
+int i, format, ext_format = 0;
 int length = x[0] & 0x1f;
 
 if (length % 3) {
@@ -1055,9 +1073,18 @@ cea_audio_block(unsigned char *x)
 
 for (i = 1; i < length; i += 3) {
format = (x[i] & 0x78) >> 3;
-   printf("%s, max channels %d\n", audio_format(format),
-  (x[i] & 0x07)+1);
-   printf("Supported sample rates (kHz):%s%s%s%s%s%s%s\n",
+   ext_format = (x[i + 2] & 0xf8) >> 3;
+   if (format != 15)
+   printf("%s, max channels %d\n", audio_format(format),
+  (x[i] & 0x07)+1);
+   else if (ext_format == 13)
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (((x[i + 1] & 0x80) >> 3) | ((x[i] & 0x80) >> 4) |
+   (x[i] & 0x07))+1);
+   else
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (x[i] & 0x07)+1);
+   printf("  Supported sample rates (kHz):%s%s%s%s%s%s%s\n",
   (x[i+1] & 0x40) ? " 192" : "",
   (x[i+1] & 0x20) ? " 176.4" : "",
   (x[i+1] & 0x10) ? " 96" : "",
@@ -1065,13 +1092,23 @@ cea_audio_block(unsigned char *x)
   (x[i+1] & 0x04) ? " 48" : "",
   (x[i+1] & 0x02) ? " 44.1" : "",
   (x[i+1] & 0x01) ? " 32" : "");
-   if (format == 1) {
-   printf("Supported sample sizes (bits):%s%s%s\n",
+   if (format == 1 || ext_format == 13) {
+   printf("  Supported sample sizes (bits):%s%s%s\n",
  (x[i+2] & 0x04) ? " 24" : "",
  (x[i+2] & 0x02) ? " 20" : "",
  (x[i+2] & 0x01) ? " 16" : "");
} else if (format <= 8) {
-   printf("Maximum bit rate: %d kHz\n", x[i+2] * 8);
+   printf("  Maximum bit rate: %d kHz\n", x[i+2] * 8);
+   } else if (format == 14) {
+   printf("  Profile: %d\n", x[i+2] & 7);
+   } else if ((ext_format >= 4 && ext_format <= 6) ||
+  ext_format == 8 || ext_format == 10) {
+   printf("  AAC audio frame lengths:%s%s\n",
+  (x[i+2] & 4) ? " 1024_TL" : "",
+  (x[i+2] & 2) ? " 960_TL" : "");
+   if (ext_format >= 8 && (x[i+2] & 1))
+   printf("  Supports %s signaled MPEG Surround data\n",
+  (x[i+2] & 1) ? "implicitly and explicitly" : "only 
implicitly");
}
 }
 }
-- 
2.14.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

[PATCHv2 3/8] edid-decode: update Speaker Allocation data block

[Hans Verkuil]

From: Hans Verkuil 

More bits are now in use, implement support for those.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index c5de5f6e..8d47a5fc 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1615,17 +1615,26 @@ static struct field *vcdb_fields[] = {
 };
 
 static const char *sadb_map[] = {
-"FL/FR",
-"LFE",
-"FC",
-"RL/RR",
-"RC",
-"FLC/FRC",
-"RLC/RRC",
-"FLW/FRW",
-"FLH/FRH",
-"TC",
-"FCH",
+"FL/FR - Front Left/Right",
+"LFE - Low Frequency Effects",
+"FC - Front Center",
+"BL/BR - Back Left/Right",
+"BC - Back Center",
+"FLC/FRC - Front Left/Right of Center",
+"RLC/RRC - Rear Left/Right of Center",
+"FLW/FRW - Front Left/Right Wide",
+"TpFL/TpFH - Top Front Left/Right",
+"TpC - Top Center",
+"TpFC - Top Front Center",
+"LS/RS - Left/Right Surround",
+"LFE2 - Low Frequency Effects 2",
+"TpBC - Top Back Center",
+"SiL/SiR - Side Left/Right",
+"TpSiL/TpSiR - Top Side Left/Right",
+"TpBL/TpBR - Top Back Left/Right",
+"BtFC - Bottom Front Center",
+"BtFL/BtBR - Bottom Front Left/Right",
+"TpLS/TpRS - Top Left/Right Surround",
 };
 
 static void
@@ -1635,16 +1644,14 @@ cea_sadb(unsigned char *x)
 int i;
 
 if (length >= 3) {
-   uint16_t sad = ((x[2] << 8) | x[1]);
+   uint32_t sad = ((x[3] << 16) | (x[2] << 8) | x[1]);
 
-   printf("Speaker map:");
+   printf("Speaker map:\n");
 
for (i = 0; i < ARRAY_SIZE(sadb_map); i++) {
if ((sad >> i) & 1)
-   printf(" %s", sadb_map[i]);
+   printf("  %s\n", sadb_map[i]);
}
-
-   printf("\n");
 }
 }
 
-- 
2.14.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: [PATCH 2/8] edid-decode: update Speaker Allocation data block

[Hans Verkuil]

On 09/08/17 10:50, walter harms wrote:
> 
> 
> Am 07.09.2017 20:03, schrieb Hans Verkuil:
>> From: Hans Verkuil 
>>
>> More bits are now in use, implement support for those.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  edid-decode.c | 38 ++
>>  1 file changed, 22 insertions(+), 16 deletions(-)
>>
>> diff --git a/edid-decode.c b/edid-decode.c
>> index 26550423..9b6c297e 100644
>> --- a/edid-decode.c
>> +++ b/edid-decode.c
>> @@ -1615,17 +1615,25 @@ static struct field *vcdb_fields[] = {
>>  };
>>  
>>  static const char *sadb_map[] = {
>> -"FL/FR",
>> -"LFE",
>> -"FC",
>> -"RL/RR",
>> -"RC",
>> -"FLC/FRC",
>> -"RLC/RRC",
>> -"FLW/FRW",
>> -"FLH/FRH",
>> -"TC",
>> -"FCH",
>> +"FL/FR - Front Left/Right",
>> +"LFE - Low Frequency Effects",
>> +"FC - Front Center",
>> +"BL/BR - Back Left/Right",
>> +"BC - Back Center",
>> +"FLC/FRC - Front Left/Right of Center",
>> +"RLC/RRC - Rear Left/Right of Center",
>> +"FLW/FRW - Front Left/Right Wide",
>> +"TpFL/TpFH - Top Front Left/Right",
>> +"TpC - Top Center",
>> +"LS/RS - Left/Right Surround",
>> +"LFE2 - Low Frequency Effects 2",
>> +"TpBC - Top Back Center",
>> +"SiL/SiR - Side Left/Right",
>> +"TpSiL/TpSiR - Top Side Left/Right",
>> +"TpBL/TpBR - Top Back Left/Right",
>> +"BtFC - Bottom Front Center",
>> +"BtFL/BtBR - Bottom Front Left/Right",
>> +"TpLS/TpRS - Top Left/Right Surround",
>>  };
>>  
>>  static void
>> @@ -1635,16 +1643,14 @@ cea_sadb(unsigned char *x)
>>  int i;
>>  
>>  if (length >= 3) {
>> -uint16_t sad = ((x[2] << 8) | x[1]);
>> +uint32_t sad = ((x[3] << 16) | (x[2] << 8) | x[1]);
>>  
>> -printf("Speaker map:");
>> +printf("Speaker map:\n");
>>  
>>  for (i = 0; i < ARRAY_SIZE(sadb_map); i++) {
>>  if ((sad >> i) & 1)
>> -printf(" %s", sadb_map[i]);
>> +printf("  %s\n", sadb_map[i]);
>>  }
> 
> just a remark:
>  if (sad & 1)
>   
>  sad >>=1 ;
>  if (sad == 0) break;
> 
> to avoid testing empty bits ..

I believe that makes the code harder to read for no real performance
advantage (it wouldn't surprise me if it would actually be slower
in some cases!).

So I leave this as-is.

Regards,

Hans
___
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 2/8] edid-decode: update Speaker Allocation data block

[walter harms]

Am 07.09.2017 20:03, schrieb Hans Verkuil:
> From: Hans Verkuil 
> 
> More bits are now in use, implement support for those.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  edid-decode.c | 38 ++
>  1 file changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/edid-decode.c b/edid-decode.c
> index 26550423..9b6c297e 100644
> --- a/edid-decode.c
> +++ b/edid-decode.c
> @@ -1615,17 +1615,25 @@ static struct field *vcdb_fields[] = {
>  };
>  
>  static const char *sadb_map[] = {
> -"FL/FR",
> -"LFE",
> -"FC",
> -"RL/RR",
> -"RC",
> -"FLC/FRC",
> -"RLC/RRC",
> -"FLW/FRW",
> -"FLH/FRH",
> -"TC",
> -"FCH",
> +"FL/FR - Front Left/Right",
> +"LFE - Low Frequency Effects",
> +"FC - Front Center",
> +"BL/BR - Back Left/Right",
> +"BC - Back Center",
> +"FLC/FRC - Front Left/Right of Center",
> +"RLC/RRC - Rear Left/Right of Center",
> +"FLW/FRW - Front Left/Right Wide",
> +"TpFL/TpFH - Top Front Left/Right",
> +"TpC - Top Center",
> +"LS/RS - Left/Right Surround",
> +"LFE2 - Low Frequency Effects 2",
> +"TpBC - Top Back Center",
> +"SiL/SiR - Side Left/Right",
> +"TpSiL/TpSiR - Top Side Left/Right",
> +"TpBL/TpBR - Top Back Left/Right",
> +"BtFC - Bottom Front Center",
> +"BtFL/BtBR - Bottom Front Left/Right",
> +"TpLS/TpRS - Top Left/Right Surround",
>  };
>  
>  static void
> @@ -1635,16 +1643,14 @@ cea_sadb(unsigned char *x)
>  int i;
>  
>  if (length >= 3) {
> - uint16_t sad = ((x[2] << 8) | x[1]);
> + uint32_t sad = ((x[3] << 16) | (x[2] << 8) | x[1]);
>  
> - printf("Speaker map:");
> + printf("Speaker map:\n");
>  
>   for (i = 0; i < ARRAY_SIZE(sadb_map); i++) {
>   if ((sad >> i) & 1)
> - printf(" %s", sadb_map[i]);
> + printf("  %s\n", sadb_map[i]);
>   }

just a remark:
 if (sad & 1)

 sad >>=1 ;
 if (sad == 0) break;

to avoid testing empty bits ..

re,
 wh

> -
> - printf("\n");
>  }
>  }
>  
___
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 2/8] edid-decode: update Speaker Allocation data block

[Hans Verkuil]

From: Hans Verkuil 

More bits are now in use, implement support for those.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 26550423..9b6c297e 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1615,17 +1615,25 @@ static struct field *vcdb_fields[] = {
 };
 
 static const char *sadb_map[] = {
-"FL/FR",
-"LFE",
-"FC",
-"RL/RR",
-"RC",
-"FLC/FRC",
-"RLC/RRC",
-"FLW/FRW",
-"FLH/FRH",
-"TC",
-"FCH",
+"FL/FR - Front Left/Right",
+"LFE - Low Frequency Effects",
+"FC - Front Center",
+"BL/BR - Back Left/Right",
+"BC - Back Center",
+"FLC/FRC - Front Left/Right of Center",
+"RLC/RRC - Rear Left/Right of Center",
+"FLW/FRW - Front Left/Right Wide",
+"TpFL/TpFH - Top Front Left/Right",
+"TpC - Top Center",
+"LS/RS - Left/Right Surround",
+"LFE2 - Low Frequency Effects 2",
+"TpBC - Top Back Center",
+"SiL/SiR - Side Left/Right",
+"TpSiL/TpSiR - Top Side Left/Right",
+"TpBL/TpBR - Top Back Left/Right",
+"BtFC - Bottom Front Center",
+"BtFL/BtBR - Bottom Front Left/Right",
+"TpLS/TpRS - Top Left/Right Surround",
 };
 
 static void
@@ -1635,16 +1643,14 @@ cea_sadb(unsigned char *x)
 int i;
 
 if (length >= 3) {
-   uint16_t sad = ((x[2] << 8) | x[1]);
+   uint32_t sad = ((x[3] << 16) | (x[2] << 8) | x[1]);
 
-   printf("Speaker map:");
+   printf("Speaker map:\n");
 
for (i = 0; i < ARRAY_SIZE(sadb_map); i++) {
if ((sad >> i) & 1)
-   printf(" %s", sadb_map[i]);
+   printf("  %s\n", sadb_map[i]);
}
-
-   printf("\n");
 }
 }
 
-- 
2.14.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

[PATCH 1/8] edid-decode: update Audio Block with CEA-861.2

[Hans Verkuil]

From: Hans Verkuil 

Add support for extended audio formats and report the format
specific information.

Signed-off-by: Hans Verkuil 
---
 edid-decode.c | 45 +
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 7aaeacee..26550423 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1017,6 +1017,24 @@ do_checksum(unsigned char *x, size_t len)
 
 /* CEA extension */
 
+static const char *
+audio_ext_format(unsigned char x)
+{
+switch (x) {
+case 4: return "MPEG-4 HE AAC";
+case 5: return "MPEG-4 HE AAC v2";
+case 6: return "MPEG-4 AAC LC";
+case 7: return "DRA";
+case 8: return "MPEG-4 HE AAC + MPEG Surround";
+case 10: return "MPEG-4 AAC + MPEG Surround";
+case 11: return "MPEG-H 3D Audio";
+case 12: return "AC-4";
+case 13: return "L-PCM 3D Audio";
+default: return "RESERVED";
+}
+return "BROKEN"; /* can't happen */
+}
+
 static const char *
 audio_format(unsigned char x)
 {
@@ -1044,7 +1062,7 @@ audio_format(unsigned char x)
 static void
 cea_audio_block(unsigned char *x)
 {
-int i, format;
+int i, format, ext_format = 0;
 int length = x[0] & 0x1f;
 
 if (length % 3) {
@@ -1055,8 +1073,17 @@ cea_audio_block(unsigned char *x)
 
 for (i = 1; i < length; i += 3) {
format = (x[i] & 0x78) >> 3;
-   printf("%s, max channels %d\n", audio_format(format),
-  (x[i] & 0x07)+1);
+   ext_format = (x[i + 2] & 0xf8) >> 3;
+   if (format != 15)
+   printf("%s, max channels %d\n", audio_format(format),
+  (x[i] & 0x07)+1);
+   else if (ext_format == 13)
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (((x[i + 1] & 0x80) >> 3) | ((x[i] & 0x80) >> 4) |
+   (x[i] & 0x07))+1);
+   else
+   printf("%s, max channels %d\n", audio_ext_format(ext_format),
+  (x[i] & 0x07)+1);
printf("Supported sample rates (kHz):%s%s%s%s%s%s%s\n",
   (x[i+1] & 0x40) ? " 192" : "",
   (x[i+1] & 0x20) ? " 176.4" : "",
@@ -1065,13 +1092,23 @@ cea_audio_block(unsigned char *x)
   (x[i+1] & 0x04) ? " 48" : "",
   (x[i+1] & 0x02) ? " 44.1" : "",
   (x[i+1] & 0x01) ? " 32" : "");
-   if (format == 1) {
+   if (format == 1 || ext_format == 13) {
printf("Supported sample sizes (bits):%s%s%s\n",
  (x[i+2] & 0x04) ? " 24" : "",
  (x[i+2] & 0x02) ? " 20" : "",
  (x[i+2] & 0x01) ? " 16" : "");
} else if (format <= 8) {
printf("Maximum bit rate: %d kHz\n", x[i+2] * 8);
+   } else if (format == 14) {
+   printf("Profile: %d\n", x[i+2] & 7);
+   } else if ((ext_format >= 4 && ext_format <= 6) ||
+  ext_format == 8 || ext_format == 10) {
+   printf("AAC audio frame lengths:%s%s\n",
+  (x[i+2] & 4) ? " 1024_TL" : "",
+  (x[i+2] & 2) ? " 960_TL" : "");
+   if (ext_format >= 8 && (x[i+2] & 1))
+   printf("Supports %s signaled MPEG Surround data\n",
+  (x[i+2] & 1) ? "implicitly and explicitly" : "only 
implicitly");
}
 }
 }
-- 
2.14.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

[PATCH xserver] glamor: update "required EGL extensions" comment

[Emil Velikov]

From: Emil Velikov 

The extensions listed have not been needed in a while. Replace with the
only remaining requirement.

Signed-off-by: Emil Velikov 
---
Decided to keep KHR_gl_texture_2D_image as-is (as opposed to respinning
the other patch I've just sent) since the hunk is badly outdated anyway.
Can split/squash if people prefer.
---
 glamor/glamor.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/glamor/glamor.h b/glamor/glamor.h
index 4ad28df17..5b15a46e5 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -155,8 +155,7 @@ extern _X_EXPORT struct gbm_device 
*glamor_egl_get_gbm_device(ScreenPtr screen);
  *
  * The EGL layer needs to have the following extensions working:
  *
- * .EGL_KHR_gl_texture_2D_image
- * .EGL_EXT_image_dma_buf_import
+ * .EGL_KHR_surfaceless_context
  * */
 extern _X_EXPORT Bool glamor_supports_pixmap_import_export(ScreenPtr screen);
 
-- 
2.13.0

___
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 driver/xf86-video-nested] Update for removal of virtualFrom from ScrnInfoRec

[Jon Turney]

Removed in xserver commit 76ef102b.

Signed-off-by: Jon Turney 
---
 src/driver.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/driver.c b/src/driver.c
index 0e3cb29..67eab71 100644
--- a/src/driver.c
+++ b/src/driver.c
@@ -443,7 +443,7 @@ NestedValidateModes(ScrnInfoPtr pScrn) {
 
 pScrn->modePool = NULL;
 
-/* Now set virtualX, virtualY, displayWidth and virtualFrom */
+/* Now set virtualX, virtualY and displayWidth*/
 
 if (pScrn->display->virtualX >= pScrn->modes->HDisplay &&
 pScrn->display->virtualY >= pScrn->modes->VDisplay) {
@@ -465,7 +465,6 @@ NestedValidateModes(ScrnInfoPtr pScrn) {
 pScrn->virtualX = maxX;
 pScrn->virtualY = maxY;
 }
-pScrn->virtualFrom = X_DEFAULT;
 pScrn->displayWidth = pScrn->virtualX;
 
 xf86DrvMsg(pScrn->scrnIndex, X_INFO, "Virtual size: %dx%d\n",
-- 
2.12.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

[PATCH xwayland v3 4/7] xwayland: Update root window size when desktop size changes

[Carlos Garnacho]

This fixes grabs on InputOnly windows whose parent is the root window
failing with GrabNotViewable. This is due to window->borderSize/windowSize
being computed as clipped by its parent, resulting in a null region.

Setting up the right size on the root window makes the InputOnly size
correct too, so the GrabNotViewable paths aren't hit anymore.

Signed-off-by: Carlos Garnacho 
---
 hw/xwayland/xwayland-output.c | 3 +++
 hw/xwayland/xwayland.c| 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index bfaf9795a..460caaf56 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -188,8 +188,11 @@ update_screen_size(struct xwl_output *xwl_output, int 
width, int height)
 SetRootClip(xwl_screen->screen, xwl_screen->root_clip_mode);
 
 if (xwl_screen->screen->root) {
+BoxRec box = { 0, 0, width, height };
+
 xwl_screen->screen->root->drawable.width = width;
 xwl_screen->screen->root->drawable.height = height;
+RegionReset(_screen->screen->root->winSize, );
 RRScreenSizeNotify(xwl_screen->screen);
 }
 
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 3eff3cb63..b7eeb4e42 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -443,9 +443,11 @@ xwl_realize_window(WindowPtr window)
 screen->RealizeWindow = xwl_realize_window;
 
 if (xwl_screen->rootless && !window->parent) {
+BoxRec box = { 0, 0, xwl_screen->width, xwl_screen->height };
+
+RegionReset(>winSize, );
 RegionNull(>clipList);
 RegionNull(>borderClip);
-RegionNull(>winSize);
 }
 
 if (xwl_screen->rootless) {
-- 
2.13.0

___
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 libXfont] readme: Update for libXfont 2.0 interface change

[Peter Hutterer]

On Thu, Apr 13, 2017 at 12:10:05PM -0400, Adam Jackson wrote:
> While xfs can be more or less trivially ported to 2.0, bcftopcf cannot
> because the font file I/O API is no longer externally visible. This is
> intentional, because bdftopcf is literally the only consumer of that
> API, and is itself only used in the build process for the classic core
> fonts themselves. The plan for bdftopcf is to import a copy of libXfont
> 1.5 and link against that statically instead.
> 
> Signed-off-by: Adam Jackson 

Acked-by: Peter Hutterer 

Cheers,
   Peter
> ---
>  README | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/README b/README
> index c95c3cf..de1512f 100644
> --- a/README
> +++ b/README
> @@ -1,9 +1,14 @@
> -libXfont provides the core of the legacy X11 font system, handling the
> -index files (fonts.dir, fonts.alias, fonts.scale), the various font file
> -formats, and rasterizing them.   It is used by the X servers, the
> -X Font Server (xfs), and some font utilities (bdftopcf for instance),
> -but should not be used by normal X11 clients.  X11 clients access fonts
> -via either the new API's in libXft, or the legacy API's in libX11.
> +libXfont provides the core of the legacy X11 font system, handling the index
> +files (fonts.dir, fonts.alias, fonts.scale), the various font file formats,
> +and rasterizing them.  It is used by the X servers, and will eventually be
> +used by the X Font Server (xfs), but should not be used by normal X11 
> clients.
> +X11 clients access fonts via either the new APIs in libXft, or the legacy
> +APIs in libX11.
> +
> +This version of libXfont is not compatible with xfs, or with the legacy
> +bdftopcf utility; these packages require libXfont 1.5, not libXfont 2.0
> +or later. The two versions can be installed in parallel, and eventually
> +the need for 1.5 will go away. We apologize for the inconvenience.
>  
>  libXfont supports a number of compression and font formats, and the
>  configure script takes various options to enable or disable them:
> -- 
> 2.9.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
> 
___
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 libXfont] readme: Update for libXfont 2.0 interface change

[Adam Jackson]

While xfs can be more or less trivially ported to 2.0, bcftopcf cannot
because the font file I/O API is no longer externally visible. This is
intentional, because bdftopcf is literally the only consumer of that
API, and is itself only used in the build process for the classic core
fonts themselves. The plan for bdftopcf is to import a copy of libXfont
1.5 and link against that statically instead.

Signed-off-by: Adam Jackson 
---
 README | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/README b/README
index c95c3cf..de1512f 100644
--- a/README
+++ b/README
@@ -1,9 +1,14 @@
-libXfont provides the core of the legacy X11 font system, handling the
-index files (fonts.dir, fonts.alias, fonts.scale), the various font file
-formats, and rasterizing them.   It is used by the X servers, the
-X Font Server (xfs), and some font utilities (bdftopcf for instance),
-but should not be used by normal X11 clients.  X11 clients access fonts
-via either the new API's in libXft, or the legacy API's in libX11.
+libXfont provides the core of the legacy X11 font system, handling the index
+files (fonts.dir, fonts.alias, fonts.scale), the various font file formats,
+and rasterizing them.  It is used by the X servers, and will eventually be
+used by the X Font Server (xfs), but should not be used by normal X11 clients.
+X11 clients access fonts via either the new APIs in libXft, or the legacy
+APIs in libX11.
+
+This version of libXfont is not compatible with xfs, or with the legacy
+bdftopcf utility; these packages require libXfont 1.5, not libXfont 2.0
+or later. The two versions can be installed in parallel, and eventually
+the need for 1.5 will go away. We apologize for the inconvenience.
 
 libXfont supports a number of compression and font formats, and the
 configure script takes various options to enable or disable them:
-- 
2.9.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 util/modular] xorg.modules: Update for mesonic rendercheck

[Eric Anholt]

Jon Turney  writes:

> Signed-off-by: Jon Turney 

Tested and pushed.  Thanks!


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

[PATCH util/modular] xorg.modules: Update for mesonic rendercheck

[Jon Turney]

Signed-off-by: Jon Turney 
---
 xorg.modules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xorg.modules b/xorg.modules
index 961ff17..65d3621 100644
--- a/xorg.modules
+++ b/xorg.modules
@@ -1202,7 +1202,7 @@
 
   
 
-  
+  
 
 
@@ -1211,7 +1211,7 @@
   
   
 
-  
+  
 
   
 http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH util-modular] release.sh: Also update srv_path for older Mesa releases.

[Peter Hutterer]

On Mon, Feb 27, 2017 at 11:56:32AM +, Emil Velikov wrote:
> On 27 February 2017 at 01:50, Peter Hutterer  wrote:
> > On Fri, Feb 24, 2017 at 04:09:06PM +, Emil Velikov wrote:
> >> On 14 February 2017 at 11:39, Emil Velikov  
> >> wrote:
> >> > From: Emil Velikov 
> >> >
> >> > Otherwise we'll be missing the "$version" directory and the files
> >> > will be uploaded the the wrong location.
> >> >
> >> > Fixes: f16477858bc "release.sh: remove $MESA_VERSION from the
> >> > destination location"
> >> > Signed-off-by: Emil Velikov 
> >> > ---
> >> >  release.sh | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/release.sh b/release.sh
> >> > index c894063..c824dea 100755
> >> > --- a/release.sh
> >> > +++ b/release.sh
> >> > @@ -580,6 +580,7 @@ process_module() {
> >> >  # Prior to 17.0.x Mesa uses separate folder for each release
> >> >  if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
> >> >  section_path=$section_path/$mesa_version
> >> > +srv_path="/srv/$host_current/www/$section_path"
> >> >  echo "Info: creating mesa directory on web server:"
> >> >  ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
> >> >  if [ $? -ne 0 ]; then
> >> > --
> >> > 2.11.0
> >> >
> >> Peter, others - humble ping ?
> >
> > I've pushed this one now:
> >
> > remote: Updating patchwork state for 
> > https://patchwork.freedesktop.org/project/Xorg/list/
> > remote: I: patch #138807 updated using rev 
> > f570660a8fd3a307ce9ccd112563e52e9696d334.
> > remote: I: 1 patch(es) updated to state Accepted.
> > To git+ssh://git.freedesktop.org/git/xorg/util/modular
> >b23d0b9..f570660  master -> master
> >
> >> There's a bunch of other patches of mine [for not so loved parts of
> >> xorg], which seems to be in limbo [1].
> >> Should I poke them individually or can I apply for commit access to
> >> xorg/ and push the trivial ones ?
> >
> > yes, applying for commit access is a good idea anyway :)
> >
> Do we have any tips/wiki how to do that ? I can only find this [1]
> page which doesn't say much.
> 
> Guessing that I'll just open a bug-report against xorg/other ?

I think this is the page:
https://wiki.freedesktop.org/www/AccountRequests/
summed up as: file bug against freedesktop.org, Account Modification
Requests, and CC someone to ack it, e.g. me in this case.

Cheers,
   Peter

> 
> Thanks
> Emil
> 
> [1] https://www.x.org/wiki/RepoPolicy/
___
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 util-modular] release.sh: Also update srv_path for older Mesa releases.

[Emil Velikov]

On 27 February 2017 at 01:50, Peter Hutterer  wrote:
> On Fri, Feb 24, 2017 at 04:09:06PM +, Emil Velikov wrote:
>> On 14 February 2017 at 11:39, Emil Velikov  wrote:
>> > From: Emil Velikov 
>> >
>> > Otherwise we'll be missing the "$version" directory and the files
>> > will be uploaded the the wrong location.
>> >
>> > Fixes: f16477858bc "release.sh: remove $MESA_VERSION from the
>> > destination location"
>> > Signed-off-by: Emil Velikov 
>> > ---
>> >  release.sh | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/release.sh b/release.sh
>> > index c894063..c824dea 100755
>> > --- a/release.sh
>> > +++ b/release.sh
>> > @@ -580,6 +580,7 @@ process_module() {
>> >  # Prior to 17.0.x Mesa uses separate folder for each release
>> >  if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
>> >  section_path=$section_path/$mesa_version
>> > +srv_path="/srv/$host_current/www/$section_path"
>> >  echo "Info: creating mesa directory on web server:"
>> >  ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
>> >  if [ $? -ne 0 ]; then
>> > --
>> > 2.11.0
>> >
>> Peter, others - humble ping ?
>
> I've pushed this one now:
>
> remote: Updating patchwork state for 
> https://patchwork.freedesktop.org/project/Xorg/list/
> remote: I: patch #138807 updated using rev 
> f570660a8fd3a307ce9ccd112563e52e9696d334.
> remote: I: 1 patch(es) updated to state Accepted.
> To git+ssh://git.freedesktop.org/git/xorg/util/modular
>b23d0b9..f570660  master -> master
>
>> There's a bunch of other patches of mine [for not so loved parts of
>> xorg], which seems to be in limbo [1].
>> Should I poke them individually or can I apply for commit access to
>> xorg/ and push the trivial ones ?
>
> yes, applying for commit access is a good idea anyway :)
>
Do we have any tips/wiki how to do that ? I can only find this [1]
page which doesn't say much.

Guessing that I'll just open a bug-report against xorg/other ?

Thanks
Emil

[1] https://www.x.org/wiki/RepoPolicy/
___
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 util-modular] release.sh: Also update srv_path for older Mesa releases.

[Peter Hutterer]

On Fri, Feb 24, 2017 at 04:09:06PM +, Emil Velikov wrote:
> On 14 February 2017 at 11:39, Emil Velikov  wrote:
> > From: Emil Velikov 
> >
> > Otherwise we'll be missing the "$version" directory and the files
> > will be uploaded the the wrong location.
> >
> > Fixes: f16477858bc "release.sh: remove $MESA_VERSION from the
> > destination location"
> > Signed-off-by: Emil Velikov 
> > ---
> >  release.sh | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/release.sh b/release.sh
> > index c894063..c824dea 100755
> > --- a/release.sh
> > +++ b/release.sh
> > @@ -580,6 +580,7 @@ process_module() {
> >  # Prior to 17.0.x Mesa uses separate folder for each release
> >  if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
> >  section_path=$section_path/$mesa_version
> > +srv_path="/srv/$host_current/www/$section_path"
> >  echo "Info: creating mesa directory on web server:"
> >  ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
> >  if [ $? -ne 0 ]; then
> > --
> > 2.11.0
> >
> Peter, others - humble ping ?

I've pushed this one now:

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #138807 updated using rev 
f570660a8fd3a307ce9ccd112563e52e9696d334.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/util/modular
   b23d0b9..f570660  master -> master

> There's a bunch of other patches of mine [for not so loved parts of
> xorg], which seems to be in limbo [1].
> Should I poke them individually or can I apply for commit access to
> xorg/ and push the trivial ones ?

yes, applying for commit access is a good idea anyway :)

I'll go through the others today, poke me for any left by (my) tomorrow.

Cheers,
   Peter

> 
> Thanks
> Emil
> 
> [1] All but the the visibility bits and build.sh add remaining... from PW
> https://patchwork.freedesktop.org/project/Xorg/patches/?submitter=2810
___
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 util-modular] release.sh: Also update srv_path for older Mesa releases.

[Emil Velikov]

On 14 February 2017 at 11:39, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Otherwise we'll be missing the "$version" directory and the files
> will be uploaded the the wrong location.
>
> Fixes: f16477858bc "release.sh: remove $MESA_VERSION from the
> destination location"
> Signed-off-by: Emil Velikov 
> ---
>  release.sh | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/release.sh b/release.sh
> index c894063..c824dea 100755
> --- a/release.sh
> +++ b/release.sh
> @@ -580,6 +580,7 @@ process_module() {
>  # Prior to 17.0.x Mesa uses separate folder for each release
>  if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
>  section_path=$section_path/$mesa_version
> +srv_path="/srv/$host_current/www/$section_path"
>  echo "Info: creating mesa directory on web server:"
>  ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
>  if [ $? -ne 0 ]; then
> --
> 2.11.0
>
Peter, others - humble ping ?

There's a bunch of other patches of mine [for not so loved parts of
xorg], which seems to be in limbo [1].
Should I poke them individually or can I apply for commit access to
xorg/ and push the trivial ones ?

Thanks
Emil

[1] All but the the visibility bits and build.sh add remaining... from PW
https://patchwork.freedesktop.org/project/Xorg/patches/?submitter=2810
___
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 xf86-input-libinput 2/3] Update pad modes in a workproc, not during the input thread

[Peter Hutterer]

Updating the property directly causes us to send events from the input thread
which has some "interesting" side effects like messing up the reply order or
just crashing the server.

Schedule a work proc instead and update it whenever the server is back in the
main thread.

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 src/xf86libinput.c | 76 --
 1 file changed, 62 insertions(+), 14 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index c1214b7..ef03d3e 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -3389,17 +3389,43 @@ static Atom prop_float;
 static Atom prop_device;
 static Atom prop_product_id;
 
-static inline void
-update_mode_prop(InputInfoPtr pInfo,
-struct libinput_event_tablet_pad *event)
-{
-   struct xf86libinput *driver_data = pInfo->private;
+struct mode_prop_state {
+   int deviceid;
+   InputInfoPtr pInfo;
+
struct libinput_tablet_pad_mode_group *group;
unsigned int mode;
unsigned int idx;
+};
+
+static Bool
+update_mode_prop_cb(ClientPtr client, pointer closure)
+{
+   struct mode_prop_state *state = closure;
+   InputInfoPtr pInfo = state->pInfo, tmp;
+   struct xf86libinput *driver_data = pInfo->private;
+   BOOL found = FALSE;
XIPropertyValuePtr val;
int rc;
unsigned char groups[4] = {0};
+   struct libinput_tablet_pad_mode_group *group = state->group;
+   unsigned int mode = state->mode;
+   unsigned int idx = state->idx;
+
+   if (idx >= ARRAY_SIZE(groups))
+   goto out;
+
+   /* The device may have gotten removed before the WorkProc was
+* scheduled. X reuses deviceids, but if the pointer value and
+* device ID are what we had before, we're good */
+   nt_list_for_each_entry(tmp, xf86FirstLocalDevice(), next) {
+   if (tmp->dev->id == state->deviceid && tmp == pInfo) {
+   found = TRUE;
+   break;
+   }
+   }
+   if (!found)
+   goto out;
 
rc = XIGetDeviceProperty(pInfo->dev,
 prop_mode_groups,
@@ -3407,18 +3433,12 @@ update_mode_prop(InputInfoPtr pInfo,
if (rc != Success ||
val->format != 8 ||
val->size <= 0)
-   return;
+   goto out;
 
memcpy(groups, (unsigned char*)val->data, val->size);
 
-   group = libinput_event_tablet_pad_get_mode_group(event);
-   mode = libinput_event_tablet_pad_get_mode(event);
-   idx = libinput_tablet_pad_mode_group_get_index(group);
-   if (idx >= ARRAY_SIZE(groups))
-   return;
-
if (groups[idx] == mode)
-   return;
+   goto out;
 
groups[idx] = mode;
 
@@ -3431,8 +3451,36 @@ update_mode_prop(InputInfoPtr pInfo,
groups,
TRUE);
driver_data->allow_mode_group_updates = false;
-   if (rc != Success)
+
+out:
+   libinput_tablet_pad_mode_group_unref(group);
+   free(state);
+   return TRUE;
+}
+
+static inline void
+update_mode_prop(InputInfoPtr pInfo,
+struct libinput_event_tablet_pad *event)
+{
+   struct libinput_tablet_pad_mode_group *group;
+   struct mode_prop_state *state;
+
+   state = calloc(1, sizeof(*state));
+   if (!state)
return;
+
+   state->deviceid = pInfo->dev->id;
+   state->pInfo = pInfo;
+
+   group = libinput_event_tablet_pad_get_mode_group(event);
+
+   state->group = libinput_tablet_pad_mode_group_ref(group);
+   state->mode = libinput_event_tablet_pad_get_mode(event);
+   state->idx = libinput_tablet_pad_mode_group_get_index(group);
+
+   /* Schedule a WorkProc so we don't update from within the input
+  thread */
+   QueueWorkProc(update_mode_prop_cb, serverClient, state);
 }
 
 static inline BOOL
-- 
2.9.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

[PATCH util-modular] release.sh: Also update srv_path for older Mesa releases.

[Emil Velikov]

From: Emil Velikov 

Otherwise we'll be missing the "$version" directory and the files
will be uploaded the the wrong location.

Fixes: f16477858bc "release.sh: remove $MESA_VERSION from the
destination location"
Signed-off-by: Emil Velikov 
---
 release.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/release.sh b/release.sh
index c894063..c824dea 100755
--- a/release.sh
+++ b/release.sh
@@ -580,6 +580,7 @@ process_module() {
 # Prior to 17.0.x Mesa uses separate folder for each release
 if test `echo $mesa_version | cut -d'.' -f1` -lt 17; then
 section_path=$section_path/$mesa_version
+srv_path="/srv/$host_current/www/$section_path"
 echo "Info: creating mesa directory on web server:"
 ssh $USER_NAME$hostname mkdir -p $srv_path  &>/dev/null
 if [ $? -ne 0 ]; then
-- 
2.11.0

___
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 v2 xserver 8/9] xwayland: update cursor on tablet tools in proximity

[Peter Hutterer]

On Thu, Feb 09, 2017 at 11:31:56AM -0800, Jason Gerecke wrote:
> On Tue, Feb 7, 2017 at 6:42 PM, Peter Hutterer <peter.hutte...@who-t.net> 
> wrote:
> > From: Carlos Garnacho <carl...@gnome.org>
> >
> > Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
> > will get an independent cursor that can be set through
> > zwp_tablet_tool.set_cursor.
> >
> > However, all tools (and the pointer) share conceptually the same VCP
> > on Xwayland, so have cursor changes trigger a xwl_cursor update on
> > every tool (and the pointer, again). Maybe Xwayland could keep track
> > of the most recent device and only update that cursor to get better
> > visual results, but this is simpler, and it's going to be odd
> > anyway...
> >
> > Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
> > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> > ---
> > No changes to v1
> >
> >  hw/xwayland/xwayland-cursor.c | 56 
> > +++
> >  hw/xwayland/xwayland-input.c  | 17 +
> >  hw/xwayland/xwayland.h|  5 
> >  3 files changed, 78 insertions(+)
> >
> > diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
> > index 1b854bf..5316b56 100644
> > --- a/hw/xwayland/xwayland-cursor.c
> > +++ b/hw/xwayland/xwayland-cursor.c
> > @@ -165,11 +165,62 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
> >  wl_surface_commit(xwl_cursor->surface);
> >  }
> >
> > +void
> > +xwl_tablet_tool_set_cursor(struct xwl_tablet_tool *xwl_tablet_tool)
> > +{
> > +struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
> > +struct xwl_cursor *xwl_cursor = _tablet_tool->cursor;
> > +PixmapPtr pixmap;
> > +CursorPtr cursor;
> > +int stride;
> > +
> > +if (!xwl_seat->x_cursor) {
> > +zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
> > +  xwl_tablet_tool->proximity_in_serial,
> > +  NULL, 0, 0);
> > +return;
> > +}
> > +
> > +if (xwl_cursor->frame_cb) {
> > +xwl_cursor->needs_update = TRUE;
> > +return;
> > +}
> > +
> > +cursor = xwl_seat->x_cursor;
> > +pixmap = dixGetPrivate(>devPrivates, _cursor_private_key);
> > +if (!pixmap)
> > +return;
> > +
> > +stride = cursor->bits->width * 4;
> > +if (cursor->bits->argb)
> > +memcpy(pixmap->devPrivate.ptr,
> > +   cursor->bits->argb, cursor->bits->height * stride);
> > +else
> > +expand_source_and_mask(cursor, pixmap->devPrivate.ptr);
> > +
> > +zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
> > +  xwl_tablet_tool->proximity_in_serial,
> > +  xwl_cursor->surface,
> > +  xwl_seat->x_cursor->bits->xhot,
> > +  xwl_seat->x_cursor->bits->yhot);
> > +wl_surface_attach(xwl_cursor->surface,
> > +  xwl_shm_pixmap_get_wl_buffer(pixmap), 0, 0);
> > +wl_surface_damage(xwl_cursor->surface, 0, 0,
> > +  xwl_seat->x_cursor->bits->width,
> > +  xwl_seat->x_cursor->bits->height);
> > +
> > +xwl_cursor->frame_cb = wl_surface_frame(xwl_cursor->surface);
> > +wl_callback_add_listener(xwl_cursor->frame_cb, _listener, 
> > xwl_cursor);
> > +
> > +wl_surface_commit(xwl_cursor->surface);
> > +}
> > +
> >  static void
> >  xwl_set_cursor(DeviceIntPtr device,
> > ScreenPtr screen, CursorPtr cursor, int x, int y)
> >  {
> >  struct xwl_seat *xwl_seat;
> > +struct xwl_tablet_tool *xwl_tablet_tool;
> >  Bool cursor_visibility_changed;
> >
> >  xwl_seat = device->public.devicePrivate;
> > @@ -184,6 +235,11 @@ xwl_set_cursor(DeviceIntPtr device,
> >  xwl_seat_cursor_visibility_changed(xwl_seat);
> >
> >  xwl_seat_set_cursor(xwl_seat);
> > +
> > +xorg_list_for_each_entry(xwl_tablet_tool, _seat->tablet_tools, 
> > link) {
> > +if (xwl_tablet_tool->proximity_in_serial != 0)
> 
> I got a segfault here once while "abusing" things with simultaneous
>

Re: [PATCH v2 xserver 8/9] xwayland: update cursor on tablet tools in proximity

[Jason Gerecke]

On Tue, Feb 7, 2017 at 6:42 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote:
> From: Carlos Garnacho <carl...@gnome.org>
>
> Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
> will get an independent cursor that can be set through
> zwp_tablet_tool.set_cursor.
>
> However, all tools (and the pointer) share conceptually the same VCP
> on Xwayland, so have cursor changes trigger a xwl_cursor update on
> every tool (and the pointer, again). Maybe Xwayland could keep track
> of the most recent device and only update that cursor to get better
> visual results, but this is simpler, and it's going to be odd
> anyway...
>
> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> ---
> No changes to v1
>
>  hw/xwayland/xwayland-cursor.c | 56 
> +++
>  hw/xwayland/xwayland-input.c  | 17 +
>  hw/xwayland/xwayland.h|  5 
>  3 files changed, 78 insertions(+)
>
> diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
> index 1b854bf..5316b56 100644
> --- a/hw/xwayland/xwayland-cursor.c
> +++ b/hw/xwayland/xwayland-cursor.c
> @@ -165,11 +165,62 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
>  wl_surface_commit(xwl_cursor->surface);
>  }
>
> +void
> +xwl_tablet_tool_set_cursor(struct xwl_tablet_tool *xwl_tablet_tool)
> +{
> +struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
> +struct xwl_cursor *xwl_cursor = _tablet_tool->cursor;
> +PixmapPtr pixmap;
> +CursorPtr cursor;
> +int stride;
> +
> +if (!xwl_seat->x_cursor) {
> +zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
> +  xwl_tablet_tool->proximity_in_serial,
> +  NULL, 0, 0);
> +return;
> +}
> +
> +if (xwl_cursor->frame_cb) {
> +xwl_cursor->needs_update = TRUE;
> +return;
> +}
> +
> +cursor = xwl_seat->x_cursor;
> +pixmap = dixGetPrivate(>devPrivates, _cursor_private_key);
> +if (!pixmap)
> +return;
> +
> +stride = cursor->bits->width * 4;
> +if (cursor->bits->argb)
> +memcpy(pixmap->devPrivate.ptr,
> +   cursor->bits->argb, cursor->bits->height * stride);
> +else
> +expand_source_and_mask(cursor, pixmap->devPrivate.ptr);
> +
> +zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
> +  xwl_tablet_tool->proximity_in_serial,
> +  xwl_cursor->surface,
> +  xwl_seat->x_cursor->bits->xhot,
> +  xwl_seat->x_cursor->bits->yhot);
> +wl_surface_attach(xwl_cursor->surface,
> +  xwl_shm_pixmap_get_wl_buffer(pixmap), 0, 0);
> +wl_surface_damage(xwl_cursor->surface, 0, 0,
> +  xwl_seat->x_cursor->bits->width,
> +  xwl_seat->x_cursor->bits->height);
> +
> +xwl_cursor->frame_cb = wl_surface_frame(xwl_cursor->surface);
> +wl_callback_add_listener(xwl_cursor->frame_cb, _listener, 
> xwl_cursor);
> +
> +wl_surface_commit(xwl_cursor->surface);
> +}
> +
>  static void
>  xwl_set_cursor(DeviceIntPtr device,
> ScreenPtr screen, CursorPtr cursor, int x, int y)
>  {
>  struct xwl_seat *xwl_seat;
> +struct xwl_tablet_tool *xwl_tablet_tool;
>  Bool cursor_visibility_changed;
>
>  xwl_seat = device->public.devicePrivate;
> @@ -184,6 +235,11 @@ xwl_set_cursor(DeviceIntPtr device,
>  xwl_seat_cursor_visibility_changed(xwl_seat);
>
>  xwl_seat_set_cursor(xwl_seat);
> +
> +xorg_list_for_each_entry(xwl_tablet_tool, _seat->tablet_tools, link) 
> {
> +if (xwl_tablet_tool->proximity_in_serial != 0)

I got a segfault here once while "abusing" things with simultaneous
stylus/pointer input in GNOME. I haven't been able to replicate it a
second time yet and don't have the coredump anymore, though I still
have the backtrace.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours

> +xwl_tablet_tool_set_cursor(xwl_tablet_tool);
> +}
>  }
>
>  static void
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index 3cf2082..31e2473 10064

[PATCH v2 xserver 8/9] xwayland: update cursor on tablet tools in proximity

[Peter Hutterer]

From: Carlos Garnacho <carl...@gnome.org>

Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
will get an independent cursor that can be set through
zwp_tablet_tool.set_cursor.

However, all tools (and the pointer) share conceptually the same VCP
on Xwayland, so have cursor changes trigger a xwl_cursor update on
every tool (and the pointer, again). Maybe Xwayland could keep track
of the most recent device and only update that cursor to get better
visual results, but this is simpler, and it's going to be odd
anyway...

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
No changes to v1

 hw/xwayland/xwayland-cursor.c | 56 +++
 hw/xwayland/xwayland-input.c  | 17 +
 hw/xwayland/xwayland.h|  5 
 3 files changed, 78 insertions(+)

diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
index 1b854bf..5316b56 100644
--- a/hw/xwayland/xwayland-cursor.c
+++ b/hw/xwayland/xwayland-cursor.c
@@ -165,11 +165,62 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
 wl_surface_commit(xwl_cursor->surface);
 }
 
+void
+xwl_tablet_tool_set_cursor(struct xwl_tablet_tool *xwl_tablet_tool)
+{
+struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
+struct xwl_cursor *xwl_cursor = _tablet_tool->cursor;
+PixmapPtr pixmap;
+CursorPtr cursor;
+int stride;
+
+if (!xwl_seat->x_cursor) {
+zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
+  xwl_tablet_tool->proximity_in_serial,
+  NULL, 0, 0);
+return;
+}
+
+if (xwl_cursor->frame_cb) {
+xwl_cursor->needs_update = TRUE;
+return;
+}
+
+cursor = xwl_seat->x_cursor;
+pixmap = dixGetPrivate(>devPrivates, _cursor_private_key);
+if (!pixmap)
+return;
+
+stride = cursor->bits->width * 4;
+if (cursor->bits->argb)
+memcpy(pixmap->devPrivate.ptr,
+   cursor->bits->argb, cursor->bits->height * stride);
+else
+expand_source_and_mask(cursor, pixmap->devPrivate.ptr);
+
+zwp_tablet_tool_v2_set_cursor(xwl_tablet_tool->tool,
+  xwl_tablet_tool->proximity_in_serial,
+  xwl_cursor->surface,
+  xwl_seat->x_cursor->bits->xhot,
+  xwl_seat->x_cursor->bits->yhot);
+wl_surface_attach(xwl_cursor->surface,
+  xwl_shm_pixmap_get_wl_buffer(pixmap), 0, 0);
+wl_surface_damage(xwl_cursor->surface, 0, 0,
+  xwl_seat->x_cursor->bits->width,
+  xwl_seat->x_cursor->bits->height);
+
+xwl_cursor->frame_cb = wl_surface_frame(xwl_cursor->surface);
+wl_callback_add_listener(xwl_cursor->frame_cb, _listener, 
xwl_cursor);
+
+wl_surface_commit(xwl_cursor->surface);
+}
+
 static void
 xwl_set_cursor(DeviceIntPtr device,
ScreenPtr screen, CursorPtr cursor, int x, int y)
 {
 struct xwl_seat *xwl_seat;
+struct xwl_tablet_tool *xwl_tablet_tool;
 Bool cursor_visibility_changed;
 
 xwl_seat = device->public.devicePrivate;
@@ -184,6 +235,11 @@ xwl_set_cursor(DeviceIntPtr device,
 xwl_seat_cursor_visibility_changed(xwl_seat);
 
 xwl_seat_set_cursor(xwl_seat);
+
+xorg_list_for_each_entry(xwl_tablet_tool, _seat->tablet_tools, link) {
+if (xwl_tablet_tool->proximity_in_serial != 0)
+xwl_tablet_tool_set_cursor(xwl_tablet_tool);
+}
 }
 
 static void
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 3cf2082..31e2473 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -1398,6 +1398,7 @@ tablet_tool_receive_removed(void *data, struct 
zwp_tablet_tool_v2 *tool)
 struct xwl_tablet_tool *xwl_tablet_tool = data;
 
 xorg_list_del(_tablet_tool->link);
+xwl_cursor_release(_tablet_tool->cursor);
 zwp_tablet_tool_v2_destroy(tool);
 free(xwl_tablet_tool);
 }
@@ -1421,7 +1422,10 @@ tablet_tool_proximity_in(void *data, struct 
zwp_tablet_tool_v2 *tool,
 if (wl_surface == NULL)
 return;
 
+xwl_tablet_tool->proximity_in_serial = serial;
 xwl_seat->focus_window = wl_surface_get_user_data(wl_surface);
+
+xwl_tablet_tool_set_cursor(xwl_tablet_tool);
 }
 
 static void
@@ -1430,6 +1434,7 @@ tablet_tool_proximity_out(void *data, struct 
zwp_tablet_tool_v2 *tool)
 struct xwl_tablet_tool *xwl_tablet_tool = data;
 struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
 
+xwl_tablet_tool->proximity_in_serial = 0;
 xwl_seat->focus_window = NULL;
 
 xwl_tablet_tool->pressure = 0;
@@ -

Re: [Mesa-dev] Time to update GSoC/EVoC ideas page

[Daniel Vetter]

On Fri, Jan 20, 2017 at 08:44:19AM -0800, Jason Ekstrand wrote:
> On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> 
> > Hi Rob,
> >
> > On 19.01.2017 23:32, Rob Clark wrote:
> >
> >> Just a friendly reminder that now would be a good time to update the
> >> wiki page for GSoC/EVoC ideas:
> >>
> >>   https://www.x.org/wiki/SummerOfCodeIdeas/
> >>
> >> There are currently still some stale ideas there (and probably plenty
> >> of missing good ideas).
> >>
> >> Also, I've added a "Potential Mentors" section.  Please add yourself
> >> if you are willing to be a mentor (and what sorts of projects you
> >> would be willing to mentor)
> >>
> >
> > I'd be happy to be listed as a possible mentor on the DriConf replacement
> > project (nha on IRC/freenode), but I either don't have a Wiki account or
> > forgot it a long time ago. Could you put my name down on the page?
> >
> 
> Pro tip: You can just git clone the wiki, change a markdown file, and git
> push it back up.  That's the way I always make edits.  Way nicer than a web
> GUI. :-)

And if you have a shell account, it's easy to resurrect your web wiki
account:

https://wiki.freedesktop.org/sitewranglers/wiki/401/

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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: Time to update GSoC/EVoC ideas page

[Nicolai Hähnle]

Hi Rob,

On 19.01.2017 23:32, Rob Clark wrote:

Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:

  https://www.x.org/wiki/SummerOfCodeIdeas/

There are currently still some stale ideas there (and probably plenty
of missing good ideas).

Also, I've added a "Potential Mentors" section.  Please add yourself
if you are willing to be a mentor (and what sorts of projects you
would be willing to mentor)


I'd be happy to be listed as a possible mentor on the DriConf 
replacement project (nha on IRC/freenode), but I either don't have a 
Wiki account or forgot it a long time ago. Could you put my name down on 
the page?


Thanks,
Nicolai



BR,
-R
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-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: [Mesa-dev] Time to update GSoC/EVoC ideas page

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:

> Hi Rob,
>
> On 19.01.2017 23:32, Rob Clark wrote:
>
>> Just a friendly reminder that now would be a good time to update the
>> wiki page for GSoC/EVoC ideas:
>>
>>   https://www.x.org/wiki/SummerOfCodeIdeas/
>>
>> There are currently still some stale ideas there (and probably plenty
>> of missing good ideas).
>>
>> Also, I've added a "Potential Mentors" section.  Please add yourself
>> if you are willing to be a mentor (and what sorts of projects you
>> would be willing to mentor)
>>
>
> I'd be happy to be listed as a possible mentor on the DriConf replacement
> project (nha on IRC/freenode), but I either don't have a Wiki account or
> forgot it a long time ago. Could you put my name down on the page?
>

Pro tip: You can just git clone the wiki, change a markdown file, and git
push it back up.  That's the way I always make edits.  Way nicer than a web
GUI. :-)
___
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

Time to update GSoC/EVoC ideas page

[Rob Clark]

Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:

  https://www.x.org/wiki/SummerOfCodeIdeas/

There are currently still some stale ideas there (and probably plenty
of missing good ideas).

Also, I've added a "Potential Mentors" section.  Please add yourself
if you are willing to be a mentor (and what sorts of projects you
would be willing to mentor)

BR,
-R
___
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:libX11] specs/libX11: Update Portability Considerations for the 21st century

[Peter Hutterer]

On Sun, Jan 01, 2017 at 08:57:58PM -0800, Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith 

thanks

   28f4b98..663f470  master -> master

Cheers,
   Peter

> ---
>  specs/libX11/AppC.xml | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> The current version of this section can be seen at:
> https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Portability_Considerations
> 
> diff --git a/specs/libX11/AppC.xml b/specs/libX11/AppC.xml
> index bac148c..8eb1e00 100644
> --- a/specs/libX11/AppC.xml
> +++ b/specs/libX11/AppC.xml
> @@ -3211,13 +3211,12 @@ You must pass back the same pointer and size that 
> were returned by
>  
>  
>  Portability Considerations
>  
>  
> -Many machine architectures, 
> -including many of the more recent RISC architectures,
> -do not correctly access data at unaligned locations; 
> +Many machine architectures
> +do not correctly or efficiently access data at unaligned locations;
>  their compilers pad out structures to preserve this characteristic.
>  Many other machines capable of unaligned references pad inside of structures
>  as well to preserve alignment, because accessing aligned data is
>  usually much faster.
>  Because the library and the server use structures to access data at
> @@ -3227,11 +3226,13 @@ that is, 16-bit data starts on 16-bit boundaries in 
> the request
>  and 32-bit data on 32-bit boundaries.
>  All requests must be a multiple of 32 bits in 
> length to preserve
>  the natural alignment in the data stream.
>  You must pad structures out to 32-bit boundaries.
>  Pad information does not have to be zeroed unless you want to
> -preserve such fields for future use in your protocol requests.
> +preserve such fields for future use in your protocol requests,
> +but it is recommended to zero it to avoid inadvertant data leakage
> +and improve compressability.
>  Floating point varies radically between machines and should be
>  avoided completely if at all possible.
>  
>  
>  
> @@ -3264,19 +3265,27 @@ take on values larger than the maximum 16-bit
>  unsigned
>  int.
>  
>  
>  
> -The library currently assumes that a
> +The library has always assumed that a
>  char
>  is 8 bits, a
>  short
>  is 16 bits, an
>  int
>  is 16 or 32 bits, and a
>  long
> -is 32 bits.  
> +is 32 bits.
> +Unfortunately, this assumption remains on machines where a long
> +can hold 64-bits, and many functions and structures require unnecessarily
> +large fields to avoid breaking compatibility with existing code.  Special
> +care must be taken with arrays of values that are transmitted in the
> +protocol as CARD32 or INT32 but have to be converted to arrays of 64-bit
> +long when passed to or from client applications.
> +
> +
>  The 
>  PackData
>  macro is a half-hearted attempt to deal with the possibility of 32 bit 
> shorts. 
>  However, much more work is needed to make this work properly.
>  
> -- 
> 2.7.4
> 
> ___
> 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

[PATCH:libX11] specs/libX11: Update Portability Considerations for the 21st century

[Alan Coopersmith]

Signed-off-by: Alan Coopersmith 
---
 specs/libX11/AppC.xml | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

The current version of this section can be seen at:
https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Portability_Considerations

diff --git a/specs/libX11/AppC.xml b/specs/libX11/AppC.xml
index bac148c..8eb1e00 100644
--- a/specs/libX11/AppC.xml
+++ b/specs/libX11/AppC.xml
@@ -3211,13 +3211,12 @@ You must pass back the same pointer and size that were 
returned by
 
 
 Portability Considerations
 
 
-Many machine architectures, 
-including many of the more recent RISC architectures,
-do not correctly access data at unaligned locations; 
+Many machine architectures
+do not correctly or efficiently access data at unaligned locations;
 their compilers pad out structures to preserve this characteristic.
 Many other machines capable of unaligned references pad inside of structures
 as well to preserve alignment, because accessing aligned data is
 usually much faster.
 Because the library and the server use structures to access data at
@@ -3227,11 +3226,13 @@ that is, 16-bit data starts on 16-bit boundaries in the 
request
 and 32-bit data on 32-bit boundaries.
 All requests must be a multiple of 32 bits in 
length to preserve
 the natural alignment in the data stream.
 You must pad structures out to 32-bit boundaries.
 Pad information does not have to be zeroed unless you want to
-preserve such fields for future use in your protocol requests.
+preserve such fields for future use in your protocol requests,
+but it is recommended to zero it to avoid inadvertant data leakage
+and improve compressability.
 Floating point varies radically between machines and should be
 avoided completely if at all possible.
 
 
 
@@ -3264,19 +3265,27 @@ take on values larger than the maximum 16-bit
 unsigned
 int.
 
 
 
-The library currently assumes that a
+The library has always assumed that a
 char
 is 8 bits, a
 short
 is 16 bits, an
 int
 is 16 or 32 bits, and a
 long
-is 32 bits.  
+is 32 bits.
+Unfortunately, this assumption remains on machines where a long
+can hold 64-bits, and many functions and structures require unnecessarily
+large fields to avoid breaking compatibility with existing code.  Special
+care must be taken with arrays of values that are transmitted in the
+protocol as CARD32 or INT32 but have to be converted to arrays of 64-bit
+long when passed to or from client applications.
+
+
 The 
 PackData
 macro is a half-hearted attempt to deal with the possibility of 32 bit shorts. 
 However, much more work is needed to make this work properly.
 
-- 
2.7.4

___
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] Xi: when creating a new master device, update barries for all clients

[Daniel Stone]

Hi,

On 11 November 2016 at 05:33, Peter Hutterer  wrote:
> The previous code only worked when the barrier was created by the same client
> as the one calling XIChangeDeviceHierarchy.

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: [PATCH xserver] Xi: when creating a new master device, update barries for all clients

[Peter Hutterer]

On Fri, Nov 11, 2016 at 03:33:26PM +1000, Peter Hutterer wrote:
> The previous code only worked when the barrier was created by the same client
> as the one calling XIChangeDeviceHierarchy.
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=1384432
> 
> Signed-off-by: Peter Hutterer 

ping? anyone up for a review?

Cheers,
   Peter

> ---
>  Xi/xichangehierarchy.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Xi/xichangehierarchy.c b/Xi/xichangehierarchy.c
> index 8d5b577..f2b7785 100644
> --- a/Xi/xichangehierarchy.c
> +++ b/Xi/xichangehierarchy.c
> @@ -194,7 +194,8 @@ add_master(ClientPtr client, xXIAddMasterInfo * c, int 
> flags[MAXDEVICES])
>  flags[XTestptr->id] |= XISlaveAttached;
>  flags[XTestkeybd->id] |= XISlaveAttached;
>  
> -XIBarrierNewMasterDevice(client, ptr->id);
> +for (int i = 0; i < currentMaxClients; i++)
> +XIBarrierNewMasterDevice(clients[i], ptr->id);
>  
>   unwind:
>  free(name);
> @@ -300,7 +301,8 @@ remove_master(ClientPtr client, xXIRemoveMasterInfo * r, 
> int flags[MAXDEVICES])
>  }
>  }
>  
> -XIBarrierRemoveMasterDevice(client, ptr->id);
> +for (int i = 0; i < currentMaxClients; i++)
> +XIBarrierRemoveMasterDevice(clients[i], ptr->id);
>  
>  /* disable the remove the devices, XTest devices must be done first
> else the sprites they rely on will be destroyed  */
> -- 
> 2.9.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

[PATCH xwayland 4/7] xwayland: Update root window size when desktop size changes

[Carlos Garnacho]

This fixes grabs on InputOnly windows whose parent is the root window
failing with GrabNotViewable. This is due to window->borderSize/windowSize
being computed as clipped by its parent, resulting in a null region.

Setting up the right size on the root window makes the InputOnly size
correct too, so the GrabNotViewable paths aren't hit anymore.

Signed-off-by: Carlos Garnacho 
---
 hw/xwayland/xwayland-output.c | 3 +++
 hw/xwayland/xwayland.c| 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index ef3b6f6..257055d 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -177,8 +177,11 @@ update_screen_size(struct xwl_output *xwl_output, int 
width, int height)
 SetRootClip(xwl_screen->screen, xwl_screen->root_clip_mode);
 
 if (xwl_screen->screen->root) {
+BoxRec box = { 0, 0, width, height };
+
 xwl_screen->screen->root->drawable.width = width;
 xwl_screen->screen->root->drawable.height = height;
+RegionReset(_screen->screen->root->winSize, );
 RRScreenSizeNotify(xwl_screen->screen);
 }
 
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 66b2089..6a6f8f8 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -313,9 +313,11 @@ xwl_realize_window(WindowPtr window)
 screen->RealizeWindow = xwl_realize_window;
 
 if (xwl_screen->rootless && !window->parent) {
+BoxRec box = { 0, 0, xwl_screen->width, xwl_screen->height };
+
+RegionReset(>winSize, );
 RegionNull(>clipList);
 RegionNull(>borderClip);
-RegionNull(>winSize);
 }
 
 if (xwl_screen->rootless) {
-- 
2.9.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

[PATCH xserver] Xi: when creating a new master device, update barries for all clients

[Peter Hutterer]

The previous code only worked when the barrier was created by the same client
as the one calling XIChangeDeviceHierarchy.

http://bugzilla.redhat.com/show_bug.cgi?id=1384432

Signed-off-by: Peter Hutterer 
---
 Xi/xichangehierarchy.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Xi/xichangehierarchy.c b/Xi/xichangehierarchy.c
index 8d5b577..f2b7785 100644
--- a/Xi/xichangehierarchy.c
+++ b/Xi/xichangehierarchy.c
@@ -194,7 +194,8 @@ add_master(ClientPtr client, xXIAddMasterInfo * c, int 
flags[MAXDEVICES])
 flags[XTestptr->id] |= XISlaveAttached;
 flags[XTestkeybd->id] |= XISlaveAttached;
 
-XIBarrierNewMasterDevice(client, ptr->id);
+for (int i = 0; i < currentMaxClients; i++)
+XIBarrierNewMasterDevice(clients[i], ptr->id);
 
  unwind:
 free(name);
@@ -300,7 +301,8 @@ remove_master(ClientPtr client, xXIRemoveMasterInfo * r, 
int flags[MAXDEVICES])
 }
 }
 
-XIBarrierRemoveMasterDevice(client, ptr->id);
+for (int i = 0; i < currentMaxClients; i++)
+XIBarrierRemoveMasterDevice(clients[i], ptr->id);
 
 /* disable the remove the devices, XTest devices must be done first
else the sprites they rely on will be destroyed  */
-- 
2.9.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