The SDDM display manager apparently randomizes the filename of the Xauthority file on each boot, placing it in /var/run/sddm
The current openrc init script packaged with gentoo's x11-misc/x11vnc cannot "guess" where Xauthority is when the display manager is SDDM, and so fails to run on boot.
Upstream, SDDM has no plans to alter this "feature" and instead recommends that x11vnc be executed from within the file:
Their discussion is here:
I currently have the init script working by deleting all the lines that test for xauth and check if a file exists in '/var/run/sddm/' but that doesn't seem to me to be good practice. Neither is good practice, I think, to edit startup scripts in unique program locations that I'll forget about in two weeks.
I could start up the vnc server through the wm's application autostart menu, but I would rather vnc's execution be independent of any logins.
Any ideas? Maybe an alteration in the init script to test for SDDM's Xauthority file? I tried, but the scripting logic in '/etc/init.d/x11vnc.init.d' was making me seasick. I'm too new at this. Still, I will provide the init I edited if requested.
I experimented with the solution of using the Xsetup file to launch x11vnc. It was documented in the link I provided. It works as expected, but the Xsetup file is quietly overwritten with a blank file each time sddm is emerged, such as in an update. The helper program etc-config does not alert the user about this change either, supposedly because the location of Xsetup is outside etc-config's sphere.
please retry with 0.9.16
This issue still exists with 0.9.16-r1.
My experience trying to update the x11-.../... packages marked stable a few days ago may provide a clue to resolving this problem.
My temporary solution is to:
package.mask =x11-base/xorg-server-1.20.4 (The newly stable version)
unmerge the driver modules my system uses (x11-drivers/xf86-...)
emerge -1uvd x11-base/xorg-server which will pull in:
=x11-base/xorg-server-1.20.3 (The previous version that works)
x11-drivers/xf86-... used by my system
The remaining x11-.../... remain the recently stablized packages.
Description of problem solved by above:
Version x11-base/xorg-server-1.20.4 was marked stable in the past few days (along with additional x11-.../... packages). I emerged @world which installed stable x11-.../... packages. I rebooted to a black screen and working mouse pointer. Xorg.log stalls trying to start sddm with "Failed to open authorization file: /var/run/sddm/<random name>". The file actually exists, contains a Magic Cookie, and is owned by ssdm:ssdm.
Trying to update the world again with:
emerge -avu --newuse --deep --autounmask-backtrack=y --autounmask-write @world
Emerge wants to remove my mask of =x11-base/xorg-server-1.20.4 so I didn't do something exactly right.
=x11-base/xorg-server-1.20.4 broke my system
=x11-base/xorg-server-1.20.3 fixed it.
The changes made between the 2 may help find a solution.
Stable x11-misc/sddm-0.18.0 is installed.
Solved my bug when downgrading xorg-server:
add --autounmask-keep-masks to the emerge options
That will take care of emerging the x11-drivers/xf86-... use by the downgraded version of xorg-server.
edit file package.mask to add =x11-base/xorg-server-1.20.4
emerge -av --update --newuse --deep --autounmask-backtrack=y --autounmask-write --autounmask-keep-masks --keep-going @world