xrandr and xorg-server

IrvineHimself · 2018-06-02 05:55:07

I know there are quite a few recent threads that mention the latest updates to xorg-server and how it affects xrandr, but I made a discovery this morning that is relevant, yet doesn't quite fit any of the other threads.

For me, my problems began when xorg-server was updated to version 1.20.0-2 of the xorg-server. As I mentioned in my original post, trying to mirror my monitors with xrandr resulted in the following error:

~$ xrandr --output eDP-1 --auto --primary --output HDMI-1 --auto --same-as eDP-1
xrandr: Configure crtc 1 failed
~$

In all the threads I have been following, there has been an implicit assumption that, 'somehow', xrandr wasn't playing nice with xorg-server. This morning I found out that this is not actually the case.

With the release of version 1.20.0-5 of the xorg-server not bringing any relief to my problems, I decided to ditch xrandr and configure mirrored monitors directly through /etc/X11/xorg.conf.d/10-monitor.conf

Section "Monitor"
    Identifier  "eDP-1"
    Option      "Primary" "true"
    Option      "Position" "0 0"
EndSection

Section "Monitor"
    Identifier  "HDMI-1"
    Option      "Position" "0 0"
EndSection

For the downgraded version 1.19.6+13+gd0d1a694f-2 of the xorg-server, this works and eDP-1 is successfully mirrored to HDMI-1 even at my xdm log-in prompt. Unfortunately, with the upgraded version of the xorg-server, the HDMI-1 monitor appears as a black screen, which can be confusing, since my background colour is actually black. However, everything is correctly scaled for mirrored monitors.

To check this, I tried replacing the above configuration with:

Section "Monitor"
    Identifier  "eDP-1"
    Option      "Primary" "true"
EndSection

Section "Monitor"
    Identifier  "HDMI-1"
    Option      "RightOf" "eDP-1"
EndSection

This works as expected with the downgraded version of the xorg-server, and I am able to drag gui's between the two monitors. But, again, when running the upgraded version, the dragged gui just vanishes as it is pushed into the HDMI-1 monitor.

Interestingly, when, with the upgrade version and my 'mirror' configuration, trying to set 'mirrored' monitors with xrandr does not result in an eror:

~$ xrandr --output eDP-1 --auto --primary --output HDMI-1 --auto --same-as eDP-1
~$

In case anyone wishes to look at a complete xorg.log of a session using xorg-server-1.20.0-5; to make sure there were no mistakes, I moved all the xorg logs into a backup folder before conducting a test run, and the 'fresh' results can be found here

Note: This log includes the above 'error free' test of xrandr --output eDP-1 --auto --primary --output HDMI-1 --auto --same-as eDP-1.

Like I say, I do not really expect a reply or a solution. I am just putting the information out there.
Irvine

edit: confusing spelling mistake

Last edited by IrvineHimself (2018-06-02 05:57:53)

loqs · 2018-06-02 09:44:34

Please try https://bbs.archlinux.org/viewtopic.php … 8#p1786538.
If that fails then please try https://bbs.archlinux.org/viewtopic.php … 6#p1788096

IrvineHimself · 2018-06-02 11:01:43

I will get onto that this afternoon. But a quick question should I update package rels of the PKGBUILD, (we are currently on xorg-server-1.20.0-5,) or just work with the indicated packages?

Last edited by IrvineHimself (2018-06-02 11:02:11)

loqs · 2018-06-02 13:22:35

Updating the package release would prevent pacman from trying to update the packages without needing to use IgnorePkg when trying the autotools build.
With the bisection apart from the 1.19.6 and 1.20.0 all the intermediate commits would be new releases but of a lower version number so would need IgnorePkg if you do a pacman -Syu.

IrvineHimself · 2018-06-02 13:40:00

I tried both links, and in both cases it really didnt like makepkg -rs

Test1

