Re: [PATCH xserver 2/3] modesetting: Remove some dead code
On 08/16/2016 02:10 AM, Hans de Goede wrote:
> The "if (pixmap) ..." block this commit removes is inside an
> "if (pixmap == NULL) ..." block, so it will never execute.
>
> Signed-off-by: Hans de Goede
> ---
> hw/xfree86/drivers/modesetting/dri2.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/dri2.c
> b/hw/xfree86/drivers/modesetting/dri2.c
> index b810d59..9bc56c2 100644
> --- a/hw/xfree86/drivers/modesetting/dri2.c
> +++ b/hw/xfree86/drivers/modesetting/dri2.c
> @@ -186,8 +186,6 @@ ms_dri2_create_buffer(DrawablePtr drawable, unsigned int
> attachment,
>pixmap_cpp,
>0);
> if (pixmap == NULL) {
> -if (pixmap)
> -screen->DestroyPixmap(pixmap);
> free(private);
> free(buffer);
> return NULL;
>
Well this one is certainly obvious.
Reviewed-by: Aaron Plattner
___
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: Proposed X server 1.19 schedule
On 09/06/2016 12:27 PM, Keith Packard wrote: > Adam Jackson writes: > >> ... move the non-critical bug deadline to 2016-10-01? Still leaves >> three weeks for critical fixes. Either way, looks plausible to me. I >> don't personally have any non-bug changes I want to land before 1.19. > > Yeah, sounds good. We don't usually get many changes during the critical > bug window anyways. When do you want to freeze the ABI? It would be good to get Alex's prime sync changes in an official ABI and run through our QA test cycle before the release. -- Aaron ___ 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 00/12] xwayland: Pointer confinement and warping
On Fri, Sep 09, 2016 at 10:38:32AM -0600, Keith Packard wrote: > Peter Hutterer writes: > > > Keith, I think the ABI changes should go in before we lock down, this is a > > pretty important feature for the Wayland transition and our release cycles > > aren't exactly predictable at this point. > > Yeah, the ABI changes look harmless enough, although I do wonder why the > existing DDX interfaces for tracking the cursor aren't sufficient. For > confining the cursor, we've already got the CursorLimits function which > is called on every confine, and of course WarpPointer always calls > SetCursorPosition. Both those functions are called from places all over the place and we'd have to do guess work in hw/xwayland to try to figure out when they were actually just warps and not arbitrary cursor position changes, and when a certain combination of CursorLimit arguments mean confineTo and not something else. ConfineTo is about asking the compositor to do limit cursor movements for us, since Xwayland doesn't have the ability to do so. Trying to use CursorLimits to try to guess when that happened as a result of a grab with a confineTo seems just as fragile and hard to understand as trying to use SetCursorPosition for detecting cursor movement happened to be a result of a pointer warp, compared to just calling vfuncs for when those things actually happened. Jonas > > -- > -keith ___ 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 00/12] xwayland: Pointer confinement and warping
Peter Hutterer writes: > Keith, I think the ABI changes should go in before we lock down, this is a > pretty important feature for the Wayland transition and our release cycles > aren't exactly predictable at this point. Yeah, the ABI changes look harmless enough, although I do wonder why the existing DDX interfaces for tracking the cursor aren't sufficient. For confining the cursor, we've already got the CursorLimits function which is called on every confine, and of course WarpPointer always calls SetCursorPosition. -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RESEND xserver] glx: Always enable EXT_texture_from_pixmap for DRI glx
On Fri, 2016-09-09 at 16:02 +0200, Hans de Goede wrote: > glx/glxdri2.c | 6 -- https://lists.freedesktop.org/archives/xorg-devel/2016-September/050853.html - 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 1/2] Hold input lock for deviceProc
Peter Hutterer writes: > not needed but it won't hurt. Right, it seemed easier to just hold locks across all calls than to try to document why locks weren't required everywhere. I did have one place where I didn't want to grab the lock and added a comment there. > Reviewed-by: Peter Hutterer , thanks. Awesome -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xwayland: Close the shm fd as early as possible
> > > [...] > > > > > > the idea here looks fine to me. > > > > > > However, I've been wondering, surely there was a reason why it wasn't > > > coded like this in the first place? > > > > > > Could you check if this patch causes Xwayland to create lots of > > > wl_buffers it will never attach and commit to a wl_surface? If it does, > > > that was probably the reason. > > > > Was that evaluated? I guess the risk here is that we might end up creating useless wl_buffers. Still, the benefit of closing the fd as soon as possible is greater than the risk of creating too many unused wl_buffer, so I think it's worth it. (Not convinced? try running 10 instances of "gtk3-demo --run=cursors" in Wayland) > > AFAICS, when using glamor, the only code path that still uses the > > xwl_shm_*_pixmap() is the cursor code, so even with glamor, running several > > X11 apps which create several cursors each will quickly cause Xwayland to > > reach the limit of file descriptors. > > > > > If that is true, then one has to weigh between creating wl_buffers > > > immediately vs. creating them only when actually needed for a > > > wl_surface. > > > > > > Maybe Daniel knows? CC'ing also Olivier for his information. > > > > I cannot tell why this was done the way it is, but I think this patch does > > improve things for e.g. downstream bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1373451 That particular bug is possibly a leak of cursors in Qt, but still, there is a weakness in Xwayland. so, weighing the pros and cons of this patch, FWIW: Reviewed-by: Olivier Fourdan Unless someone else is opposed to this patch, I'm in... Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RESEND xserver 0/1] glx: Always enable EXT_texture_from_pixmap for DRI glx
Hi All, I know that when this was sent before it was not liked because things should really be fixed in Mesa, but in the mean time no-one has stepped up and fixed Mesa. Without this patch 1.19 will regress users who rely on llvmpipe, e.g. people running gnome as desktop in VMs, so I believe that we should add this patch to 1.19 as it is much too late to rely on / expect a Mesa fix now. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RESEND xserver] glx: Always enable EXT_texture_from_pixmap for DRI glx
Prior to commit f95645c6f700 ("glx: Don't enable EXT_texture_from_pixmap
unconditionally") DRI glx would always advertise EXT_texture_from_pixmap.
That commit moved the setting of the extension in the extension bits from
__glXInitExtensionEnableBits to its callers so that
__glXInitExtensionEnableBits can be used more generally, but at the same
time made the setting of EXT_texture_from_pixmap conditionally on
__DRI_TEX_BUFFER being present.
This has result in an unintended behavior change which breaks e.g.
compositors running on llvmpipe. This commit makes the DRI glx code
advertise EXT_texture_from_pixmap unconditionally again fixing this.
Fixes: f95645c6f700 ("glx: Don't enable EXT_texture_from_pixmap
unconditionally")
Signed-off-by: Hans de Goede
---
glx/glxdri2.c | 6 --
glx/glxdriswrast.c | 3 +--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index c2dab90..2e550e6 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -837,6 +837,10 @@ initializeExtensions(__GLXscreen * 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_EXT_texture_from_pixmap");
+LogMessage(X_INFO, "AIGLX: enabled GLX_EXT_texture_from_pixmap\n");
+
if (dri->dri2->base.version >= 3) {
__glXEnableExtension(screen->glx_enable_bits,
"GLX_ARB_create_context");
@@ -881,8 +885,6 @@ initializeExtensions(__GLXscreen * screen)
for (i = 0; extensions[i]; i++) {
if (strcmp(extensions[i]->name, __DRI_TEX_BUFFER) == 0) {
dri->texBuffer = (const __DRItexBufferExtension *) extensions[i];
-__glXEnableExtension(screen->glx_enable_bits,
- "GLX_EXT_texture_from_pixmap");
LogMessage(X_INFO,
"AIGLX: GLX_EXT_texture_from_pixmap backed by buffer
objects\n");
}
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index ac8bda8..f5c0c9f 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdriswrast.c
@@ -396,6 +396,7 @@ initializeExtensions(__GLXscreen * screen)
__glXEnableExtension(screen->glx_enable_bits, "GLX_EXT_framebuffer_sRGB");
__glXEnableExtension(screen->glx_enable_bits, "GLX_ARB_fbconfig_float");
__glXEnableExtension(screen->glx_enable_bits,
"GLX_EXT_fbconfig_packed_float");
+__glXEnableExtension(screen->glx_enable_bits,
"GLX_EXT_texture_from_pixmap");
extensions = dri->core->getExtensions(dri->driScreen);
@@ -407,8 +408,6 @@ initializeExtensions(__GLXscreen * screen)
if (strcmp(extensions[i]->name, __DRI_TEX_BUFFER) == 0) {
dri->texBuffer = (const __DRItexBufferExtension *) extensions[i];
-__glXEnableExtension(screen->glx_enable_bits,
- "GLX_EXT_texture_from_pixmap\n");
}
#ifdef __DRI2_FLUSH_CONTROL
--
2.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
modesetting driver maintenance
Hi All, I've several modesetting driver patches which have been awaiting review for a while now: https://patchwork.freedesktop.org/patch/105350/ https://patchwork.freedesktop.org/patch/105351/ https://patchwork.freedesktop.org/patch/105352/ https://patchwork.freedesktop.org/patch/107096/ https://patchwork.freedesktop.org/patch/107269/ And despite several pings these do not seem to be getting anywhere. Recently we've been appointing people in roles like "glamor maintainer", etc. which helps greatly with getting patches in those areas reviewed. I believe that we also need a modesetting maintainer. Since I've done some of the recent work on the modesetting driver; and I don't see anyone else volunteering, I'll even volunteer for this. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v7 xserver 6/7] xf86Cursor: Deal with rotation on GPU screens using a hw-cursor
Hi, On 09-09-16 03:11, Michel Dänzer wrote: On 08/09/16 07:08 PM, Hans De Goede wrote: When a slave-output is rotated the transformation is done on the blit from master to slave GPU, so crtc->transform_in_use is not set, but we still need to adjust the mouse position for things to work. This commit modifies xf86_crtc_transform_cursor_position to not rely on crtc->f_framebuffer_to_crtc, so that it can be used with GPU screens to and always calls it for cursors on GPU screens. Note not using crtc->f_framebuffer_to_crtc means that crtc->transform will not be taken into account, that is ok, because when we've a transform active hw-cursors are not used and xf86_crtc_transform_cursor_position will never get called. Signed-off-by: Hans de Goede --- Changes in v7: -Do not use xf86_crtc_rotate_coord_back, it is not suitable for our purposes -Modify xf86_crtc_transform_cursor_position instead of adding a new xf86_crtc_transform_gpu_cursor_position function [...] diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c index 8437000..f638452 100644 --- a/hw/xfree86/modes/xf86Cursors.c +++ b/hw/xfree86/modes/xf86Cursors.c @@ -384,16 +384,35 @@ xf86_crtc_transform_cursor_position(xf86CrtcPtr crtc, int *x, int *y) xf86CursorScreenPtr ScreenPriv = (xf86CursorScreenPtr) dixLookupPrivate(&screen->devPrivates, xf86CursorScreenKey); -struct pict_f_vector v; -int dx, dy; - -v.v[0] = (*x + ScreenPriv->HotX) + 0.5; -v.v[1] = (*y + ScreenPriv->HotY) + 0.5; -v.v[2] = 1; -pixman_f_transform_point(&crtc->f_framebuffer_to_crtc, &v); -/* cursor will have 0.5 added to it already so floor is sufficent */ -*x = floor(v.v[0]); -*y = floor(v.v[1]); +int dx, dy, t; + +*x = *x - crtc->x + ScreenPriv->HotX; +*y = *y - crtc->y + ScreenPriv->HotY; + +if (crtc->rotation & RR_Reflect_X) +*x = crtc->mode.HDisplay - *x - 1; +if (crtc->rotation & RR_Reflect_Y) +*y = crtc->mode.VDisplay - *y - 1; I think reflection needs to be applied after rotation. Please test the combination of 90/270 degree rotation and reflection to make sure it works well. Funny I was thinking about this patchset while doing my "laps" in the swimingpool this morning and I was wondering if I got reflection right too (note no I didn't will fix in v8). @@ -416,7 +436,7 @@ xf86_crtc_set_cursor_position(xf86CrtcPtr crtc, int x, int y) /* * Transform position of cursor on screen */ -if (crtc->transform_in_use) +if (crtc->transform_in_use || screen->isGPU) xf86_crtc_transform_cursor_position(crtc, &crtc_x, &crtc_y); Use something like if (crtc->transform_in_use || crtc->rotation != RR_Rotate_0) instead. No need to call xf86_crtc_transform_cursor_position for a GPU screen with crtc->rotation == RR_Rotate_0. Coincidence or not this actually was the other thing I was thinking about this morning. Since we're no longer using crtc->f_framebuffer_to_crtc still checking for crtc->transform_in_use is a bit weird and also unnecessary, so I've replaced this with just if (crtc->rotation != RR_Rotate_0) for v8. Patches 3 & 5 are Reviewed-by: Michel Dänzer Thanks. P.S. Until we've figured why I'm not receiving your patches from the list, please Cc this e-mail address of mine on future revisions of this patch. Will do, v8 is coming up, since this is the last patch in the set which has not been reviewed, I'm only go to send out this one and not the entire set again. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v8 xserver 6/7] xf86Cursor: Deal with rotation on GPU screens using a hw-cursor
When a slave-output is rotated the transformation is done on the blit
from master to slave GPU, so crtc->transform_in_use is not set, but we
still need to adjust the mouse position for things to work.
This commit modifies xf86_crtc_transform_cursor_position to not rely
on crtc->f_framebuffer_to_crtc, so that it can be used with GPU screens
to and always calls it for cursors on GPU screens.
Note not using crtc->f_framebuffer_to_crtc means that crtc->transform
will not be taken into account, that is ok, because when we've a transform
active hw-cursors are not used and xf86_crtc_transform_cursor_position
will never get called.
Signed-off-by: Hans de Goede
---
Changes in v8:
-Fix reflection on rotated outputs (use xf86_crtc_rotate_coord_back again)
-Only call xf86_crtc_transform_cursor_position when rotating or reflecting
(instead of always calling it for GPU screens)
Changes in v7:
-Do not use xf86_crtc_rotate_coord_back, it is not suitable for our purposes
-Modify xf86_crtc_transform_cursor_position instead of adding a new
xf86_crtc_transform_gpu_cursor_position function
Changes in v5:
-New patch in v5 of this patch-series
---
hw/xfree86/modes/xf86Cursors.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index c836534..3e9582b 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -367,16 +367,22 @@ xf86_crtc_transform_cursor_position(xf86CrtcPtr crtc, int
*x, int *y)
xf86CursorScreenPtr ScreenPriv =
(xf86CursorScreenPtr) dixLookupPrivate(&screen->devPrivates,
xf86CursorScreenKey);
-struct pict_f_vector v;
-int dx, dy;
-
-v.v[0] = (*x + ScreenPriv->HotX) + 0.5;
-v.v[1] = (*y + ScreenPriv->HotY) + 0.5;
-v.v[2] = 1;
-pixman_f_transform_point(&crtc->f_framebuffer_to_crtc, &v);
-/* cursor will have 0.5 added to it already so floor is sufficent */
-*x = floor(v.v[0]);
-*y = floor(v.v[1]);
+int dx, dy, width, height, rotation;
+
+rotation = crtc->rotation & 0xf;
+if (rotation == RR_Rotate_90 || rotation == RR_Rotate_270) {
+width = crtc->mode.VDisplay;
+height = crtc->mode.HDisplay;
+} else {
+width = crtc->mode.HDisplay;
+height = crtc->mode.VDisplay;
+}
+
+*x = *x - crtc->x + ScreenPriv->HotX;
+*y = *y - crtc->y + ScreenPriv->HotY;
+
+xf86_crtc_rotate_coord_back(crtc->rotation, width, height, *x, *y, x, y);
+
/*
* Transform position of cursor upper left corner
*/
@@ -399,7 +405,7 @@ xf86_crtc_set_cursor_position(xf86CrtcPtr crtc, int x, int
y)
/*
* Transform position of cursor on screen
*/
-if (crtc->transform_in_use)
+if (crtc->rotation != RR_Rotate_0)
xf86_crtc_transform_cursor_position(crtc, &crtc_x, &crtc_y);
else {
crtc_x -= crtc->x;
--
2.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Bump ABI versions
On Fri, Sep 09, 2016 at 05:38:12PM +0900, Michel Dänzer wrote:
> On 09/09/16 05:12 PM, Jonas Ådahl wrote:
> > Bump both the xinput and videodrv versions. The xinput due to the added
> > valuator mask setter, and videodrv due to the added vfuncs to the
> > Screen struct.
> >
> > Signed-off-by: Jonas Ådahl
> > ---
> > hw/xfree86/common/xf86Module.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
> > index e0212cf..8470ab4 100644
> > --- a/hw/xfree86/common/xf86Module.h
> > +++ b/hw/xfree86/common/xf86Module.h
> > @@ -79,8 +79,8 @@ typedef enum {
> > * mask is 0x.
> > */
> > #define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4)
> > -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(23, 0)
> > -#define ABI_XINPUT_VERSION SET_ABI_VERSION(24, 1)
> > +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(24, 0)
> > +#define ABI_XINPUT_VERSION SET_ABI_VERSION(25, 0)
> > #define ABI_EXTENSION_VERSION SET_ABI_VERSION(10, 0)
> >
> > #define MODINFOSTRING1 0xef23fdc5
> >
>
> Both ABI versions have already been bumped multiple times since 1.18. Is
> there any particular reason for bumping them again? I.e. is there
> anything which needs to be able to distinguish between the ABI versions
> before and after this change?
No, the only purpose would be to make it more obvious that there were
more changes that needed ABI bumping.
Jonas
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Bump ABI versions
On 09/09/16 05:12 PM, Jonas Ådahl wrote:
> Bump both the xinput and videodrv versions. The xinput due to the added
> valuator mask setter, and videodrv due to the added vfuncs to the
> Screen struct.
>
> Signed-off-by: Jonas Ådahl
> ---
> hw/xfree86/common/xf86Module.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
> index e0212cf..8470ab4 100644
> --- a/hw/xfree86/common/xf86Module.h
> +++ b/hw/xfree86/common/xf86Module.h
> @@ -79,8 +79,8 @@ typedef enum {
> * mask is 0x.
> */
> #define ABI_ANSIC_VERSIONSET_ABI_VERSION(0, 4)
> -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(23, 0)
> -#define ABI_XINPUT_VERSION SET_ABI_VERSION(24, 1)
> +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(24, 0)
> +#define ABI_XINPUT_VERSION SET_ABI_VERSION(25, 0)
> #define ABI_EXTENSION_VERSIONSET_ABI_VERSION(10, 0)
>
> #define MODINFOSTRING1 0xef23fdc5
>
Both ABI versions have already been bumped multiple times since 1.18. Is
there any particular reason for bumping them again? I.e. is there
anything which needs to be able to distinguish between the ABI versions
before and after this change?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RESEND,v4] xfree86: Immediately handle failure to set HW cursor
Hi Hans, apologies for the delayed reply! On Thu, Sep 1, 2016 at 11:24 PM, Hans de Goede wrote: > Hi, > > On 22-06-16 10:48, Alexandre Courbot wrote: >> >> There is currently no reliable way to report failure to set a HW >> cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM >> ioctl fails (which currently happens at least with modesetting on Tegra >> for format incompatibility reasons). >> >> As failures are currently handled by setting the HW cursor size to >> (0,0), the fallback to SW cursor will not happen until the next time the >> cursor changes and xf86CursorSetCursor() is called again. In the >> meantime, the cursor will be invisible to the user. >> >> This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and >> _xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans. >> This allows to propagate errors up to xf86CursorSetCursor(), which can >> then fall back to using the SW cursor immediately. >> >> Signed-off-by: Alexandre Courbot >> Reviewed-by: Keith Packard >> Cc: Michael Thayer >> Cc: Michel Dänzer > > > Is this one still needed; or is this fully covered by the switch to > load_cursor_argb_check() ? : > > https://cgit.freedesktop.org/xorg/xserver/commit/?id=14c21ea1c9496638b1feb8e6145c440fb4f1d14b > > ? It appears this patch indeed fixes the issue I have - looking at the commit log it seems like it was addressing the exact same problem. So you can just drop my patch - thanks! ___ 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] Bump ABI versions
Bump both the xinput and videodrv versions. The xinput due to the added
valuator mask setter, and videodrv due to the added vfuncs to the
Screen struct.
Signed-off-by: Jonas Ådahl
---
hw/xfree86/common/xf86Module.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
index e0212cf..8470ab4 100644
--- a/hw/xfree86/common/xf86Module.h
+++ b/hw/xfree86/common/xf86Module.h
@@ -79,8 +79,8 @@ typedef enum {
* mask is 0x.
*/
#define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4)
-#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(23, 0)
-#define ABI_XINPUT_VERSION SET_ABI_VERSION(24, 1)
+#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(24, 0)
+#define ABI_XINPUT_VERSION SET_ABI_VERSION(25, 0)
#define ABI_EXTENSION_VERSION SET_ABI_VERSION(10, 0)
#define MODINFOSTRING1 0xef23fdc5
--
2.7.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 00/12] xwayland: Pointer confinement and warping
On Thu, Sep 08, 2016 at 06:46:29PM +0800, Jonas Ådahl wrote: > Hi, > > This series adds support for raw pointer events, pointer confinement and > introduces pointer warp emulation to implement pointer-lock like features > clients use pointer warping for. > > Raw pointer events is done by adding a new valuator mask setter that takes > both > an absolute value and an unaccelerated value. It is similar to that of > valuator_mask_set_unaccelerated() except that it takes an absolute pointer > coordinate instead of a relative coordinate. > > Confinement is pretty straight forward; if a client tries to grab a pointer > with a confineTo set to some window, this will be translated into confining > the > pointer using the pointer constraints protocol. > > Pointer warping emulation works roughly by locking the pointer whenever an X11 > client tries to warp the pointer while the cursor is invisible. See the > corresponding patch for further details. > > Note that the compositor side implementation of the pointer constraints > protocol need to special case X11 clients due to various reasons. Thus, an > unpatched mutter/weston will not be able to enable confinement and warp > emulation to work properly. mutter/gnome-shell patches, however, are available > here[0]. > > All of this seems to work fairly Ok on various games I have tested. I've > tested > SDL 2 using the X11 backend (ioquake3), GLFW using the X11 backend, OpenTTD, > Half Life 1, Half Life 2, Shadow Warrior, Trine 2, Portal, and they seem to > work with no obvious flaws right now. However given the nature of this > approach, I expect various things needs to be tweaked to get all applications > working. Also special thanks to Krzysztof Sobiecki for helping out and for > testing a lot of games finding. > > While I realize it is pretty late in the development schedule, assuming these > patches introduces too much changes for the coming release, would it be > possible to land at least the ABI breaking ones (1-3?) so that it is possible > to distribute a patched version that will be ABI compatible with the coming > release? 01-11 are Reviewed-by: Peter Hutterer , though it's Friday evening here... I'll try to get to 12 tomorrow. Keith, I think the ABI changes should go in before we lock down, this is a pretty important feature for the Wayland transition and our release cycles aren't exactly predictable at this point. Cheers, Peter > Jonas > > [0] https://github.com/jadahl/mutter/commits/wip/xwayland-pointer-warps > > > Jonas Ådahl (11): > dix: Introduce CursorWarpedTo vfunc in Screen > dix: Incroduce CursorConfinedTo vfunc in Screen > dix: Add valuator_mask_set_absolute_unaccelerated > xwayland: Bind the relative pointer manager > xwayland: Split up device class init/release into functions > xwayland: Dispatch pointer motion events on wl_pointer.frame if > possible > xwayland: Set unaccelerated pointer motion delta if available > xwayland: Put getting a xwl_window from a Window in a helper > xwayland: Bind pointer constraints global > xwayland: Translate a pointer grab with confineTo to pointer > confinement > xwayland: Add pointer warp emulator > > Krzysztof Sobiecki (1): > xwayland: Add a new input device used for pointer warping/locking > > configure.ac | 4 +- > dix/events.c | 8 + > dix/inpututils.c | 13 + > hw/xwayland/.gitignore| 4 + > hw/xwayland/Makefile.am | 28 +- > hw/xwayland/xwayland-cursor.c | 7 + > hw/xwayland/xwayland-input.c | 674 > +- > hw/xwayland/xwayland.c| 89 +- > hw/xwayland/xwayland.h| 43 +++ > include/input.h | 5 +- > include/scrnintstr.h | 14 + > 11 files changed, 815 insertions(+), 74 deletions(-) > > -- > 2.7.4 > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
