Is ANYONE using separate X screens?

taylorkh · 12-14-2016, 09:36 AM

Thanks wpeckham,

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.

Thanks again,

Ken

Shadow_7 · 12-14-2016, 09:46 AM

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).

taylorkh · 12-14-2016, 11:49 AM

Thanks Shadow_7,

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.

Ken

Shadow_7 · 12-14-2016, 12:20 PM

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.

wpeckham · 12-14-2016, 02:26 PM

Quote:

Originally Posted by Shadow_7

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.

Shadow_7 · 12-14-2016, 03:31 PM

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.

$ xrandr --output HDMI1 --mode 1920x1080 --panning 1920x1080 --primary --output eDP1 --mode 1366x768 --panning 1920x1080

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.

business_kid · 12-15-2016, 04:43 AM

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.

descendant_command · 12-15-2016, 05:51 AM

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.

Code:

# xorg.conf

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    Screen      1  "Screen1" 1366 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "AU Optronics Corporation"
    HorizSync       30.0 - 75.0
    VertRefresh     60.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "PANASONIC-TV"
    HorizSync       15.0 - 45.0
    VertRefresh     48.0 - 61.0
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    Option	   "NoLogo" "true"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GT 540M"
    BusID          "PCI:1:0:0"
    Screen          0
	Option              "UseEdidDpi" "False"
	Option              "DPI" "81 x 81"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    Option	   "NoLogo" "true"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GT 540M"
    BusID          "PCI:1:0:0"
    Screen          1
EndSection

Section "Screen"

# Removed Option "metamodes" "nvidia-auto-select +0+0"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "LVDS-0: nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"

# Removed Option "metamodes" "HDMI-0: nvidia-auto-select +0+0"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "HDMI-0: 1920x1080 +0+0; HDMI-0: nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Lexridge · 06-26-2019, 11:08 PM

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.

wpeckham · 06-27-2019, 06:29 AM

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)

Lexridge · 07-05-2019, 01:23 AM

Quote:

Originally Posted by wpeckham

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).

wpeckham · 07-05-2019, 06:22 AM

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.

Lexridge · 07-05-2019, 01:42 PM

Quote:

Originally Posted by wpeckham

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:

Code:

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 430.26

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" Below "Screen1"
    Screen      1  "Screen1" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Sceptre E24"
    HorizSync       30.0 - 85.0
    VertRefresh     48.0 - 76.0
    Option         "DPMS"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "ONKYO Corporation TX-NR609"
    HorizSync       30.0 - 80.0
    VertRefresh     30.0 - 76.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX TITAN Black"
    BusID          "PCI:1:0:0"
    Screen          0
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX TITAN Black"
    BusID          "PCI:1:0:0"
    Screen          1
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "DVI-I-1: 1920x1080 +0+0 {ForceCompositionPipeline=On}"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "DVI-D-0: 1920x1080 +0+0 {AllowGSYNC=Off}"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

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.

descendant_command · 07-07-2019, 12:18 AM

In my experience, Xfce works with multi-head, as does openbox (so, presumably, LXDE also).

mrmazda · 07-07-2019, 01:30 AM

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:

Code:

# ll /etc/X11/xorg.conf
ls: cannot access '/etc/X11/xorg.conf': No such file or directory
# ls -l /var/log/Xorg*
-rw-r--r-- 1 root root 21561 Jan  1  2015 /var/log/Xorg.1.log.old
-rw-r--r-- 1 root root 50710 Jul  7 01:23 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 64721 Jul  7 01:58 /var/log/Xorg.0.log.old
-rw-r--r-- 1 root root 66177 Jul  7 02:24 /var/log/Xorg.0.log
# ps -A | egrep 'tty|twin|tde|icew|kons|term'
  755 tty5     00:00:00 agetty
  759 tty6     00:00:00 agetty
 1030 ?        00:00:00 tde_dbus_hardwa
 1223 tty3     00:00:00 bash
 1273 tty2     00:00:00 bash
 1300 tty2     00:00:00 mc
 1341 tty4     00:00:00 bash
 1365 tty4     00:00:00 startx
 1388 tty4     00:00:00 xinit
 1389 tty4     00:00:00 Xorg
 1394 ?        00:00:00 icewm
 1395 ?        00:00:00 xterm
 1407 tty7     00:00:02 Xorg
 1415 ?        00:00:00 tdekbdledsync
 1444 ?        00:00:00 starttde
 1561 ?        00:00:00 start_tdeinit
 1562 ?        00:00:00 tdeinit
 1565 ?        00:00:00 tdelauncher
 1571 ?        00:00:00 tdeinit_phase1
 1575 ?        00:00:00 twin
 1599 ?        00:00:00 tderandrtray
 1602 ?        00:00:00 konsole
# inxi -GxxS
System:    Host: p5bse Kernel: 5.1.16-300.fc30.x86_64 x86_64 bits: 64 compiler: gcc v: 9.1.1 Desktop: Trinity R14.0.5 
           tk: Qt 3.5.0 wm: Twin dm: TDM Distro: Fedora release 30 (Thirty) 
Graphics:  Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 
           chip ID: 10de:107d 
           Display: x11 server: Fedora Project X.org 1.20.5 driver: modesetting unloaded: fbdev,vesa 
           resolution: 2560x1440~60Hz, 1920x1200~60Hz 
           OpenGL: renderer: NVD9 v: 4.3 Mesa 19.0.8 direct render: Yes
# xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x43 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 2 associated providers: 0 name:modesetting
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
DP-2 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 519mm x 324mm
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   1920x1200     59.95*+