New KScreen Supplies Some Magic For Multi-Monitor Linux Set-Ups
An anonymous reader points out developer Àlex Fiestas's work on multiple monitor configuration for Linux. In particular, the screen manager that he and Dan Vrátil are working on — KScreen — gives KDE users a utility "making the configuration of monitors either auto-magical or super simple." This is one thing that's certainly gotten much better in recent years for Linux GUI users in general, but the video in the linked post makes me a little envious — another good reason to swap desktops once in a while.
I'm glad that the Linux desktop has this feature after being on AppleOS and Windows for only about ten years.
The set-up is also super-simple:
Finally if you want to get this working:
1.Compile libkscreen /kded org.kde.kded.unloadModule randrmonitor /kded org.kde.kded.setModuleAutoloading randrmonitor false /kded org.kde.kded.loadModule kscreen
2.Compile kscreen
3.qdbus org.kde.kded
4.qdbus org.kde.kded
5.qdbus org.kde.kded
This is great for users who want to get started with Linux. It will also end their Linux experience after 10 minutes.
Yes, Linux wins another accolade in being user-friendly.
Sorely missing for oh so many years. Still, gratz and thank you.
I've only been able to do this with Windows OS since 1998.
Kudos KDE team! :D
The first time I ran X on my home computer, I had to call Diamond to get the timings for my SpeedStar card so I could calculate the correct values to put in my xconfig file. And the person who answered the phone knew exactly what I needed, flipped thru a binder, and read off the numbers.
Alright. Now when we can have the same desktop span multiple cards we'll have caught up to windows of 12 years ago.
A suggestion to the developers. Please allow for degenerate cases. I deal with a set of old, specialized, practically irreplaceable displays that cannot produce DPMS data. In the past I've suffered with embedded displays that produce completely inaccurate DPMS data.
Allow the operator a means to manually override whatever display parameters your software obtains (probably via xrandr) from the operating system. The display parameters are often bogus and must be corrected.
Maw! Fire up the karma burner!
Now i hope someone will implement away of controlling which screen your icons will be on.
Basically..
* it will remember what you configuration was used with that monitor
* when you close your laptop it will go to the native resolution of the attached screen
I don't even know how new those are, but I've never personally used (or noticed) either of them before...
Everything else, I've been using succesfully since I started using laptops on both Windows and Linux.
I have 3 TFTs with 2 nVidia cards and I really hope this tool makes it somehow easier to configure. So far I always had to tweak xorg.conf using twinview etc. For some unknown reason the KDE devs seem to think the world only uses 2 screens max. What a pain!!!!!!!
I was doing this on a Mac II in 1986.
It is the common Linux empasse: tons of features hidden behind complex command (and features are the very last things Linux lacks....)
A pretty obvious solution to come out of it could be that for a GUI-related feature, i.e. X, or any other graphic code, to be considered as such, must have a... (now, mod this redundant)... GUI available to use it.
Obviously? Well, not very much so, if we still need to cheer this kind of news as... news.
Don't get me wrong, I consider this new tool extremely useful, but it basically builds on top of xrandr, a respectable piece of code dating back to way too many years ago.
By the way, if they would add some extra info on screen when switching between modes, I would consider it simply perfect.
I don't see any noticeable value above and beyond what you already get from a combination of any display configurator out there (Nvidia-settings, YaST, etc) and Cinnamon's Display Switcher applet ( http://cinnamon-spices.linuxmint.com/applets/view/43 ).
Configuring monitors (even multiple monitors) has gotten to be dirt simple in most cases - the auto-magic configurators in the various Linux distros are all pretty functional, these days.
Heh, your subject line betrays your loyalties.
What DOS-based browser are you using? Arachne? How does it handle large web pages like /.? Do you use extended or expanded memory?
Unity and GNOME 3 don't even work correctly with multiple monitors and don't work with multiple video cards at all.
In the general space multi-monitor support has gotten much worse. My 2 video card, 4 monitor configuration worked fine 10 years ago but nowadays I have to do all kinds of hacks to get it to work. Disable compiz, run a hacked window manager, hacked libXinerama, etc.
KDE is the only desktop that works out of the box on my setup. I don't run KDE though because it's too fat and weird in the way it looks and operates.
How about doing it with 3,4,5, or 6 screens?
Too complicated for KDE users?
Probably.
This is great - can someone port to Unity and/or Gnome on Ubuntu?
The article says: "This is one thing that's certainly gotten much better in recent years for Linux GUI users in general..." -- I cannot agree. While connecting a beamer to a notebook is simpler today, support for multiple monitors (of a desktop machine) is far from where it was some years ago. For years I had been able to disable the (default) Xinerama options, so I could have two separate instances of (e.g. KDE 3) running on both screens. That allowed me for example to stay on virtual desktop 1 on the left monitor and cycle through my virtual desktops on the right monitor. (Imagine lots of data sources on the right screen and some application I use to combine stuff on the left monitor; I want to switch desktops without the left monitor changing its content). This is still possible today, but it's a lot harder and depends on what kind of graphics card you use. Granted, my old way required knowledge of the xorg.conf syntax, but once it was finished it gave me maximum configurability. Last time I checked, KDE 4 wasn't able to start two instances on :0.0 and :0.1 properly which is why I'm still using KDE 3 (a.k.a. "Trinity" today).
Hans-Georg
Uhh, highlight them and drag them to the desired screen?
Not what he meant. He wants it set or fixed when the app is initiated, not after. Thanks for playing, though.
Also putting words in my mouth, then calling me a troll based on those words of yours really makes me think you just came here for a fight or something instead of trying to tell us all about "an exciting feature of MS windows" (the remote access stuff) as if we hadn't been using it for years and found it lacking.
Anyway, enough of that, I'm not here for a fight, instead I'll just give you a solution to this challenge you posted above, even though I'm a little surprised that you don't already know the solution since it's been around for at least a decade:
Then gladly download this (http://www.karlrunge.com/x11vnc/), run it, then suddenly your entire desktop is available remotely without restarting X or the applications, and at the same site there's some nice little frontends to get to remote VNC sessions via an ssh tunnel if that's what you need to get to a VNC session. It may not be X windows transport but it perfectly solves your little "showstopper" and gives you the behaviour you appear to be suggesting is only available on MS Windows.
I have used x11vnc and its performance is unacceptable as I already said. But it is irrelevant anyway because I can't use it for my local desktop AND expect to watch videos, or do anything with advanced graphics. Windows RDP does not suffer from this limitation. It lets me use a local desktop with all its performance and then lets me remote the apps in that session.
It is not a fight I am looking for but a feature. And I know I am not the only one who notices this feature is missing, but whenever I bring it up I get these smart-associated non-solutions. I said "troll" after being accused of cheering for Microsoft.
I did nothing of the sort, if you read above it's about cheering for RDP (which seems to be behaving better for you than and instance of RDP I've ever seen). Meanwhile I was watching videos and using advanced graphics with X, both thanks to OpenGL, in around 2000, so it appears you do not know what you are talking about.
Meanwhile I was watching videos and using advanced graphics remotely with X, both thanks to OpenGL, in around 2000
It ticks all the boxes of the "showstopper" you had and I think you are going to have to quantify what is "unacceptable performance", because it seems to outperform RDP over ADSL, local network, and even dial-up. Are you going to shift the goalposts to something I haven't tried like satellite?
so it appears you do not know what you are talking about
Really it appears that you don't know what I'm talking about, but I can't understand why. Perhaps you haven't read the thread. I never claim I can't watch videos etc over X and I never asked to do those remotely. I do these things locally now and have been for years. I've used Linux since 99 and exclusively since 2006.
And so can you. Fantastic, but on that same X where you watch videos, can you start a word processor (for example) use it for a while, then remotely resume that instance from a friend's house? With RDP this was possible, but I don't use Windows anymore.
So now I'm typing a message into a browser window. If I go to a friend's house and want to resume typing this reply, I can't. I could have if I had started this in x11vnc, yes, except I can't use x11vnc for my desktop because it can't do videos/opengl/etc. With RDP I could, but I don't use Windows anymore.
What looks promising is xpra, which I just learned about here, although I still have to choose between performance and remotability at application startup or find a way to do so automatically.
I either didn't explain it well enough or you missed the point that you can install x11vnc after X is running and export an existing desktop that is already being displayed. I did that on one machine a couple of weeks ago so that I could read the text in an open terminal window from home. Given the number of compression and transport options available to that and similar but not yet available on RDP I cannot take your "performance" claims seriously. I've had nothing but disappointment every time I go near RDP - even the third party proxy based desktop sharing systems like WebEx and GoToMyPC piss all over it by any measure, let alone properly compressed X or VNC.
Dammit, sorry, the technology I was thinking of was Xvnc's not x11vnc's. I apologize for adding to the confusion.
The big problem with VNCs like x11vnc is the latency incurred by screen polling. Xvnc doesn't need to do this, and neither does RDP. (This is why I thought that's what you were talking about.)
Even if latency were solved, there's still the issue of VNC just being a remote view of a local display and RDP is a remote display. The difference is that with the latter, the desktop takes on the shape of the remote end. Trying to view a 3840x1200 display on a 1200x768 display is just a disaster (not to mention the unnecessary performance degradation it also incurs as a result of needing to send vastly more data in my cases)
RDP's design isn't perfect, though. I prefer X's design by far if it were to fix the must-decide-at-startup and network performance issues.
Oh, and as an aside, the latency with X's protocol is in large part not solved by compression. What makes NX much faster is its elimination of a lot of the round trips inherent in X's protocol (by essentially faking responses) which are the biggest cause of X slowness, but much trickier to implement than just compression.
I mentioned that one because of the long list of optimisations cut down on the amount of polling and do a lot of compression (which does help VNC, and that's why I mentioned it). I've got two geophysists using x11vnc that look at their desktops on nights and weekends to see what state their running jobs are up to and to start off new ones. Others just use plain X over ssh or VPN, but don't do much graphical stuff.
An extension to hand windows over to other displays would be nice.