Re: [PATCH xserver] xfree86: Restore newline before "X Protocol Version" string

2018-04-02 Thread Peter Hutterer
On Mon, Apr 02, 2018 at 03:04:08PM -0700, Aaron Plattner wrote:
> The newline before the protocl version got lost in commit
> 6cbefc3e0a33b380c147c533914437c7798d9b93. Prior to that commit, the
> release date printed a newline at the end:
> 
>  X.Org X Server 1.19.6
>  Release Date: 2017-12-20
>  X Protocol Version 11, Revision 0
>  Build Operating System: Linux 4.14.12-1-ARCH x86_64
> 
> Now, that string gets run together with the version:
> 
>  X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
>  Build Operating System: Linux
> 
> Since the version string printing has a variety of #ifdefs in it, just
> add the newline to the begining of the protocol version string.
> 
> Signed-off-by: Aaron Plattner 

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #214323 updated using rev 
574069c2912893a9b9fd3d701eb3ad4784e31553.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/xserver
   df6cbf7a2..574069c29  master -> master

Cheers,
   Peter

> ---
>  hw/xfree86/common/xf86Init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
> index ea42ec946167..3c5cc7097c49 100644
> --- a/hw/xfree86/common/xf86Init.c
> +++ b/hw/xfree86/common/xf86Init.c
> @@ -165,7 +165,7 @@ xf86PrintBanner(void)
>  #ifdef XORG_CUSTOM_VERSION
>  xf86ErrorFVerb(0, " (%s)", XORG_CUSTOM_VERSION);
>  #endif
> -xf86ErrorFVerb(0, "X Protocol Version %d, Revision %d\n",
> +xf86ErrorFVerb(0, "\nX Protocol Version %d, Revision %d\n",
> X_PROTOCOL, X_PROTOCOL_REVISION);
>  xf86ErrorFVerb(0, "Build Operating System: %s %s\n", OSNAME, OSVENDOR);
>  #ifdef HAS_UTSNAME
> -- 
> 2.16.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 xserver] xfree86: Restore newline before "X Protocol Version" string

2018-04-02 Thread Aaron Plattner
The newline before the protocl version got lost in commit
6cbefc3e0a33b380c147c533914437c7798d9b93. Prior to that commit, the
release date printed a newline at the end:

 X.Org X Server 1.19.6
 Release Date: 2017-12-20
 X Protocol Version 11, Revision 0
 Build Operating System: Linux 4.14.12-1-ARCH x86_64

Now, that string gets run together with the version:

 X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
 Build Operating System: Linux

Since the version string printing has a variety of #ifdefs in it, just
add the newline to the begining of the protocol version string.

Signed-off-by: Aaron Plattner 
---
 hw/xfree86/common/xf86Init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index ea42ec946167..3c5cc7097c49 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -165,7 +165,7 @@ xf86PrintBanner(void)
 #ifdef XORG_CUSTOM_VERSION
 xf86ErrorFVerb(0, " (%s)", XORG_CUSTOM_VERSION);
 #endif
-xf86ErrorFVerb(0, "X Protocol Version %d, Revision %d\n",
+xf86ErrorFVerb(0, "\nX Protocol Version %d, Revision %d\n",
X_PROTOCOL, X_PROTOCOL_REVISION);
 xf86ErrorFVerb(0, "Build Operating System: %s %s\n", OSNAME, OSVENDOR);
 #ifdef HAS_UTSNAME
-- 
2.16.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] meson: Fix module_dir configuration

2018-04-02 Thread Aaron Plattner
meson.build has code to set the module_dir variable to
${libdir}/xorg/modules if the module_dir option string is empty.
However, this has several problems:

1. The variable is only used for an unused @moduledir@ substitution in
   the man page. The rule for xorg-server.pc uses option('module_dir')
   directly instead.
2. The 'module_dir' option has a default value of 'xorg/modules' so the
   above rule doesn't do anything by default.
3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
   the effect of #2 is that the default moduledir is different between
   autoconf and meson. E.g. if ${prefix} is /X, then you get

 autoconf: moduledir=/X/lib/xorg/modules
 meson:moduledir=/X/xorg/modules

Fix this by using the module_dir variable when generating
xorg-server.pc, and by removing the default value for the module_dir
option.

Signed-off-by: Aaron Plattner 
---
 meson.build   | 2 +-
 meson_options.txt | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 277534093b94..3e3f808b2d7a 100644
--- a/meson.build
+++ b/meson.build
@@ -595,7 +595,7 @@ if build_xorg
 sdkconfig.set('libdir', join_paths('${exec_prefix}', get_option('libdir')))
 sdkconfig.set('includedir', join_paths('${prefix}', 
get_option('includedir')))
 sdkconfig.set('datarootdir', join_paths('${prefix}', 
get_option('datadir')))
-sdkconfig.set('moduledir', join_paths('${exec_prefix}', 
get_option('module_dir')))
+sdkconfig.set('moduledir', join_paths('${exec_prefix}', module_dir))
 sdkconfig.set('sdkdir', join_paths('${prefix}', get_option('includedir'), 
'xorg'))
 sdkconfig.set('sysconfigdir', join_paths('${datarootdir}', 
'X11/xorg.conf.d'))
 
diff --git a/meson_options.txt b/meson_options.txt
index 5c7be0e26ce5..4cf8349ba9e5 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -19,8 +19,7 @@ option('builder_addr', type: 'string', description: 'Builder 
address', value: 'x
 option('builder_string', type: 'string', description: 'Additional builder 
string')
 
 option('log_dir', type: 'string')
-option('module_dir', type: 'string', value: 'xorg/modules',
-   description: 'X.Org modules directory')
+option('module_dir', type: 'string', description: 'X.Org modules directory')
 option('default_font_path', type: 'string')
 
 option('glx', type: 'boolean', value: true)
-- 
2.16.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glx: Fix attribute handling for GLX_TEXTURE_FORMAT_EXT

2018-04-02 Thread Adam Jackson
On Mon, 2018-04-02 at 14:52 -0400, Adam Jackson wrote:

> @@ -1737,6 +1740,9 @@ __glXDisp_BindTexImageEXT(__GLXclientState * cl, GLbyte 
> * pc)
>DixReadAccess, , ))
>  return error;
>  
> +if (pGlxDraw->format == GLX_TEXTURE_FORMAT_NONE_EXT)
> +return BadMatch;
> +
>  if (!context->bindTexImage)
>  return __glXError(GLXUnsupportedPrivateRequest);
> 

The conditional added here is correct in a specification sense, but the
behavior change would be subtle. As it stands you can do
glXBindTexImage on _any_ GLX pixmap, even one created without a
texture-target attribute; due to accident of how various conditionals
are written it looks like such pixmaps would implicitly be treated as
RGBA. I'm not aware of any apps that do that and I don't think they
would work on non-Mesa drivers, but we could instead set a default
texture target derived from (the number of alpha bits of) the requested
fbconfig and it would probably do the right thing.

- 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

[ANNOUNCE] xorg-server 1.19.99.903

2018-04-02 Thread Adam Jackson
Fixes for meson, modesetting, and a crash I introduced right before RC2.

Adam Jackson (1):
  xserver 1.20 RC3

Emil Velikov (2):
  docs: purge some ISA references
  docs: remove resource management references

Louis-Francis Ratté-Boulianne (2):
  modesetting: Ignore alpha channel when importing BOs for modesetting
  modesetting: Fix reported size when using atomic modesetting

Olivier Fourdan (1):
  modesetting: Use actual crtc position for pageflip

Thierry Reding (3):
  meson: Remove usage of pkg-config --variable=includedir
  meson: Distribute more SDK headers
  meson: Add pixman-1 to required modules in xorg-server.pc

Tobias Klausmann (2):
  glamor: sanitze handling of "Debug" Option for "dmabuf_capable"
  modesetting/drmmode: add NULL pointer check in drmmode_output_dpms

