Re: Buildability of the Xorg drivers
> On Feb 2, 2022, at 15:27, Matt Turner wrote: > > On Sun, Jan 30, 2022 at 4:16 PM Alan Coopersmith > wrote: >> xf86-input-vmmouse >> xf86-video-vmware >> - do not allow merge requests > > This has been an issue before, in conjunction with not even knowing > who the nominal maintainer was. E.g. someone submitted a patch almost > a year ago > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.x.org%2Farchives%2Fxorg-devel%2F2021-March%2F058688.htmldata=04%7C01%7Czackr%40vmware.com%7C28b295c074264147244e08d9e68a7838%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637794304668232703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Zj%2Fnj4NL4pRtM7Cb0AwzAQlZQFMYBS3kDQhTtAfqUXU%3Dreserved=0 > after asking on IRC how to make a merge request and being told... > dunno, looks like you can't? Can we just turn on MRs for these > projects? > > I see Zack recently joined the project on Gitlab and pushed to master, > so Cc'ing him. Hey, yes, that’s correct, I’ll be maintaining those drivers going forward. I did enable MR’s on xf86-video-vmware. I’m actually not a member of xf86-input-vmmouse so if someone could add me then I’ll enable MR’s in there as well. z
Re: [PATCH] GLX/DRI2: Do not expose INTEL_swap_event without swap control
Swap events depent on the implementation of ScheduleSwap. By unconditionally enabling GLX_INTEL_swap_event we're breaking the system with drivers that don't support it because the apps are forever stuck waiting for an event that will never be delivered. So lets enable the extension only if the hooks it depends on are actually there. Ping. Can someone please review/push this? It's quite important. z ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] GLX/DRI2: Do not expose INTEL_swap_event without swap control
Swap events depent on the implementation of ScheduleSwap. By
unconditionally enabling GLX_INTEL_swap_event we're breaking
the system with drivers that don't support it because the apps
are forever stuck waiting for an event that will never be
delivered. So lets enable the extension only if the hooks it
depends on are actually there.
Signed-off-by: Zack Rusin za...@vmware.com
---
glx/glxdri2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index b26e501..28bb8c2 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -857,8 +857,6 @@ initializeExtensions(__GLXDRIscreen * screen)
__glXEnableExtension(screen-glx_enable_bits, GLX_MESA_copy_sub_buffer);
LogMessage(X_INFO, AIGLX: enabled GLX_MESA_copy_sub_buffer\n);
-__glXEnableExtension(screen-glx_enable_bits, GLX_INTEL_swap_event);
-LogMessage(X_INFO, AIGLX: enabled GLX_INTEL_swap_event\n);
#if __DRI_DRI2_VERSION = 3
if (screen-dri2-base.version = 3) {
@@ -876,8 +874,10 @@ initializeExtensions(__GLXDRIscreen * screen)
#endif
if (DRI2HasSwapControl(pScreen)) {
+__glXEnableExtension(screen-glx_enable_bits, GLX_INTEL_swap_event);
__glXEnableExtension(screen-glx_enable_bits, GLX_SGI_swap_control);
__glXEnableExtension(screen-glx_enable_bits, GLX_MESA_swap_control);
+LogMessage(X_INFO, AIGLX: enabled GLX_INTEL_swap_event\n);
LogMessage(X_INFO,
AIGLX: enabled GLX_SGI_swap_control and
GLX_MESA_swap_control\n);
}
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH input-vmmouse] Enable hardware access during vmmouse preinit.
On Thursday, May 03, 2012 05:55:24 PM Michal Srb wrote: Vmmouse driver uses outl calls but never requests hardware access. In case there are no other drivers that requests it, vmmouse initialization will fail. (Found on KVM virtual machine with fbdev graphics driver and vmmouse input driver.) Request hardware access in same way xf86-input-keyboard does. Thanks, looks good. I just pushed it to master. z ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: vmware driver freeing non malloced object
On Thursday, March 15, 2012 10:14:25 AM Dave Airlie wrote: Just packaged xorg-x11-drv-vmware-12.0.1 and got this in build logs /bin/sh ../libtool --silent --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -fvisibility=hidden -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm -I../src -I../saa -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -c -o libvmwgfx_la-vmwgfx_xa_surface.lo `test -f 'vmwgfx_xa_surface.c' || echo './'`vmwgfx_xa_surface.c In file included from /usr/include/xorg/region.h:51:0, from /usr/include/xorg/mi.h:51, from vmwgfx_saa.c:29: In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1154:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1158:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] CCLD libvmwgfx.la Thanks Dave! I just pushed a fix for it. z ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] exa: Unset and restore per alpha in exaTryMagicTwoPassCompositeHelper
On Tuesday 20 October 2009 07:25:02 Michel Dänzer wrote:
On Mon, 2009-10-19 at 15:02 -0400, Zack Rusin wrote:
On Monday 19 October 2009 08:58:22 Michel Dänzer wrote:
On Fri, 2009-10-16 at 00:29 +0100, ja...@vmware.com wrote:
From: Zack Rusin za...@vmware.com
This fixes the component alpha fallback in exa. I'm not sure which
branches this should go into. Also before committing this patch make
sure that we get a Tested-by by somebody with a radeon card as this
turns on new and wonderful paths not tested in the drivers.
This shouldn't make any difference for sub-pixel AA text with the
radeon driver, as it doesn't simply check for pMask-componentAlpha
but:
if (pMaskPicture-componentAlpha) {
/* Check if it's component alpha that relies on a source alpha and
* on the source value. We can only get one of those into the
* single source value that we get to blend with.
*/
if (RadeonBlendOp[op].src_alpha
(RadeonBlendOp[op].blend_cntl RADEON_SRC_BLEND_MASK) !=
RADEON_SRC_BLEND_GL_ZERO) {
RADEON_FALLBACK((Component alpha not supported with source
alpha and source value blending.\n));
}
}
I'm not sure offhand if the proposed change is necessary or even
sensible given this, or if the Gallium Xorg state tracker shouldn't
just use similar checks, and I may not find the time to build a firmer
opinion before I'm back from vacation next month.
Well, the question we're asking the driver is: do you support the
following operation, we expect an answer based on its own capabilities
not on the capabilities of the acceleration architecture.
So the question: do you support component alpha when the driver doesn't
should always be a no, not a conditional maybe that depends on code it
has no control over.
IMO if Exa decomposes PictOpOver component alpha into two
non-compoment-alpha passes, it should actually do that and not depend on
driver being able to figure out what it's trying to do.
Makes sense - assuming the fact that the mask picture has component
alpha actually makes a difference for the decomposed operations. Does
it? I'm not sure offhand, and I'm not inclined to find out before the
end of the month for reasons stated earlier. :) Though I'm inclined to
assume it doesn't, or I'm not sure how the decomposition would help for
hardware that doesn't support component alpha.
Yea, no doubt, you're right, the patch is useless :) I'll fix it appropriately
in xorg state tracker.
z
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] exa: Unset and restore per alpha in exaTryMagicTwoPassCompositeHelper
On Monday 19 October 2009 08:58:22 Michel Dänzer wrote:
On Fri, 2009-10-16 at 00:29 +0100, ja...@vmware.com wrote:
From: Zack Rusin za...@vmware.com
This fixes the component alpha fallback in exa. I'm not sure which
branches this should go into. Also before committing this patch make sure
that we get a Tested-by by somebody with a radeon card as this turns on
new and wonderful paths not tested in the drivers.
This shouldn't make any difference for sub-pixel AA text with the radeon
driver, as it doesn't simply check for pMask-componentAlpha but:
if (pMaskPicture-componentAlpha) {
/* Check if it's component alpha that relies on a source alpha and
* on the source value. We can only get one of those into the
* single source value that we get to blend with.
*/
if (RadeonBlendOp[op].src_alpha
(RadeonBlendOp[op].blend_cntl RADEON_SRC_BLEND_MASK) !=
RADEON_SRC_BLEND_GL_ZERO) {
RADEON_FALLBACK((Component alpha not supported with source
alpha and source value blending.\n));
}
}
I'm not sure offhand if the proposed change is necessary or even
sensible given this, or if the Gallium Xorg state tracker shouldn't just
use similar checks, and I may not find the time to build a firmer
opinion before I'm back from vacation next month.
Well, the question we're asking the driver is: do you support the following
operation, we expect an answer based on its own capabilities not on the
capabilities of the acceleration architecture.
So the question: do you support component alpha when the driver doesn't should
always be a no, not a conditional maybe that depends on code it has no control
over.
IMO if Exa decomposes PictOpOver component alpha into two non-compoment-alpha
passes, it should actually do that and not depend on driver being able to
figure out what it's trying to do.
z
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
