[RFC PATCH libinput] udev: add libinput_udev_rescan_devices()
When a libinput context for a given seat is initialized, not all devices may
be available. Some or all devices may be paused by systemd-logind. Waiting for
a unplug event is not appropriate here as the devices are physically
available, just prevented from getting access.
Add a libinput_udev_rescan_devices() function that triggers a scan of all
devices on the current udev seat. Devices that do not exist on the seat are
added, devices that already exist on the seat but have been revoked are
removed.
Note that devices that have been physically removed are not removed, instead
we wait for the udev event to handle this for us.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
The idea here is basically to start a udev context as usual. If the
compositor doesn't have the session, open_restricted will fail. Once the
ResumeDevice signals are handled by the compositor it can ask libinput to
rescan the device list to add the ones that failed before (or remove revoked
ones).
Notes on why this approach:
* libinput_device_suspend()/resume() seems nicer at first but if a device
fails to open, we don't have a libinput_device context. handling that
would make the API complicated since we cannot guarantee that all
libinput_device_* functions (specificall has_capability) work on all
devices anymore.
* I suspect in the 90% case the the PauseDevice/ResumeDevice signals come in
in a batch anyway, so the compositor should be able to optimise this to
one single call
* this is a udev specific call, for the path backend the compositor can and
should maintain the devices manually anyway
* EVIOCGVERSION was picked because it always succeeds, except after revoke
This is an RFC at this point, let me know if that approach works. Still need
to write tests and better evdev duplicate detection - right now there is a
race condition that could remove the wrong device.
src/evdev.c | 15 +++
src/evdev.h | 2 ++
src/libinput.h | 21 +
src/udev-seat.c | 46 +-
4 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index ba7c8b3..018fbb1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -790,3 +790,18 @@ evdev_device_destroy(struct evdev_device *device)
free(device-sysname);
free(device);
}
+
+int
+evdev_device_is_alive(struct evdev_device *device)
+{
+ int rc;
+ int version;
+
+ rc = ioctl(device-fd, EVIOCGVERSION, version);
+
+ if (rc 0 errno != ENODEV)
+ log_info(evdev: %s failed with errno %d (%s)\n,
+__func__, errno, strerror(errno));
+
+ return rc != -1;
+}
diff --git a/src/evdev.h b/src/evdev.h
index b83a2f9..82a3873 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -156,4 +156,6 @@ evdev_device_remove(struct evdev_device *device);
void
evdev_device_destroy(struct evdev_device *device);
+int
+evdev_device_is_alive(struct evdev_device *device);
#endif /* EVDEV_H */
diff --git a/src/libinput.h b/src/libinput.h
index 3e09871..dadcac2 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -715,6 +715,27 @@ libinput_udev_create_for_seat(const struct
libinput_interface *interface,
/**
* @ingroup base
*
+ * Re-scan the list of devices available to this context. Devices in the
+ * seat specified in libinput_udev_create_for_seat() that previously have
+ * failed to initialize are re-initialized. Devices that have successfully
+ * re-initialized but are now revoked are removed.
+ *
+ * Calling libinput_udev_rescan_devices() on a context suspended with
+ * libinput_suspend() does nothing.
+ *
+ * @note This function should not be used for detection of physically added
+ * or removed devices, libinput_dispatch() detects those. This function
+ * should only be used to re-open or close existing devices, e.g. if
+ * systemd-logind prevented access to a device before.
+ *
+ * @param libinput The previously initialized libinput context
+ */
+void
+libinput_udev_rescan_devices(struct libinput *libinput);
+
+/**
+ * @ingroup base
+ *
* Create a new libinput context that requires the caller to manually add or
* remove devices with libinput_path_add_device() and
* libinput_path_remove_device().
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 366c92b..5b09e4b 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -136,12 +136,28 @@ device_removed(struct udev_device *udev_device, struct
udev_input *input)
}
}
+static struct evdev_device*
+udev_input_find_device_by_sysname(struct udev_input *input, const char
*sysname)
+{
+ struct udev_seat *seat;
+ struct evdev_device *device;
+
+ list_for_each(seat, input-base.seat_list, base.link) {
+ list_for_each(device, seat-base.devices_list, base.link)
+ if (!strcmp(device-sysname, sysname)) {
+ return device;
+ }
+ }
+ return NULL;
+}
+
static
Re: [PATCH weston-ivi-shell v2 01/10] This vfunc lets us read out a rectangle of pixels from the currently attached surface buffer.
On Wed, 12 Mar 2014 23:46:35 +0900
Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp wrote:
Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp
---
Changes for v2:
- gl_renderer_read_shmbuffer_pixels to support different types of format of
shmbuffer.
src/compositor.h | 3 ++
src/gl-renderer.c | 114
++
2 files changed, 117 insertions(+)
diff --git a/src/compositor.h b/src/compositor.h
index 22a485f..ace75da 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -540,6 +540,9 @@ struct weston_renderer {
pixman_format_code_t format, void *pixels,
uint32_t x, uint32_t y,
uint32_t width, uint32_t height);
+ int (*read_surface_pixels)(struct weston_surface *es,
+pixman_format_code_t format, void *pixels,
+int x, int y, int width, int height);
void (*repaint_output)(struct weston_output *output,
pixman_region32_t *output_damage);
void (*flush_damage)(struct weston_surface *surface);
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 0e5afbe..7881fd8 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -106,6 +106,8 @@ struct gl_renderer {
EGLContext egl_context;
EGLConfig egl_config;
+ GLuint fbo;
+
struct wl_array vertices;
struct wl_array vtxcnt;
@@ -585,6 +587,114 @@ out:
pixman_region32_fini(repaint);
}
+static int
+gl_renderer_read_shmbuffer_pixels(struct wl_shm_buffer *shm_buffer,
+ void *pixels, int x, int y, int width, int
height)
How is 'pixels' allocated, what should we assume?
Is the size of the 'pixels' buffer as width*height*4 bytes, with
stride=width*4 bytes?
What do we assume about the 'pixels' color format?
What if the shm_buffer has color format RGB565?
What if shm_buffer stride is more than width*4 bytes?
But, see below.
+{
+ int i;
+ int pixel_size = 0;
+ uint8_t *ptr = NULL;
+ int32_t src_width, src_height, src_stride;
+ int32_t dst_stride;
+ int32_t offset;
+
+ /* Get some parameters of wl_shm_buffer. */
+ src_width = wl_shm_buffer_get_width(shm_buffer);
+ src_height = wl_shm_buffer_get_height(shm_buffer);
+ src_stride = wl_shm_buffer_get_stride(shm_buffer);
+
+ assert((src_width 0) (src_height 0));
+ if ((src_width = 0) || (src_height = 0))
+ return -1;
+
+ /* the start of reading position has to be changed. */
+ ptr = wl_shm_buffer_get_data(shm_buffer);
+ ptr += y * src_stride;
+ if ((x == 0) (width == src_width) (height = (src_height - y))) {
+ /* If x is 0 and widths are the same,
+ * whole pixel can be copied in only one time.
+ */
+ memcpy(pixels, ptr, src_stride * height);
+ } else {
+ /* If x is not 0,
+ * every line have to be copied one by one.
+ */
+ pixel_size = src_stride / src_width;
+ assert(pixel_size 5);
+ if (pixel_size 4) return -1;
+
+ dst_stride = width * pixel_size;
+ offset = x * pixel_size;
+
+ for (i = 0; i height; i++, ptr += src_stride) {
+ memcpy(pixels, ptr + offset, dst_stride);
+ pixels = (uint8_t*)pixels + dst_stride;
+ }
+ }
+
+ return 0;
+}
+
+static int
+gl_renderer_read_glsurface_pixels(struct weston_surface *es,
+ pixman_format_code_t format, void *pixels,
+ int x, int y, int width, int height)
+{
+ struct weston_compositor *ec = es-compositor;
+ struct gl_renderer *gr = get_renderer(ec);
+ struct gl_surface_state *gs = get_surface_state(es);
+ GLenum gl_format;
+
+ switch (format) {
+ case PIXMAN_a8r8g8b8:
+ gl_format = GL_BGRA_EXT;
+ break;
+ case PIXMAN_a8b8g8r8:
+ gl_format = GL_RGBA;
+ break;
+ default:
+ return -1;
+ }
+
+ if (gr-fbo == 0)
+ glGenFramebuffers(1, gr-fbo);
+ glBindFramebuffer(GL_FRAMEBUFFER, gr-fbo);
+ glFramebufferTexture2D(GL_FRAMEBUFFER,
+GL_COLOR_ATTACHMENT0,
+GL_TEXTURE_2D,
+gs-textures[0], 0);
+
+ glReadPixels(x, y, width, height,
+ gl_format, GL_UNSIGNED_BYTE, pixels);
+
+ glBindFramebuffer(GL_FRAMEBUFFER, 0);
+
+ return 0;
+}
+
+static int
+gl_renderer_read_surface_pixels(struct weston_surface *es,
+ pixman_format_code_t format, void *pixels,
+ int x, int y, int width, int height)
+{
+
Re: [Mesa-dev] [PATCH 0/7] EGL_MESA_configless_context
Kristian Høgsberg k...@bitplanet.net writes: Thanks Neil, series applied to mesa and weston. Great, thanks! I've reposted the piglit patch to the piglit list in case someone wants to review it there. Regards, - Neil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: replace the usage of selection with clipboard
On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak spit...@gmail.com wrote: Isn't Wayland differentiating between the selection and the clipboard? It is not doing that at the moment. Only explicit clipboard actions are supposed to be used. The selection is changed when the user selects an object.The clipboard is changed only when the user does a cut or copy operation. There is no such thing as a selection in the Wayland protocol, even though things are named 'selection'. It actually just refers to the clipboard (or so I'm told). There is also drag drop. Though in most cases this can be the same as the selection, I think there was some pathological examples showing that it has to be it's own piece of data. Drag and drop is separate from the clipboard in the protocol. One of the patches changed selection to data source, maybe data source is a better name? That was because it was referring to a data source being cancelled, not a clipboard data source specifically. It might be used for drag and drop too. I also am trying to reattach the patch here because for some reason it did not show up at text in my email: From abe49cf93128063d55cf881658b30b99d892ae53 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?John=20K=C3=A5re=20Alsaker?= john.kare.alsa...@gmail.com Date: Wed, 12 Mar 2014 15:28:52 +0100 Subject: [PATCH] protocol: replace the usage of selection with clipboard Make it clear that we're dealing with a clipboard and not X-style selections in the protocol. --- protocol/wayland.xml | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3aa89af..7a1efdd 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -508,7 +508,7 @@ /event event name=cancelled - description summary=selection was cancelled + description summary=data source was cancelled This data source has been replaced by another data source. The client should clean up and destroy this data source. /description @@ -559,11 +559,11 @@ /request request name=set_selection - description summary=copy data to the selection - This request asks the compositor to set the selection + description summary=copy data to the clipboard + This request asks the compositor to change the clipboard data to the data from the source on behalf of the client. - To unset the selection, set the source to NULL. + To empty the clipboard, set the source to NULL. /description arg name=source type=object interface=wl_data_source allow-null=true/ arg name=serial type=uint summary=serial of the event that triggered this request/ @@ -574,7 +574,7 @@ The data_offer event introduces a new wl_data_offer object, which will subsequently be used in either the data_device.enter event (for drag-and-drop) or the - data_device.selection event (for selections). Immediately + data_device.selection event (for clipboard data). Immediately following the data_device_data_offer event, the new data_offer object will send out data_offer.offer events to describe the mime types it offers. @@ -626,14 +626,14 @@ /event event name=selection - description summary=advertise new selection + description summary=advertise new clipboard data The selection event is sent out to notify the client of a new - wl_data_offer for the selection for this device. The + wl_data_offer for the clipboard for this device. The data_device.data_offer and the data_offer.offer events are sent out immediately before this event to introduce the data offer object. The selection event is sent to a client - immediately before receiving keyboard focus and when a new - selection is set while the client has keyboard focus. The + immediately before receiving keyboard focus and when new + clipboard data is set while the client has keyboard focus. The data_offer is valid until a new data_offer or NULL is received or until the client loses keyboard focus. /description -- 1.8.4.msysgit.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: replace the usage of selection with clipboard
John Kåre Alsaker wrote: On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak spit...@gmail.com wrote: Isn't Wayland differentiating between the selection and the clipboard? It is not doing that at the moment. Only explicit clipboard actions are supposed to be used. The selection is changed when the user selects an object.The clipboard is changed only when the user does a cut or copy operation. There is no such thing as a selection in the Wayland protocol, even though things are named 'selection'. It actually just refers to the clipboard (or so I'm told). In that case this patch makes sense. There is also drag drop. Though in most cases this can be the same as the selection, I think there was some pathological examples showing that it has to be it's own piece of data. Drag and drop is separate from the clipboard in the protocol. I believe then that drag drop can be used for x-style selection. The idea is that a client can turn some action (such as a middle mouse click) into the same result as though the user dragged from a selected object and dropped at that point. Hopefully this can be done by reusing as much of the drag drop api as possible. I don't think it has to be any more complex than that. There is only one potential drag source (whichever client last said it was a drag source, there is no attempt to choose from many potential drag sources to find the correct data type). The clients on either end are aware that this is happening so they can disable it or make the result different from drag drop, though making it identical is encouraged. I do not believe that removing middle-mouse paste (or making it use the clipboard) will be acceptable to X users, so something MUST be done in Wayland. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: replace the usage of selection with clipboard
On Thu, Mar 13, 2014 at 3:12 PM, Bill Spitzak spit...@gmail.com wrote: John Kåre Alsaker wrote: On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak spit...@gmail.com wrote: Isn't Wayland differentiating between the selection and the clipboard? It is not doing that at the moment. Only explicit clipboard actions are supposed to be used. The selection is changed when the user selects an object.The clipboard is changed only when the user does a cut or copy operation. There is no such thing as a selection in the Wayland protocol, even though things are named 'selection'. It actually just refers to the clipboard (or so I'm told). In that case this patch makes sense. There is also drag drop. Though in most cases this can be the same as the selection, I think there was some pathological examples showing that it has to be it's own piece of data. Drag and drop is separate from the clipboard in the protocol. I believe then that drag drop can be used for x-style selection. The idea is that a client can turn some action (such as a middle mouse click) into the same result as though the user dragged from a selected object and dropped at that point. Hopefully this can be done by reusing as much of the drag drop api as possible. I don't think it has to be any more complex than that. There is only one potential drag source (whichever client last said it was a drag source, there is no attempt to choose from many potential drag sources to find the correct data type). The clients on either end are aware that this is happening so they can disable it or make the result different from drag drop, though making it identical is encouraged. I do not believe that removing middle-mouse paste (or making it use the clipboard) will be acceptable to X users, so something MUST be done in Wayland. Patches welcome. Complaining is not. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] weston: Send done event with version 2 of wl_output
With protocol of wl_output version 2, after the output change,
it should send done event to all clients bount with it.
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 7c29d51..98a4f6f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3245,7 +3245,7 @@ weston_output_move(struct weston_output *output, int x,
int y)
wl_signal_emit(output-compositor-output_moved_signal, output);
/* Notify clients of the change for output position. */
- wl_resource_for_each(resource, output-resource_list)
+ wl_resource_for_each(resource, output-resource_list) {
wl_output_send_geometry(resource,
output-x,
output-y,
@@ -3255,6 +3255,10 @@ weston_output_move(struct weston_output *output, int x,
int y)
output-make,
output-model,
output-transform);
+
+ if (wl_resource_get_version(resource) = 2)
+ wl_output_send_done(resource);
+ }
}
WL_EXPORT void
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] wayland: Add wl_output name event
This event contains name of output. It may be sent after binding the output object. It is intended that client could input a character output name as a parameter or for log info. Signed-off-by: Quanxian Wang quanxian.w...@intel.com --- protocol/wayland.xml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d47ee62..c91a91a 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1756,6 +1756,17 @@ /description arg name=factor type=int summary=scaling factor of output/ /event + +event name=name since=2 + description summary=output name properties + This event contains name of output. It may be sent after + binding the output object. It will provide sensible name + for client when they generate the log for user. + Also it is intended that client could input a character + output name as a parameter or log. + /description + arg name=name type=string summary=char name of output/ +/event /interface interface name=wl_region version=1 -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/3] Add wl_output name event
This event contains name of output. It may be sent after binding the output object. It is intended that client could input a character output name as a parameter or for log info. Mainly for client, provide a sensible character name instead of object. Quanxian Wang (3): wayland: Add wl_output name event shell: Add wl_output name event weston:Add wl_output name event Wayland: protocol/wayland.xml | 11 +++ 1 file changed, 11 insertions(+) Shell: clients/desktop-shell.c | 10 +- clients/window.c| 10 +- 2 files changed, 18 insertions(+), 2 deletions(-) Weston: src/compositor.c| 3 +++ 1 files changed, 3 insertions(+) -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] shell: Add wl_output name event
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
clients/desktop-shell.c | 10 +-
clients/window.c| 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a0c6b6d..cefe936 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1172,6 +1172,13 @@ output_handle_mode(void *data,
}
static void
+output_handle_name(void *data,
+ struct wl_output *wl_output,
+ const char *name)
+{
+}
+
+static void
output_handle_done(void *data,
struct wl_output *wl_output)
{
@@ -1192,7 +1199,8 @@ static const struct wl_output_listener output_listener = {
output_handle_geometry,
output_handle_mode,
output_handle_done,
- output_handle_scale
+ output_handle_scale,
+ output_handle_name
};
static void
diff --git a/clients/window.c b/clients/window.c
index 3136a7d..4946b7a 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -4714,11 +4714,19 @@ display_handle_mode(void *data,
}
}
+static void
+display_handle_name(void *data,
+ struct wl_output *wl_output,
+ const char *name)
+{
+}
+
static const struct wl_output_listener output_listener = {
display_handle_geometry,
display_handle_mode,
display_handle_done,
- display_handle_scale
+ display_handle_scale,
+ display_handle_name
};
static void
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/3] weston:Add wl_output name event
Signed-off-by: Quanxian Wang quanxian.w...@intel.com --- src/compositor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/compositor.c b/src/compositor.c index 98a4f6f..8e8964b 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -3045,6 +3045,9 @@ bind_output(struct wl_client *client, } if (version = 2) + wl_output_send_name(resource, output-name); + + if (version = 2) wl_output_send_done(resource); } -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] weston: Send done event with version 2 of wl_output
On Fri, Mar 14, 2014 at 09:16:25AM +0800, Quanxian Wang wrote:
With protocol of wl_output version 2, after the output change,
it should send done event to all clients bount with it.
bound?
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 7c29d51..98a4f6f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3245,7 +3245,7 @@ weston_output_move(struct weston_output *output, int x,
int y)
wl_signal_emit(output-compositor-output_moved_signal, output);
/* Notify clients of the change for output position. */
- wl_resource_for_each(resource, output-resource_list)
+ wl_resource_for_each(resource, output-resource_list) {
wl_output_send_geometry(resource,
output-x,
output-y,
@@ -3255,6 +3255,10 @@ weston_output_move(struct weston_output *output, int
x, int y)
output-make,
output-model,
output-transform);
+
+ if (wl_resource_get_version(resource) = 2)
+ wl_output_send_done(resource);
+ }
}
WL_EXPORT void
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 1/6] Add weston randr protocol
From: magc...@gmail.com [mailto:magc...@gmail.com] On Behalf Of Jasper St. Pierre Sent: Monday, March 10, 2014 10:42 AM To: Wang, Quanxian Cc: Hardening; wayland-devel@lists.freedesktop.org; Zhang, Xiong Y; Pekka Paalanen; Matthias Clasen; Jason Ekstrand Subject: Re: [PATCH 1/6] Add weston randr protocol There's two different things here. There's the protocol and the UI. (By UI I also mean a command-line tool like /usr/bin/xrandr, I just mean the way the user does a mode-set). I think to build a good UI, we need a list of available modes that the user can choose from. Having a tool where the user enters two numbers, and then tells the user No, guess again if they entered the wrong numbers is bad user interface design. But, as Hardening said, the protocol should allow setting modes that aren't in the advertised list. [Wang, Quanxian] Sorry for response later. From command line tools, Weston-wrandr will provide the mode list instead of guessing what is in. you can firstly use 'weston-wrandr --output' to query all modes of output. And then select one of them. Of course, if you want to new a mode, that is fine. It is also reasonable for me. On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote: 5) mode setting parameters control Mode and output will be under the control. User could not randomly to set their mode. They have to select the available modes and outputs provided by compositor. Don't allow random mode setting. The mode and output information could be provided by weston-randr apps or wl_output interface. I don't think that allowing to set only announced modes is a good idea. The RDP compositor is a good example where you can't know the supported modes (as nearly all modes can be supported). IIRC depending on the drivers, drm can also set arbitrary modes. [Wang, Quanxian] so, let user set the mode without limitation? Not sure if we should support that. Any comment for this requirement? Regards -- David FORT website: http://www.hardening-consulting.com/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.orgmailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/3] weston:Add wl_output name event
On Fri, Mar 14, 2014 at 10:27:05AM +0800, Quanxian Wang wrote:
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c
index 98a4f6f..8e8964b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3045,6 +3045,9 @@ bind_output(struct wl_client *client,
}
if (version = 2)
+ wl_output_send_name(resource, output-name);
+
+ if (version = 2)
wl_output_send_done(resource);
Why not just put the two calls in a block?
if (version = 2) {
wl_output_send_name(resource, output-name);
wl_output_send_done(resource);
}
}
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
weston: weston randr protocol for testing and configuration
Objective: With discussion in mail list, currently we have an agreement. Randr interfaces will not be exposed public. The objective will be only for testing and configuration. Thanks Pq, Jason, Jasper, Hardening, and other's comment. Before sending the email, the function list below is implementedi(tested) except new mode creating(not testing). Thanks for your support. Updates: 1) Change wl_randr to weston_randr for weston-specific. 2) Unique operation issue Given that one client has two more threads to do mode setting on the same output at the same time, how to identify what response (done event) is belong to one or another request when they want to get response? This is a design flaw in the first version of randr protocol. The solution is to use the wayland/weston mechanism, every request will generate a resource which be used to send done event to the owner who start it. Owner could set the listener on that and keep tuning on the response event. For example In client: randr_resource = wl_randr_set_transform(randr.randr,wayland_output,argument.transform); wl_randr_add_listener(randr_resource, randr_transform_listener, randr); In compositor: randr_resource = wl_resource_create(client,wl_randr_interface,1, action); ... wl_randr_send_action_done(randr_resource, 1WL_RANDR_ACTION_TRANSFORM, ret, action); wl_resource_destroy(randr_resource); 3) Mess up issue Will take randr protocol implementation as a module. This will keep compositor clear and avoid messing up in compositor.c. You can enable it from command line 'weston --tty=1 --enable-wrandr' or put wrandr.so in to module list in weston.ini. 4) Add group randr operations After talking with Pq, in order to avoid glitches, group operation is needed. However, if operating on two outputs more at one time, it will bring more issues which could not control. In this randr design, will not provide group operation on multiple outputs. We provide atomic operation on one output, multi outputs operation logic are left to designer/developers. Group operation on one output will be designed. For example, you can set mode, scale, and transform at one time with one randr request. 5) Mode setting parameters control Output name will be under the control, for mode setting, from suggestion of Hardening and Jasper St. Pierre, it'd better to let user new mode. Defaultly I agree that. If someone has other suggestion and reason, please let me know. 6) Disconnected outputs Currently I have disable that. But basically, when user query output information, showing connected and disconnected output as a whole will be fine for user and QA people. Sometime, QA people or user like that information. It will be helpful for them to identify how many outputs are provided by their machine. Which is connected and which is not connected. So when user has requirement, that is fine. I could enable it. 7) wl_output property name event I have sent patches to enable it. Not only for randr, for any client of wayland, it will be helpful to get a sensible name instead of only wl_output object. 8) adding set_scale request Mode, scale, transform are the basic properties of output, I will add them as a whole. Original information: The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode. If you want to make sure if it is successful, you need keep tuning done event. after all, it is a protocol communication. With this protocol, weston-wrandr application is developped to help implement randr protocol in command line just like xrandr command in xserver. Weston protocol wrandr will provide interface to 1) set output mode, scale, transform 2) move output to relative position Here are some use cases. 1. weston-randr -q # query all output mode info and disconnected output HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 ... VGA1 1)1280x1024@60 (current) 2)1152x864@60 3)1024x768@60 ... 2. weston-randr --output HDMI3 # query HDMI3 output mode info HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 3. weston-randr --output HDMI3 --mode 2 # which will set mode as 1920x1200 or weston-randr --output HDMI3 --mode 1920x1200@60 or weston-randr --output HDMI3 --mode 1920x1200 4. weston-randr --output HDMI3 --transform 1 # rotate HDMI3 output 90 degree 5. weston-randr --output HDMI3 --leftof VGA1 # put HDMI3 output leftof VGA1 Group operations example: 5. weston-randr --output HDMI3 --transform 3 --scale 2 --mode 2 -leftof VGA1 Signed-off-by: Quanxian Wang quanxian.w...@intel.com --- protocol/randr.xml | 166 +++ 1 files changed, 166 insertions(+) create mode 100644 protocol/randr.xml diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode 100644 index 000..5c1d2d2 --- /dev/null +++ b/protocol/randr.xml @@ -0,0 +1,166
RE: [PATCH] weston: Send done event with version 2 of wl_output
-Original Message-
From: Bryce W. Harrington [mailto:b.harring...@samsung.com]
Sent: Friday, March 14, 2014 10:19 AM
To: Wang, Quanxian
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] weston: Send done event with version 2 of wl_output
On Fri, Mar 14, 2014 at 09:16:25AM +0800, Quanxian Wang wrote:
With protocol of wl_output version 2, after the output change, it
should send done event to all clients bount with it.
bound?
[Wang, Quanxian] yes. Sorry.
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c index
7c29d51..98a4f6f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3245,7 +3245,7 @@ weston_output_move(struct weston_output *output,
int x, int y)
wl_signal_emit(output-compositor-output_moved_signal, output);
/* Notify clients of the change for output position. */
-wl_resource_for_each(resource, output-resource_list)
+wl_resource_for_each(resource, output-resource_list) {
wl_output_send_geometry(resource,
output-x,
output-y,
@@ -3255,6 +3255,10 @@ weston_output_move(struct weston_output
*output, int x, int y)
output-make,
output-model,
output-transform);
+
+if (wl_resource_get_version(resource) = 2)
+wl_output_send_done(resource);
+}
}
WL_EXPORT void
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 2/3] weston:Add wl_output name event
-Original Message-
From: Bryce W. Harrington [mailto:b.harring...@samsung.com]
Sent: Friday, March 14, 2014 10:44 AM
To: Wang, Quanxian
Cc: wayland-devel@lists.freedesktop.org; ppaala...@gmail.com
Subject: Re: [PATCH 2/3] weston:Add wl_output name event
On Fri, Mar 14, 2014 at 10:27:05AM +0800, Quanxian Wang wrote:
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c index
98a4f6f..8e8964b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3045,6 +3045,9 @@ bind_output(struct wl_client *client,
}
if (version = 2)
+wl_output_send_name(resource, output-name);
+
+if (version = 2)
wl_output_send_done(resource);
Why not just put the two calls in a block?
if (version = 2) {
wl_output_send_name(resource, output-name);
wl_output_send_done(resource);
}
[Wang, Quanxian] I found scale and done are separately sent instead of in one
block. I don't know why. Therefore I follow their original code style to do
that.
}
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] weston:Send done event with version 2 of wl_output
With protocol of wl_output version 2, after the output change,
it should send done event to all clients bound with it.
Signed-off-by: Quanxian Wang quanxian.w...@intel.com
---
src/compositor.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 7c29d51..98a4f6f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3245,7 +3245,7 @@ weston_output_move(struct weston_output *output, int x,
int y)
wl_signal_emit(output-compositor-output_moved_signal, output);
/* Notify clients of the change for output position. */
- wl_resource_for_each(resource, output-resource_list)
+ wl_resource_for_each(resource, output-resource_list) {
wl_output_send_geometry(resource,
output-x,
output-y,
@@ -3255,6 +3255,10 @@ weston_output_move(struct weston_output *output, int x,
int y)
output-make,
output-model,
output-transform);
+
+ if (wl_resource_get_version(resource) = 2)
+ wl_output_send_done(resource);
+ }
}
WL_EXPORT void
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
