Question about multi-displays control on wayland protocol‏

[Pekka Paalanen]

On Fri, 10 Oct 2014 03:35:28 +0000
Yang Andy <williamyang13 at hotmail.com> wrote:

> Hi Pekka
> 
> Thank you very much for your reply.
> 
> I got your meaning,but i have another question.
> 
> Is there any necessary for modify weston/compositor?
> 
> Because i investigate source code[compositor-fbdev.c],and find that compositor open device [/dev/fb0].
> 
> It seems that the compositor is constant with /dev/fb0,how does compositor direct surfaces to specific outputs(fb0/fb1...)
> 

Right, if you have multiple monitors attached, the legacy fbdev
interface is not going to be enough at all. Therefore you cannot use
compositor-fbdev.c. Even the EGL support in compositor-fbdev.c is a far
stretch we do not really like, because fbdev should just die.

The recommended solution is to move to a kernel DRM driver, and use the
compositor-drm.c backend. I understand it might not be feasible for
you, if you don't have a DRM driver and an EGL stack to go with it, but
that is the direction you should be pushing for in the long run.

If you really are stuck with using fbdev, you will need to write (fork)
and maintain your own fbdev backend.

I'm not sure how your EGL integration would work, because obviously
EGL_DEFAULT_DISPLAY cannot specify which output to target. Probably
your proprietary EGL stack has proprietary ways to choose the right
/dev/fb* to target, but for that too you will need to modify the
existing code in Weston.

If you need several EGLdisplays, e.g. one per /dev/fb*, then you may
need to modify Weston even more, because I don't think it supports
multiple renderer instances at the same time, and currently gl-renderer
assumes a single EGLDisplay. Furthermore, if you create multiple
EGLDisplays, then initializing EGL_WL_bind_wayland_display extension
properly may be an issue: will you initialize it for each EGLDisplay
separately, or for just one? Both ways cause side-effects that your EGL
stack needs to correctly handle, and they are probably unexpected (not
implemented or never tested), so proceed with caution.

It would definitely be easier if you only need one EGLDisplay, and
can use the EGLNativeWindowType argument of eglCreateWindowSurface() to
choose the target output for the EGLSurface. In this case the required
modifications would be limited to your version of compositor-fbdev.c.

It all depends on the EGL implementation you have.

If you could use compositor-drm.c, it would all just work without
modifications.


Thanks,
pq