Re: GSoC : Multiscreen management
On Sunday 04 April 2010 23:30:38 Zack Rusin wrote: On Sunday 04 April 2010 15:48:32 Sebastian Kügler wrote: 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 =) Nice analogy. :) displayconfig was actually written at a time when xrandr was rotate and resize, and nothing more than that. At least those bits worked, more or less reliably. Well, the resize at least. Often. :) 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 That sounds sensible, yes. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 5, 2010, Will Stephenson wrote: 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. hopefully this is already being taken into consideration, but just in case: one thing to keep in mind here is ensuring that x.org is set up asap when the desktop is started. we have had a number of bug reports related to issues that occur when the user logs in and x.org changes resolutions after the desktop is loaded. plasma-desktop tends to do just fine in these cases now-a-days, but it does add time and computation to the start up sequence. it would be great if we can guarantee that x.org is fully configured before plasma-desktop starts. if that means kicking off that configuration in plasma- desktop itself, so be it, but i'd personally prefer to see a separate process that is guaranteed to run first in the log in process (otherwise we end up duplicating this code in all the shells; though we do have libplasmagenericshell for that as well i suppose..) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Sunday 04 April 2010 22:24:11 Aaron J. Seigo wrote: On April 4, 2010, Detlev Casanova wrote: Is the current Kephal API correct ? i haven't done a thorough API review of it myself. using it has been quite straightforward. The only parts of Kephal currently in use are the Screens API and its associated ScreenUtils helper, though. there are some small things missing still, though, like being able to get the available screen geometry using a Kephal screen id. right now we have to go back to KWindowSystem for that; and while it works, it feels a bit inconsistent to have to mix Kephal and KWindwoSystem calls. I think that should be possible using Kephal's Output class. Can you point me to somewhere in the code where these are mixed What Aike said seems ok but it has to be well documented so people don't mix everything up. yes.. Note, I've just committed a fundamental reorganisation of the Kephal sources to make the code easier to understand. The build result is the same though. I've started to add some API docs and notes as I work through the code and get my head around it. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Friday 02 April 2010 14:13:03 Aike J Sommer wrote: Well.. A Screen is the logical area to which you can maximize a window for example, or which has a panel at the bottom! An output is the actual physical hardware / monitor... So, for each connector that appears when calling xrandr there will be one Output created, some enabled, some disabled... On my netbook those are VGA and LVDS, on my notebook something like VGA, LVDS and TMDS-1 and on my HTPC VGA and TV-1! How many Screens there are depends on your configuration: - If you have only one enabled Output, you will have one Screen with the same geometry - If you have 2 or more overlapping Outputs, one Screen will be created which spans all of those - If you have multiple non-overlapping Outputs, one Screen will be created per Output One of the ideas was to be able to configure even non-overlapping Outputs to be combined in one Screen, but that is not implemented... Hope that helps! Thanks, it cleared a lot of questions up. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Saturday 03 April 2010 21:04:33 Aaron J. Seigo wrote: On April 2, 2010, Will Stephenson wrote: Björn's description matches the xrandr model, but not the Kephal one. Xrandr 1.3 has a single Screen numbered 0 but does not support additional Screens; xrandr Screens are distinct from the screennumber in X's $DISPLAY, and multiple Screen support is being discussed again for xrandr 1.4 according to one of our local Xorg guys. while i have respect for the low level work that goes on in xrandr, i have no respect for their inability to create an API that is reliable and usable by application developers. they have changed definitions and even behaviours so many times with no compatibility efforts or warning often enough, and the makes-sense-to-driver- writers-but-is-incomprehensible-to-app-developers naming systems combines with that to lead me to concluce that there is no point or purpose in trying to track xrandr's terminology in our application facing API. that, really, should be the role of Kephal: to provide a sensible naming scheme, an API that does not jump around every N months underneath us and which is easy to use. so we only should care about how xrandr (and other systems, should we care to :) mates up with Kephal, and to ensure that Kephal gets that right. So, does that mean that Kephal would have to have backends to follow xrandr changing API ? Is the current Kephal API correct ? I never created an API :-) What Aike said seems ok but it has to be well documented so people don't mix everything up. A Screen might not feel like what it represents in xrandr but how would you name that ? I think about a Desktop and you could put your Desktop on multiple Outputs (Not Screen, a beamer's not really a Screen) Kephal has both multiple Outputs and multiple Screens in its model. A the definition of Screen is different between xrandr and Kephal. Kephal uses it to mean what app develpers think it means: it's a part of the whole output geometry that the user percieves as one screen. That's what I would have called an Output. everything else, for an application like plasma or kwin, is a detail. so, where this gets tricky is when we want to build a tool which allows the user to configure how the xrandr outputs/screens are configured. Kephal needs to allow this to happen (perhaps even throught a separate Controller API?) and the tool needs to be written for mortal users not xrandr developers. the nice thing about making the configuration tool use Kephal is it will put the developer in the right mindset and not get sucked into xrandr's accurate but useless for creating usable interfaces model (which is what we have right now). i'm not sure (have to look at it again) how much work will be needed in Kephal to get this going. I thought you meant that it was the way Kephal currently works when you wrote (which is what we have right now) Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 4, 2010, Detlev Casanova wrote: On Saturday 03 April 2010 21:04:33 Aaron J. Seigo wrote: On April 2, 2010, Will Stephenson wrote: Björn's description matches the xrandr model, but not the Kephal one. Xrandr 1.3 has a single Screen numbered 0 but does not support additional Screens; xrandr Screens are distinct from the screennumber in X's $DISPLAY, and multiple Screen support is being discussed again for xrandr 1.4 according to one of our local Xorg guys. while i have respect for the low level work that goes on in xrandr, i have no respect for their inability to create an API that is reliable and usable by application developers. they have changed definitions and even behaviours so many times with no compatibility efforts or warning often enough, and the makes-sense-to-driver- writers-but-is-incomprehensible-to-app-developers naming systems combines with that to lead me to concluce that there is no point or purpose in trying to track xrandr's terminology in our application facing API. that, really, should be the role of Kephal: to provide a sensible naming scheme, an API that does not jump around every N months underneath us and which is easy to use. so we only should care about how xrandr (and other systems, should we care to :) mates up with Kephal, and to ensure that Kephal gets that right. So, does that mean that Kephal would have to have backends to follow xrandr changing API ? and to be portable to other platforms. Is the current Kephal API correct ? i haven't done a thorough API review of it myself. using it has been quite straightforward. there are some small things missing still, though, like being able to get the available screen geometry using a Kephal screen id. right now we have to go back to KWindowSystem for that; and while it works, it feels a bit inconsistent to have to mix Kephal and KWindwoSystem calls. What Aike said seems ok but it has to be well documented so people don't mix everything up. yes.. A Screen might not feel like what it represents in xrandr but how would you name that ? I think about a Desktop and you could put your Desktop on multiple Outputs (Not Screen, a beamer's not really a Screen) first, i think we should stick with Kephal's current terminology. we already have code using it and changing it at this point is unlikely to win us very much, particularly since this API is just for kdebase/workspace/ (as opposed to kde-wide, which would make getting it right more important). Kephal has both multiple Outputs and multiple Screens in its model. A the definition of Screen is different between xrandr and Kephal. Kephal uses it to mean what app develpers think it means: it's a part of the whole output geometry that the user percieves as one screen. That's what I would have called an Output. an app developer looks at his computer and sees what everyone calls a screen. guess what they expect it to be called in the API? ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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. That said, I'd be super-glad if at multi-screen support, especially hotplugging would be improved in Plasma. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
Am 02.04.2010 12:06, schrieb Will Stephenson: On Friday 02 April 2010 00:09:01 Björn Ruberg wrote: I have to check the difference between Monitor, Screen, Display and Head or are those actually the same thing ? Monitor, Display and Head are probably the same - in Kephal they are named as Output. Screen ist actually something different. A screen can have several outputs ordered left to right. If you have two monitors with 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels and two outputs in it. One at position 0x0 and one at 1600x0. Aike, could you shed some light on this question? Or Aaron, if you have the overview of how Kephal works from mentoring Aike? Well.. A Screen is the logical area to which you can maximize a window for example, or which has a panel at the bottom! An output is the actual physical hardware / monitor... So, for each connector that appears when calling xrandr there will be one Output created, some enabled, some disabled... On my netbook those are VGA and LVDS, on my notebook something like VGA, LVDS and TMDS-1 and on my HTPC VGA and TV-1! How many Screens there are depends on your configuration: - If you have only one enabled Output, you will have one Screen with the same geometry - If you have 2 or more overlapping Outputs, one Screen will be created which spans all of those - If you have multiple non-overlapping Outputs, one Screen will be created per Output One of the ideas was to be able to configure even non-overlapping Outputs to be combined in one Screen, but that is not implemented... Hope that helps! :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 2, 2010, Will Stephenson wrote: Björn's description matches the xrandr model, but not the Kephal one. Xrandr 1.3 has a single Screen numbered 0 but does not support additional Screens; xrandr Screens are distinct from the screennumber in X's $DISPLAY, and multiple Screen support is being discussed again for xrandr 1.4 according to one of our local Xorg guys. while i have respect for the low level work that goes on in xrandr, i have no respect for their inability to create an API that is reliable and usable by application developers. they have changed definitions and even behaviours so many times with no compatibility efforts or warning often enough, and the makes-sense-to-driver- writers-but-is-incomprehensible-to-app-developers naming systems combines with that to lead me to concluce that there is no point or purpose in trying to track xrandr's terminology in our application facing API. that, really, should be the role of Kephal: to provide a sensible naming scheme, an API that does not jump around every N months underneath us and which is easy to use. so we only should care about how xrandr (and other systems, should we care to :) mates up with Kephal, and to ensure that Kephal gets that right. Kephal has both multiple Outputs and multiple Screens in its model. A the definition of Screen is different between xrandr and Kephal. Kephal uses it to mean what app develpers think it means: it's a part of the whole output geometry that the user percieves as one screen. everything else, for an application like plasma or kwin, is a detail. so, where this gets tricky is when we want to build a tool which allows the user to configure how the xrandr outputs/screens are configured. Kephal needs to allow this to happen (perhaps even throught a separate Controller API?) and the tool needs to be written for mortal users not xrandr developers. the nice thing about making the configuration tool use Kephal is it will put the developer in the right mindset and not get sucked into xrandr's accurate but useless for creating usable interfaces model (which is what we have right now). i'm not sure (have to look at it again) how much work will be needed in Kephal to get this going. i do know that there is already one such plasmoid out there that does screen configuration more elegantly than what we currently have, but i think it is also using xrandr directly atm? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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 :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 2, 2010, Detlev Casanova wrote: On Friday 02 April 2010 16:26:36 todd rme wrote: On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova detlev.casan...@gmail.com wrote: So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. There is also an issue with plasma were activities that end up on a monitor of the wrong size do not properly re-scale the widgets they contain, which can result in widgets overlapping, having unpredictable locations, extending off the screen, or having large blank areas. Fixing this would probably be a worthwhile task. Mmmh, I'm not using plasma activities but it's also to be checked, of course. yes you are: it's that thing sitting on your desktop ;) that said, i don't think it is in scope for this particular project. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 20:07:14 Chani wrote: On April 1, 2010 09:40:12 Björn Ruberg wrote: Hello, I fully agree with Detlev's points. The multiscreen management is very bad in KDE currently, although in KDE 4.4 it is a little better than in KDE 4.3. Every time I want to plug a beamer to my laptop in university I have to fight up to one minute getting every thing correct I have *very* little experience with multiscreen, but... how much of this is a distro or driver thing? Distro/driver is not important; the multiscreen features discussed above are simply missing even with a perfect driver/distro combination. when I plugged my tv into my laptop running arch, the video seemed to Just Work - I opened up krandr, set the new screen to the first resolution and there it was. later I thought maybe I wanted the other screen on top, so I tried that, and it worked too. when I tried the netbook reference thing, though, it didn't really want to obey the settings I chose. it just wanted to clone the laptop screen onto the tv screen. weird stuff happened as I fought with it... :/ I'm not saying multiscreen is in a *good* state, just that I had two very different experiences on different distros. The intel driver can cause this behaviour, since contemporary releases of different distros ship different X servers *and* different intel drivers, and intel's feature set varies from release to release. The intel driver in the openSUSE 11.2 build of Plasma Netbook Reference Platform is especially bad at detecting the correct native monitor resolution from the EDID. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Friday 02 April 2010 00:09:01 Björn Ruberg wrote: I have to check the difference between Monitor, Screen, Display and Head or are those actually the same thing ? Monitor, Display and Head are probably the same - in Kephal they are named as Output. Screen ist actually something different. A screen can have several outputs ordered left to right. If you have two monitors with 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels and two outputs in it. One at position 0x0 and one at 1600x0. Aike, could you shed some light on this question? Or Aaron, if you have the overview of how Kephal works from mentoring Aike? Björn's description matches the xrandr model, but not the Kephal one. Xrandr 1.3 has a single Screen numbered 0 but does not support additional Screens; xrandr Screens are distinct from the screennumber in X's $DISPLAY, and multiple Screen support is being discussed again for xrandr 1.4 according to one of our local Xorg guys. Kephal has both multiple Outputs and multiple Screens in its model. A screen owns zero or more Outputs, But it also seems that one Screen per output is created, looking at the usage of Kephal in KRunner, Plasma and KWin, which iterate, because they iterate the screens, react to screen added/removed signals, and use screen ids for panel and popup placement. If this is the case I'm not sure why there are both Screens and Outputs. Perhaps it's future-proofing for when xrandr supports multiple Screens. But if that is true, I don't know why Plasma and KWin react to Screen changes but not Output changes. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 21:28:38 Detlev Casanova wrote: On Thursday 01 April 2010 18:13:09 Will Stephenson wrote: On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote: What do you think ? All great features, but you should look at http://techbase.kde.org/Projects/Plasma/ScreenManagement Well, that's almost exactly what I had in mind :-) http://aike.me/site/blog/20090407/multihead_in_kde_422 This is more like a bug fixes list. But I see the idea of improving multihead management is at least 1 year old. That was Aike (the previous GSoC student)'s introduction. http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/ I'll have a look at it, but it seems to be exactly what I wanted to do. It doesn't _do_ everything it claims to do though. http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/ So you think another plasma widget than the device notifier should be used for monitors ? Is the Device Notifier widget only for mass storage devices ? I didn't say anything, just pointing out Aike's prototype UI plasmoid. I think these events should be displayed using Device Notifier. This was already the subject of a GSoC project in 2008, which was successful but stopped short of applying policies to restore previous configuration, doing KNotifications or events or providing UI to edit configurations. KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some SUSE patches to launch an improved version of the KRandR KCM, and does not use Kephal. But couldn't KRandR use Kephal eventually ? Yes. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova detlev.casan...@gmail.com wrote: So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. There is also an issue with plasma were activities that end up on a monitor of the wrong size do not properly re-scale the widgets they contain, which can result in widgets overlapping, having unpredictable locations, extending off the screen, or having large blank areas. Fixing this would probably be a worthwhile task. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Friday 02 April 2010 16:26:36 todd rme wrote: On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova detlev.casan...@gmail.com wrote: So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. There is also an issue with plasma were activities that end up on a monitor of the wrong size do not properly re-scale the widgets they contain, which can result in widgets overlapping, having unpredictable locations, extending off the screen, or having large blank areas. Fixing this would probably be a worthwhile task. Mmmh, I'm not using plasma activities but it's also to be checked, of course. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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 ? I'll keep asking about implementation issues while I'm looking how to do that and what's necessary to do that project. At first glance, it looks a bit light to make it as a GSoC but I can be wrong about that. By the way, I'm Cazou on IRC. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
GSoC : Multiscreen management
Hello folks ! I'd like to work with you this summer (and even longer after that :-) ). So, there's something in KDE that I find not really nice, It's the multiscreen management. For instance, I have an extra monitor for my laptop which I use every day but I also unplug it every day. The problem is that the screen configuration is never kept and sometimes, the screen is deactivated and KRandr says the screen is configured in 1980x1200... So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. If a configuration exists for a monitor when it's plugged in, the configuration should directly be applied with the monitor entry still in the device notifier (so that it can be modified). KRandr could also be more handy : the view could be used to move screens to place them at the wanted position (like a widget is moved on the desktop). What do you think ? I already posted the idea on #plasma but had to leave before you could answer so, it might feel familiar. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. Cheers, Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova detlev.casan...@gmail.com wrote: So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. I might also suggest a quick-config system that allows you to select common configurations (display 1 only, display 2 only, clone displays, side-by-side). This could also be triggered with the laptop's change screen configuration keyboard combo (often Fn+F#, where F# is an F1-F12 key that depends on the laptop). In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. This would be extremely useful. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. The size of the problem is basically NVidia does not support randr at all and may never support it. They have been promising for years that it is a has-priority task and that it is coming very soon, but late last year they admitted that it wasn't actually ever a priority and there are no real firm plans to implement it ever and there never were. So if you want support for nvidia cards you will need to integrate with NVidia's own tools. There is a third-party command-line tool called disper that is supposed to replicate some of the features that randr has: http://willem.engen.nl/projects/disper/ -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote: I'd like to work with you this summer (and even longer after that :-) ). So, there's something in KDE that I find not really nice, It's the multiscreen management. For instance, I have an extra monitor for my laptop which I use every day but I also unplug it every day. The problem is that the screen configuration is never kept and sometimes, the screen is deactivated and KRandr says the screen is configured in 1980x1200... So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. If a configuration exists for a monitor when it's plugged in, the configuration should directly be applied with the monitor entry still in the device notifier (so that it can be modified). KRandr could also be more handy : the view could be used to move screens to place them at the wanted position (like a widget is moved on the desktop). What do you think ? All great features, but you should look at http://techbase.kde.org/Projects/Plasma/ScreenManagement http://aike.me/site/blog/20090407/multihead_in_kde_422 http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/ http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/ This was already the subject of a GSoC project in 2008, which was successful but stopped short of applying policies to restore previous configuration, doing KNotifications or events or providing UI to edit configurations. KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some SUSE patches to launch an improved version of the KRandR KCM, and does not use Kephal. I feel the same itch as you do and have spent the last couple of days getting into the Kephal code - it's been hardly touched since 2008 and could do with a clean up, so I'll see how far I get with it over the weekend. Aaron, do you think there's another GSoC project in completing Kephal? I already posted the idea on #plasma but had to leave before you could answer so, it might feel familiar. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. I know the disper tool tries to abstract both systems, but haven't used it. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
Hei, i would just like to add my support for that idea, because as of kde 4.4, my second screen has no more wallpaper (plasma) and if i set dragonplayer to fullscreen on it, it goes to the first screen (kwin?). this is sadly with the nvidia driver. It would be great to have a more robust multiscreen support. Even if this is probably not the scope of the project, there are quite alot of plasma bugreports about multiscreen bugs, perhaps a few might get fixed during that project? greetings beat wolf Am Donnerstag 01 April 2010 16.35:59 schrieb Detlev Casanova: Hello folks ! I'd like to work with you this summer (and even longer after that :-) ). So, there's something in KDE that I find not really nice, It's the multiscreen management. For instance, I have an extra monitor for my laptop which I use every day but I also unplug it every day. The problem is that the screen configuration is never kept and sometimes, the screen is deactivated and KRandr says the screen is configured in 1980x1200... So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. If a configuration exists for a monitor when it's plugged in, the configuration should directly be applied with the monitor entry still in the device notifier (so that it can be modified). KRandr could also be more handy : the view could be used to move screens to place them at the wanted position (like a widget is moved on the desktop). What do you think ? I already posted the idea on #plasma but had to leave before you could answer so, it might feel familiar. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. Cheers, Detlev. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
Hello, I fully agree with Detlev's points. The multiscreen management is very bad in KDE currently, although in KDE 4.4 it is a little better than in KDE 4.3. Every time I want to plug a beamer to my laptop in university I have to fight up to one minute getting every thing correct - and the other students using MacOS or Windows laugh at me. KDE and Linux makes no good impression concerning multi screens - and that is no special feature but one that is much needed everywhere and everyday. The problem for me is not the intel-driver. I can get everything as I want with xrandr. It is a interface problem! I wrote some mails about this on kde-devel half a year ago and wanted to do a plasmoid myself. Sadly I have not the free time to do such a project on my own as long the underlying libarys are not in better shape. My own screen management plasmoid is here: http://websvn.kde.org/trunk/playground/base/plasma/applets/screen_control/ Add this to Wills list of related work :) It uses Kephal just for reading in data - for actually changing anything it makes command line calls to xrandr. That may sound ugly but it works - at least it works much better than kephal does in changing screen configuration. If Kephal would not only be useable for finding out your screen configuration but could actually change it, I'm quite confident I would bring this applet in a good and working shape. So, it would be great if Kephal could become a GSOC project. Even if proprietary nvidia drivers would not work (what may be worked around by an abstraction layer) it would be a great improvement. In the current state you have no good time with multiple screens in KDE with any driver you can use. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 1, 2010 09:40:12 Björn Ruberg wrote: Hello, I fully agree with Detlev's points. The multiscreen management is very bad in KDE currently, although in KDE 4.4 it is a little better than in KDE 4.3. Every time I want to plug a beamer to my laptop in university I have to fight up to one minute getting every thing correct I have *very* little experience with multiscreen, but... how much of this is a distro or driver thing? when I plugged my tv into my laptop running arch, the video seemed to Just Work - I opened up krandr, set the new screen to the first resolution and there it was. later I thought maybe I wanted the other screen on top, so I tried that, and it worked too. when I tried the netbook reference thing, though, it didn't really want to obey the settings I chose. it just wanted to clone the laptop screen onto the tv screen. weird stuff happened as I fought with it... :/ I'm not saying multiscreen is in a *good* state, just that I had two very different experiences on different distros. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 1, 2010, Asraniel wrote: Hei, i would just like to add my support for that idea, because as of kde 4.4, my second screen has no more wallpaper (plasma) and if i set dual head? or is the second screen just not being seen at all? can you provide some debug output from plasma-desktop regarding the scren setup process? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 18:13:09 Will Stephenson wrote: On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote: I'd like to work with you this summer (and even longer after that :-) ). So, there's something in KDE that I find not really nice, It's the multiscreen management. For instance, I have an extra monitor for my laptop which I use every day but I also unplug it every day. The problem is that the screen configuration is never kept and sometimes, the screen is deactivated and KRandr says the screen is configured in 1980x1200... So, my point is : there are problems. So far, what's the link with plasma you might ask. Well, I'd like the device notifier to react when a monitor is plugged in, showing the screen. 2 actions should be possible : Auto configure and manual configuration. - Auto configure would try to find the best configuration depending on the screen capabilities (read resolutions). - Manual configuration would open KRandr. In KRandr, there should be a possibility to keep configurations depending on the plugged device : I'd like the university projector to be on the right of my laptop screen. I'd like my 26 screen to be a clone of my laptop screen. If a configuration exists for a monitor when it's plugged in, the configuration should directly be applied with the monitor entry still in the device notifier (so that it can be modified). KRandr could also be more handy : the view could be used to move screens to place them at the wanted position (like a widget is moved on the desktop). What do you think ? All great features, but you should look at http://techbase.kde.org/Projects/Plasma/ScreenManagement Well, that's almost exactly what I had in mind :-) http://aike.me/site/blog/20090407/multihead_in_kde_422 This is more like a bug fixes list. But I see the idea of improving multihead management is at least 1 year old. http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/ I'll have a look at it, but it seems to be exactly what I wanted to do. http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/ So you think another plasma widget than the device notifier should be used for monitors ? Is the Device Notifier widget only for mass storage devices ? This was already the subject of a GSoC project in 2008, which was successful but stopped short of applying policies to restore previous configuration, doing KNotifications or events or providing UI to edit configurations. KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some SUSE patches to launch an improved version of the KRandR KCM, and does not use Kephal. But couldn't KRandR use Kephal eventually ? I feel the same itch as you do and have spent the last couple of days getting into the Kephal code - it's been hardly touched since 2008 and could do with a clean up, so I'll see how far I get with it over the weekend. Aaron, do you think there's another GSoC project in completing Kephal? I already posted the idea on #plasma but had to leave before you could answer so, it might feel familiar. I know though that there are problems with xrandr and some drivers, like the NVidia driver. I'm not sure how big are the problems but interfacing with the NVidia tools is maybe possible. I know the disper tool tries to abstract both systems, but haven't used it. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 18:40:12 Björn Ruberg wrote: Hello, I fully agree with Detlev's points. The multiscreen management is very bad in KDE currently, although in KDE 4.4 it is a little better than in KDE 4.3. Every time I want to plug a beamer to my laptop in university I have to fight up to one minute getting every thing correct - and the other students using MacOS or Windows laugh at me. KDE and Linux makes no good impression concerning multi screens - and that is no special feature but one that is much needed everywhere and everyday. Yes, I've had that problem. The problem for me is not the intel-driver. I can get everything as I want with xrandr. It is a interface problem! I wrote some mails about this on kde-devel half a year ago and wanted to do a plasmoid myself. Sadly I have not the free time to do such a project on my own as long the underlying libarys are not in better shape. My own screen management plasmoid is here: http://websvn.kde.org/trunk/playground/base/plasma/applets/screen_control/ Add this to Wills list of related work :) I'm not sure having multiple places where you can configure the same thing is a good idea. Also, I think that Plasma Widgets shouldn't be configuration interfaces. But it's only what I think, and people usually love widgets on theyr desktop :) It uses Kephal just for reading in data - for actually changing anything it makes command line calls to xrandr. That may sound ugly but it works - at least it works much better than kephal does in changing screen configuration. If Kephal would not only be useable for finding out your screen configuration but could actually change it, I'm quite confident I would bring this applet in a good and working shape. Centralizing everything in on library (Kephal for instance), is IMHO a good idea. So, it would be great if Kephal could become a GSOC project. I think so too :-) Even if proprietary nvidia drivers would not work (what may be worked around by an abstraction layer) it would be a great improvement. In the current state you have no good time with multiple screens in KDE with any driver you can use. It would be great to have something that works with friendly drivers first. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
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) I also recently found some bugs with that icon (apparently not always showing all plugged in monitors to configure them) I have to check the difference between Monitor, Screen, Display and Head or are those actually the same thing ? I'm obviously really interested in that project, that's how I thought things should work except that I did not know about Kephal (even though I remember hearing about it but not really care at that time) Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
I have to check the difference between Monitor, Screen, Display and Head or are those actually the same thing ? Monitor, Display and Head are probably the same - in Kephal they are named as Output. Screen ist actually something different. A screen can have several outputs ordered left to right. If you have two monitors with 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels and two outputs in it. One at position 0x0 and one at 1600x0. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
