startx fails

[Member schnabel]

I installed xorg-server-xorg-legacy, startx still fails
I edited /etc/X11/Xwrapper.config,
both

needs_root_rights = yes
needs_root_rights=yes

give an error (key not available.

the part from ~/.local/share/xorg/Xorg.0.log

[    21.387] (EE) modeset(0): drmSetMaster failed: Permission denied
[    21.387] (EE)
Fatal server error:
[    21.387] (EE) AddScreen/ScreenInit failed for driver 0
[    21.387] (EE)
[    21.387] (EE)

startx as root works fine.

thanks in advance

[Anonymous]

Helpful

Up

0

::

search box on antixforum main page
query: startx

the likely solution is described within a post (#66806) by anticapitalista, dated Sept 9, 2021

[Member schnabel]

Helpful

Up

0

::

Anonymous wrote:

search box on antixforum main page
query: startx

the likely solution is described within a post (#66806) by anticapitalista, dated Sept 9, 2021

That is what i did, and if i didn’t miss something, it is exactly what i described in my question. And it doesn’t work.

[Member schnabel]

Helpful

Up

0

::

Ok, there was a typo in Xwrapper.conf. I had needs_root_right, not needs_root_rights.

Why is there a need for all that at all? I never had any problems running startx without such?

[Moderator christophe]

Helpful

Up

0

::

I’ve had to always add that in antiX 17, when building up from core.
But with antiX 19, it’s come pre-setup that way. No more having to add that to Xwrapper.conf.

confirmed antiX frugaler, since 2019

[Member schnabel]

Helpful

Up

0

::

But why? What is the reason for such unusual needs?

[Anonymous]

Helpful

Up

2

::

Why is there a need for all that at all?
[..]
But why? What is the reason for such unusual needs?

antiX strives to support older devices.

Modern open source video drivers rely on kernel mode setting (KMS).
KMS provides an improved graphical boot with:
— less flickering
— faster user switching
— a built-in framebuffer console
— seamless switching from the console to Xorg

The Xorg server is responsible for loading appropriate module (driver) for the detected graphics card.
Prior to KMS, this operation was performed in userspace so necessitated launching X as root… and (so) up until 2015 [[[in Debian, ref Debian-Non-Root-X]]]. At that time (er, by that point in time) Debian chose to add logind, aka systemd-logind, into the stack ~~ rather than developing consolekit or other component to support PAM userspace authorization.

antiX eschews systemd. Under the current status quo, both systemd-logind and KMS are necessary to support “rootless X”
Debian (still) packages xorg-xserver–-legacy “setuid root Xorg server wrapper ~~ This package provides a wrapper for the Xorg X server, which is necessary for legacy drivers”. Similarly, back in 2009, The X executable had its setuid bit set in most distributions…

related, mentioned as an aside:
Toward supporting older graphics cards, including those which predated the advent of KMS, antiX kernel includes support for vesafb, fbdev… and these are incompatible with KMS.

(2009) https://www.phoronix.com/scan.php?page=news_item&px=NzM2MA

A Root-less X Server Nears Reality
X.ORG — One of the benefits of moving the different graphics hardware drivers over to using kernel mode-setting, an in-kernel GPU memory manager (whether it be GEM or TTM), and other newer X innovations is the possibility of now running the X Server without root privileges. By doing so, this of course improves the security since this very large chunk of code is no longer running with all of these high-privileged rights.
Due to now living in a KMS-enabled world, at least on the Intel and ATI side (the NVIDIA side is still slowly but surely coming via Nouveau), it’s rather easy to get the X Server running without any special rights. Intel’s Jesse Barnes explains on the X.Org mailing list that only a small patch is needed for the X Server and then a trivial one to the Direct Rendering Manager in the kernel. Right now, however, the X Server patch is a bit “hackish”, but he and other developers are currently collaborating on the best approach to implement this new capability.
It looks like we may be seeing root-less X Servers in the near future.

By 2010, KMS work to accomplish this had already been done by Intel and Red Hat, and debuted in (2014) fedoraproject XorgWithoutRootRights

Here’s how Ubuntu explained the changeover to, the emphasis toward, KMS back in 2010:

(page last edited 2010-07-11) https://wiki.ubuntu.com/X/Rootless
For video drivers that support kernel mode-setting (KMS), X can be set up to run as a non-root user.

Historically, X has been responsible for setting up the graphics modes (resolutions, refresh rates, etc.) X did this by talking to the hardware directly, which it could only do if it ran with root privileges.
The reason X was tasked with doing this work was to keep graphics as platform-agnostic as possible, so the same graphics code could be used for BSD and other *nix flavors.
Today, the feeling is that this mode-setting logic XXXshould be moved intoXXX BELONGS IN the kernel. Several video drivers now have this ‘kernel mode-setting’ (KMS) ability implemented.
In uBUNTU lucid, the -intel, -nouveau, and -radeon drivers all use KMS. But other drivers, including those for uncommon hardware and the proprietary -fglrx and -nvidia, do not support KMS at all.

^— less than ideal, I’ve pasted excerpts snipped from my too many notes without proofreading to gauge whether the result yields a coherent presentation.

[Member schnabel]

Helpful

Up

0

::

Thanks for your elaborate explanation.
I think i understand, more or less.
Most systems i used since systemd entered debian as default didn’t use systemd, and i never ran in such.
So i assume it is either not using kms or supporting *fb* which makes it the way it is.

If i wouldn’t have run in the typo i made in Xwrapper.conf, it would have confused me much less, but that really is my fault.

Again, thanks for the answer.

• This reply was modified 1 year, 7 months ago by schnabel.

[Author]

Posts