Re: [Mesa-dev] [PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
Hi Jason & Daniel, maybe I should explain once more where the problem with this approach is and why I think we need to get that fixed before we can do something like this here. To summarize what this patch here does is that it copies the exclusive fence and/or the shared fences into a sync_file. This alone is totally unproblematic. The problem is what this implies. When you need to copy the exclusive fence to a sync_file then this means that the driver is at some point ignoring the exclusive fence on a buffer object. When you combine that with complex drivers which use TTM and buffer moves underneath you can construct an information leak using this and give userspace access to memory which is allocated to the driver, but not yet initialized. This way you can leak things like page tables, passwords, kernel data etc... in large amounts to userspace and is an absolutely no-go for security. That's why I'm said we need to get this fixed before we upstream this patch set here and especially the driver change which is using that. Regards, Christian. Am 10.06.21 um 23:09 schrieb Jason Ekstrand: Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König Cc: Michel Dänzer Cc: Dave Airlie Cc: Bas Nieuwenhuizen Cc: Daniel Stone Cc: mesa-...@lists.freedesktop.org Cc: wayland-devel@lists.freedesktop.org Test-with: 20210524205225.872316-1-ja...@jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c| 103 + drivers/dma-buf/dma-fence-array.c| 27 +++ drivers/dma-buf/dma-resv.c | 110 +++ include/linux/dma-fence-array.h | 17 + include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 - 7 files changed, 369
scanner: use descriptions in entries
This series fixes https://gitlab.freedesktop.org/wayland/wayland/-/issues/208 and alters a test to confirm it. I know I'm supposed to use a gitlab pull request, but I can't create an account as there is an error with reCAPTCHA, already reported here: https://lists.freedesktop.org/archives/sitewranglers/2021-May/013103.html and I wouldn't use proprietary javascript to provide training data for a proprietary machine learning system even if reCAPTCHA did load. James ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] tests: Test wayland-scanner with a description in an entry
This previously would have caused a memory leak and incorrect
comments.
Signed-off-by: James Legg
---
tests/data/example-client.h | 20 ++--
tests/data/example-server.h | 20 ++--
tests/data/example.xml | 26 ++
3 files changed, 34 insertions(+), 32 deletions(-)
diff --git a/tests/data/example-client.h b/tests/data/example-client.h
index d421af9..9a2200a 100644
--- a/tests/data/example-client.h
+++ b/tests/data/example-client.h
@@ -4095,16 +4095,6 @@ enum wl_pointer_axis {
* from a "finger" source may be in a smooth coordinate space with
* kinetic scrolling whereas a "wheel" source may be in discrete steps
* of a number of lines.
- *
- * The "continuous" axis source is a device generating events in a
- * continuous coordinate space, but using something other than a
- * finger. One example for this source is button-based scrolling where
- * the vertical motion of a device is converted to scroll events while
- * a button is held down.
- *
- * The "wheel tilt" axis source indicates that the actual device is a
- * wheel but the scroll event is not caused by a rotation but a
- * (usually sideways) tilt of the wheel.
*/
enum wl_pointer_axis_source {
/**
@@ -4117,10 +4107,20 @@ enum wl_pointer_axis_source {
WL_POINTER_AXIS_SOURCE_FINGER = 1,
/**
* continuous coordinate space
+*
+* A device generating events in a continuous coordinate space,
+* but using something other than a finger. One example for this
+* source is button-based scrolling where the vertical motion of a
+* device is converted to scroll events while a button is held
+* down.
*/
WL_POINTER_AXIS_SOURCE_CONTINUOUS = 2,
/**
* a physical wheel tilt
+*
+* Indicates that the actual device is a wheel but the scroll
+* event is not caused by a rotation but a (usually sideways) tilt
+* of the wheel.
* @since 6
*/
WL_POINTER_AXIS_SOURCE_WHEEL_TILT = 3,
diff --git a/tests/data/example-server.h b/tests/data/example-server.h
index 3311c5d..7cfa4e7 100644
--- a/tests/data/example-server.h
+++ b/tests/data/example-server.h
@@ -3304,16 +3304,6 @@ enum wl_pointer_axis {
* from a "finger" source may be in a smooth coordinate space with
* kinetic scrolling whereas a "wheel" source may be in discrete steps
* of a number of lines.
- *
- * The "continuous" axis source is a device generating events in a
- * continuous coordinate space, but using something other than a
- * finger. One example for this source is button-based scrolling where
- * the vertical motion of a device is converted to scroll events while
- * a button is held down.
- *
- * The "wheel tilt" axis source indicates that the actual device is a
- * wheel but the scroll event is not caused by a rotation but a
- * (usually sideways) tilt of the wheel.
*/
enum wl_pointer_axis_source {
/**
@@ -3326,10 +3316,20 @@ enum wl_pointer_axis_source {
WL_POINTER_AXIS_SOURCE_FINGER = 1,
/**
* continuous coordinate space
+*
+* A device generating events in a continuous coordinate space,
+* but using something other than a finger. One example for this
+* source is button-based scrolling where the vertical motion of a
+* device is converted to scroll events while a button is held
+* down.
*/
WL_POINTER_AXIS_SOURCE_CONTINUOUS = 2,
/**
* a physical wheel tilt
+*
+* Indicates that the actual device is a wheel but the scroll
+* event is not caused by a rotation but a (usually sideways) tilt
+* of the wheel.
* @since 6
*/
WL_POINTER_AXIS_SOURCE_WHEEL_TILT = 3,
diff --git a/tests/data/example.xml b/tests/data/example.xml
index 29b63be..38feec3 100644
--- a/tests/data/example.xml
+++ b/tests/data/example.xml
@@ -1980,21 +1980,23 @@
from a "finger" source may be in a smooth coordinate space with
kinetic scrolling whereas a "wheel" source may be in discrete steps
of a number of lines.
-
- The "continuous" axis source is a device generating events in a
- continuous coordinate space, but using something other than a
- finger. One example for this source is button-based scrolling where
- the vertical motion of a device is converted to scroll events while
- a button is held down.
-
- The "wheel tilt" axis source indicates that the actual device is a
- wheel but the scroll event is not caused by a rotation but a
- (usually sideways) tilt of the wheel.
-
-
+
+
+ A device generating events in a continuous coordinate space, but
+ using something other than a finger. One example for this source
+ is button-based scrolling where the vertical motion of a device
+ is conve
[PATCH 1/2] scanner: Use descriptions in entries
entry may have a description according to the DTD. This is used in
some protocols including xdg-shell.
Fixes the code comment on an enum declaration using the description of
the last enum that had one, adds the descriptions to the comments on
enumerators, and avoids leaking the previously missing descriptions.
Fixes #208
Signed-off-by: James Legg
---
src/scanner.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/scanner.c b/src/scanner.c
index 46bdfc2..64df6e8 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -236,6 +236,7 @@ struct entry {
char *summary;
int since;
struct wl_list link;
+ struct description *description;
};
struct parse_context {
@@ -245,6 +246,7 @@ struct parse_context {
struct interface *interface;
struct message *message;
struct enumeration *enumeration;
+ struct entry *entry;
struct description *description;
char character_data[8192];
unsigned int character_data_length;
@@ -542,6 +544,7 @@ free_entry(struct entry *entry)
free(entry->uppercase_name);
free(entry->value);
free(entry->summary);
+ free_description(entry->description);
free(entry);
}
@@ -884,6 +887,7 @@ start_element(void *data, const char *element_name, const
char **atts)
entry->summary = NULL;
wl_list_insert(ctx->enumeration->entry_list.prev,
&entry->link);
+ ctx->entry = entry;
} else if (strcmp(element_name, "description") == 0) {
if (summary == NULL)
fail(&ctx->loc, "description without summary");
@@ -893,6 +897,8 @@ start_element(void *data, const char *element_name, const
char **atts)
if (ctx->message)
ctx->message->description = description;
+ else if (ctx->entry)
+ ctx->entry->description = description;
else if (ctx->enumeration)
ctx->enumeration->description = description;
else if (ctx->interface)
@@ -1008,6 +1014,8 @@ end_element(void *data, const XML_Char *name)
ctx->enumeration->name);
}
ctx->enumeration = NULL;
+ } else if (strcmp(name, "entry") == 0) {
+ ctx->entry = NULL;
} else if (strcmp(name, "protocol") == 0) {
struct interface *i;
@@ -1364,10 +1372,17 @@ emit_enumerations(struct interface *interface)
}
printf("enum %s_%s {\n", interface->name, e->name);
wl_list_for_each(entry, &e->entry_list, link) {
- if (entry->summary || entry->since > 1) {
+ desc = entry->description;
+ if (entry->summary || entry->since > 1 || desc) {
printf("\t/**\n");
if (entry->summary)
printf("\t * %s\n", entry->summary);
+ if (desc) {
+ printf("\t * %s\n", desc->summary);
+ printf("\t *\n");
+ if (desc->text)
+ desc_dump(desc->text, "\t * ");
+ }
if (entry->since > 1)
printf("\t * @since %d\n",
entry->since);
printf("\t */\n");
--
2.31.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Surface ID assignment for multiple instances of an application
Hi Dalvi, The ivi id is something application needs to set explicitly, need to understand how the id is assigned for application you already can control?! Are you using id-agent plugin? Best regards Jena Vaibhav Dalvi schrieb am Fr. 4. Juni 2021 um 07:19: > Hi all, > I'm working on a simple C++ application (dbus-service) which can > start/stop another application ( a vnc viewer application ). My platform is > arm-linux with wayland + ivi-shell. Now I am able to start / stop the x11 > vncviewer application one instance. Needed to add desktop-app entries in > weston.ini. I'm using LayerManagerControl commands to manage the window ( > at present - further on ilm API's shall be used. ) > > Now my next use case is multiple instances of this vnc viewer application. > And for that I added few more desktop-app entries to weston.ini, and > updated the service to launch multiple instances of vnc viewer. I am able > to launch multiple instances of vncviewer. But to control those instances, > I need to know which instance is assigned which surface ID. > > Another look at ilm api's led me to surface-property's creator-PID field. > Unfortunately with xwayland, for x11 apps this field contains PID of > xwayland instance and not the actual x11 app. > > I looked at libweston as well as xwayland-api, but not able to see a clear > solution. Please suggest any way to obtain this mapping of surface ID and > process ID for x11 apps with xwayland. > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
