Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have an xorg.conf which WORKS. I get two screens on two monitors. I can move the mouse between them (but I cannot move windows/programs). I can launch programs from the panel on the second screen by using the modified launchers which I described earlier so I have a workable solution (unless and until it breaks again).
I found an rpm for dosemu for Fedora 25. I will try a localinstall on a test machine. It is not in the CentOS base, epel nor nux-dextop repos. I have asked on the CentOS forum if someone can point me to it. I will also look at dosbox. I have only ONE program which I need to run. It is an expense tracker which I wrote in FoxPro in the late '80s.
I mostly use xrandr to position screens and rotate them. Although that doesn't work so great on nVidia GPUs. But nVidia probably has it's own tool that "might" work. If if if if if... As far as xorg.conf's, a lot of distros are scripted to mostly ignore it these days. The last time I tried to use a xorg.conf I couldn't so much as enable 3 button mouse emulation. Fortunately xinput lets you enable that now, after X has started (YMMV depending on distro).
I believe you have contributed to some of my threads on this subject in the past. xorg.conf seems to be ignored by the "built in" Intel driver in CentOS, Ubuntu, Linux Mint and anything else I tried. The nVidia proprietary driver from the Ubuntu repository and kmod.nvidia from elrepo do seem to process the file.
In debian there's a lot of /etc/X11/Xsession.d/ files that seem to take priority over a /etc/X11/xorg.conf. And various other files and directories under /etc/X11/. Rendering all but the most obscure xorg.conf settings futile. Most times I just override AFTER X has started with xrandr, xinput, and other things. Like xbacklight, xsetbg, and on and on. But it's a simple bash script that I run once after starting X.
In debian there's a lot of /etc/X11/Xsession.d/ files that seem to take priority over a /etc/X11/xorg.conf. And various other files and directories under /etc/X11/. Rendering all but the most obscure xorg.conf settings futile. Most times I just override AFTER X has started with xrandr, xinput, and other things. Like xbacklight, xsetbg, and on and on. But it's a simple bash script that I run once after starting X.
That is a good way to go. Without that you need to take control of the startup and FORCE it to read a particular config file. It is getting so the common case is trivially easy, but a custom configuration is getting more and more difficult.
In my case, most distros give the laptops LCD priority, so everything is geared toward the lowest common denominator, which is 1366x768. Although the only shared resolution between it and the 1080p display is 1024x768, so that's the default. In the case of ubuntu, I couldn't even get their setup tool to do what I wanted, but xrandr worked just fine.
Basically clones them at 1080p. The laptop being more of a viewport that scrolls with the mouse. But I turn that screen off. Could probably add --same-as if that's not already the default.
$ xbacklight -set 0%
$ xset dpms force off
And wiggle the mouse so the 1080p screen comes back on. The --primary and the --panning parts let me fullscreen things at the 1080p resolution. The panning option actually allows for a 4096x4096 viewport with the intel GPU of my hp stream 11s. Not really a useful mode outside of a few image things like creating ascii art that scales well for other systems. Or dumb gui apps that make things too big for your existing displays.
Personally, I think one is better converting to the xorg.conf.d/ format because if xorg.conf is not being presently ignored, it soon will be.
Have you considered making the right monitor the Primary monitor and have screen 1 "Left of Screen 0" as a way of getting stuff to open on the right monitor? It's probably worth a try.
Last edited by business_kid; 12-15-2016 at 08:12 AM.
Reason: Typos: Have use of one hand & smartphone isn't that smart :-|
I use a separate screen on the HDMI output of my laptop to a tv, mainly so I can play media on the tv and work in multiple workspaces on the lappy.
Debian Jessie / XFCE 4.10 / kwin for wm
Works great.
I don't bother with a panel on the tv (rt-clk on desktop shows the xfce menu and starts apps on that screen).
I also run a conky on it with big clock and mpd monitor.
Main use is mplayer output (custom Thunar action "mplayer -fs -display :0.1 %F" to stick any media file on it).
I also sometimes run firefox (needs "-no-remote" switch if running instances on each screen) and the odd celestia session.
Wallpaper can be set from xfce "Desktop" settings applet ("Display" doesn't open though).
I also tried this setup with KDE 4.<whatever is in Jessie> and it did sort of work, but the kde session on the tv crashed on start, so no window controls etc, (and I still don't like kde so I just kept using xfce rather than troubleshooting it).
xorg.conf built by fiddling with the nvidia-settings tool, reading some docs and trimming and testing - probably not all of it is necessary, but doesn't give me any trouble.
Also works fine just booting without it connected too when out and about, no alterations needed.
This is a pretty old thread by now, but I have had this exact same problem since way back when I updated from Fedora 24 to Fedora 25, something definitely changed. I am now on Fedora 29 and the exact same problem persists. I am running dual mode, which I do not want. I want different X-Sessions. I do not want or need to drag apps to separate screens. I want to them to be completely independent. It is a workflow that I was happy to have, and irritated to lose. Still, to this day.
X.ORG has made a huge project out of making X-windows autoconfig as complete as possible to make the normal case "plug and play" for new users and those migrating from proprietary systems. (Think small fruit and MicroSoft based.) If you want to engage the configuration and FORCE a non-default configuration then the most simple or default case will not work for you.
The full solution is to take charge of the configuration and write a COMPLETE AND CORRECT configuration to do exactly what you want and FORCE the X to use it. This means your configuration file will NOT be simple. It also means that updates to the X system could easily obsolete or change your settings, so you would have to stay on top of changes.
Very few people wish that degree of control of the display, most just need it to work. Even fewer are willing to do the learning, work, and expend the ATTENTION to maintain such a system going forward.
It sounds as if you have a workaround that is not what you originally described, but that serves you well enough and will be less work to maintain. That is an acceptable solution. You have the advantage that CentOS drags on RHEL change, and those changes tend to be small since RHEL is very stable and conservative. That means your workaround is unlikely to break as soon as with many distributions. (Sparky, Fedora, VSIDO, Ubuntu not LTS release - these break things that are unique and non-standard early and often)
X.ORG has made a huge project out of making X-windows autoconfig as complete as possible to make the normal case "plug and play" for new users and those migrating from proprietary systems. (Think small fruit and MicroSoft based.) If you want to engage the configuration and FORCE a non-default configuration then the most simple or default case will not work for you.
The full solution is to take charge of the configuration and write a COMPLETE AND CORRECT configuration to do exactly what you want and FORCE the X to use it. This means your configuration file will NOT be simple. It also means that updates to the X system could easily obsolete or change your settings, so you would have to stay on top of changes.
Very few people wish that degree of control of the display, most just need it to work. Even fewer are willing to do the learning, work, and expend the ATTENTION to maintain such a system going forward.
It sounds as if you have a workaround that is not what you originally described, but that serves you well enough and will be less work to maintain. That is an acceptable solution. You have the advantage that CentOS drags on RHEL change, and those changes tend to be small since RHEL is very stable and conservative. That means your workaround is unlikely to break as soon as with many distributions. (Sparky, Fedora, VSIDO, Ubuntu not LTS release - these break things that are unique and non-standard early and often)
When attempting to run this command #sh -c 'DISPLAY=":0.1" konsole', I discovered that while it does open konsole on the top display (display 1), it immediately causes marco to crash loop, causing a rapid flashing on both monitors, until I break it. The log clearly shows it is marco that is crashing. This appears to be a Mate issue, as this does not happen with other window managers. With other WMs, konsole opens but has no drag bar and is not movable, hence, no WM is running there to manage it. So looks like Mate/marco is buggy and needs fixed (by the mate devs. The second issue is, since no windows manager is actually running on screen 1, only on screen 0. I was thinking it may be possible to run a different window manager on the second screen and launch a startx after starting the first mate Xsession. Since marco appears to not be able to run more than one instance, perhaps I could launch XFCE or KDE or LXDE on the second monitor?
I would be fine with this, as I have plenty of RAM, but how to make it work? Would I need to completely disable the top monitor in the first Xsession (xorg.conf) and create a second xorg.conf2 which is exclusive to the top monitor? Or would I keep the top monitor included in the xorg.conf as a separate Xsession before launching a second "startx" command? I would guess the former. It seems I have actually tried doing this before with some limited success a few years ago but my memory is short on the details.
This was so easy to achieve in the past. It's a shame making it easier for Windows/Apple migration has made it so hard for dedicated Linux users (since 1991 for me).
I am not at all certain that your interpretation of the evidence is a valid conclusion. If X were not managing that display your command would not open anything there. Certainly it is not working properly, but I think you might need to manage the X configuration to go forward with the Windows manager.
That said, it costs nothing to give something a try to see what works. Even if it fails, it will teach something.
Try opening a windows manager on that display and see what happens! If it fails, then try restricting your existing manager to AVOID that display and go again. The results should be interesting.
I am not at all certain that your interpretation of the evidence is a valid conclusion. If X were not managing that display your command would not open anything there. Certainly it is not working properly, but I think you might need to manage the X configuration to go forward with the Windows manager.
That said, it costs nothing to give something a try to see what works. Even if it fails, it will teach something.
Try opening a windows manager on that display and see what happens! If it fails, then try restricting your existing manager to AVOID that display and go again. The results should be interesting.
Thanks for your reply. You are correct, nothing would open on the top screen if X were not running on it. I should have been more specific and said Mate was not running was not running on that display.
I am still troubleshooting on this, and I am wondering if I need to be working with the lightdm.conf file perhaps, as well as xorg.conf. After looking back at some old backups, I discovered the dual X-sessions appears to have stopped working whenever Fedora changed from gdm to lightdm. Probably just a coincidence however.
I will continue to experiment and get back with the results.
EDIT-UPDATE: LightDM config has nothing to do with it. That was a complete waste of time. Here is my xorg.conf file presently:
This almost works, with Cinnamon DE. I can launch apps using "#DISPLAY=:0.1 konsole" and they open on screen1 and are usable without the annoying screens flashing effect. However, they have no window decorations ie. can't resize or drag them around. For running MythTVFrontend, I can certainly live with that, as it runs full screen and 75% of the time it is running when using this PC (it's the other 25% that is still a concern).
Sometimes I use Ardour/Mixbus on that screen as well, as it's a 43" monitor. It's 4k too, but only running in 1080P. Not a big fan of Cinnamon DE, but if that is what (semi) works, I may have to live with it. Seeing how it at least works this well with Cinnamon, there must certainly be a problem with Mate DE, or perhaps my configuration of Mate is mucked up. I will find the Mate section over in FedoraForum and see if anyone there has any bright ideas.
Before I try to adapt your xorg.conf to use with FOSS DDX, I want to be sure I understand what your goals are:
1-only one keyboard?
2-only one mouse?
3-one X session on left display?
4-some other X session on right display, simultaneously with first session on left display?
5-Other?
Having two different X sessions at once here on Fedora is working, but whichever session is has been switched to using Ctrl-Alt-Fn is using both displays, while the not visible other is apparently not responding to mouse or keyboard events:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