git tag: xorg-server-1.19.99.903

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2
MD5:  514ca5990c32a9530985e0fc1dd1d29b  xorg-server-1.19.99.903.tar.bz2
SHA1: e9bcc93b67786a5809529c74d44b07243de02863  xorg-server-1.19.99.903.tar.bz2
SHA256: 84e0895ce72b127cfded4c9c18201a94c806dd53af9c135edcd59947eac1d070  
xorg-server-1.19.99.903.tar.bz2
SHA512: 
6884d7a477fdab118d61ed22d264d7ee03117673fdd40e63bc1eccc5109f23a058c9a1fc08aa9215b2c7fe1e6a677adfde4aadc1cbbec559b3edc024baf87444
  xorg-server-1.19.99.903.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz
MD5:  e36ad67defece8a98f05bbe4fbe32976  xorg-server-1.19.99.903.tar.gz
SHA1: 420f54771fac106eafaa56ce9d5066babbbde652  xorg-server-1.19.99.903.tar.gz
SHA256: 9cfcb585a8b84b657456d445f1c5ad521fa461bdcf06e009f1ae4e625eba6529  
xorg-server-1.19.99.903.tar.gz
SHA512: 
9707f9d3f370ead127140dc36ce9e665827676255eb5e91940f31d2065f1b0760f973a23dafc7726ec9e60f4efcfd5045de94e787cd22d873eb5d4e1dbd47da0
  xorg-server-1.19.99.903.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xorg-server 1.19.99.903

2018-04-02 Thread Adam Jackson
Fixes for meson, modesetting, and a crash I introduced right before RC2.

Adam Jackson (1):
  xserver 1.20 RC3

Emil Velikov (2):
  docs: purge some ISA references
  docs: remove resource management references

Louis-Francis Ratté-Boulianne (2):
  modesetting: Ignore alpha channel when importing BOs for modesetting
  modesetting: Fix reported size when using atomic modesetting

Olivier Fourdan (1):
  modesetting: Use actual crtc position for pageflip

Thierry Reding (3):
  meson: Remove usage of pkg-config --variable=includedir
  meson: Distribute more SDK headers
  meson: Add pixman-1 to required modules in xorg-server.pc

Tobias Klausmann (2):
  glamor: sanitze handling of "Debug" Option for "dmabuf_capable"
  modesetting/drmmode: add NULL pointer check in drmmode_output_dpms

git tag: xorg-server-1.19.99.903

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2
MD5:  514ca5990c32a9530985e0fc1dd1d29b  xorg-server-1.19.99.903.tar.bz2
SHA1: e9bcc93b67786a5809529c74d44b07243de02863  xorg-server-1.19.99.903.tar.bz2
SHA256: 84e0895ce72b127cfded4c9c18201a94c806dd53af9c135edcd59947eac1d070  
xorg-server-1.19.99.903.tar.bz2
SHA512: 
6884d7a477fdab118d61ed22d264d7ee03117673fdd40e63bc1eccc5109f23a058c9a1fc08aa9215b2c7fe1e6a677adfde4aadc1cbbec559b3edc024baf87444
  xorg-server-1.19.99.903.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz
MD5:  e36ad67defece8a98f05bbe4fbe32976  xorg-server-1.19.99.903.tar.gz
SHA1: 420f54771fac106eafaa56ce9d5066babbbde652  xorg-server-1.19.99.903.tar.gz
SHA256: 9cfcb585a8b84b657456d445f1c5ad521fa461bdcf06e009f1ae4e625eba6529  
xorg-server-1.19.99.903.tar.gz
SHA512: 
9707f9d3f370ead127140dc36ce9e665827676255eb5e91940f31d2065f1b0760f973a23dafc7726ec9e60f4efcfd5045de94e787cd22d873eb5d4e1dbd47da0
  xorg-server-1.19.99.903.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce


Re: [PATCH xserver 2/2] modesetting: Fix reported size when using atomic modesetting

2018-04-02 Thread Adam Jackson
On Thu, 2018-03-29 at 09:16 +0100, Daniel Stone wrote:
> On 29 March 2018 at 08:46, Olivier Fourdan  wrote:
> > Looks good to me *but* this is not sufficient because
> > do_queue_flip_on_crtc() calls drmmode_crtc_set_fb() with (x=0,y=0) for any
> > CRTC regardless of its actual location...
> > 
> > So, it also requires https://patchwork.freedesktop.org/series/40860/ and
> > with this, this patch is:
> > 
> > Tested-by: Olivier Fourdan 
> > Reviewed-by: Olivier Fourdan 
> 
> Reviewed-by: Daniel Stone 

Merged both, thanks:

remote: I: patch #213610 updated using rev 
ce7d5087cfe1d2df756d93b7f567b3c0b0a7f6a8.
remote: I: patch #213611 updated using rev 
f580116f3c89b3c086655cbd441f84e50115ea78.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   85b3fc1860..f580116f3c  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 01/15] dri3: annotate the dri3_screen_info data as const

2018-04-02 Thread Adam Jackson
On Mon, 2018-04-02 at 16:41 +0100, Emil Velikov wrote:

> Why do we have the explicit _rec and _ptr typecasts to begin with?

Convention, mostly. The typedef for the struct is because 'struct' is a
dumb word to need to say all the time. The typedef for the pointer is
vaguely distasteful and I've been trying to stop.

- 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: 2018 Election voting OPEN

2018-04-02 Thread Rob Clark
To all X.Org Foundation Members:

Due to some technical difficulties, the earlier election notification
messages to memb...@x.org list did not go through (but also did not
trigger bounce/moderator notification).  We cross referenced the
members list to the subscriber lists for xorg-devel, xorg, mesa-dev,
and wayland-devel lists and concluded that there are a small
percentage of x.org foundation members who were not also subscribed to
one of the lists CC'd on the original notification about election
period.

For this reason, to ensure that all x.org foundation members have an
opportunity to vote, we are extending the voting period by one week.
The voting period will now remain open until 23:59 UTC on 12 April
2018.

Rob Clark,
on behalf of the X.Org elections committee

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.
>
> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 2018 Election voting OPEN

2018-04-02 Thread Rob Clark
To all X.Org Foundation Members:

Due to some technical difficulties, the earlier election notification
messages to memb...@x.org list did not go through (but also did not
trigger bounce/moderator notification).  We cross referenced the
members list to the subscriber lists for xorg-devel, xorg, mesa-dev,
and wayland-devel lists and concluded that there are a small
percentage of x.org foundation members who were not also subscribed to
one of the lists CC'd on the original notification about election
period.

For this reason, to ensure that all x.org foundation members have an
opportunity to vote, we are extending the voting period by one week.
The voting period will now remain open until 23:59 UTC on 12 April
2018.

Rob Clark,
on behalf of the X.Org elections committee

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.
>
> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
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] modesettings: Use actual crtc position for pageflip

2018-04-02 Thread Adam Jackson
On Thu, 2018-03-29 at 09:16 +0100, Daniel Stone wrote:
> On 29 March 2018 at 08:42, Olivier Fourdan  wrote:
> > Otherwise the same content is shown on all outputs.
> 
> Yeah, good point.
> 
> Reviewed-by: Daniel Stone 

remote: I: patch #213635 updated using rev 
85b3fc18606e56d01734defb0e9fa04182f9fc1c.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   a10f1c9e08..85b3fc1860  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] glx: Fix attribute handling for GLX_TEXTURE_FORMAT_EXT

2018-04-02 Thread Adam Jackson
Initialize it correctly to GLX_TEXTURE_FORMAT_NONE_EXT, and report it in
GLXGetDrawableAttributes. Note that it and TEXTURE_TARGET are only
meaningful attributes for GLXPixmaps.

Signed-off-by: Adam Jackson 
---
 glx/glxcmds.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 6785e9db38..847271e9e3 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -1173,6 +1173,9 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen * 
pGlxScreen,
 !AddResource(pDraw->id, __glXDrawableRes, pGlxDraw))
 return BadAlloc;
 
+if (type == GLX_DRAWABLE_PIXMAP)
+pGlxDraw->format = GLX_TEXTURE_FORMAT_NONE_EXT;
+
 return Success;
 }
 
