[PATCH libXi] _XIPassiveGrabDevice needs to set time value
When setting up a XIPassiveGrabDevice request, the time field is not
being set, leading to improper data being passed 'over the wire'.
Accept a time value into _XIPassiveGrabDevice and use it to set the time
field in the request. Since the the functions calling
_XIPassiveGrabDevice are part of the API, and they do not accept time
values, they can just pass CurrentTime.
Signed-off-by: Jeff Smith
---
src/XIPassiveGrab.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
index c743516..32b0ab3 100644
--- a/src/XIPassiveGrab.c
+++ b/src/XIPassiveGrab.c
@@ -38,7 +38,8 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int
grabtype, int detail,
Window grab_window, Cursor cursor,
int grab_mode, int paired_device_mode,
Bool owner_events, XIEventMask *mask,
- int num_modifiers, XIGrabModifiers *modifiers_inout)
+ int num_modifiers, XIGrabModifiers *modifiers_inout,
+ Time time)
{
xXIPassiveGrabDeviceReq *req;
xXIPassiveGrabDeviceReply reply;
@@ -74,6 +75,7 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int
grabtype, int detail,
req->num_modifiers = num_modifiers;
req->mask_len = (mask->mask_len + 3)/4;
req->grab_type = grabtype;
+req->time = time;
len = req->mask_len + num_modifiers;
SetReqLen(req, len, len);
@@ -118,7 +120,7 @@ XIGrabButton(Display* dpy, int deviceid, int button,
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeButton, button,
grab_window, cursor, grab_mode,
paired_device_mode, owner_events, mask,
-num_modifiers, modifiers_inout);
+num_modifiers, modifiers_inout, CurrentTime);
}
int
@@ -130,7 +132,7 @@ XIGrabKeycode(Display* dpy, int deviceid, int keycode,
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeKeycode, keycode,
grab_window, None, grab_mode,
paired_device_mode,
owner_events, mask, num_modifiers,
-modifiers_inout);
+modifiers_inout, CurrentTime);
}
int
@@ -142,7 +144,7 @@ XIGrabEnter(Display *dpy, int deviceid, Window grab_window,
Cursor cursor,
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeEnter, 0,
grab_window, cursor, grab_mode,
paired_device_mode,
owner_events, mask, num_modifiers,
-modifiers_inout);
+modifiers_inout, CurrentTime);
}
int
@@ -153,7 +155,7 @@ XIGrabFocusIn(Display *dpy, int deviceid, Window
grab_window, int grab_mode,
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeFocusIn, 0,
grab_window, None, grab_mode,
paired_device_mode,
owner_events, mask, num_modifiers,
-modifiers_inout);
+modifiers_inout, CurrentTime);
}
int
@@ -172,7 +174,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
grab_window,
return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,
grab_window, None, XIGrabModeTouch,
GrabModeAsync, owner_events, mask,
-num_modifiers, modifiers_inout);
+num_modifiers, modifiers_inout, CurrentTime);
}
--
2.14.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: [ANNOUNCE] xkeyboard-config 2.23.1
On Thursday 01 of February 2018, Sergey Udaltsov wrote: > Hello everyone! There was a packaging issue with 2.23 - so here is the > fix, repackaged. Sorry for the hassle. With 2.23 there is a problem which wasn't there on 2.22: $ setxkbmap -v 100 pl Illegal verbose level 100. Reset to 10 Setting verbose level to 10 locale is C Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Trying to load rules file ./rules/evdev... Trying to load rules file /usr/share/X11/xkb/rules/evdev... Success. Applied rules from evdev: rules: evdev model: pc104 layout: pl Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols:pc+pl+inet(evdev) geometry: pc(pc104) Error loading new keyboard description > > Sergey Udaltsov (1): > Fixing the build, 2.23.1 > > git tag: xkeyboard-config-2.23.1 > > https://xorg.freedesktop.org/archive/individual/data/xkeyboard-config/xkeyb > oard-config-2.23.1.tar.bz2 MD5: 875cbd09ab8394277fd16070326abbae > xkeyboard-config-2.23.1.tar.bz2 SHA1: > 184c9ce35f4fa44188acbf549f80d36407697ac3 xkeyboard-config-2.23.1.tar.bz2 > SHA256: 2a4bbc05fea22151b7a7c8ac2655d549aa9b0486bedc7f5a68c72716343b02f3 > xkeyboard-config-2.23.1.tar.bz2 > SHA512: > d651bb89c265e58abe8bba4af6683364a8023cb73af7d00f401f33960e44fa94a7d8a8fdd2 > 483d6703d1c261ca72ae5f2b53f543cfb70b2f571cfe9dcb80c3ba > xkeyboard-config-2.23.1.tar.bz2 > PGP: > https://xorg.freedesktop.org/archive/individual/data/xkeyboard-config/xkey > board-config-2.23.1.tar.bz2.sig > > https://xorg.freedesktop.org/archive/individual/data/xkeyboard-config/xkeyb > oard-config-2.23.1.tar.gz MD5: baad22820d19668a3bbcdc46ba729d04 > xkeyboard-config-2.23.1.tar.gz SHA1: > 6f0ff8ac2361eb8baf4d1550f49c0e9dac99d68f xkeyboard-config-2.23.1.tar.gz > SHA256: 6567ccf5d134aae19ef110f5c847d5326aed01fc671167a6b8f8c47aeada0b85 > xkeyboard-config-2.23.1.tar.gz > SHA512: > 2f11039e48b1a0f45d5c3c5e1b7a3c915b1d6050972b11434ec13caafe3948c5bde6f4bba8 > 56c4e1fa7408ccd2680d39c5250ab267558b55f2b010528dc73016 > xkeyboard-config-2.23.1.tar.gz > PGP: > https://xorg.freedesktop.org/archive/individual/data/xkeyboard-config/xkey > board-config-2.23.1.tar.gz.sig > ___ > xorg-announce mailing list > xorg-annou...@lists.x.org > https://lists.x.org/mailman/listinfo/xorg-announce -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ 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 14/19] present: Add window flip mode
On 2018-01-29 02:34 PM, Roman Gilg wrote: > In contrast to screen flip mode this mode currently: > * supports flips per windows (these windows need to have the same size > as their parent windows with the same pixmap), > * always copies back to the original pixmap instead of pure flips, while > giving the driver the flip pixmap provided by the application, What are the reasons for always copying back to the original pixmap? I don't think that should be necessary. -- 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: [RFC][PATCH xserver] xwayland: Queue Present events
On 2018-01-29 06:15 PM, Roman Gilg wrote: > This is a RFC on a follow-up patch to my recently posted patch series on the > xorg-devel mailing list to enable per window flips of Present Pixmaps to > Wayland surfaces: > https://lists.freedesktop.org/archives/xorg-devel/2018-January/055674.html > > With the attached patch queuing events should be possible. This works with the > changed timer interval reasonable well, but I don't fully understand the logic > of queuing, that's why I decided on excluding the patch from the above patch > series. > > The problem with the old timer interval was, that this was too slow. For > example VLC would send new Pixmaps too slow and the video would stutter. So > changing it to a larger value makes sense. > > But the question is if this needs to take into account the refresh rate of the > display as well. I would then go over to analyzing the current position of the > window and the refresh rate of the xwl_output the window covers the most (this > is similar to how the xfree86 modesetting driver does it). Yes, something like that is necessary. As it is, it looks like the patch will always use the same timer interval, regardless of the target MSC value. This won't work as expected in general, though it might happen to work for simple clients (which is probably the majority), which always just want to synchronize to the next MSC. > Anyways I don't fully understand the logic behind this queuing mechanism. The > client would need to know the refresh rate it can accept to predict the > upcomping MSC counter its next presentation is supposed to be depicted on. > > I don't see such logic in the Present extension. Or is the client supposed to > calculate the refresh rate from the returned UST values? That's one possibility, which is used e.g. by the Mesa src/gallium/auxiliary/vl/vl_winsys_dri3.c code. Another possibility might be determining the refresh rate e.g. via RandR. -- 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: [RFC][PATCH xserver] xwayland: Queue Present events
On 2018-02-01 04:45 PM, Michel Dänzer wrote: > On 2018-01-29 06:15 PM, Roman Gilg wrote: >> This is a RFC on a follow-up patch to my recently posted patch series on the >> xorg-devel mailing list to enable per window flips of Present Pixmaps to >> Wayland surfaces: >> https://lists.freedesktop.org/archives/xorg-devel/2018-January/055674.html >> >> With the attached patch queuing events should be possible. This works with >> the >> changed timer interval reasonable well, but I don't fully understand the >> logic >> of queuing, that's why I decided on excluding the patch from the above patch >> series. >> >> The problem with the old timer interval was, that this was too slow. For >> example VLC would send new Pixmaps too slow and the video would stutter. So >> changing it to a larger value makes sense. >> >> But the question is if this needs to take into account the refresh rate of >> the >> display as well. I would then go over to analyzing the current position of >> the >> window and the refresh rate of the xwl_output the window covers the most >> (this >> is similar to how the xfree86 modesetting driver does it). > > Yes, something like that is necessary. > > As it is, it looks like the patch will always use the same timer > interval, regardless of the target MSC value. This won't work as > expected in general, though it might happen to work for simple clients > (which is probably the majority), which always just want to synchronize > to the next MSC. Note that even with such simple clients, if the timer interval doesn't align with the refresh rate, there might be judder artifacts due to not consistently hitting every refresh cycle. -- 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
X.Org Foundation Membership Renewal
On Feb 1st all xorg members were expired as part of the regular process to remove inactive members. If you would still like to be a member of the X.Org Foundation, please renew your membership. To renew or to become a first time member, go to https://members.x.org/ . For renewals, log in and click the renewal link. For new members, click the Join Now link. The X.org Foundation is a non-profit organization under the SPI umbrella which acts as a steward for the X Window System and related projects. Board elections are coming up so renew or join today! 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
Re: [PATCH xserver 2/2] Xephyr: Prefer using MIT-SHM FD-passing when possible
On Wed, 2018-01-31 at 15:57 -0800, Keith Packard wrote: > Alexander Volkov writes: > > > This makes the shared memory visible only for the Xephyr > > and the X server to which it is connected. > > And looks good as well. > > Reviewed-by: Keith Packard remote: I: patch #201725 updated using rev 8a220bd83c3e23de7e07d3976bfc1248c38558d4. remote: I: patch #201726 updated using rev 90996f5909aab4bc9aa4011a6a6d0555a7aa3adf. remote: I: 2 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 510e7d0d86..90996f5909 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 4/7] glx: Use vnd layer for dispatch (v2)
On Wed, 2018-01-10 at 13:57 -0700, Kyle Brenneman wrote: > xorgGlxThunkRequest should be calling addXIDMap and removeXIDMap, not > the internal handlers. I'm not sure that can be right. If it did, and adding the map failed, there's no way to get the backend to clean up; at least, not the way GlxAddXIDMap is currently written. Perhaps that should be changed to call FreeResource on the XID if AddResource fails? (Like the one place in the whole server where that'd be correct...) > The default branch there may need some additional > attention if it would handle any requests that create or destroy resources. It would. The only other vendorpriv extension I know of that does that is the underspecified and probably unimplementable GLX_SGIX_video_source though, so it's not really a big deal. - 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] randr: Fix rotation check in ProcRRSetScreenSize()
On Tue, 2018-01-30 at 13:06 -0800, Alex Goins wrote: > It sounds like this patch is the one we want. Can it be merged? remote: I: patch #196514 updated using rev 6b26a7bda9efa93440734ede0382a3e9a6761365. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 90996f590..6b26a7bda 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 4/7] glx: Use vnd layer for dispatch (v2)
On 02/01/2018 02:31 PM, Adam Jackson wrote: On Wed, 2018-01-10 at 13:57 -0700, Kyle Brenneman wrote: xorgGlxThunkRequest should be calling addXIDMap and removeXIDMap, not the internal handlers. I'm not sure that can be right. If it did, and adding the map failed, there's no way to get the backend to clean up; at least, not the way GlxAddXIDMap is currently written. Perhaps that should be changed to call FreeResource on the XID if AddResource fails? (Like the one place in the whole server where that'd be correct...) It works if the stub calls addXIDMap first, before calling into the vendor. Then, if addXIDMap fails, then the stub can return BadAlloc before the vendor has a chance to do anything that would require cleanup. If the vendor returns an error code, then the stub would call removeXIDMap to clean up before returning. That's also why the LEGAL_NEW_RESOURCE call has to be moved to the dispatch stub: The addXIDMap call happens before calling into the vendor, so by the time the vendor gets called, there's a resource defined for that XID and LEGAL_NEW_RESOURCE would fail. The default branch there may need some additional attention if it would handle any requests that create or destroy resources. It would. The only other vendorpriv extension I know of that does that is the underspecified and probably unimplementable GLX_SGIX_video_source though, so it's not really a big deal. - 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
