GSoC : Multiscreen management

[Zack Rusin]

On Sunday 04 April 2010 15:48:32 Sebastian Kügler wrote:
> On Saturday 03 April 2010 21:06:00 Aaron J. Seigo wrote:
> > On April 2, 2010, Detlev Casanova wrote:
> > > On Thursday 01 April 2010 20:15:40 Aaron J. Seigo wrote:
> > > > On April 1, 2010, Will Stephenson wrote:
> > > > > Aaron, do you think there's another GSoC project in completing
> > > > > Kephal?
> > > >
> > > > yes, particularly on the storing / restoring of configurations and
> > > > integrating it with the existing UI elements (device notifier and
> > > > providing a more user- friendly alternative to the current kandr
> > > > icon, which is highly functional but also tricky to use)
> > >
> > > Ok, Can I write a proposal for this then ?
> >
> > imho: +1 on that.
> >
> > > At first glance, it looks a bit light to make it as a GSoC but I can be
> > > wrong about that.
> >
> > honestly, i think there will be enough to keep you busy for an entire
> > GSoC.  besides getting a plasmoid up to snuff there will be Kephal work
> > that needs to be done. getting thoe workflows as elegant as possible can
> > take as much time as we can throw at it :)
> 
> Having done this myself a couple of years ago (and being one of those who
>  got burnt by the ever-changing monster that is X configuration and
>  therefore eventually gave up on the idea. (Google for "guidance
>  displayconfig" if you want to see how far we got). BTW, did you know that
>  the upcoming release of X Server again changes configuration options!?), I
>  can tell you one thing: It will not be easy, especially not if you want it
>  to work with different drivers (and possibly different versions at that).
> 
> The amount of opportunities to tear your hair out in X.org land is near
>  inifinite.

Well, it's a lot like feeding a tiger - it's not that really difficult, it's 
just a bit dangerous especially if you try to stuff the food down the wrong 
hole. As you seemed to have been doing =) 

It's worth to remember that X should be policy less, what and how it does 
should really be done higher. You never want to change the X config, especially 
nowadays when the there's really nothing there worth changing and it's not 
like "hey, you've just started kpresenter, please restart X so that new output 
config can take be in effect " is a good strategy anyway.

The output config should be stored as part of the KDE config (Kephal I guess), 
and when I say output config I mean "when an output with this identifier (and 
maybe even this exact edid) is connected we should do A" where A is mirroring, 
setting up a new screen, doing nothing or doing whatever user picked the first 
time this action was performed. Once you know what you want to do, you simply 
use xrandr to actually do it.

z