Multihead, where there is more than one physical screen and one X server per physical screen (not to be confused with xinerama, xrandr, mergefb, etc.), and Plasma Desktop is getting into a rather usable state thanks to testing and feedback from users with those systems that goes beyond "it doesn't work". Thanks to the digging and debugging work of several individuals, my "coding in the blind" has produced finally produced useful results as of the 4.5.3 release. There are still some KWin issues, apparently, but plasma-desktop is pretty well there.
Today I added a boolean multihead variable to the Plasma Desktop Scripting, and yes it is documented. This allows scripts, should they need to, do different things in a multihead setup.
There are some unique annoyances with multihead, though. For instance, when enumerating the screens with Kephal it will report that there are N screens, but each the origin point of the geometry of each screen will be (0,0) meaning that it looks like they overlap, even thought they don't. This leads to some awkward behavior both in the initial layout set up as well as things like repositioning panels on screens other than the first one. Nothing fatal, but not optimal either.
An approach occurred to me today that might make this easier to handle: make plasma-desktop's Corona "lie" when in multihead mode and say it has just one screen and map screen "0" to the real screen id transparently behind everything's back. It's a bit of a hack, but so is multihead. ;)
I have no idea how well this works due to not having a system to test it with, though in theory it should be an improvement. What I need are people with multihead systems who are running trunk to try this patch to plasma-desktop and report back what happens. I expect that it does nothing for the panel moving issue, but other things should improve or at least not degrade. If that is the case, then fixing the panel moving issue becomes trivial by extending this approach there as well.
Please test if you can and let me know on plasma-devel at kde.org or in a comment on my blog here. Cheers.
Subscribe to:
Post Comments (Atom)
22 comments:
Hi Aaron,
I read the title as multi-threaded and vaguely remembered that you had mentioned sometime ago that Plasmoids did not get their own process in order to save on memory.
So was wondering whether it would be possible to use something like KSM (kernel samepage merging) on plasma in order to run multiple plasmoids in their own process.
Sorry to hijack your post :)
Cheers,
Pete
Sorry if ask: why are you unable to test? Are you missing a "spare display"? In that case me and probably other people will be very pleased to help you buying such a device: a 22" monitor now costs well under 200$!
I hope someone wise would write to kde userbase about those multiple different changes what is what multihead system and making in the start a very nice graphic explaining them.
I do not know well at all what are all possible multi-monitor setups with Xorg. But I made this example what
http://imagebin.ca/view/onLCz8jO.html
What I have always wanted is the multihead desktop environment where I can have one Plasma Desktop instance running but different (or same) virtual desktops/activities on different screens.
Why is it not possible to test using nested X servers, like described in e.g. http://movingparts.net/2008/09/25/a-poor-mans-multi-monitor-setup-on-a-single-physical-head/
You are the second KDE developer to blog, "I don't have the hardware". Perhaps KDE could set up a site where official developers could register hardware wishlists and things it would assist on.
I think it could be nice to have a developers wish-list for demanded harware.
Like Aaron could have maded a wish to rise money to get a dual-screen setup.
A Krita developer could have wish to have a tablet/scanner.
KOffice developer to have a OCR supported scanner.
KDE Partitionmanager developers to have a RAID card.
And so on...
It could be official by that the developer writes for what need it is. What device it would be about and why.
And even that after got the device, it could be even signed with somekind official "Part of the KDE" sticker and sell away. (But I think the developer would then later deserve the device as he/she has helped the community. Those who rised money to the wish would gain names to the software supporting).
That way it would be nice to see a device list with the fund rising amount, like "62 euros from 75" with nice bar.
Of course the developer would need to find out the safe and cheap place where to buy it. And KDE Ev could get the money and buy the device for the developer.
So I like very much your idea xenoterracide!
Since I have three monitors attached to my computer of which one will eventually be used as a separate "workstation" i.e. watching movies in the room nearby i'll configure multihead and test your patch.
My company provides small office companies with computers running kde and we want the best user experience for them. And some wish a dual monitor configuration and stuff, maybe we can arrange a donation of a second monitor. Stay tuned :)
Ah, took me a second to figure out what was meant here. I actually have two video cards, each with their own X session and monitor. So it might technically be multihead, but in reality its multiseat since its for my girlfriend and myself to use at the same time. So we each have our own user, keyboard, mouse etc.
Anyways, multiseat works fine with Plasma I can attest. :)
@Pete: "was wondering whether it would be possible to use something like KSM (kernel samepage merging) on plasma in order to run multiple plasmoids in their own process."
besides KSM being Linux specific (which is a detail we can ignore for this discussion :), it really isn't getting data to be shared that's the problem.
the problem comes in the form of synchronizing events (input and paint) which would be extremely non-trivial to do.
we'd also end up passing around handles to large pixmaps representing the individual plasmoids and compositing those back together in the "main" process, which would be very bad performance wise but which we'd have no real choice since all Xorg stuff is "one thread and one thread only". so we'd have to lock resources, pass them by handle between processes, trigger repaints .. and that's all before it gets to the "stitching it back together in the main process" fun. gah.. very ugly.
i outlined a workable path forward here:
http://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.html
basically, we need to transition Plasma components 100% to QML, put QSceneGraph behind QML and then we can do all of this with OpenGL directly. not only will performance skyrocket with the current design, but it opens up all sorts of new possibilities because OpenGL, unlike X11, is designed for hardcore graphics processing. multithreaded rendering with QSceneGraph works just fine, for instance.
it's not a short distance to there, but it is doable. i'm giving us 2 years. :)
@Diego: "why are you unable to test? Are you missing a "spare display"?"
i have a spare display sitting right next to me. i even have a laptop on the desk behind me running a dual screen setup with xrandr. that's not the problem.
the problem is that i don't _use_ multihead.
which means to test it i need a separate set up, which means time spent in Xorg configuration management. i really don't have the time to test multihead like that. it's much more sensible if people who actually already have such setups test. distribute the workload, it's the only way we are able to make progress at the pace we do with so few resources to apply.
there's also the issue that because i don't use multihead, i won't actually put it through its paces properly. i need this tested with real world multihead workflows. as i don't use multihead (last time i did was in the year 2002, iirc), i have no real idea what those would be.
so even if i did have a set up for multihead, i'd probably end up starting it up, playing with things for 15-20 minutes and calling it good. that's really not what we need :)
so it needs people with multihead helping out. and if people with multihead can't be bothered to pitch in, neither can i.
open source gets away without formal testing and Q/A groups not by avoiding testing and Q/A but by having less formal testing and Q/A groups.
in this case, my informal Q/A group is lacking someone for multihead. well, that's not entirely true: on bugs.kde.org i now have a few testers who have been really helpful. and that's only because i am asking for that help instead of trying to do everything myself.
@Stefan: that's not multihead, that's multiscreen. see the first sentence in my blog entry :)
@xenoterracide, @Fri13: while such a hardware donation system is not relevant here (because it's not the problem in this case), i do think that it would be useful in the general case.
while i was still on the board of KDE e.V. i proposed such a thing. but it never took off due to not having the manpower to put to it.
i think the only way it could work is if we found someone in Berlin (where our offices are, and thus where the hardware would go in and out of) could volunteer to help run the program.
@Kai Uwe: thanks, that testing will be highly welcome.
@Ian Monroe: yes, multi-seat does work, which is good. as does multi-screen.
multi-head .. that's the beast. mostly because few people use it and it's such a bloody hack.
Just for clarity, when not using an Xorg config file and setting up a second monitor via KDE's System Settings, that would be multi-screen, correct? Or could KDE configure X either way?
@TemporalBeing: yes, that's multi-screen, usually via xrandr.
@Aaron - Thanks for the detailed explanation! It makes sense now :)
Out of curiosity, what would it cost and how long would it take if someone was to sponsor those Plasma improvements (switch to qml / scene graph etc)?
I'm unfortunately not in a position to help in this way, just wondering what it the price would be to get those remaining rough edges polished off in kde within say a years timeframe or so?
Not to in anyway imply that you guys aren't doing a fantastic job, I love to watch the progress and have been using kde since 4.2. Keep it up!
@Pete: having 2 people who are familiar with Plasma working on the QML transition full time would probably enable us to do a very good job of it within two 6-month releases.
without that, i expect it will take twice as long and the results may not be as comprehensive.
Oh, really wouldn't it be nice to have a KDE app to set up X for us,both for multi-screen (randr, since krandr doesn't seem to allow enough (cannot drag the screens into position, for example)), a tool to set up multiuser scenarios, and that same tool to set up for multihead? Allowing the user to pick the driver to use, the hardware to use, the layout to use...
I know, its an Xorg issue, right? But the're not doing anything about it.
Anyone have tips on where to go to start with this, getting the multihead part started?
Thanks for the work on this, Aaron!
For example bug 248916 is connected to multihead and should be easily fixed.
It is one of examples of bugs how it can end when someone write code for multihead and don't use it ....
@michal: "For example bug 248916 is connected to multihead and should be easily fixed."
indeed that is a good example.
i don't think it will last for long, though, as it is one of the effects that will be fixed once i migrate the panel controller to use the approach in the patch lined to in this blog entry.
you are quite right, though, that these will get picked up quickly (and probably fixed equally quickly) by someone who actually uses multihead. hopefully someone will join the Plasma Workspace team to fill this gap. if 'all' they did was look after the multihead support (which wouldn't involve much: once it is working, it's just a matter of watching out for regressions which happen pretty rarely in this particular code) that would be an awesome contribution to KDE.
"i think the only way it could work is if we found someone in Berlin (where our offices are, and thus where the hardware would go in and out of) could volunteer to help run the program."
I am in Berlin and I can help with that, depending what is required and how much time I would need to dedicate since I don't have much free time. You (or anyone else from KDE) can contact me on my email if you are interested.
I do multihead (multiseat) kde 4.5.
http://www.youtube.com/watch?v=qlPhVsFgYe0
Post a Comment