Re: [PATCH xserver] xfree86: Restore newline before "X Protocol Version" string
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 Plattnerremote: 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
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
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
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
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
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
On Thu, 2018-03-29 at 09:16 +0100, Daniel Stone wrote: > On 29 March 2018 at 08:46, Olivier Fourdanwrote: > > 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
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
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 Clarkwrote: > 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
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 Clarkwrote: > 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
On Thu, 2018-03-29 at 09:16 +0100, Daniel Stone wrote: > On 29 March 2018 at 08:42, Olivier Fourdanwrote: > > 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
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
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
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
From: Emil VelikovThe 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
From: Emil VelikovThe 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
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
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
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clarkwrote: > 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
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clarkwrote: > 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"
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
From: Emil VelikovCc: 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
From: Emil VelikovCurrently 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
From: Emil VelikovCut 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
From: Emil VelikovThe 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
From: Emil VelikovThe 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
From: Emil VelikovCc: 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
From: Emil VelikovSigned-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
From: Emil VelikovRead-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}
From: Emil VelikovIf 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
From: Emil VelikovIt 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
From: Emil Velikovdri3_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
From: Emil VelikovThe 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
From: Emil VelikovCurrently 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
From: Emil VelikovThe 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
From: Emil VelikovThe 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