Talk:Non root Xorg
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.Instructions not working?
I spent some time on this but was unable to get it working. My best explanation is that my user lacks the (root) rights necessary to become the DRM master (for /dev/dri/card0). My understanding is that systemd and D-Bus will provision these rights to users who wish to run Xorg. Since my Gentoo deployment lacks these systems, I observed Xorg failed to start as a regular user with the log entry, "no primary bus or device found". Note that Xorg would still run without issue when run as root.
If someone gets Xorg working without suid set and without systemd/D-Bus, please remove the warning box I posted on this page (and add the additional necessary steps).
Ennui (talk) 19:17, 10 June 2015 (UTC)
- It seems the key step you missed was adding your user to the video group. As with using direct rendering, the user needs permissions to access the video hardware. If this is done, it certainly works for Intel without systemd, ConsoleKit, or anything other than standard UNIX user/group permissions. --JJS (talk) 21:32, 30 November 2015 (UTC)
Handling of DRM IOctls
Hello,
Please do not edit Non_root_Xorg#Handling_of_DRM_ioctls, as I am currently working out a draft on my user page. I want to persist the diff files and provide preciser instructions.
Thank you!
Keks24 (talk) 04:26, 27 July 2020 (UTC)
- Too late, Piotr Karbowski (Slashbeast) , doesn't want that content in the article, apparently. Old content is available as part of the article's history, as usual. — GuillermoDH (talk) 00:56, 31 July 2020 (UTC)
- Wow! This is outright vandalism, it just destroyed a year of work by the community and graffiti'd over it with poorly formatted mechanical instructions for one dude's pet project that could've gone in a pkg_postinst instead. Someone please rein this loose cannon in already, their open contempt toward Gentoo as a whole is unacceptable. Ant P. (talk) 12:06, 31 July 2020 (UTC)
- Just mentioning it: Everything is licensed under CC-BY-SA-3.0, so be bold as the Editing_pages article says. :) By the way: equery files xorg-server does not output me any wrapper Piotr Karbowski (Slashbeast) is mentioning or does he mean drm_master_util, which he has deleted? Keks24 (talk) 19:28, 31 July 2020 (UTC)
- He means the /usr/libexec/Xorg.wrap program. It will be there if xorg-base/xorg-server is installed with both the elogind and suid flags set, or both the systemd and suid flags set. — GuillermoDH (talk) 00:53, 1 August 2020 (UTC)
Non root Xorg as service
It seems that recent Xorg versions require elogind, as indicated in this manual, but that elogind requires user to be logged in. I have a kodi service running as user kodi which cannot start anymore because of that. I now have to modify it to be run as root. I think that this should be indicated in this page for other user searching why such service does not work anymore. — The preceding unsigned comment was added by Sveyret (talk • contribs)
- I'm running into that same problem.
- Maybe an alternative would be to perform what the header warning suggests: "Users who wish to start X remotely will need to take extra steps to ensure that a seat is given to the user from which they start X"
- Unfortunately I have no idea what or how to do this...
- Samb (talk) 08:08, 13 October 2020 (UTC)
Insufficient detail
The troubleshooting section says
One can confirm that elogind is working by running
loginctl user-status. If it does not work...
What does "does not work" mean in this context? What is the expected result of this command if it "works," and what is the different result if it "does not work"? (This same shortcoming is, frustratingly, also in the official Gentoo news item xorg-server dropping default suid, added by Piotr Karbowski (Slashbeast) on 2020-06-24.) As a neophyte to elogind, I've never encountered this command before, so I don't know what its usual output (if any) is, thus don't know if the output I'm seeing constitutes a "working" or "not working" status. Median (talk) 21:47, 26 September 2020 (UTC)
- I believe what it means is if
loginctl user-statusoutputs an error of any kind. IIRC, when I first switched to theelogindUSE flag I got something like this:
user $loginctl user-status
Failed to create bus connection: No such file or directory
- If everything is working correctly, the output should look something like this:
user $loginctl user-status
user (1000)
Since: Tue 2020-10-13 12:03:02 CDT; 2h 16min ago
State: active
Sessions: *1
Linger: no
Unit: user-1000.slice
- xxc3nsoredxx (talk) 19:40, 13 October 2020 (UTC)
- Thank you, I have incorporated your advice in this edit.
- However, this section still needs some work. For instance, it says:
This does not tell the reader whether this string should appear in this file, or whether this answer is different for non-systemd users. Median (talk) 11:23, 20 November 2020 (UTC)(systemd users) Is there any trace of pam_elogind.so in /etc/pam.d/system-auth?
- However, this section still needs some work. For instance, it says:
- I'm running elogind with openrc and see no mention of pam_elogind.so in /etc/pam.d/system-auth and everything seems to work for me. However, equery f elogind does say that it installed it into /lib64/security/pam_elogind.so. Maybe Piotr Karbowski (Slashbeast) can provide more input as to whether it should or shouldn't show up in the PAM config.
- I also copied the full output into the main page. xxc3nsoredxx (talk) 07:52, 24 November 2020 (UTC)
A logind provider is not required
It is possible to run non root (rootless) Xorg without a logind provider. All that is needed for rootless Xorg to work is a DRM kernel driver that also supports KMS, and a DDX driver that uses it. The only issue is that Xorg will try to open /dev/tty0 and fail to run, but that can be fixed by adjusting the permissions on /dev/tty0 or specifying the VT Xorg should use with the vtXX parameter.
EDIT: I've just noticed that in an older revision of this page, this alternative method was mentioned. Why did it get removed? It is still valuable information in my opinion, even if it's a method that isn't officially supported.
Nket (talk) 03:30, 11 July 2021 (UTC)
- I don't think adjusting permissions on any of the standard entries in /dev is generally a good longterm solution. It may not persist across boot unless you change any udev rules that might be managing that specific device file. At least it didn't on my machine. After trying to replicate the behavior you described by disabling elogind, configuring my window manager to start without using dbus, and rebooting, I get the following in my logs after running
startx ./test_no_elogind.xinitrc:
- FILE
~/.local/share/xorg/Xorg.0.log[ 535.573] (--) using VT number 7 ... snip ... [ 535.598] (EE) Fatal server error: [ 535.598] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied) [ 535.598] (EE) [ 535.598] (EE)
- I didn't get /dev/tty0 like you did, but this is what /dev/tty4 (my current TTY) and /dev/tty7 look like on my machine:
user $ls -alF /dev/tty{4,7}crw-------. 1 user tty 4, 4 Jan 23 11:59 /dev/tty4 crw--w----. 1 root tty 4, 7 Jan 23 11:25 /dev/tty7
- When I instead run
startx ./test_no_elogind.xinitrc -- vt4I get dwm as expected. To make it more user-friendly, you can even add an alias in your .bashrc to make it work on any TTY without having to manually specify it each time:
- FILE
~/.bashrcalias startx="startx /path/to/xinitrc -- vt$(tty | sed -e 's|/dev/tty||')"
- So this seems like a viable solution! I'll add it in sometime today. Just for reference, this is the xinitrc that I was using:
- FILE
test_no_elogind.xinitrc[[ -f ./.Xresources ]] && xrdb -merge ./.Xresources urxvtd --quiet --opendisplay --fork exec ./dwm
- EDIT: I will still test it by uninstalling sys-auth/elogind before adding it just to make sure it being there hasn't changed some other relevant system configs.
- xxc3nsoredxx (talk) 19:54, 23 January 2022 (UTC)
- I've added the instructions for running without a logind provider: Special:Diff/1036186/1044582
- xxc3nsoredxx (talk) 01:15, 24 January 2022 (UTC)
Running i3
starting X with:
user $startx /usr/bin/i3
(EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
Solution :
user $startx /usr/bin/i3 -- vt1
where 1 is number terminal where I'm logged, if not 1, adjust the command
Cacoch (talk) 01:53, 20 September 2021 (UTC)
- I've added instructions similar to this as part of the discussion in "A logind provider is not required". The relevant changes: Special:Diff/1036186/1044582
- xxc3nsoredxx (talk) 01:20, 24 January 2022 (UTC)
Starting X Remotely
It is suggested that "additional steps" must be taken to properly assign an elogind seat to remote users intending to execute 'startx', but no detail is given. Perhaps these stages should be described in slightly more detail?
Owd (talk) 16:13, 23 January 2022 (UTC)
Definition of "locally seated user"
As of 12/29/2023, the article has at the top in an "important" box this sentence:
The logind provider does not provide the same level of access as the legacy SUID-enabled Xorg does. The elogind provider allows a locally seated user to be granted access to $TTY and input devices.
What is the definition of a "locally seated user"? How do you or the operating system identify whether a user is locally seated or not? I tried searching using this term and practically no results, so I'd like to understand how you would distintguish a "locally seated user" from others, especially in terms of values associated with their login/shell. Jlpoole (talk) 20:01, 29 December 2023 (UTC)