[PATCH] Mirroing mode
Pekka Paalanen
ppaalanen at gmail.com
Fri Apr 10 06:05:03 PDT 2015
On Fri, 10 Apr 2015 15:36:36 +0800
Leslie Zhai <xiang.zhai at i-soft.com.cn> wrote:
> Hi Pekka,
>
> I am reading src/compositor-drm.c in create_outputs(...) function, it
> uses drmModeGetResources to get count_connectors,
> then update the X position in a for loop shown as below:
>
> ```
> x += container_of(ec->base.output_list.prev,
> struct weston_output,
> link)->width;
> ```
>
> so it is absolutely extend mode by default, "draw" count_connectors`
> create_output_for_connector(...) rectangles with DIFFERENT X position,
> if take a screenshot, it should be
> https://twitter.com/xiangzhai/status/586061869279883266/photo/1
>
> But if add mirror to drm_options (shown as below patch) it is able to
> run weston --mirror with the SAME X position,
> the screenshot
> https://twitter.com/xiangzhai/status/586428721533288449/photo/1
>
I have a huge deja vu experience here. I warmly suggest you dig up the
previous discussions from the mailing list archives when this kind of
simple (too stupid to work for more than 2 outputs) mirroring was
proposed.
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 153ca5d..d28a32e 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -216,6 +216,7 @@ struct drm_parameters {
> int tty;
> int use_pixman;
> const char *seat_id;
> + int mirror;
> };
>
> static struct gl_renderer_interface *gl_renderer;
> @@ -2327,7 +2328,7 @@ destroy_sprites(struct drm_compositor *compositor)
>
> static int
> create_outputs(struct drm_compositor *ec, uint32_t option_connector,
> - struct udev_device *drm_device)
> + struct udev_device *drm_device, int mirror_mode)
> {
> drmModeConnector *connector;
> drmModeRes *resources;
> @@ -2370,9 +2371,12 @@ create_outputs(struct drm_compositor *ec,
> uint32_t option_connector,
> continue;
> }
>
> - x += container_of(ec->base.output_list.prev,
> + /* FIXME: mirroring mode */
> + if (!mirror_mode) {
> + x += container_of(ec->base.output_list.prev,
> struct weston_output,
> link)->width;
> + }
> }
>
> drmModeFreeConnector(connector);
> @@ -2936,7 +2940,7 @@ drm_compositor_create(struct wl_display *display,
> goto err_sprite;
> }
>
> - if (create_outputs(ec, param->connector, drm_device) < 0) {
> + if (create_outputs(ec, param->connector, drm_device, param->mirror)
> < 0) {
> weston_log("failed to create output for %s\n", path);
> goto err_udev_input;
> }
> @@ -3021,6 +3025,7 @@ backend_init(struct wl_display *display, int
> *argc, char *argv[],
> { WESTON_OPTION_INTEGER, "tty", 0, ¶m.tty },
> { WESTON_OPTION_BOOLEAN, "current-mode", 0,
> &option_current_mode },
> { WESTON_OPTION_BOOLEAN, "use-pixman", 0, ¶m.use_pixman },
> + { WESTON_OPTION_BOOLEAN, "mirror", 0, ¶m.mirror }
> };
>
> param.seat_id = default_seat;
> diff --git a/src/compositor.c b/src/compositor.c
> index 6fbb8e8..d29cabc 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -5043,7 +5043,8 @@ usage(int error_code)
> " --seat=SEAT\t\tThe seat that weston should run on\n"
> " --tty=TTY\t\tThe tty to use\n"
> " --use-pixman\t\tUse the pixman (CPU) renderer\n"
> - " --current-mode\tPrefer current KMS mode over EDID preferred
> mode\n\n");
> + " --current-mode\tPrefer current KMS mode over EDID preferred
> mode\n"
> + " --mirror\t\tUse mirroring mode\n\n");
> #endif
>
> #if defined(BUILD_FBDEV_COMPOSITOR)
>
>
>
> It is a monkey patch ;-) there are a lot of things I have to fix or
> learn, such as:
> 1. how to "draw" the SAME "rectangle" to different outputs, what do I
> need to hack for recent weston`s architecture?
> 2. xrandr utility will choose the SAME mode for different outputs, for
> example, 1024x768, I have not implemented it for mirroring mode!
Like I said, a simple test does not guarantee that weston's damage
tracking can cope with it. You have to ensure the renderer/backend can
do partial updates, and then watch for glitches when causing partial
repaints.
The answer to your question about rectangles involves understanding the
damage tracking system and making sure it works also for overlapping
outputs. After that, it should just work. I cannot explain it off-hand,
it is so complex that it would take a good while for me to study and
understand again how it works.
Screenshooting forces a full repaint IIRC, so that would immediately
hide any glitches you might see.
Thanks,
pq
More information about the wayland-devel
mailing list