If you're using dpkg to install a .deb, it's not "compiling". "Compiling" refers to a process which creates binary object files (which contain executable machine code) from text source files. Usually when you try to install something from source, it comes in a tarball.

Anyway, I'd go for using whatever older version is in the repositories. Installing various things with newer/different versions than what the rest of the system's software expects can lead to more headaches than it's worth.

So why was the older version too old?

BTW, there are plenty of regular Intel based conventional computers which consume way less than 100W. I use 60W power bricks on my cheap used T5010 laptops, and that's just for peak power. That's power consumption including the power consumed by the display, of course. You can easily get some old off-lease corporate fleet laptops dumped on eBay for $30. The cheapest ones typically don't come with any hard drive, but you'd be doing diskless boot to minimized power consumption anyway.

Problem is I'm on a distro that uses a package manager, I should and don't want to install stuff manually as it will cause conflicts and other issues. I've fully updated the system and those dependencies are at their latest version but it still won't install because it wants even higher versions then what the distro provides.

If I install the synergy version that's in the repo, then the one that's in the repo for the RPI won't match. They have to match or they won't connect.

***Your right:-

So....unless you want to over ride your pkg mgr I don't see the most current versions of those dependencies getting met.

This is why I run Slackware.
It's dependency hell sometimes but worth it in the end.

Do you think Red Squirrel that if the API of the applications that are opening on the wrong monitor 'could be modified' it would stop opening on the wrong monitor?

OR> is the window mgr that needs modified with a script too make the app open on the desired screen?

You could use the same OS for both the Raspberry Pi and your main computer. Also, there's a certain amount of compatibility between versions. IIRC, the version in Debian Wheezy (e.g. Raspbian) is compatible with the version in Debian Jessie (current Debian Stable). I don't remember for sure, though, since I may not have spent as much time with a mixed Wheezy/Jessie state during the dist-upgrades than I have done in the past.

1 members found this post helpful.

Idealy it should be the window manager that handles it, then it's not app dependent. Though I'm not even sure if it's a Window manager thing, maybe it's more an X thing. The way things should work is that when any GUI element is launched it opens where it was actually launched from. That seems like such a simple thing.

I opened gimp for the first time, and it went into it's horrible multi window mode and it literally exploded across all 3 monitors. It was like a GUI bomb went off. That's completely insane. Thankfully they have single window mode for it so it's only a one time issue, I set it to single window mode and hopefully next time it will open on primary. But some apps do spawn their own dialogs for open/save and other stuff. Dev c++ is notorious for having certain dialogs insist on going on the left monitor no matter what you do. It should not be app dependent, the OS should basically create a boundary of sorts to force apps to only spawn on the monitor they were launched from.

As a test I just went to the Nouveau driver but I don't see a change in behavior. Had an app open 3 monitors down from where it was opened.

Also, in my previous Distro (Mint 17 KDE) I was able to install different window managers and pick them from a drop down somewhere in system settings. I can't seem to find that in 18 Cinnamon, anyone know how to do that? I'm thinking of just installing a very simplified window manager, then look at the code to see what is involved. I might just look at coding my own. I imagine it's quite involved though... but if I can just modify an existing and figure out how to get it to integrate in the system so it creates an entry in that drop down, might be worth a shot.

Though I was really counting on separate X sessions working though, it's really too bad it does not. That would have been the ultimate fix.



RPI is fairly limited in the distros it can run, there are only a few for it. THough I never thought of using old laptops, they use less power than a full blown PC, but would allow me to run x86 /x 64 based OSes giving me more choices. Ex: same OS as main machine, then I can use whatever synergy is in the repo.

I suppose one other options is to do the separate X sessions, but rather than open stuff through the normal methods (Ex: application menu) I could just have scripts that set the environment display variable then launches the stuff. Typically on the side monitors the stuff I open is fairly limited. Browser, consoles, maybe RDP/VNC sessions. So I could just create special shortcuts for those I suppose, and they would set the proper display variable.

Come to think of it, is there a way to force everything on one X session, if I force everything to the primary by default then there's no chance of stuff launched from the primary to go to the other monitors. Then for the other two monitors I could have full screen VNC sessions open to some remote server/VM. Basically have everything open on primary unless I use environment variable set. By default, it seems to be random.

1 members found this post helpful.

Thank you-

Knowing that information might help me in my research to reveal something to stop this maddening multi-monitor nightmare and put it to bed. (that's what I'm hoping)

