How to run Weston on specific devices?

Pekka Paalanen ppaalanen at
Thu Jan 7 00:42:59 PST 2016

On Tue, 5 Jan 2016 18:10:23 +0200
me at wrote:

> Thank you for your answer.
> On 05.01.16 10:07, Pekka Paalanen wrote:
> > On Tue, 5 Jan 2016 00:08:56 +0200
> > me at wrote:
> >  
> >> Hello. My computer has 2 seats. By seat I mean a set containing a
> >> monitor, a videocard, a mouse, and a keyboard. I can drive them with 2
> >> Xorg server, and I am looking for how to replicate this configuration
> >> with Wayland.
> >>
> >> AFAIK, Weston uses "libinput", so I assigned "WL_SEAT" of input devices  
> >
> > Hi,
> >
> > should that not be ID_SEAT?
> >
> > Also remember to set it for the DRM device you want to use with the
> > seat.
> >
> > ID_SEAT is for physical seats which is what you are setting up. WL_SEAT
> > is for "seats" inside a single Weston session so that you can group
> > input devices to different wl_seat Wayland objects. Particularly, two
> > mouse devices in the same wl_seat move the same pointer, while two
> > mouse devices in different wl_seats gets you two independent pointers
> > in the same session.  
> In fact, this is the thing I don't quite understand. In what situations 
> having 2 logical seats inside 1 physical seat is useful? And what seats 
> the event "wl_registry::global" announces--logical or physical?
> Anyway, I set WL_SEAT and ID_SEAT to "seat1" before writing to this 
> list. For example. {{{
> $ udevadm info /sys/devices/pci0000:00/0000:00:0d.0/drm/renderD129
> calling: info
> P: /devices/pci0000:00/0000:00:0d.0/drm/renderD129
> N: dri/renderD129
> E: DEVNAME=/dev/dri/renderD129
> E: DEVPATH=/devices/pci0000:00/0000:00:0d.0/drm/renderD129
> E: DEVTYPE=drm_minor
> E: ID_FOR_SEAT=drm-pci-0000_00_0d_0
> E: ID_PATH=pci-0000:00:0d.0
> E: ID_PATH_TAG=pci-0000_00_0d_0
> E: ID_SEAT=seat1
> E: MAJOR=226
> E: MINOR=129
> E: TAGS=:seat:seat1:uaccess:
> E: WL_SEAT=seat1
> }}}

Peter already replied to the above.

> > Have you tried using the --seat command line argument to make Weston's
> > DRM-backend pick a seat other than the default "seat0"?  
> Okay, Weston drives "seat1" if given the option "--seat=seat1" and no 
> configuration file. But "seat0" where I start Weston freezes until 
> Weston terminates.

What do you mean by "freeze"? Black screen? Blank screen? Desktop, but
no reaction to any input? Does the clock update? Got a log from that,
does it open any input devices then?

> Why should I run "weston-launch" from a virtual terminal? I would like 
> to run it from "gnome-terminal".

You cannot run it from X, because the X server is already holding the
DRM master for the gfx card. The X server must release DRM master
before Weston can get it, and you do that by switching away from X's VT
or quitting X. DRM master status is required for controlling KMS
resources by the Weston DRM-backend.

Essentially, this way a random program cannot steal your gfx card away
from your desktop session.

If you want to run Weston from X, use 'weston' which will then open an
X window for Weston and it behaves like any X app, using the X11-backend.

> BTW, the option "--connectorid=card1-VGA-2" gives the "unhandled option" 
> error.

That's because the option is --connector, not --connectorid. The value
is also an integer, not a name.

> > You would be running an instance of Weston per each seat / gfx card.  
> It is an old dream of mine to attach all seats to 1 videocard. Is it 
> possible? If not, is this a limitation of Weston, Wayland, or Linux? I 
> mean, may 2 processes drive 1 videocard?

It is not possible. It is a limitation of DRM in the Linux kernel. It
does not implement splitting KMS resources of a single device to
several device nodes. A program that opens a device node gets exclusive
control of all KMS resources on that node by becoming "DRM master".
It's all or nothing.

Another solution would be to run a system compositor controlling all
heads, and then running one compositor per seat under the system
compositor. I think this is largely unimplemented in Weston as a system
compositor, though, particularly for the input side.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the wayland-devel mailing list