@@ -1737,6 +1740,9 @@ __glXDisp_BindTexImageEXT(__GLXclientState * cl, GLbyte * 
pc)
   DixReadAccess, , ))
 return error;
 
+if (pGlxDraw->format == GLX_TEXTURE_FORMAT_NONE_EXT)
+return BadMatch;
+
 if (!context->bindTexImage)
 return __glXError(GLXUnsupportedPrivateRequest);
 
@@ -1851,7 +1857,7 @@ DoGetDrawableAttributes(__GLXclientState * cl, XID drawId)
 xGLXGetDrawableAttributesReply reply;
 __GLXdrawable *pGlxDraw = NULL;
 DrawablePtr pDraw;
-CARD32 attributes[18];
+CARD32 attributes[19];
 int num = 0, error;
 
 if (!validGlxDrawable(client, drawId, GLX_DRAWABLE_ANY,
@@ -1876,11 +1882,14 @@ DoGetDrawableAttributes(__GLXclientState * cl, XID 
drawId)
 ATTRIB(GLX_HEIGHT, pDraw->height);
 ATTRIB(GLX_SCREEN, pDraw->pScreen->myNum);
 if (pGlxDraw) {
-ATTRIB(GLX_TEXTURE_TARGET_EXT,
-   pGlxDraw->target == GL_TEXTURE_2D ?
-GLX_TEXTURE_2D_EXT : GLX_TEXTURE_RECTANGLE_EXT);
 ATTRIB(GLX_EVENT_MASK, pGlxDraw->eventMask);
 ATTRIB(GLX_FBCONFIG_ID, pGlxDraw->config->fbconfigID);
+if (pGlxDraw->type == GLX_DRAWABLE_PIXMAP) {
+ATTRIB(GLX_TEXTURE_TARGET_EXT,
+   pGlxDraw->target == GL_TEXTURE_2D ?
+GLX_TEXTURE_2D_EXT : GLX_TEXTURE_RECTANGLE_EXT);
+ATTRIB(GLX_TEXTURE_FORMAT_EXT, pGlxDraw->format);
+}
 if (pGlxDraw->type == GLX_DRAWABLE_PBUFFER) {
 ATTRIB(GLX_PRESERVED_CONTENTS, GL_TRUE);
 }
-- 
2.16.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 xserver 2/2] docs: remove resource management references

2018-04-02 Thread Adam Jackson
On Mon, 2018-04-02 at 18:51 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The code referenced was removed back in 2009.
> 
> Signed-off-by: Emil Velikov 

Fixed 1/2's commit message's capitalization of "ISA" and merged:

remote: E: failed to find patch for rev 
32c07e6b83fdb5b0ed99fc6b1eaa18064f6c3527.
remote: E: failed to find patch for rev 
a10f1c9e08b982029186028b144d9243a2ebdde3.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   80d4098411..a10f1c9e08  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] meson: Add pixman-1 to required modules in xorg-server.pc

2018-04-02 Thread Adam Jackson
On Thu, 2018-03-29 at 13:07 +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> pixman headers will be included for builds of external modules against
> the xorg-server SDK. Make sure pixman is listed as a required module so
> that the correct CFLAGS will be added.
> 
> Note that the xorg-server.pc generated by the autotools-based build has
> many more modules listed, but this seems to be enough to build at least
> some of the external drivers against an X server built with Meson (I've
> tested with xf86-input-libinput, xf86-video-nouveau and xf86-video-ati).
> 
> Signed-off-by: Thierry Reding 

Series merged, thanks:

remote: I: patch #213710 updated using rev 
f3b0a2aee21f12f3332bf598d3ba0fcbd2832f95.
remote: I: patch #213711 updated using rev 
88c7b8bf4bae080ecb879fe7e3f8be2bede6f0a6.
remote: I: patch #213712 updated using rev 
80d4098411ad96b662e830db06e59a7ab7f5c9d3.
remote: I: 3 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   1c002bc434..80d4098411  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 2/2] docs: remove resource management references

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The code referenced was removed back in 2009.

Signed-off-by: Emil Velikov 
---
 hw/xfree86/doc/ddxDesign.xml | 168 ---
 1 file changed, 168 deletions(-)

diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
index becb0c2c5..367844136 100644
--- a/hw/xfree86/doc/ddxDesign.xml
+++ b/hw/xfree86/doc/ddxDesign.xml
@@ -1107,16 +1107,6 @@ Here is what InitOutput() does:
   them.

 
-   
-  All additional resources that the screen needs must be registered
-  here.  This should be done with
-  xf86RegisterResources().  If some of the fixed
-  resources registered in the Probe phase are not needed or not
-  decoded by the hardware when in the OPERATING server state, their
-  status should be updated with
-  xf86SetOperatingState().
-   
-

   Modules may be loaded at any point in this function, and all
   modules that the driver will need must be loaded before the end
@@ -2599,20 +2589,6 @@ The
 These two helper functions make use of several core functions that are
 available at the driver level:
 
- 
- 
-void xf86ClaimFixedResources(resList list, int entityIndex);
- 
- 
-  This function registers the non-relocatable resources which cannot
-  be disabled and which therefore would cause the server to fail
-  immediately if they were found to conflict.  It also records
-  non-relocatable but sharable resources for processing after the
-  Probe() phase.
-   
-
- 
-
  
  
 void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex);
@@ -2692,52 +2668,6 @@ Several functions are provided to simplify resource 
registration:
  

 
-   
-The primary function for registration of resources is:
- 
- 
-resPtr xf86RegisterResources(int entityIndex, resList list,
- int access);
- 
- 
-  This function tries to register the resources in
-  list.  If list is NULL it 
tries
-  to determine the resources automatically.  This only works for
-  entities that provide a generic way to read out the resource ranges
-  they decode.  So far this is only the case for PCI devices.  By
-  default the PCI resources are registered as shared
-  (ResShared) if the driver wants to set a different
-  access type it can do so by specifying the access flags in the
-  third argument.  A value of 0 means to use the
-  default settings.  If for any reason the resource broker is not
-  able to register some of the requested resources the function will
-  return a pointer to a list of the failed ones.  In this case the
-  driver may be able to move the resource to different locations.
-  In case of PCI bus entities this is done by passing the list of
-  failed resources to xf86ReallocatePciResources().
-  When the registration succeeds, the return value is
-  NULL.
-   
-
- 
- 
-
-   
-   
-resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes);
-   
-   
-  This function takes a list of PCI resources that need to be
-  reallocated and returns NULL when all relocations 
are
-  successful.
-  xf86RegisterResources() should be called again to
-  register the relocated resources with the broker.
-  If the reallocation fails, a list of the resources that could not be
-  relocated is returned.
- 
-
-   
-
 
 Two functions are provided to obtain a resource range of a given type:
  
@@ -2795,93 +2725,6 @@ Two functions are provided to obtain a resource range of 
a given type:
  

 
-   
-The driver may replace the generic access control functions for an entity.
-This is done with the xf86SetAccessFuncs():
- 
- 
-void xf86SetAccessFuncs(EntityInfoPtr pEnt,
-xf86SetAccessFuncPtr funcs,
-xf86SetAccessFuncPtr oldFuncs);
- 
- with:
- 
-  typedef struct {
-  xf86AccessPtr mem;
-  xf86AccessPtr io;
-  xf86AccessPtr io_mem;
-  } xf86SetAccessFuncRec, *xf86SetAccessFuncPtr;
- 
- 
-  The driver can pass three functions: one for I/O access, one for
-  memory access and one for combined memory and I/O access.  If the
-  memory access and combined access functions are identical the
-  common level assumes that the memory access cannot be controlled
-  independently of I/O access, if the I/O access function and the
-  combined access functions are the same it is assumed that I/O can
-  not be controlled independently.  If memory and I/O have 

[PATCH xserver 1/2] docs: purge some Isa references

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The respective Isa functions were dropped back in 2008