I've talked to other Guru's about reading code and working with it and it's not easy.
From the impression they gave me it's very involved.
If you can read code you've got it made!

No, sorry- Google it and see what you get.

https://www.slant.co/topics/390/~win...gers-for-linux
http://www.techradar.com/news/softwa...r-linux-972570

I find XFCE works fine, until it doesn't. For example, when opening a file in Thunar some applications open in the active session and others just open in the primary (:0.0), though those same applications open fine form the menu. Then, as Red Squirrel mentions, some applications just open dialogue boxes or other popups on the primary monitor regardless. I find anything asking for root password will also open on the primary regardless.

I just had another idea, a twist on the Synergy idea, while keeping the ability to use the RPI. I can setup a VM, or two, that uses the same OS as my workstation, so that I can use the synergy package that is in the repo and don't have to worry about all the dependencies and crap when trying to install it manually. I would setup the RPIs to automaticly VNC full screen into the VM. I can probably have a single VM, since VNC in Linux acts kind of like RDP in Windows, so I would just have two separate sessions.

This feels kinda dirty though, I'm hoping there's a better way without having to rely on external hardware and VNC. VNC is kinda slow, too. But I suppose this is worth a shot.

I did not get a chance to play with the above idea, but another thing I thought of, is this the sort of thing that Wayland could have the ability to solve? I wonder if this is something that should be brought up to their developers as something to look into. Since it's something fresh and new perhaps more thought can go into it for better window behaviour at a global level, so that individual window managers don't need to worry about it.

I also hope Wayland will solve screen tearing, that seems to be a big issue in a lot of Linux configurations. Maybe this whole issue is just the thing of waiting for Wayland, if it will indeed solve all this.

I'm having surgery in a couple of days so the research I've mentioned in post #66 will be on hold for at least a week.

If I find something worthy Red Squirrel I'll post it for you.

As far as Wayland is concerned Gnome and KDE are expected to be ported to it for now.
https://wayland.freedesktop.org/

Never heard of the 3D Maze Compositor till today:-
https://wiki.archlinux.org/index.php/wayland

If Wayland would solve your entire issue that would be GREAT!

Appreciated, but no rush, take care of yourself first.

Got it- Thanks-

In my research I found a fix for the KDE DE with dual monitors.

To make app open on the same monitor every time in KDE:

In KDE 4.13.3 (mayby in some olders and newers you can do this (translation may be inacurrate - I use polish version):
1. run the desired program
2. right-click on its title bar
3. choose "more actions"->"additional window settings..." (even more options are under "additional program settings...")
4. go to tab "size&layout"
5. Mark checkbox "Screen" and choose "Force" and choose the screen number. Window of this program will be opened always on that screen.

Another fix for the KDE DE:

This is a window manager specific solution. This is how to do it with kwin which is KDE's default window manager.
If you right click on the application Title Bar and select more settings -> special application settings.
Go to Window matching tab. Click on Detect Window Properties button. Then with mouse cursor click on application main window. It will select window class etc and also get window positioning info etc.
Then click on Size and Position tab. Click the Box Position and box Size and drop down box to right of both and set to remember.
Then click ok.
Next time you run the app it should be the same size and on same monitor.

-----------------------------------------------------------------

If you are using XINERAMA to make both displays look like one to X, then you would use the -geometry option to ask applications to appear at a specific location. If you have the displays setup as different screens then you will use the DISPLAY to achieve this.
Give these a try:
$ DISPLAY=0.0 xterm &
$ DISPLAY=0.1 xterm &
Other tools for multi monitors
Sensible toolkits support a -geometry option, which allows your application to request being placed at a specific position. If you don't have this option
available, you can use wmctrl if you have an EWMH/NetWM compatible X Window Manager to move and resize already existing windows (see wmctrl (1), you need options -r and -e). I use devilspie to force placement of some windows and of course your window manager of choice may have its own facility to force window placement.
devilspie allows to apply certain actions on X windows and can use X window properties to discern different windows and applications. The key rule for you would be geometry "<width>x<height>+<xoffset>+<yoffset>".

Aside from those solutions I didn't find anything else worthy to manage a Window Mgr or multipule monitors. (it's really discouraging)

WiKi for Multipule Monitors
https://wiki.gentoo.org/wiki/Xorg/Gu...tiple_monitors

HTH -

I spoke to a guy that use to work in SQL and he suggested to look in 'display settings'.

Maybe look into the display environment variable; what it does and what it is responsible for.