Multi-user DisplayManagement

From Tizen Wiki
Jump to: navigation, search

Introduction

Tizen requires a consistent model about how it will manage multiple displays, with regards to its Multi-user Architecture.


General model

The concept of seat, as it is used by the Weston compositor, represents a group of input devices.

By extension, and as Weston will statically associate these seats with displays at startup (depending on its configuration file), seats are often referred to as group of input devices + displays. Please note, however, that this is dependent on the actual integration choice, and technically incorrect.

User sessions are not associated with a particular seat ; nor are applications.


Expectations

If we take the case of UserA and UserB, Display1 and Display2 :

  • UserA chooses to launch an application, which will be initialized by the Application Framework, and positioned on a display (Display1 e.g.). UserA can then interact with it using the input devices (seat) associated with Display1 ;
  • UserB chooses to launch an application, which will be initialized by the Application Framework, and positioned on a display (Display2 e.g.). UserB can then interact with it using the input devices (seat) associated with Display2 ;
  • UserA and UserB cannot interact with each other's application.
  • Application Framework can move any App from one display to another
  • If allowed by its privileges a UserA can request the Application Framework to move one of its application from Display1 to Dislay2

(PS : this is currently WIP)


Using the multi-user version of Weston (Common)

The version of Weston provided in Tizen Common is adapted to a multi-user architecture. Most notably :

  • the compositor runs as a specific unprivilegied user named "display" ;
  • compositor access is shared among user sessions ;
  • at startup, 3 user sessions (alice, bob, carol) will automatically be started, and the corresponding launchers will appear on screen ;
  • by clicking on the launcher icons, you are actually launching application as the actual user, with his specific environment.
  • dragging a running application from Display1 to Display2 is possible.
  • dragging the launcher icons of a user to another Display will change the default Display of newly launched applications.


Associating input devices with displays in Wayland/Weston

Weston currently supports a static model, where any number or input devices (keyboards, mouses, touchscreens) can be grouped together as a seat, and then associated with one or more displays at startup.

Once associated with their displays, seats cannot interact with other ones any more. In the case of a mouse e.g., the pointer will be "prisoner" of its displays and cannot move to other displays.

One part of the configuration is made in Udev rules, the other part in a configuration file (weston.ini) read at startup.


Practical example

  • In "/usr/lib/udev/rules.d", create a new rule file (named, for example, "weston.rules") ;

Fill it will the the precise path of a Udev-compatible device, which will be associated to a static WL_SEAT variable :

ACTION=="add", SUBSYSTEMS=="input", DEVPATH=="/devices/pci0000:00/0000:00:1a.0/usb1/*", ENV{WL_SEAT}+="seat1"

(you can obtain Udev device paths from the "udevadm info --query=property --name=/dev/input/<device>" command)

Here, the first USB device -touchpad- will be associated to the seat1 group.

  • Reload the Udev rules :
$ udevadm control reload-rules
  • In "/etc/xdg/weston/weston.ini", create a [output] section which will associate the given display with a given seat  :
[output]
name=VGA1
seat=seat1
  • Restart Tizen.


Result

Notice that the configured input device can only interact (click, move...) with the displays it has been associated with.

Notice that another user, having access to this user's display, can move a window to it.

Notice that even in this case, the user can not interact with the window (because it is originating from a display for which the user's seat does not have "access").