screenmanagment review :-)

[Thomas Fjellstrom]

On Tuesday 02 September 2008, Aike J Sommer wrote:
> Hi,
>
> i have the feeling that my gsoc-project finally is in a state, in which it
> could be made ready for trunk... So i wanna get a discussion started on
> what still needs to be done or what should be changed! :-)
>
> The current state is:
> - there is a daemon (kephald) which will monitor xrandr events and change
>   configurations accordingly
>   - each set of connected monitors will be saved along with the last used
>     configuration for them
>   - if a known set of monitors is plugged in, that saved configuration will
> be loaded and applied to the monitors (that includes position, size, rate,
> rotation, reflection)
>   - if unknown monitors are plugged in a default configuration will be
> loaded - theres a library (libkephal) which wraps kephald's d-bus api,
> which is split in 3 parts:
>   1) screens: the individual areas available for apps, eg what plasma needs
>       for deciding where to put a desktop-containment
>   2) outputs: the actual outputs and its connected monitor, needed for
>       configuration of those
>   3) configurations: the configurations, these have a unique name and can
> be used for context
> - theres a dataengine, holding most of the available information from
>   libkephal, including jobs for actions like move, resize...
> - theres a (very basic) applet for managment of screens, it allows for:
>   - moving of an output
>   - resizing of an output
>   - reverting or confirming the change
>   - its not really well tested yet and still lacks lots of possible
> settings
>
> There is currently only support for xrandr 1.2, but xinerama support is
> already started locally... If xrandr is not available it will just fall
> back to using QDesktopWidget for screen-information, so it should still
> behave kind of sane!! ;-)
>
> My currently planned next steps would be:
>  - compile time checks for xrandr 1.2
>  - xinerama support
>  - maybe nv-control support
>  - work on the applet
>  - use as much of the applet as possible to create a kcm

I've been working on some multi monitor support for another open source 
project, and I have a few things to say:

AMD's fglrx and nvidia's drivers both only support XRandR 1.1 at best, and 
Xorg will erroneously wrap them into an incomplete 1.2 api. They do not 
actually return the right number of CRTCs or Outputs. Everything else is 
effected as well, including Xinerama, XF86VidMode, and nv-control (since nv-
control just uses nvidia's XRandR 1.1 support, they are both stuck with the 
same information).

It is currently impossible to implement a 100% complete working multimon app 
on any of the binary drivers. Nvidia currently "plans" to support XRandR but 
have no timetable for it, and they have been promising it "in the future" for 
over a year now. I have no idea what AMD plans for fglrx.

Basically, and machine with BigDesktop or TwinView enabled will only be able 
to fetch one CRTC and Output from XRandR. fakeXinerama will still output the 
size and relative position of each display, but only for the active mode. 
There is no way to get modes for the individual monitors as far as I can see.

> What would be needed in plasma:
>  - make plasma listen to libkephal's signaling about screen-changes instead
> of qdesktopwidget
>  - use the configuration-name for context
>
>
> There's also a techbase page, where i put some more infos:
> http://techbase.kde.org/Projects/Plasma/ScreenManagement
>
>
> Now... Would be nice to get as much input as possible... :-)
> One of my open questions would be: Should kephald be converted into a
> kded-module?
> And of course: What do or dont you like?
> What did i forget?
> What ideas do you have?
>
> :-)
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


-- 
Thomas Fjellstrom
tfjellstrom at strangesoft.net