Talk:Non root Xorg

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 17:03, 3 December 2024 (UTC)
:: Your reply ~~~~

Instructions not working?

Talk status

This discussion is done as of 2015-11-30.

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

Talk status

This discussion is done as of 2020-07-30.

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

Talk status

This discussion is still ongoing.

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

Talk status

This discussion is still ongoing.

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-status outputs an error of any kind. IIRC, when I first switched to the elogind USE 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:

(systemd users) Is there any trace of pam_elogind.so in /etc/pam.d/system-auth?

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)

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

Talk status

This discussion is done as of 2022-01-24.

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 -- vt4 I 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 ~/.bashrc

alias 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

Talk status

This discussion is done as of 2022-01-24.

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

Talk status

This discussion is still ongoing as of 2022-01-23.

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"

Talk status

This discussion is still ongoing as of 2023-12-29.

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)