So it's 2008 and one would think that by now we'd have the whole mult-screen thing figured out in the F/OSS world, right? Hook up a couple of monitors to your machine and go .. right? In a word: meh. In two: you wish.
There are various fundamental issues that include the likes of xrandr failures, driver shortcomings, etc. But there are also some pretty amazingly basic stuff we just haven't gotten to yet.
Just the other week I finally came to fully understand why there are problems with panels on multiple screens: strut reservation is not designed for multiple screens.
Let me back up here a bit and explain what "struts" are: when a panel sits on the edge of a screen it may not want windows to overlap it. So it publishes it's geometry so that the window manager can keep windows out of its way and treat that area of the screen with a bit of extra respect.
Struts used to be very simple: N pixels reserved on the four respective edges of the screen. Now with extended struts we have the ability to note where those reservations begin and end. A panel can, for instance, publish that it wishes to reserve 32 pixels at the bottom of the screen starting 50 pixels from the left and continuing on for 400 pixels.
However, struts are treated as if the desktop space is one big rectangle that includes all screens. That means there is no way to reserve space on the right edge of a screen that sits to the left of another screen. To the strut definition, there is no screen edge there. Sure, the X11 API provides means to know that there is a screen edge there, but the strut mechanism ignores it completely.
I'm about to go fix a bug related to this in plasma, but it will still be hamstrung by this built in limitation.
So we have the old NETWM struts and the newer NETWM extended struts, but still no real multi-screen support. I suppose we need NETWM "complete" struts? =) This seems like a really interesting project to take on, perhaps as part of a Summer of Code project.
Coming up with an extension to the "extended" struts that takes multiscreen systems into consideration and writing a practical implementation of in a window manager (e.g. KWin) would help seal off one more pain point and it would benefit not just KDE but all F/OSS workspace projects (the NET WM stuff is a shared spec hosted at freedesktop.org).
About Me
Labels
- akademy (3)
- amarok (1)
- appeal (1)
- build system (1)
- community (7)
- crash (2)
- d-bus (1)
- dataengine (1)
- dolphin (2)
- events (1)
- family (1)
- free software (1)
- gnome (2)
- graphics (1)
- guademy (1)
- kde (52)
- kde e.v. (3)
- kde; kdegraphics (1)
- konqueror (1)
- krunner (4)
- libs (5)
- lug radio (1)
- media center (1)
- misc (1)
- openid (1)
- oxygen (2)
- performance (1)
- photos (1)
- plasma (26)
- podcast (1)
- pr (1)
- prose (1)
- release (1)
- social (1)
- solaris (1)
- techbase (6)
- travel (6)
- trolltech (3)
- web2.0 (1)
18 comments:
It is very good news, that KDE developers turn to Multi-head configurations!
Although Linux doesn't provide user-friendly means to setup multiple screens, it is still possible to do it. I set up two 3-head systems myself :) and it is very convenient to have multiple monitors for programmer: one screen you can use for editor, other for class explorer, console, debugger, etc.
BTW. Did you use Desktop Zoom on dual-screen configuration? :)
"Did you use Desktop Zoom on dual-screen configuration?"
yes. plasma internally has a lot of consideration for multi-screen setups already.
My biggest problem wasn't so much that you can't define what to do with the shared screen edges; it was more that if I tell the extended struts that 10x10 pixels on the bottom-left are taken, I see the windows across both monitors move up a bit to make 10 pixels free at the bottom. I expected windows with an x pos > 10 to not be affected at all.
I like your explanation of extended struts; that made it possible to write the above interpretation of what happened. Maybe I'll take a stab at fixing it. (no promise I won't run away screaming, though)
Oh, maybe this is a KWin bug, and maybe its even been fixed since I noted this at 4.0.0 release. That would be even better :)
"yes. plasma internally has a lot of consideration for multi-screen setups already."
And I really appreciate it.
It was big surprise, to see 2 desktops instead of one (with 2 palettes :) )
But I encountered some strange behavior: when I zoom out one desktop, plasma shows me 2 copies of other desktop: one at usual place, and the one small.
I know, it is better to file such issues to bugzilla, but I didn't know how may developers can reproduce this bug :(
@Thomas: it's a problem in the definition of NET Extended Struts on freedesktop.org. kwin just follows that. so it means extending the definition of extended struts and then implementing support for them in kwin.
@Yurik: that's not a bug, that's just an unfinished feature. you'll see what we're driving at with it when we're all done there =)
yurik: that's a feature. :)
since it's already being shown on the other monitor you can't zoom *into* it, though; we should have visual feedback for that eventually.
Unfortunately, it's not the only basic thing missing in FOSS...
Sometimes, it's just sadly amazing seeing Linux zealots proclaiming FOSS inherently better than e.g. Windows, while FOSS lacks things taken in the Windows world for granted since about Windows XP or even earlier (kinda switching multiscreen modes on the fly etc). It's even more sad and even more amazing considering the enormous FOSS development pace.
"proclaiming FOSS inherently better than"
there's a real difference between saying "better than" and "better in every way than". every system has strengths and challenges. it's the balance of those strengths and challenges that matter in the end, and saying "because it doesn't have $foo you shouldn't promote it" is really unfair.
unless we can get everyone to live by those standards. just think: no more advertising of any technology! ;)
"switching multiscreen modes on the fly"
to be fair, we do have this now. there are some outstanding issues (it doesn't always work as well as one might hope, e.g. in getting optimal resolutions on both monitors), but it isn't a missing feature anymore.
I have an issue with multihead configuration, which hardly prevents me from using kde4. It works just fine with kde3, but doesn't with kde4
http://i261.photobucket.com/albums/ii79/non7top/kde4/snapshot3.jpg
@non7top: that's due to a combination of things:
a) xrandr 1.2 being rather screwed in the head when it comes to publishing screen information
b) your qt not being patched with a fix for that
c) plasma blindly trusting what info it got
i've addressed (c) in 4.1 by changing the placement strategy to pretty much ignore what x.org says.
The main issue I have with multi-screen X and KDE4 is I have no way of specifying what to put on which screens at this moment. It can be seemingly random as to which screen my panel will be on and I have no way of changing it (when it is on the right screen, I lose the corner sweet-spot for the k button).
The same is true for placement of new windows. I've been using KDE4 svn at work all day long and this is the only thing that is keeping me from being really comfortable.
I've attached screenshots to http://bugs.kde.org/show_bug.cgi?id=152549, seems he had same problems.
And tony has a point which bothers me too: sometimes it is hard to guess where new window will appear. But I think it is conceptual problem: we move from rather small resolutions. Usually, it was one maximized window of main application which user works with most of the time (word, spreadsheet, IDE, etc), and small amount of supplementary windows, like browsers, IM messages, etc. With multi-head configurations, we come to huge resolutions where we can afford multiple non-maximized, non-overlapping windows. I suppose, It is realm of usability team how to organize them :)
I'd like to see something like this in X (KDE whatever).
http://reptils.free.fr/
It allows you to define your desktop as a grid and have applications open to defined sizes. There are very few programs now that actually need the whole desktop. This is true of things like the debugger where you want multiple windows open at a time. But also, I would like to be able to set in the window manager that when I click on firefox for example that it 'maximises' to half of my screen. Or say for OpenOffice that it maximises to a size only slightly bigger than what it needs. At the moment it opens to the full size of my screen when it only needs about half.
Dunno if that makes sense, hopefully you get the idea. Admittedly people with huge desktops are a minority at the moment, but I think is changing particularly as people will start using their TVs more and more.
"have applications open to defined sizes"
There is already similar thing since KDE3 (at least), which is called "Special Window/Application" settings. It allows force / apply initially specific geometry settings for particular applications.
Just click on window Icon -> advanced.
Also, it is funny to play with border-less or full-screen windows. There are many useful options :) May be not you expected, but still may help tuning Desktop to your needs.
But I can't find Xinerama support there... :(
Another problem is that X cannot resize the framebuffer on the fly, so if you plug in an extra 30 inch screen in your spare VGA/DVI port, xrandr will see it, but it cannot do anything with it (except clone the screen to it perhaps). Easy multi-screen setups won't be possible until the X guys sort that out.
>>> a) xrandr 1.2 being rather screwed in the head when it comes to publishing screen information <<<
would you care to elaborate how it's screwed??
Possibly as an answer to comment 15 here (kde bugzilla).
Hey Mr. Seigo, is KDE switching over to git?
Happy holidays
"but it isn't a missing feature anymore".
Sorry for giving ambiguous definitions; what I've actually meant is, so to say, "multi-screening" modes, i.e. "Clone" vs. "Continuation" etc. Nvidia driver has something of the kind, but it is still half-baked.
Post a Comment