Signed-off-by: Emil Velikov 
---
 hw/xfree86/doc/ddxDesign.xml | 89 +---
 1 file changed, 2 insertions(+), 87 deletions(-)

diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
index a7f74e4d7..becb0c2c5 100644
--- a/hw/xfree86/doc/ddxDesign.xml
+++ b/hw/xfree86/doc/ddxDesign.xml
@@ -820,13 +820,11 @@ Here is what InitOutput() does:
   like probing for other details such as the amount of memory
   installed, etc.  It is recommended that the
   xf86MatchPciInstances() helper function be used
-  for identifying matching PCI devices, and similarly the
-  xf86MatchIsaInstances() for ISA (non-PCI) devices
+  for identifying matching PCI devices
   (see the RAC section).  These helpers also
   checks and claims the appropriate entity.  When not using the
   helper, that should be done with xf86CheckPciSlot()
-  and xf86ClaimPciSlot() for PCI devices and
-  xf86ClaimIsaSlot() for ISA devices (see the
+  and xf86ClaimPciSlot() for PCI devices (see the
   RAC section).

 
@@ -2491,53 +2489,6 @@ xorg.conf file to the devices:
   return value of -1 indicates an internal error.
   The returned foundEntities array should be freed
   by the driver with xfree() when it is no longer
-  needed in cases where the return value is greater than zero.
- 
-
-   
-
-   
-   
-int xf86MatchIsaInstances(const char *driverName,
-  SymTabPtr chipsets, IsaChipsets *ISAchipsets,
-  DriverPtr drvp, FindIsaDevProc FindIsaDevice,
-  GDevPtr *devList, int numDevs,
-  int **foundEntities);
-   
-   
-  This function finds matches between ISA cards that a driver supports
-  and config file device sections.  It is intended for use in the
-  ChipProbe() function of drivers for ISA cards.
-  devList and numDevs are
-  typically those found from calling 
xf86MatchDevice(),
-  and represent the active config file device sections relevant to
-  the driver.  ISAchipsets is a table that provides
-  a mapping between the driver's internal chipset tokens and the
-  resource classes.  FindIsaDevice is a
-  driver-provided function that probes the hardware and returns the
-  chipset token corresponding to what was detected, and
-  -1 if nothing was detected.
- 
-
- 
-  If the config file device section contains a chipset entry, then
-  it is checked against the chipsets list.  When
-  no chipset entry is present, the FindIsaDevice
-  function is called instead.
- 
-
- 
-  Entity index numbers for confirmed matches are returned as an
-  array via foundEntities.  The chipset token and
-  device section for each match are found in the
-  EntityInfoRec referenced by the indices.
- 
-
- 
-  The function return value is the number of confirmed matches.  A
-  return value of -1 indicates an internal error.
-  The returned foundEntities array should be freed
-  by the driver with xfree() when it is no longer
   needed in cases where the return value is greater than zero.
  
 
@@ -2581,18 +2532,6 @@ available at the driver level:
 

 
-   
-   
-Bool xf86ParseIsaBusString(const char *busID);
-   
-   
-  Compares a BusID string with the ISA bus ID string
-  ("ISA" or "ISA:").  If they match TRUE is returned,
-  and FALSE if they don't.
- 
-
-   
-


 Bool xf86CheckPciSlot(int bus, int device, int func);
@@ -2632,30 +2571,6 @@ available at the driver level:
 

 
-   
-   
-int xf86ClaimIsaSlot(DriverPtr drvp, int chipset,
- GDevPtr dev, Bool active);
-   
-   
-  This allocates an entity record entity and initialise the data
-  structures.  The return value is the index of the newly allocated
-  entity record.
- 
-
-   
-
-   
-   
-Bool xf86IsPrimaryIsa(void);
-   
-   
-  This function returns TRUE if the primary card is
-  an ISA (non-PCI) device, and FALSE otherwise.
- 
-
-   
-

 Two helper functions are provided to aid configuring entities:

-- 
2.16.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] modesetting/drmmode: add NULL pointer check in drmmode_output_dpms

2018-04-02 Thread Adam Jackson
On Fri, 2018-03-30 at 22:32 +0200, Tobias Klausmann wrote:
> drmmode_output_dpms is called especially with !output->crtc found in
> xf86DisableUnusedFunctions so we have to guard for it, else the server
> segfaults:

Merged, thanks:

remote: I: patch #214118 updated using rev 
1c002bc43472063cf8599abb0d6d7367e30456e2.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   258081759f..1c002bc434  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

XDC 2018: Call for Papers

2018-04-02 Thread Samuel Iglesias Gonsálvez
Hello,

I have the pleasure to announce that the X.org Developer Conference 2018
will be held in A Coruña, Spain from September 26th to September 28th.
The venue is located at the Computer Science faculty of the University
of Coruña.

This year, we have created a new website for the event:

https://xdc2018.x.org

And a Twitter account for announcing updates, please follow us!

https://twitter.com/xdc2018

However, we are going to keep updating the good old wiki too:

https://www.x.org/wiki/Events/XDC2018

As usual, we are open to talks across the layers of the graphics stack,
from the kernel to desktop environments / graphical applications and
about how to make things better for the developers who build them. Other
topics such as Virtual Reality are also welcome. If you're not sure if
something might fit, mail us or add it to the ideas list found in the
program page at:

https://www.x.org/wiki/Events/XDC2018/Program/

The Call for Papers information is here: https://xdc2018.x.org/#cfp.
Remember, the deadline for submissions is Wednesday 25th July 2018 17:00
UTC. Don't forget to send your proposals to bo...@foundation.x.org!

The conference is free of charge and open to the general public. If you
plan on coming, please add yourself to the attendees list:

https://www.x.org/wiki/Events/XDC2018/Attendees/

We'll use this list of attendees to make badges and plan for the
catering, so if you are attending please add your name as early as
possible.

I am looking forward to seeing you there. If you have any
inquiries/questions, please send an email to xdc2...@gpul.org, adding on
CC the X.org board (bo...@foundation.x.org).

Best regards,

Sam
___
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: 2018 Election voting OPEN

2018-04-02 Thread Rob Clark
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.

Reminder that the elections are open until midnight on Thurs, so if
you have not already voted, please do.

> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 2018 Election voting OPEN

2018-04-02 Thread Rob Clark
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.

Reminder that the elections are open until midnight on Thurs, so if
you have not already voted, please do.

> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
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] glamor: sanitze handling of "Debug" Option for "dmabuf_capable"

2018-04-02 Thread Adam Jackson
On Fri, 2018-03-30 at 22:31 +0200, Tobias Klausmann wrote:
> With the appearance of the this new Option the X Server would crash if the
> option is not set.
> 
> Default dmabuf_capable to off/FALSE for now - a user without knowledge about
> this option does not want to enable it until its save.

Argh. I was certain I'd pushed a version of this patch that already had
this. Clearly I was too eager for the long weekend. Merged, thanks:

remote: I: patch #214117 updated using rev 
258081759fa70202a2e61344fe25ca54bedb.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   debf75bd0b..258081759f  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 14/15] dri3: s/intersect/window/ to match the names used in caller

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 dri3/dri3_screen.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index f5ca07934..2b0e139fa 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -167,8 +167,8 @@ cache_formats_and_modifiers(ScreenPtr screen)
 int
 dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr drawable,
  CARD8 depth, CARD8 bpp,
