Hello,

i finally managed to get on this list!! ;-)


> > > what's the kephal maintainer's position on this?
> >
> > I think this is a deliberate design. In theory this could make different
> > setups autodetectable (imagine laptop on the road or laptop on the desk).
> >  The real problem is that the backend code is active while the frontend
> >  that would make it really useful is still missing. Autodetecting based
> > on predefined profiles that the user can not control is potentially buggy
> > at best, and deliberately destructive at worst.

You are right, there is no such frontend yet. For this reason all presets 
default to a configuration called "external". This configuration changes 
nothing, being basically a read-only configuration.
So unless you manually changed things in the configuration you should not see 
any problems from autodetecting or similar.

> >
> > Fortunately I think krandrtray which does not use kephal is loaded later
> >  and does our current randr layout, undoing anything weird kephal might
> >  have done. Kephal is however still reporting information based on its
> > own selected profile, if that profile does not match reality,
> > applications using data from kephal will have a wrong picture of how the
> > desktop is configured.

Kephal listens to Xrandr-events and updates it's internal state, so in theory 
you should always get up-to-date information. If this is not the case please 
tell me or open a br about that issue.
On some systems Kephal will actually fall back to using QDesktopWidget instead 
of XRandR, and QDW misses changes in some situations.

>
> > Some of the bugs are also caused by other applications using Kephal in a
> >  wrong way. For instance to detect if multiple screens are attached to
> >  provide actions to activate them or use them. Kephal is however not
> >  reporting hardware details it is only reporting the current selected
> >  kephal configuration. If kephal has selected a 1 screen configuration
> > for a dual-headed setup, kephal is reporting the setup has 1 screen.
>
> interesting; and broken sounding.
>
> if kephal maintains this position, which i can see as being useful as a way
> to shield most apps from the more complex (and irrelevant to them) reality
> under the hood, we will need to add some API to it that also provides
> information on what's actually there.

That's exactly the reason for having Screens and Outputs in the API. The 
Screen is the logical thing to which a window can be maximized or which a 
panel belongs to.
An Output is the physical unit representing your (possibly) connected monitor.

So in a clone-layout with monitors running at 1024x768 and 1024x600 you will 
get only one screen at 0x0+1024+768, but 2 outputs being both active with 
0x0+1024+768 and 0x0+1024+600.
While in a left-of / right-of layout, you will have 2 screens at 0x0+1024+768 
and 1024x0+1024+600 for example!

>
> > > > I've been trying to fix multiscreen support in kwin and kephal, and
> > > > the only sensible solution I can come up with is removing kephal or
> > > > at least stop using it anywhere.
> > >
> > > without a replacement, not using it isn't an option. fewer things are
> > >  broken, at least for our use cases in plasma, than before we had it.
> > > if there are things that need fixing, let's identify and fix them. but
> > > let's move forward rather than backward or sideways.
> >
> > Which is why I haven't complained about it before. There was an
> > alternative discussed in this thread, and I am merely pointing out that
> > kephal in its current state is not a good argument against new projects
> > in the same field.
>
> true enough; hm. we should find some time on irc to sit together and work
> through some ideas for kephal, pref with their developers.

Just tell me when... ;-)

Aike
:-)

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<