Projects/Plasma/ScreenManagement

Architecture

The management of multiple screens and hot-plug thereof will make extensive use of XRandR 1.2, there should be a fallback mechanism for systems not supporting it though. For the client (ie Plasma, but also others) this should be completely transparent, so the API needs to be designed to be able to give all information it can get, but also act sensible when there is little or no information about the screen configuration available.

The system should offer a set of configurations/profiles which will be autoselected depending on the pugged devices. Clients should be able to easily change the used configuration, which will then be remembered for the next time these devices are plugged in.

Configuration

The configuration for this might look like the following. The ideal solution would be to agree with the Gnome-folks on one config-spec. This is just a real quick, first draft, so feel free to comment as much as you feel like!

<configuration name="single">

   <screen id="0">
   </screen>

</configuration> <configuration name="presentation">

   <screen id="0">
   </screen>
   <screen id="1">
       <privacy>true</privacy>
       <right-of>0</right-of>
   </screen>

</configuration> <configuration name="extended-right">

   <screen id="0">
   </screen>
   <screen id="1">
       <right-of>0</right-of>
   </screen>

</configuration> <configuration name="clone">

   <screen id="0">
   </screen>
   <screen id="1">
       <clone-of>0</clone-of>
   </screen>

</configuration>

<outputs configuration="single">

   <output name="TMDS-1">
   </output>
   <output name="LVDS" screen="0">
       <vendor>X</vendor>
       <product>0x1234</product>
       <serial>0x12345678</serial>
       <width>1280</width>
       <height>800</height>
       <rate>60</rate>
       <rotation>normal</rotation>
       <reflect_x>no</reflect_x>
       <reflect_y>no</reflect_y>
   </output>
   <output name="VGA">
   </output>

</outputs> <outputs configuration="presentation">

   <output name="TMDS-1">
   </output>
   <output name="LVDS" screen="0">
       <vendor>X</vendor>
       <product>0x1234</product>
       <serial>0x12345678</serial>
       <width>1280</width>
       <height>800</height>
       <rate>60</rate>
       <rotation>normal</rotation>
       <reflect_x>no</reflect_x>
       <reflect_y>no</reflect_y>
   </output>
   <output name="VGA" screen="1">
       <vendor>Y</vendor>
       <product>0x9876</product>
       <serial>0x98765432</serial>
       <width>1024</width>
       <height>768</height>
       <rate>60</rate>
       <rotation>normal</rotation>
       <reflect_x>no</reflect_x>
       <reflect_y>no</reflect_y>
   </output>

</outputs> <outputs configuration="extended-right">

   <output name="TMDS-1" screen="0">
       <vendor>Z</vendor>
       <product>0xABCD</product>
       <serial>0xABCDEF01</serial>
       <width>1680</width>
       <height>1050</height>
       <rate>60</rate>
       <rotation>normal</rotation>
       <reflect_x>no</reflect_x>
       <reflect_y>no</reflect_y>
   </output>
   <output name="LVDS" screen="1">
       <vendor>X</vendor>
       <product>0x1234</product>
       <serial>0x12345678</serial>
       <width>1280</width>
       <height>800</height>
       <rate>60</rate>
       <rotation>normal</rotation>
       <reflect_x>no</reflect_x>
       <reflect_y>no</reflect_y>
   </output>
   <output name="VGA">
   </output>

</outputs>

Most of this should be rather self-explanatory (at least to me ;-) ). Just a few quick explanations:

• The naming is basically just supposed to reflect the naming in xrandr.
• The element <privacy>true</privacy> should inform the window-manager not to open any windows on that screen, as it would be a little annoying if any notification of new messages or similar would pop up on the projector during a presentation.
• The screen "0" should always be the primary screen.
• The numbering of the screens is important for ie Plasma to load up the right Containment on the right screen.

What this leaves open for now:

• What set of configurations will be shipped?
• Will it be possible create new configurations for the user?
• Will it be possible to change or even delete shipped configurations?
• When the user selects to change the positions of his screens, should this switch or modify the configuration?

Defaults

If it's possible to detect the type of plugged device, ie projector or plasma-tv ;-) the configuration could be extended to include defaults like this:

<outputs configuration="presentation">

   <output name="LVDS" output="0">
       <type>*</type>
   </output>
   <output name="*" output="1">
       <type>projector</type>
   </output>

</outputs>

Forcing outputs

For setups where the hardware/driver can not detect a device to be plugged in it might be necessary to force a certain output to be activated and to some mode. That could look like:

<configuration name="tv">

   <screen id="0">
   </screen>
   <screen id="1" force="composite">
       <privacy>true</privacy>
       <right-of>0</right-of>
   </screen>

</configuration>

<force name="composite" output="Composite">

   <width>768</width>
   <height>576</height>
   <rate>50</rate>
   <rotation>normal</rotation>
   <reflect_x>no</reflect_x>
   <reflect_y>no</reflect_y>

</force>

This could of course not be auto-selected, but would make it a lot easier for user to activate devices if needed.

Base-Component

There should be a base-component, that will take care of the followings tasks:

• On startup check the connected devices and select a matching configuration.
• Publish informations such as primary or private
• Listen to XRandR events and switch configurations accordingly.
• Allow clients to select for what kind of events they want to be notified
  • Screen added/removed
  • Screen resized
  • Screen position changed
  • Rate changed
• Dispatch notifications to the clients
• Allow clients to change the selected configuration

This component should be able to fallback to XRandR 1.1/Xinerama if XRandR 1.2 is not available. Maybe it should even be able to fallback to using Qt's QDesktopWidget as its only source for information, that should allow this component to be used on all platforms. In that situation there would be no modifications possible, but it might still be interesting for applications that need to be informed of some screen-events.