- CARD32 *num_intersect_modifiers,
- CARD64 **intersect_modifiers,
+ CARD32 *num_window_modifiers,
+ CARD64 **window_modifiers,
  CARD32 *num_screen_modifiers,
  CARD64 **screen_modifiers)
 {
@@ -178,7 +178,7 @@ dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr 
drawable,
 int ret;
 CARD32  num_drawable_mods;
 CARD64 *drawable_mods;
-CARD64 *intersect_mods = NULL;
+CARD64 *window_mods = NULL;
 CARD64 *screen_mods = NULL;
 CARD32  format;
 dri3_dmabuf_format_ptr  screen_format = NULL;
@@ -204,7 +204,7 @@ dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr 
drawable,
 
 if (screen_format->num_modifiers == 0) {
 *num_screen_modifiers = 0;
-*num_intersect_modifiers = 0;
+*num_window_modifiers = 0;
 return Success;
 }
 
@@ -217,44 +217,44 @@ dri3_get_supported_modifiers(ScreenPtr screen, 
DrawablePtr drawable,
 }
 
 /* We're allocating slightly more memory than necessary but it reduces
- * the complexity of finding the intersection set.
+ * the complexity of finding the windowion set.
  */
 screen_mods = malloc(screen_format->num_modifiers * sizeof(CARD64));
 if (!screen_mods)
 return BadAlloc;
 if (num_drawable_mods > 0) {
-intersect_mods = malloc(screen_format->num_modifiers * sizeof(CARD64));
-if (!intersect_mods) {
+window_mods = malloc(screen_format->num_modifiers * sizeof(CARD64));
+if (!window_mods) {
 free(screen_mods);
 return BadAlloc;
 }
 }
 
 *num_screen_modifiers = 0;
-*num_intersect_modifiers = 0;
+*num_window_modifiers = 0;
 for (i = 0; i < screen_format->num_modifiers; i++) {
 CARD64 modifier = screen_format->modifiers[i];
-Bool intersect = FALSE;
+Bool window_mod = FALSE;
 
 for (j = 0; j < num_drawable_mods; j++) {
 if (drawable_mods[j] == modifier) {
-intersect = TRUE;
+window_mod = TRUE;
 break;
 }
 }
 
-if (intersect) {
-intersect_mods[*num_intersect_modifiers] = modifier;
-*num_intersect_modifiers += 1;
+if (window_mod) {
+window_mods[*num_window_modifiers] = modifier;
+*num_window_modifiers += 1;
 } else {
 screen_mods[*num_screen_modifiers] = modifier;
 *num_screen_modifiers += 1;
 }
 }
 
-assert(*num_intersect_modifiers + *num_screen_modifiers == 
screen_format->num_modifiers);
+assert(*num_window_modifiers + *num_screen_modifiers == 
screen_format->num_modifiers);
 
-*intersect_modifiers = intersect_mods;
+*window_modifiers = window_mods;
 *screen_modifiers = screen_mods;
 free(drawable_mods);
 
-- 
2.16.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 xserver 15/15] dri3: correctly handle failed get_supported_modifiers requests

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Currently depending on the code path hit, the helper will set some of
the output values and not others.

It could also leak memory ;-)

At the same time the caller was:
 - working around the broken behaviour - by initialising the variables
 - outright ignoring if the helper fails

Fix all that by consistently setting the output variables and returning
a protocol error if we fail to get the data required.

Bonus points: current code does not attribute if we cannot get the
modifiers info for certain format. A smaller format array is available,
yet the original length is stored.

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
We could still return "success" to the user - I've opted for this
solution since we already bail on dixLookupWindow failure.
---
 dri3/dri3_request.c | 18 ++
 dri3/dri3_screen.c  | 38 +-
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index edcd0e782..9b7d81ea3 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -335,10 +335,10 @@ proc_dri3_get_supported_modifiers(ClientPtr client)
 };
 WindowPtr window;
 ScreenPtr pScreen;
-CARD64 *window_modifiers = NULL;
-CARD64 *screen_modifiers = NULL;
-CARD32 nwindowmodifiers = 0;
-CARD32 nscreenmodifiers = 0;
+CARD64 *window_modifiers;
+CARD64 *screen_modifiers;
+CARD32 nwindowmodifiers;
+CARD32 nscreenmodifiers;
 int status;
 int i;
 
@@ -349,10 +349,12 @@ proc_dri3_get_supported_modifiers(ClientPtr client)
 return status;
 pScreen = window->drawable.pScreen;
 
-dri3_get_supported_modifiers(pScreen, >drawable,
-stuff->depth, stuff->bpp,
- , _modifiers,
- , _modifiers);
+status = dri3_get_supported_modifiers(pScreen, >drawable,
+  stuff->depth, stuff->bpp,
+  , _modifiers,
+  , 
_modifiers);
+if (status != Success)
+return status;
 
 rep.numWindowModifiers = nwindowmodifiers;
 rep.numScreenModifiers = nscreenmodifiers;
diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 2b0e139fa..de97d55bc 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -178,7 +178,9 @@ dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr 
drawable,
 int ret;
 CARD32  num_drawable_mods;
 CARD64 *drawable_mods;
+CARD32  num_window_mods = 0;
 CARD64 *window_mods = NULL;
+CARD32  num_screen_mods = 0;
 CARD64 *screen_mods = NULL;
 CARD32  format;
 dri3_dmabuf_format_ptr  screen_format = NULL;
@@ -202,11 +204,8 @@ dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr 
drawable,
 if (screen_format == NULL)
 return BadMatch;
 