[stupidme@mine trunk]$ makepkg -rs
==> Making package: xorg-server 1.20.0-1 (Sat 02 Jun 2018 14:16:52 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
/usr/bin/makepkg: line 235: /usr/bin/sudo: Permission denied
==> ERROR: 'pacman' failed to install missing dependencies.
==> WARNING: Failed to remove installed dependencies.
[stupidme@mine trunk]$

Test2

[stupidme@mine xorg-server-git]$ makepkg -rs
==> Making package: xorg-server 1.19.6-1 (Sat 02 Jun 2018 14:30:15 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
/usr/bin/makepkg: line 235: /usr/bin/sudo: Permission denied
==> ERROR: 'pacman' failed to install missing dependencies.
==> WARNING: Failed to remove installed dependencies.
[stupidme@mine xorg-server-git]$

I am going to keep plugging away at it by installing and removing missing dependencies by hand

Irvine

loqs · 2018-06-02 13:45:32

/usr/bin/makepkg: line 235: /usr/bin/sudo: Permission denied

Any idea why makepkg can not execute /usr/bin/sudo?

IrvineHimself · 2018-06-02 15:02:46

Sorry, I just realised when I saw execute /usr/bin/sudo that I have makepkg sandboxed with seccomp and nonewprivs. Although, very rarely, the combination of hash tables and a suspect symlinked profile can really mess with my head, this is the first time since I set the system up that I can ever recall makepckg being a problem. I mean it is probably the one pacman related program that is never supposed to have root privileges

Anyway, that is all beside the point. I just ran the first test without success. I mean it compiled and installed without problems, but the underlying issue of no dual monitor setup is still there.

To make sure there was no misunderstandings, I tried both

sudo pacman -U xorg-server-1.20.0-1-x86_64.pkg.tar.xz xorg-server-common-1.20.0-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/libinput-1.10.6-1-x86_64.pkg.tar.xz

And

sudo pacman -U xorg-server-1.20.0-1-x86_64.pkg.tar.xz xorg-server-common-1.20.0-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/libinput-1.10.7-1-x86_64.pkg.tar.xz

But, I will bash on; try the second set of tests and get back to you
Irvine

Edit:
I didn't have xf86-video-vesa installed before, should I have installed it?

Last edited by IrvineHimself (2018-06-02 15:05:15)

loqs · 2018-06-02 15:38:45

IrvineHimself wrote:

I didn't have xf86-video-vesa installed before, should I have installed it?

Looking at the Xorg.log you posted the system is using modesetting only so presence or absense of xf86-video-vesa should not make a difference as modesetting should take precedence unless you have a config overriding that.

IrvineHimself · 2018-06-02 16:34:25

Okay, I disabled my Firejail symlinks folder and followed the first set of steps; replaced the PKGBUILD and ran makepkg -rs, however, it kept updating the PKGBUILD to 1.20.0-1, so I tried just running a naked makepkg, but it still keeps switching to a new branch

To capture this, I added a pipe after makepkg to redirect some of the output away from the terminal window. If you want to see it, I will gladly post it, but it's just compiler stuff and not directly related to makepkg branching the build.

[stupidme@mine XorgTest2]$ git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
Cloning into 'packages'...
remote: Counting objects: 2690, done.
remote: Compressing objects: 100% (1856/1856), done.
remote: Total 2690 (delta 907), reused 2356 (delta 812)
Receiving objects: 100% (2690/2690), 670.80 KiB | 443.00 KiB/s, done.
Resolving deltas: 100% (907/907), done.
[stupidme@mine XorgTest2]$ cd packages/trunk/
[stupidme@mine trunk]$ git checkout 42bf42476cf05ea49c54ddb5d5ba62179e68b45d
Note: checking out '42bf42476cf05ea49c54ddb5d5ba62179e68b45d'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 42bf424 prepare update
[stupidme@mine trunk]$ cd ../..
[stupidme@mine XorgTest2]$ cp -r packages/trunk xorg-server-git
[stupidme@mine XorgTest2]$ cd xorg-server-git
[stupidme@mine xorg-server-git]$ makepkg  > /home/stupidme/Git/Cower/XorgTest2/MakePckgTest
==> Making package: xorg-server 1.19.6-1 (Sat 02 Jun 2018 17:07:00 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Cloning xserver git repo...
Cloning into bare repository '/home/stupidme/Git/Cower/XorgTest2/xorg-server-git/xserver'...
remote: Counting objects: 168099, done.
remote: Compressing objects: 100% (34878/34878), done.
remote: Total 168099 (delta 137861), reused 160411 (delta 131885)
Receiving objects: 100% (168099/168099), 38.00 MiB | 675.00 KiB/s, done.
Resolving deltas: 100% (137861/137861), done.
  -> Found xserver-autobind-hotplug.patch
  -> Found xvfb-run
  -> Found xvfb-run.1
==> Validating source files with sha512sums...
    xserver ... Skipped
    xserver-autobind-hotplug.patch ... Passed
    xvfb-run ... Passed
    xvfb-run.1 ... Passed
==> Extracting sources...
  -> Creating working copy of xserver git repo...
Cloning into 'xserver'...
done.
Switched to a new branch 'makepkg'
==> Starting pkgver()...
==> Updated version: xorg-server 1.20.0-1
==> Starting build()...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4

I did actually leave it to complete the build with both makepkg -rs and makepkg and both times I ended up with packages for xorg-server 1.20.0-1 which, I believe, defeats the purpose if I am trying to do a bisection.

If you could let me know how you wish me to proceed, I will gladly continue.

Irvine

Edit: I have not configured modeseting in any way.

Last edited by IrvineHimself (2018-06-02 16:36:56)

loqs · 2018-06-02 16:46:16

~~You need -e to cause makepkg to use use the existing src directory which contains the git bisection.~~
Edit:
No thats not it something else is going on.
Edit2:
I posted the PKGBUILD I used for testing 1.20.0 apologies
In the altered PKGBUILD there are two lines

_commit=82f8fc5ffc0065537896ec43ae60d67d9a164c75 # 1.20.0 tag
#_commit=ebfb06b11955a6c32500b7086be912ab96b753a7 # 1.19.6 tag

change that to

#_commit=82f8fc5ffc0065537896ec43ae60d67d9a164c75 # 1.20.0 tag
_commit=ebfb06b11955a6c32500b7086be912ab96b753a7 # 1.19.6 tag

Last edited by loqs (2018-06-02 16:59:54)

IrvineHimself · 2018-06-02 18:15:37

I am really glad you realised that. I have crashed at boot about half a dozen times, and my head is starting to spin like a scene from the Exorcist.

I don't know if it's relevant, but it seemed to want to start the bisection at xorg-server-1.19.0-1, and I was about to start downgrading everything related to xorg

For the moment, I am going to have to leave this; have something to eat and maybe sleep a little, but I will make the required mods and start afresh early tomorrow morning.
Irvine

Last edited by IrvineHimself (2018-06-02 18:16:38)

Lone_Wolf · 2018-06-03 13:37:46

IrvineHimself post #9 wrote:

Sorry, I just realised when I saw execute /usr/bin/sudo that I have makepkg sandboxed with seccomp and nonewprivs. Although, very rarely, the combination of hash tables and a suspect symlinked profile can really mess with my head, this is the first time since I set the system up that I can ever recall makepckg being a problem. I mean it is
probably the one pacman related program that is never supposed to have root privileges

I think makepkg tries to run "sudo pacman" to execute install/removal when using makepkg -rs .
On my system I use this in /etc/sudoers :

Defaults:username passwd_timeout=0
username local-hostname = /usr/bin/pacman, path/to/command2, /path/to/command3

Hopefully this helps you to configure your sandboxing so it will work with pacman -rs .

IrvineHimself · 2018-06-03 14:52:27

Lone_Wolf wrote:

.....Hopefully this helps you to configure your sandboxing so it will work with pacman -rs .

I keep all my Firejail symlinks in /usr/local/bin/FjSymlinks which I add to $Path. That way, when the occasion arises, and I need to disable Firejail, it's just a case of launching a bash which re-names the folder and removes it from $PATH

edit: with this method, you really need to start a new virtual terminal, or otherwise clear the hash tables, or else it will really mess with your head
edit2: (another bisection) it's not pacman that's the problem. It's makepkg raising privileges, Preventing this is the 'raison d'être' for the sandbox.

@loqs I am in the middle of running the bisection at the moment, (on the vanilla kernel and with Firejail disabled,) and I will get back to you with some results ASAP

Irvine

Last edited by IrvineHimself (2018-06-03 15:15:11)

IrvineHimself · 2018-06-03 15:47:04

Okay, here is the bisection result

[stupidme@mine xserver]$ git bisect $result good
c8c276c9569b3ca1e695682a5443f1b615c606bd is the first bad commit
commit c8c276c9569b3ca1e695682a5443f1b615c606bd
Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Date:   Wed Feb 28 01:19:43 2018 +0000

    glamor: Implement PixmapFromBuffers and BuffersFromPixmap
    
    It relies on GBM >= 17.1.0 where we can import BO with multiple
    planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).
    
    v2: Properly free fds in Xwayland
    
    [Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax]
    
    Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
    Reviewed-by: Daniel Stone <daniels@collabora.com>
    Acked-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Adam Jackson <ajax@redhat.com>

:100644 100644 f4534e30be40418d52459bdc35b504f101de0d19 773567b53d5df6d7f8f2d94bcefd43bd71247de4 M	configure.ac
:040000 040000 c0b6c60c7f495b364563a1c4bc2ab09a894d0226 631ddb5a8cd1df72577a082b9fb2b51c489bfe4f M	glamor
:040000 040000 e3c1ceb61a269c4672143f59d5dc149ce8ade721 033f6fbcc370ba076c2ca811ce67673368b0fa6f M	hw
:040000 040000 26e8d926cdd79d805a7850ee0c20c49f5e9de969 ac974d68896345c126304f5338c4f52abd83acfd M	include
[stupidme@mine xserver]$

Is that okay?

If you need them, I backed up numbered copies of Xorg.0.log.old after each test run.

If you do not need anything else, I will remove the following; run an update and restore my system to a more normal environment.

xorg-server-devel-1.19.99.901+14+g9d147305b-1  xorg-server-xdmx-1.19.99.901+14+g9d147305b-1
xorg-server-xephyr-1.19.99.901+14+g9d147305b-1  xorg-server-xnest-1.19.99.901+14+g9d147305b-1
xorg-server-xvfb-1.19.99.901+14+g9d147305b-1  xorg-server-xwayland-1.19.99.901+14+g9d147305b-1

Irvine

Last edited by IrvineHimself (2018-06-03 15:55:58)

loqs · 2018-06-03 15:57:50

No thats great unfortunately the commit does not want to revert cleanly.
Edit:
Looking at where you bisected the issue to that was supposed to be fixed with two patches added in xorg-server-1.20.0-5 which you already tested and did not resolve the issue for you.
Can you try xorg-server-1.20.0-6 see if that fixes it. If not

git checkout xorg-server-1.20.0
git cherry-pick 3da999a0390407d512bf784e4faf01482bfff9ea
git cherry-pick 4d5950ce14676f970d9de97380929a93948b98f2

See if using 1.20.0 built using autotools with the patches applies works.

Last edited by loqs (2018-06-03 18:22:23)

Arch Linux

#1 2018-06-02 05:55:07

xrandr and xorg-server

#2 2018-06-02 09:44:34

Re: xrandr and xorg-server

#3 2018-06-02 11:01:43

Re: xrandr and xorg-server

#4 2018-06-02 13:22:35

Re: xrandr and xorg-server

#5 2018-06-02 13:40:00

Re: xrandr and xorg-server

#6 2018-06-02 13:45:32

Re: xrandr and xorg-server

#7 2018-06-02 15:02:46

Re: xrandr and xorg-server

#8 2018-06-02 15:38:45

Re: xrandr and xorg-server

#9 2018-06-02 16:34:25

Re: xrandr and xorg-server

#10 2018-06-02 16:46:16

Re: xrandr and xorg-server

#11 2018-06-02 18:15:37

Re: xrandr and xorg-server

#12 2018-06-03 13:37:46

Re: xrandr and xorg-server

#13 2018-06-03 14:52:27

Re: xrandr and xorg-server

#14 2018-06-03 15:47:04

Re: xrandr and xorg-server

#15 2018-06-03 15:57:50

Re: xrandr and xorg-server

Board footer