I received no testing feedback from my last blog entry about multihead improvements for Plasma Desktop, which underscores the challenges we face with multihead support very nicely.
In any case, today I went through plasma-desktop and moved all the relevant code over to the new solution and committed all the changes to trunk. In theory this should improve plasma-desktop on multihead even further, with things like moving panels around with the mouse working as expected and what not.
Again: in theory, and I can't stress that enough. For those of us without multihead, the changes make zero difference as in the non-multihead case they are just small detours in the code that lead to the exact same calls that were being made previously, so there is quite literally no way of testing this beyond "Hey, it compiles, let's commit that." To know what the impacts are, we need people testing this.
These changes will not be a part of the 4.6beta1 release, but they should be part of beta2. Please install and test that if you have multihead and let me know how it goes.
Subscribe to:
Post Comments (Atom)
17 comments:
Thanks for working on this! multi-head support may not be the biggest essential for desktop support, but it does enable a lot of different workflows that can greatly improve productivity.
Partly prompted by your blogging (and partly prompted by the fact that my desktop gave up the ghost and I had an extra monitor), I decided to try multihead out on my laptop at work (which is running KDE SC 4.5).
It actually works fairly well, minus a strange glitch in which all my windows disappear until I kill plasma-desktop.
(My guess -- and this is just a guess -- is that the plasma-desktop window itself is covering the other windows. plasma-netbook works fine, but only on one screen).
I will have to give trunk a try to see if this issue is fixed now.
It's great to see that someone is working to improve multi-head support in KDE even when only a few people are using it. Thanks!
I'm very fortune to have two machines with multi-head installations. One at home and one at work. I would like to help out testing your modifications, if you let me know you to do it.
Thank you for you efforts on multihead systems. Indeed Plasma already behaves pretty good!
But:
get a build service for trunk for all mayor distributions. i'm willing to test, but compiling kde on a intel atom is just not what i'm gonna do!
Thanks. I was just about installing from trunk to test your last patch (sry had no time at the weekend to do this). Now I've read this post. I don't need to test the last patch anymore, right? Instead I will try your new multihead improvements in trunk. Because I don't want compile the whole trunk by myself, I will use the opensuse unstable build packages. Can you tell me what revision I have to use (just to be safe that the changes are already inside the packages)? Furthermore, can you tell me with simple words what improvments I have to expect (just to have a focus of what I have to test)?
Thanks for your efforts.
would like to test your patches.
My desktop box runs KDE-4.5.3 on Gentoo Linux, Intel i7 processor,
four heads (2 nvidia cards)
At the moment it runs kwin on all of them ( with a little trick )
but only one task panel on the first screen.
Previous patches I have compiled on kdebase-workspace taken form gentoo distribution.
Could you tell me from which place can I download your modified code ?
Regards,
Stan
Hi Aaron, thanks for the patches. I'm running trunk right now and it's working great: compared to 4.5.3, activities are working correctly and panels can be freely moved anywhere. There is just that small problem that plasma (and only plasma) is in english on the second display.
Great work!
Sorry for double posting. Maybe it is a kwin issue, but I'm not able to add widgets on the second screen, because the applet is positioned below the screen (probably because it has a lower resolution than the first one). I can see it "flying down" for an instant when I click on "Add widgets". Pretty much the same for the activities widget on the second screen.
Hi Robert!
I've heard about this project of you from the opensuse.org mail list!
First of all, congratulations for the work! Second, I've been using multi-seat and multi-head systems for about an year or two now, after I implemented them using a gdm 2.0 + Xephyr approach at my last job.
I'm really interested in doing it here, and a new solution based solely or partially on kde would be the best option for me! Unfortunately, at the moment the only machine that may be available for testing is my personal notebook, and I'm not quite sure if the card it holds can support it. I'll give it a try, but it it doesn't work it would just take me some extra time to start testing!
Anyway, I would still be in need of some kind of basic tutorial in order to properly implement the testing system, and port the configurations I'm used to do for the Xephyr + gdm 2.0 solution to kde. Could you please point me the basic instruction for me to the adaptations I will need to do?
Thanks and congrats again!
Sincerely,
Jones
4.6beta1 will be release tomorrow, but it will not have these modifications.
when beta2 comes out in a few weeks, please install that. most Linux distributions will have packages for the beta on the day it comes out, and the release will be announced in various places, including dot.kde.org.
once beta2 (or later) is installed, try things like adding and removing panels, moving them around, using plasmoids, etc.
feedback on both what is and is not working is valuable.
It looks quite optimistic. I haven't found any new bug but there are still bugs from KDE4.5.3
1. Labels gets on the second screen (always from right to left, from left to right it is correct)
http://yfrog.com/nebug1zj
2. Panel and panel menu can't be maximized (in the bottom position on the bigger screen)
Bottom position:
http://yfrog.com/dybug20j
Bottom position+Add Widgets
http://yfrog.com/08bug22j
Top position
http://yfrog.com/64bug23jj
PS: People, if you can try to confirm these bugs !! And also search for new ones.
I'll give it a shot when the beta comes out, my second monitor is a bit flaky these days so I don't use it as much as I once did.
@Michal: and you are testing using svn trunk from Nov 24th or newer?
the label placement probably is not addressed by these fixes, but the panel sizing should be.
I view this as falling into the same category as general desktop support items like printing and wireless/network management. I think first and foremost a good DE needs to have the basics in place before trying to create bling or random desktop items. But at the same time, these are things are are generally hard and as you put it, not really something often tested or loved.
@Roman Shtylman: "I view this as falling into the same category as general desktop support items like printing and wireless/network management."
i don't agree with this at all. multihead is a hack with few if any really defensible use cases. most of the time it comes down to odd hardware configurations and/or drivers that suck.
furthermore, the number of people who use multihead is absolutely miniscule compared to printing, which itself experiences smaller usage rates than networking.
calling a hack that extremely few people use "core" is a recipe to divert resources from things people actually do need or want into things that can wait and which, in the big picture, can be lived without.
(and in case anyone misses the nuance here: multihead is _not_ multiscreen or multiseat.)
"I think first and foremost a good DE needs to have the basics in place before trying to create bling or random desktop items."
your personal bias is getting in the way. if we lined up all the people for whom multihead actually matters, then all the people for whom "bling" matters, then all the people for whom those "random desktop items" (which is a phrase that wreaks of bias rather than analysis), we'd find that multihead is a tiny group next to far larger ones.
it's impossible to be everything to everyone, and it's almost as impossible to be what you can be instantly: one has to prioritize. and we try to do that based on a combination of what our users, as a group, are looking for, what tools they have to use in the meantime, etc.
@Aaron, I am sure some of my bias gets in the way :) But I personally don't have a problem with the kde multimonitor support for my use cases. I am actually happy with it. My point was more along the lines of considering the impact of adding more features into the desktop for users to interact with versus focusing on polishing out "supported" features. I would also note that while you may not feel that multihead support is important, more and more businesses (in my experience) have multiple monitor setups for their users (especially in the technology area). Monitors are cheap. But again I digress because I find that kde multimonitor support is better than most.
@Roman Shtylman: "more and more businesses (in my experience) have multiple monitor setups for their users"
i believe you are confusing different things here.
in my reply to your first comment i added this observation:
"(and in case anyone misses the nuance here: multihead is _not_ multiscreen or multiseat.)"
i have repeated this in my blog entries on multihead as well.
multihead (different x servers for different physical screens for one user session) is not the same as multiscreen (one x server with multiple physical screens for one user session) which is also different from multiseat (multiple x servers, each associated with a set of physical screens, for multiple simultaneous user sessions)
yes, multiscreen is very important due to its usage frequency. as such, we've had good support for it for some time now. it was something we worked on a lot in KDE3 and worked on quite early on in KDE Plasma.
multihead, which is what this is all about, is far less common (increasingly so over time as drivers improve, in fact) and has only a few uncommon edge cases as "valid" use cases.
so your critique would be accurate, but only if one confuses our prioritization of multihead with that of multiscreen. as such, your critique is not actually relevant; as i noted we do try (though of course we do not get to 100% efficiency) to prioritize based on both real and perceived value of feature sets amongst our user base.
(a rough equation for the value of a feature would be sum of (# of Users * Perceived Value) as Perceived value goes from 0 (not important at all) to 1 (critical feature set: without it, the software is not able to be used). easy to see that this would not be a number one can nail down with complete accuracy, but can be approximated pretty well with even moderate sample sizes. insert notions of sample biasing, etc, etc. couple with dynamics of open source development which is inherently more bottom up, etc.)
as Plasma Desktop matures more and more, resources become available to work on things fewer people value. e.g. multihead. which is what we see happening here.
@Aaron, sorry I also didn't know the correct different between multiscreen and multihead. So the bug I have reported here are connected to multiscreen !!!
I have used multihead 3 years ago and it is true that usability is really low. I even don't know if it works with modern drivers.
Post a Comment