-if (screen_format->num_modifiers == 0) {
-*num_screen_modifiers = 0;
-*num_window_modifiers = 0;
-return Success;
-}
+if (screen_format->num_modifiers == 0)
+goto done;
 
 if (!info->get_drawable_modifiers ||
 !info->get_drawable_modifiers(drawable, format,
@@ -221,17 +220,13 @@ dri3_get_supported_modifiers(ScreenPtr screen, 
DrawablePtr drawable,
  */
 screen_mods = malloc(screen_format->num_modifiers * sizeof(CARD64));
 if (!screen_mods)
-return BadAlloc;
+goto bad_alloc;
 if (num_drawable_mods > 0) {
 window_mods = malloc(screen_format->num_modifiers * sizeof(CARD64));
-if (!window_mods) {
-free(screen_mods);
-return BadAlloc;
-}
+if (!window_mods)
+goto bad_alloc;
 }
 
-*num_screen_modifiers = 0;
-*num_window_modifiers = 0;
 for (i = 0; i < screen_format->num_modifiers; i++) {
 CARD64 modifier = screen_format->modifiers[i];
 Bool window_mod = FALSE;
@@ -245,18 +240,27 @@ dri3_get_supported_modifiers(ScreenPtr screen, 
DrawablePtr drawable,
 
 if (window_mod) {
 window_mods[*num_window_modifiers] = modifier;
-*num_window_modifiers += 1;
+num_window_mods++;
 } else {
 screen_mods[*num_screen_modifiers] = modifier;
-*num_screen_modifiers += 1;
+num_screen_mods++;
 }
 }
 
-assert(*num_window_modifiers + *num_screen_modifiers == 
screen_format->num_modifiers);
+assert(num_window_mods + num_screen_mods == screen_format->num_modifiers);
 
-*window_modifiers = window_mods;
-

[PATCH xserver 13/15] dri3: rework format/modifier caching

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Cut down the unnecessary malloc/memcpy/free by utilising the explicit
copy provided by the client.

But above all: do so, after ensuring we get valid data from the
implementation.

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 dri3/dri3_screen.c | 50 +++---
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index ec9afe28a..f5ca07934 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -117,8 +117,10 @@ cache_formats_and_modifiers(ScreenPtr screen)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
 const dri3_screen_info_rec *info = ds->info;
-CARD32 *formats = NULL;
-CARD64 *modifiers = NULL;
+CARD32  num_formats;
+CARD32 *formats;
+CARD32  num_modifiers;
+CARD64 *modifiers;
 int i;
 
 if (ds->formats_cached)
@@ -127,34 +129,36 @@ cache_formats_and_modifiers(ScreenPtr screen)
 if (!info || !info->get_formats || !info->get_modifiers)
 return BadImplementation;
 
-(*info->get_formats) (screen, >num_formats, );
-ds->formats = calloc(ds->num_formats, sizeof(dri3_dmabuf_format_rec));
+if (!info->get_formats(screen, _formats, ))
+return BadAlloc;
+
+if (!num_formats) {
+ds->num_formats = 0;
+ds->formats_cached = TRUE;
+return Success;
+}
+
+ds->formats = calloc(num_formats, sizeof(dri3_dmabuf_format_rec));
 if (!ds->formats)
 return BadAlloc;
 
-for (i = 0; i < ds->num_formats; i++) {
+for (i = 0; i < num_formats; i++) {
 dri3_dmabuf_format_ptr iter = >formats[i];
 
+if (!info->get_modifiers(screen, formats[i],
+ _modifiers,
+ ))
+continue;
+
+if (!num_modifiers)
+continue;
+
 iter->format = formats[i];
-(*info->get_modifiers) (screen, formats[i],
->num_modifiers,
-);
-
-iter->modifiers = malloc(iter->num_modifiers * sizeof(CARD64));
-if (iter->modifiers == NULL)
-goto error;
-
-memcpy(iter->modifiers, modifiers,
-   iter->num_modifiers * sizeof(CARD64));
-goto done;
-
-error:
-iter->num_modifiers = 0;
-free(iter->modifiers);
-done:
-free(modifiers);
+iter->num_modifiers = num_modifiers;
+iter->modifiers = modifiers;
 }
-free(formats);
+
+ds->num_formats = i;
 ds->formats_cached = TRUE;
 
 return Success;
-- 
2.16.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 xserver 07/15] xwayland: zero num_modifiers from the start

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 hw/xwayland/xwayland-glamor.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 339420e05..59461be1f 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -779,13 +779,14 @@ glamor_get_modifiers(ScreenPtr screen, CARD32 format,
 struct xwl_format *xwl_format = NULL;
 int i;
 
+/* Explicitly zero the count as the caller may ignore the return value */
+*num_modifiers = 0;
+
 if (!xwl_screen->dmabuf_capable || !xwl_screen->dmabuf)
 return FALSE;
 
-if (xwl_screen->num_formats == 0) {
-   *num_modifiers = 0;
-   return TRUE;
-}
+if (xwl_screen->num_formats == 0)
+return TRUE;
 
 for (i = 0; i < xwl_screen->num_formats; i++) {
if (xwl_screen->formats[i].format == format) {
@@ -794,16 +795,12 @@ glamor_get_modifiers(ScreenPtr screen, CARD32 format,
}
 }
 
-if (!xwl_format) {
-   *num_modifiers = 0;
+if (!xwl_format)
 return FALSE;
-}
 
 *modifiers = calloc(xwl_format->num_modifiers, sizeof(uint64_t));
-if (*modifiers == NULL) {
-*num_modifiers = 0;
+if (*modifiers == NULL)
 return FALSE;
-}
 
 for (i = 0; i < xwl_format->num_modifiers; i++)
(*modifiers)[i] = xwl_format->modifiers[i];
-- 
2.16.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 xserver 12/15] glamor: zero num_formats from the start

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 glamor/glamor_egl.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index fab280ebf..3e1f45635 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -558,30 +558,26 @@ glamor_get_formats(ScreenPtr screen,
 struct glamor_egl_screen_private *glamor_egl;
 EGLint num;
 
+/* Explicitly zero the count as the caller may ignore the return value */
+*num_formats = 0;
+
 glamor_egl = glamor_egl_get_screen_private(xf86ScreenToScrn(screen));
 
 if (!glamor_egl->dmabuf_capable)
 return FALSE;
 
-if (!eglQueryDmaBufFormatsEXT(glamor_egl->display, 0, NULL, )) {
-*num_formats = 0;
+if (!eglQueryDmaBufFormatsEXT(glamor_egl->display, 0, NULL, ))
 return FALSE;
-}
 
-if (num == 0) {
-*num_formats = 0;
+if (num == 0)
 return TRUE;
-}
 
 *formats = calloc(num, sizeof(CARD32));
-if (*formats == NULL) {
-*num_formats = 0;
+if (*formats == NULL)
 return FALSE;
-}
 
 if (!eglQueryDmaBufFormatsEXT(glamor_egl->display, num,
   (EGLint *) *formats, )) {
-*num_formats = 0;
 free(*formats);
 return FALSE;
 }
-- 
2.16.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 xserver 06/15] dri3: use designated initializers for {s, }proc_dri3_vector

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
Seems like the underscore went missing with v1.2?
---
 dri3/dri3_request.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index 7ced6747c..edcd0e782 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -537,15 +537,15 @@ proc_dri3_buffers_from_pixmap(ClientPtr client)
 
 static const
 DispatchProc proc_dri3_vector[DRI3NumberRequests] = {
-proc_dri3_query_version,/* 0 */
-proc_dri3_open, /* 1 */
-proc_dri3_pixmap_from_buffer,   /* 2 */
-proc_dri3_buffer_from_pixmap,   /* 3 */
-proc_dri3_fence_from_fd,/* 4 */
-proc_dri3_fd_from_fence,/* 5 */
-proc_dri3_get_supported_modifiers,  /* 6 */
-proc_dri3_pixmap_from_buffers,  /* 7 */
-proc_dri3_buffers_from_pixmap,  /* 8 */
+[X_DRI3QueryVersion] = proc_dri3_query_version,
+[X_DRI3Open] = proc_dri3_open,
+[X_DRI3PixmapFromBuffer] = proc_dri3_pixmap_from_buffer,
+[X_DRI3BufferFromPixmap] = proc_dri3_buffer_from_pixmap,
+[X_DRI3FenceFromFD]  = proc_dri3_fence_from_fd,
+[X_DRI3FDFromFence]  = proc_dri3_fd_from_fence,
+[xDRI3GetSupportedModifiers] = proc_dri3_get_supported_modifiers,
+[xDRI3PixmapFromBuffers] = proc_dri3_pixmap_from_buffers,
+[xDRI3BuffersFromPixmap] = proc_dri3_buffers_from_pixmap,
 };
 
 int
@@ -681,15 +681,15 @@ sproc_dri3_buffers_from_pixmap(ClientPtr client)
 
 static const
 DispatchProc sproc_dri3_vector[DRI3NumberRequests] = {
-sproc_dri3_query_version,   /* 0 */
-sproc_dri3_open,/* 1 */
-sproc_dri3_pixmap_from_buffer,  /* 2 */
-sproc_dri3_buffer_from_pixmap,  /* 3 */
-sproc_dri3_fence_from_fd,   /* 4 */
-sproc_dri3_fd_from_fence,   /* 5 */
-sproc_dri3_get_supported_modifiers, /* 6 */
-sproc_dri3_pixmap_from_buffers, /* 7 */
-sproc_dri3_buffers_from_pixmap, /* 8 */
+[X_DRI3QueryVersion] = sproc_dri3_query_version,
+[X_DRI3Open] = sproc_dri3_open,
+[X_DRI3PixmapFromBuffer] = sproc_dri3_pixmap_from_buffer,
+[X_DRI3BufferFromPixmap] = sproc_dri3_buffer_from_pixmap,
+[X_DRI3FenceFromFD]  = sproc_dri3_fence_from_fd,
+[X_DRI3FDFromFence]  = sproc_dri3_fd_from_fence,
+[xDRI3GetSupportedModifiers] = sproc_dri3_get_supported_modifiers,
+[xDRI3PixmapFromBuffers] = sproc_dri3_pixmap_from_buffers,
+[xDRI3BuffersFromPixmap] = sproc_dri3_buffers_from_pixmap,
 };
 
 int _X_COLD
-- 
2.16.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 xserver 04/15] dri3: simplify dri3_open() implementation

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 dri3/dri3_screen.c | 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index f5e87bc9e..628f7616e 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -31,33 +31,21 @@
 #include 
 #include 
 
-static inline Bool has_open(const dri3_screen_info_rec *info) {
-if (info == NULL)
-return FALSE;
-
-return info->open != NULL ||
-(info->version >= 1 && info->open_client != NULL);
-}
-
 int
 dri3_open(ClientPtr client, ScreenPtr screen, RRProviderPtr provider, int *fd)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
 const dri3_screen_info_rec *info = ds->info;
-int rc;
 
-if (!has_open(info))
+if (info == NULL)
 return BadMatch;
 
 if (info->version >= 1 && info->open_client != NULL)
-rc = (*info->open_client) (client, screen, provider, fd);
-else
-rc = (*info->open) (screen, provider, fd);
-
-if (rc != Success)
-return rc;
+return (*info->open_client) (client, screen, provider, fd);
+if (info->open != NULL)
+return (*info->open) (screen, provider, fd);
 
-return Success;
+return BadMatch;
 }
 
 int
-- 
2.16.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 xserver 05/15] dri3: annotate {s, }proc_dri3_vector as static const

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Read-only data, used only locally.

Signed-off-by: Emil Velikov 
---
 dri3/dri3_request.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index fc258711b..7ced6747c 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -32,6 +32,9 @@
 #include 
 #include 
 
+/* Should be provided by the guts of X */
+typedef int (* DispatchProc) (ClientPtr client);
+
 static int
 proc_dri3_query_version(ClientPtr client)
 {
@@ -532,7 +535,8 @@ proc_dri3_buffers_from_pixmap(ClientPtr client)
 return Success;
 }
 
-int (*proc_dri3_vector[DRI3NumberRequests]) (ClientPtr) = {
+static const
+DispatchProc proc_dri3_vector[DRI3NumberRequests] = {
 proc_dri3_query_version,/* 0 */
 proc_dri3_open, /* 1 */
 proc_dri3_pixmap_from_buffer,   /* 2 */
@@ -675,7 +679,8 @@ sproc_dri3_buffers_from_pixmap(ClientPtr client)
 return (*proc_dri3_vector[stuff->dri3ReqType]) (client);
 }
 
-int (*sproc_dri3_vector[DRI3NumberRequests]) (ClientPtr) = {
+static const
+DispatchProc sproc_dri3_vector[DRI3NumberRequests] = {
 sproc_dri3_query_version,   /* 0 */
 sproc_dri3_open,/* 1 */
 sproc_dri3_pixmap_from_buffer,  /* 2 */
-- 
2.16.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 xserver 10/15] dri3: return BadImplementation when missing ::get_{formats, modifiers}

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

If the implementations is missing the required functionality simply
return BadImplementation.

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 dri3/dri3_screen.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index ee23336a5..ec9afe28a 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -124,16 +124,9 @@ cache_formats_and_modifiers(ScreenPtr screen)
 if (ds->formats_cached)
 return Success;
 
-if (!info)
+if (!info || !info->get_formats || !info->get_modifiers)
 return BadImplementation;
 
-if (!info->get_formats || !info->get_modifiers) {
-ds->formats = NULL;
-ds->num_formats = 0;
-ds->formats_cached = TRUE;
-return Success;
-}
-
 (*info->get_formats) (screen, >num_formats, );
 ds->formats = calloc(ds->num_formats, sizeof(dri3_dmabuf_format_rec));
 if (!ds->formats)
-- 
2.16.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 xserver 03/15] dri3: annotate fds/strides/offsets arrays as const

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

It makes it perfectly clear that we should not be modifying them.
Should help highlight issues like the one fixed with previous commit.

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
Strictly speaking one should annotate everything but pixmap/screen as
const to be perfectly clear about in/out arguments. Yet again nobody
bothers annotating int arguments so meh for now ;-)
---
 dri3/dri3.h   | 6 +++---
 dri3/dri3_priv.h  | 6 --
 dri3/dri3_screen.c| 4 ++--
 glamor/glamor.h   | 6 +++---
 glamor/glamor_egl.c   | 4 ++--
 hw/xwayland/xwayland-glamor.c | 8 
 6 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/dri3/dri3.h b/dri3/dri3.h
index bd17522b0..fc76908e1 100644
--- a/dri3/dri3.h
+++ b/dri3/dri3.h
@@ -49,11 +49,11 @@ typedef PixmapPtr (*dri3_pixmap_from_fd_proc) (ScreenPtr 
screen,
 
 typedef PixmapPtr (*dri3_pixmap_from_fds_proc) (ScreenPtr screen,
 CARD8 num_fds,
-int *fds,
+const int *fds,
 CARD16 width,
 CARD16 height,
-CARD32 *strides,
-CARD32 *offsets,
+const CARD32 *strides,
+const CARD32 *offsets,
 CARD8 depth,
 CARD8 bpp,
 CARD64 modifier);
diff --git a/dri3/dri3_priv.h b/dri3/dri3_priv.h
index cf6632ddf..ea278049d 100644
--- a/dri3/dri3_priv.h
+++ b/dri3/dri3_priv.h
@@ -79,8 +79,10 @@ int
 dri3_open(ClientPtr client, ScreenPtr screen, RRProviderPtr provider, int *fd);
 
 int
-dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen, CARD8 num_fds, int 
*fds,
- CARD16 width, CARD16 height, CARD32 *strides, CARD32 
*offsets,
+dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen,
+ CARD8 num_fds, const int *fds,
+ CARD16 width, CARD16 height,
+ const CARD32 *strides, const CARD32 *offsets,
  CARD8 depth, CARD8 bpp, CARD64 modifier);
 
 int
diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 0b045c413..f5e87bc9e 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -62,9 +62,9 @@ dri3_open(ClientPtr client, ScreenPtr screen, RRProviderPtr 
provider, int *fd)
 
 int
 dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen,
- CARD8 num_fds, int *fds,
+ CARD8 num_fds, const int *fds,
  CARD16 width, CARD16 height,
- CARD32 *strides, CARD32 *offsets,
+ const CARD32 *strides, const CARD32 *offsets,
  CARD8 depth, CARD8 bpp, CARD64 modifier)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 7b5676226..ef10e5cda 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -264,11 +264,11 @@ extern _X_EXPORT struct gbm_bo 
*glamor_gbm_bo_from_pixmap(ScreenPtr screen,
  * */
 extern _X_EXPORT PixmapPtr glamor_pixmap_from_fds(ScreenPtr screen,
   CARD8 num_fds,
-  int *fds,
+  const int *fds,
   CARD16 width,
   CARD16 height,
-  CARD32 *strides,
-  CARD32 *offsets,
+  const CARD32 *strides,
+  const CARD32 *offsets,
   CARD8 depth,
   CARD8 bpp,
   uint64_t modifier);
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 5992b9279..aeb21c162 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -476,9 +476,9 @@ gbm_format_for_depth(CARD8 depth)
 
 _X_EXPORT PixmapPtr
 glamor_pixmap_from_fds(ScreenPtr screen,
-   CARD8 num_fds, int *fds,
+   CARD8 num_fds, const int *fds,
CARD16 width, CARD16 height,
-   CARD32 *strides, CARD32 *offsets,
+   const CARD32 *strides, 

[PATCH xserver 01/15] dri3: annotate the dri3_screen_info data as const

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

dri3_screen_info is the user provide dispatch. Something that we do
not and should not change.

When using the _ptr typecast + const the compiler barfs at us
(rightfully so), so use the _rec one.

Fixes: 56313829886 ("dri3: Add DRI3 extension")
Cc: Keith Packard 
Cc: Adam Jackson 
Signed-off-by: Emil Velikov 
---
Why do we have the explicit _rec and _ptr typecasts to begin with?

It reminds be of Pascal with it's infamous record ... from some 20
years ago.
---
 dri3/dri3.c   |  2 +-
 dri3/dri3.h   |  2 +-
 dri3/dri3_priv.h  |  2 +-
 dri3/dri3_screen.c| 12 ++--
 glamor/glamor_egl.c   |  2 +-
 hw/xwayland/xwayland-glamor.c |  2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/dri3/dri3.c b/dri3/dri3.c
index 8ac0f3ae2..ba32facd7 100644
--- a/dri3/dri3.c
+++ b/dri3/dri3.c
@@ -45,7 +45,7 @@ dri3_close_screen(ScreenPtr screen)
 }
 
 Bool
-dri3_screen_init(ScreenPtr screen, dri3_screen_info_ptr info)
+dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info)
 {
 dri3_screen_generation = serverGeneration;
 
diff --git a/dri3/dri3.h b/dri3/dri3.h
index 89ad13ad9..bd17522b0 100644
--- a/dri3/dri3.h
+++ b/dri3/dri3.h
@@ -104,7 +104,7 @@ typedef struct dri3_screen_info {
 } dri3_screen_info_rec, *dri3_screen_info_ptr;
 
 extern _X_EXPORT Bool
-dri3_screen_init(ScreenPtr screen, dri3_screen_info_ptr info);
+dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info);
 
 extern _X_EXPORT int
 dri3_send_open_reply(ClientPtr client, int fd);
diff --git a/dri3/dri3_priv.h b/dri3/dri3_priv.h
index 8447680ba..cf6632ddf 100644
--- a/dri3/dri3_priv.h
+++ b/dri3/dri3_priv.h
@@ -49,7 +49,7 @@ typedef struct dri3_screen_priv {
 CARD32  num_formats;
 dri3_dmabuf_format_ptr  formats;
 
-dri3_screen_info_ptrinfo;
+const dri3_screen_info_rec *info;
 } dri3_screen_priv_rec, *dri3_screen_priv_ptr;
 
 #define wrap(priv,real,mem,func) {\
diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index df40f8281..0b045c413 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-static inline Bool has_open(dri3_screen_info_ptr info) {
+static inline Bool has_open(const dri3_screen_info_rec *info) {
 if (info == NULL)
 return FALSE;
 
@@ -43,7 +43,7 @@ int
 dri3_open(ClientPtr client, ScreenPtr screen, RRProviderPtr provider, int *fd)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
-dri3_screen_info_ptrinfo = ds->info;
+const dri3_screen_info_rec *info = ds->info;
 int rc;
 
 if (!has_open(info))
@@ -68,7 +68,7 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen,
  CARD8 depth, CARD8 bpp, CARD64 modifier)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
-dri3_screen_info_ptrinfo = ds->info;
+const dri3_screen_info_rec *info = ds->info;
 PixmapPtr   pixmap;
 
 if (!info)
@@ -99,7 +99,7 @@ dri3_fds_from_pixmap(PixmapPtr pixmap, int *fds,
 {
 ScreenPtr   screen = pixmap->drawable.pScreen;
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
-dri3_screen_info_ptrinfo = ds->info;
+const dri3_screen_info_rec *info = ds->info;
 
 if (!info)
 return 0;
@@ -128,7 +128,7 @@ static int
 cache_formats_and_modifiers(ScreenPtr screen)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
-dri3_screen_info_ptrinfo = ds->info;
+const dri3_screen_info_rec *info = ds->info;
 CARD32 *formats = NULL;
 CARD64 *modifiers = NULL;
 int i;
@@ -188,7 +188,7 @@ dri3_get_supported_modifiers(ScreenPtr screen, DrawablePtr 
drawable,
  CARD64 **screen_modifiers)
 {
 dri3_screen_priv_ptrds = dri3_screen_priv(screen);
-dri3_screen_info_ptrinfo = ds->info;
+const dri3_screen_info_rec *info = ds->info;
 int i, j;
 int ret;
 CARD32  num_drawable_mods;
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 4a550932a..5992b9279 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -755,7 +755,7 @@ glamor_dri3_open_client(ClientPtr client,
 return Success;
 }
 
-static dri3_screen_info_rec glamor_dri3_info = {
+static const dri3_screen_info_rec glamor_dri3_info = {
 .version = 2,
 .open_client = glamor_dri3_open_client,
 .pixmap_from_fds = glamor_pixmap_from_fds,
diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 7e9815626..7f64483bf 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -815,7 +815,7 @@ 

[PATCH xserver 02/15] xwayland: don't close() fds we don't own

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The glamor_pixmap_from_fds error path erroneously closes the fds.
We don't own them, plus the caller closes them after the function in
called.

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 hw/xwayland/xwayland-glamor.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 7f64483bf..6ba716263 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -704,8 +704,6 @@ glamor_pixmap_from_fds(ScreenPtr screen,
 return pixmap;
 
 error:
-for (i = 0; i < num_fds; i++)
-   close(fds[i]);
 return NULL;
 }
 
-- 
2.16.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 xserver 09/15] dri3: check for ::get_drawable_modifiers failure

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

Currently if the function fails, we'll fall into two false assumptions:
 - the the count is zero
 - that the storage pointer is safe for free()

I've just fixed the former (in glamore + xwayland) and have no
plans on adding yet another workaround for the latter.

Simply zero both variables. Regardless if the implementation is missing
the callback or it foobars with output variables (normally a bad idea).

Bonus points - this fixes a bug where we feed garbage to free() further
down ;-)

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 dri3/dri3_screen.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 628f7616e..ee23336a5 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -211,10 +211,13 @@ dri3_get_supported_modifiers(ScreenPtr screen, 
DrawablePtr drawable,
 return Success;
 }
 
-if (info->get_drawable_modifiers)
-(*info->get_drawable_modifiers) (drawable, format,
- _drawable_mods,
- _mods);
+if (!info->get_drawable_modifiers ||
+!info->get_drawable_modifiers(drawable, format,
+  _drawable_mods,
+  _mods)) {
+num_drawable_mods = 0;
+drawable_mods = NULL;
+}
 
 /* We're allocating slightly more memory than necessary but it reduces
  * the complexity of finding the intersection set.
-- 
2.16.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 xserver 11/15] xwayland: zero num_formats from the start

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 

Signed-off-by: Emil Velikov 
---
 hw/xwayland/xwayland-glamor.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 59461be1f..1b9a6b030 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -750,19 +750,18 @@ glamor_get_formats(ScreenPtr screen,
 struct xwl_screen *xwl_screen = xwl_screen_get(screen);
 int i;
 
+/* Explicitly zero the count as the caller may ignore the return value */
+*num_formats = 0;
+
 if (!xwl_screen->dmabuf_capable || !xwl_screen->dmabuf)
 return FALSE;
 
-if (xwl_screen->num_formats == 0) {
-   *num_formats = 0;
+if (xwl_screen->num_formats == 0)
return TRUE;
-}
 
 *formats = calloc(xwl_screen->num_formats, sizeof(CARD32));
-if (*formats == NULL) {
-*num_formats = 0;
+if (*formats == NULL)
 return FALSE;
-}
 
 for (i = 0; i < xwl_screen->num_formats; i++)
(*formats)[i] = xwl_screen->formats[i].format;
-- 
2.16.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 xserver 08/15] glamor: zero num_modifiers from the start

2018-04-02 Thread Emil Velikov
From: Emil Velikov 

The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\

Fixes: cef12efc15c ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne 
Cc: Daniel Stone 
Signed-off-by: Emil Velikov 
---
 glamor/glamor_egl.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index aeb21c162..fab280ebf 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -602,31 +602,27 @@ glamor_get_modifiers(ScreenPtr screen, CARD32 format,
 struct glamor_egl_screen_private *glamor_egl;
 EGLint num;
 
+/* Explicitly zero the count as the caller may ignore the return value */
+*num_modifiers = 0;
+
 glamor_egl = glamor_egl_get_screen_private(xf86ScreenToScrn(screen));
 
 if (!glamor_egl->dmabuf_capable)
 return FALSE;
 
 if (!eglQueryDmaBufModifiersEXT(glamor_egl->display, format, 0, NULL,
-NULL, )) {
-*num_modifiers = 0;
+NULL, ))
 return FALSE;
-}
 
-if (num == 0) {
-*num_modifiers = 0;
+if (num == 0)
 return TRUE;
-}
 
 *modifiers = calloc(num, sizeof(uint64_t));
-if (*modifiers == NULL) {
-*num_modifiers = 0;
+if (*modifiers == NULL)
 return FALSE;
-}
 
 if (!eglQueryDmaBufModifiersEXT(glamor_egl->display, format, num,
 (EGLuint64KHR *) *modifiers, NULL, )) {
-*num_modifiers = 0;
 free(*modifiers);
 return FALSE;
 }
-- 
2.16.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