GSoC : Multiscreen management

[Will Stephenson]

On Sunday 04 April 2010 23:30:38 Zack Rusin wrote:
> 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)

+1, and this is where KDE really falls behind the competition now that fewer 
Xorgs have fixed configuration files, and we don't have store/restorable X 
configuration in the user session.

> , 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.

This is what Kephal set out to do, has code for but does not actually achieve 
yet.

Will