Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Solved] Non root Xorg on AMD video cards
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next  
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 487
Location: South America

PostPosted: Sun Aug 02, 2020 2:57 pm    Post subject: Reply with quote

halcon wrote:
keks24 wrote:
more like a draft, which you then can merge with the original Wiki article

Ah, it works so...

You can directly edit an article if you leave it in a decent state afterwards. It is practices like e.g. editing a 'finished' article just to add the title of a new section and the sentence "I'll write this later" as its content that are frowned upon.
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Sun Aug 02, 2020 3:00 pm    Post subject: Reply with quote

I don't see why would information regarding this hurt or confuse someone.
When someone ends up on that Wiki page that's because that person is interested in running rootless Xorg
Now yes, elogind does that job, but obviously there are people who don't want or need extra stuff like login managers, display managers, seat managers, *kits ....
If that's the case then all that Wiki page does is pointing them in the right direction.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15999

PostPosted: Sun Aug 02, 2020 5:25 pm    Post subject: Reply with quote

I will probably go to the trouble of converting to elogind-based rootless X at some point, but for me, part of the appeal of the drm_master_util approach is that, as described, it actually will work out of the box with no changes to user scripts or system configuration. To make the elogind approach work, I need several workflow changes (one of which I really don't like).
  • dbus must be installed, and always running.
  • It's no longer possible to have a delayed console logout after X starts. Per comment from SlashBeast, the workflows that will work with elogind are either leave the shell sitting there (which is a security problem if the system is not physically secured, as in a pre-pandemic office) or use exec to replace the shell, which means there is no grace period to return to the shell if the server does not start correctly.
  • Change the X startup flow to add a dbus-launch into the pipeline ahead of the window manager. (As an aside, why is this needed? I've seen it suggested several times across various threads, but never explained why another dbus is needed here. Reading man dbus-launch tells me how to do it, but not why I would want this.)
On the downside for the drm_master_util approach (and for this, I am considering both the X11 driver patch and the helper utility), it is clearly hacked together and assumes that there are no malicious users in the same namespaces. It doesn't check for errors in any of several system calls that could fail. It doesn't have any permissions enforcement to ensure that the privileged DRM calls are used only where they should be, so you might as well just patch the kernel not to enforce those checks and then let X make the call directly.

I'm dubious whether elogind has equivalent checks to prevent some random shell in my session from doing the same, but the elogind code is so large and complicated that I could have missed it. Similarly, I've seen several references to loginctl suspend and similar. I don't want processes running as the logged in user to be able to suspend the system, so I'm leery of having elogind suddenly offering that capability. Only root, or a physically present user who can press the power button, should have that capability.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Sun Aug 02, 2020 5:39 pm    Post subject: Reply with quote

kajzer wrote:
I don't see why would information regarding this hurt or confuse someone.
When someone ends up on that Wiki page that's because that person is interested in running rootless Xorg
Now yes, elogind does that job, but obviously there are people who don't want or need extra stuff like login managers, display managers, seat managers, *kits ....
If that's the case then all that Wiki page does is pointing them in the right direction.


It is common that if user cannot get things running due to some misconfiguration like lack of update config files or dbus not running, he will try alternative approaches, and I rather not have users going unsupported path, with patching ebuilds or dropping patches in /etc/portage/patches, then reporting that something is not working.

if you want to have pages about out of bounds and unsupported, manual, flow with patching and installing drm_master_util out of tree, please create such, but write big notice at the very beginning page that this is not supported by Gentoo and because of that, no bug regarding issues connected to this are to be reported to bugzilla, but please do not join pages that have supported methods and then add alternative medicine there.
Back to top
View user's profile Send private message
keks24
n00b
n00b


Joined: 12 May 2017
Posts: 4
Location: Cologne, Germany

PostPosted: Sun Aug 02, 2020 5:40 pm    Post subject: Reply with quote

Hu wrote:
[...] which is a security problem if the system is not physically secured, as in a pre-pandemic office [...]


That is why I am using "physlock". I cannot change TTYs or use the "sysrq" key, when locked.

I also combined it with "xautolock" and a nice "awesome_notifier" wrapper.

Code:

$ physlock -msp "$(< /home/ramon/.config/physlock/lock_ascii_bigmono12.logo)" >/dev/null 2>&1


Code:

-d       fork and detach, parent returns after everything is set up
         (useful for suspend/hibernate scripts)
-h       print short usage help and exit
-l       only lock console switching
-L       only enable console switching
-m       mute kernel messages on console while physlock is running
-p MSG   Display MSG before the password prompt
-s       disable sysrq key while physlock is running
-v       print version information and exit


https://github.com/muennich/physlock

xautolock: https://codeberg.org/keks24/dotfiles/src/branch/master/home/username/.zprofile#L62-L69
locker: https://codeberg.org/keks24/dotfiles/src/branch/master/home/username/bin/locker
awesome_notifier: https://codeberg.org/keks24/dotfiles/src/branch/master/home/username/bin/awesome_notifier
_________________
This sentence is wrong!
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Sun Aug 02, 2020 5:43 pm    Post subject: Reply with quote

Hu wrote:
[*]Change the X startup flow to add a dbus-launch into the pipeline ahead of the window manager.


This is not needed. The only reason why you might want to do it is if you're running some big DE. dbus built with X USE flag will start ad-hoc when needed, for example, by gtk3 file picker.

To go with elogind, all you need is dbus running (rc-update add dbus default), and elogind USE flag enabled, that's all. The `exec` flow is there because X starts on the logged-in tty, rather than on tty7 (that is not owned by your user, since you have not logged there).
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Sun Aug 02, 2020 6:26 pm    Post subject: Reply with quote

SlashBeast wrote:
It is common that if user cannot get things running due to some misconfiguration like lack of update config files or dbus not running, he will try alternative approaches, and I rather not have users going unsupported path, with patching ebuilds or dropping patches in /etc/portage/patches, then reporting that something is not working.

if you want to have pages about out of bounds and unsupported, manual, flow with patching and installing drm_master_util out of tree, please create such, but write big notice at the very beginning page that this is not supported by Gentoo and because of that, no bug regarding issues connected to this are to be reported to bugzilla, but please do not join pages that have supported methods and then add alternative medicine there.


Indeed, understandable.
Of course I was thinking that option would be absolutely last on the list of options, clearly indicating that this route is intended only for people who feel adventurous and like to take risks.
Maybe linking to this thread would be enough, I'm not sure.
Perhaps this thread is not clear enough about the steps...
Anyway, there was talk about getting this into the portage and I knew it right then that's not going to happen.
Wiki.. why not, but I understand the reasons why not and I'm good either way.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Sun Aug 02, 2020 7:16 pm    Post subject: Reply with quote

kajzer wrote:
Anyway, there was talk about getting this into the portage and I knew it right then that's not going to happen.


Getting it into portage is not a problem, but maintenance is. It all goes to who's going to deal with it. If we were to add drm_master_util into tree, it's not an issue, but then we need to patch xorg and drivers. So let's assume there's new release of xorg and driver, and for some reason, patches no longer fit, either we postpone getting updates into tree, or we release new versions without this feature, effectively breaking a lot of systems, neither is good.

If you can upstream support for drm_master_util, then it's another story.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Sun Aug 02, 2020 7:16 pm    Post subject: Reply with quote

kajzer wrote:
Anyway, there was talk about getting this into the portage and I knew it right then that's not going to happen.


Getting it into portage is not a problem, but maintenance is. It all goes to who's going to deal with it. If we were to add drm_master_util into tree, it's not an issue, but then we need to patch xorg and drivers. So let's assume there's new release of xorg and driver, and for some reason, patches no longer fit, either we postpone getting updates into tree and then spend effort on forward porting patches, or we release new versions without this feature, effectively breaking a lot of systems, neither is good.

If you can upstream support for drm_master_util, then it's another story.
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 487
Location: South America

PostPosted: Sun Aug 02, 2020 7:32 pm    Post subject: Reply with quote

SlashBeast wrote:
I was just genuinely curious why would you go extra mile to replace something that is already integrated and works by default, [...] and I just cannot wrap my head what problem would another solution solve, when it's transparent and does not even have an interface that one could 'not like'.
elogind is still a complex process running as root, that does too much for the needs of Xorg. I'd argue that having to 'speak' the D-Bus protocol already puts a limit on how simple the process can be. This isn't elogind's fault, of course, it's systemd's; elogind is just forced to stay compatible. But I digress.

I do acknowledge that, since 'big' desktop environments already make use of seat and session managers, Polkit and D-Bus, using these mechanisms to also allow Xorg to run as an unprivileged process comes at no extra cost in those cases.

But if you look at the mechanism, all that Xorg needs is a separate process that performs privileged open() and ioctl() calls on its behalf, and hands file descriptors to it. It doesn't actually need the freedesktop.org session concept other than as 'courtesy' to those desktop enviroments, so it doesn't need PAM, the chosen mechanism to implement sessions, either. And let's be grateful that the methods that Xorg calls do not require authorization, or, in addition to elogind and D-Bus, we'd be forced to also have Polkit.

Personally, I don't think drm_master_util is the best solution, as it needs per-driver patches. A better one IMO would be a process that replaces elogind's role, doing only the privileged calls and the file descriptor passing, with a simple request-response protocol. That would only require a patch to Xorg itself, and would reuse the mechanisms already in place for passing those FDs from Xorg to the drivers that need them. But I also acknowledge the fact that drm_master_util and the patches to the X11 drivers exist, and something that implememts the solution I'd like does not, as far as I'm aware. And even then, drm_master_util is still simpler than elogind.

SlashBeast wrote:
if you want to have pages about out of bounds and unsupported, manual, flow with patching and installing drm_master_util out of tree, please create such, but write big notice at the very beginning page that this is not supported by Gentoo and because of that, no bug regarding issues connected to this are to be reported to bugzilla, but please do not join pages that have supported methods and then add alternative medicine there.
I'm also not a fan of what you did to the Wiki article. It did mention the logind provider-based solution, it clearly (IMO) labeled it as the officially supported one by upstream and Gentoo, it referenced the relevant news items, and even attempted to explain the underlying mechanism. Something you just decided to remove as well, for who knows what reason. And if you look at the article's history, you'd realize that the "alternative medicine" was the original content, and that the supported (recent!) solution was the late addition. To the best of my knowledge, that article had no glaring errors.

Given that, a more polite approach would have been better. If you wanted to make the instructions for users of the officially supported solution clearer, and separated from the technical details, you could have rearranged the text in the 'supported' section, so that the latter could be skipped by uninterested readers. If you wanted to point out additional drawbacks of the 'alternative' solutions, you could have added the information to the relevant sections. If you thought that readers would not understand that solutions that rely on patching or ebuilds that are not in Gentoo's repository are clearly unsupported, you could have added that big notice. Someone had already mentioned the risk of adding users to the input group.

Frankly, if someone who wasn't a developer had done what you did, I would have seriously considered simply reverting the edits.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Sun Aug 02, 2020 7:45 pm    Post subject: Reply with quote

GDH-gentoo wrote:
Frankly, if someone who wasn't a developer had done what you did, I would have seriously considered simply reverting the edits.


Anyone can become a developer and then can join X11 team to make himself responsible for Xorg and Xorg related things in gentoo. I did what I decided is best to keep things simple and technically correct. I did not removed the history to make old page unreadable, instead I overhaul the page to focus it only on what's supported, you can take the old content from history and move it to page that is clearly marked as user-supported, so people are aware of it.

Join the project and make yourself the maintainer of those things, possibly making them supported.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6717

PostPosted: Mon Aug 03, 2020 4:27 am    Post subject: Reply with quote

I thought developers were required to know why Gentoo exists and how things are run?

We already maintain a lot of things (without demanding fake authority over others), but it's hard to do so when someone with next to zero involvement in the community beyond showing up once every two years to lecture us runs in and begins kicking the sandcastle down repeatedly.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4885
Location: Dallas area

PostPosted: Mon Aug 03, 2020 9:26 am    Post subject: Reply with quote

Slashbeast, I still think this is wrong, (xorg-server-1.20.8-r1.ebuild)

Code:
    if use systemd || use elogind; then
        XORG_CONFIGURE_OPTIONS+=(
            "--enable-systemd-logind"
            "--disable-install-setuid"
            "$(use_enable suid suid-wrapper)"
        )
    else
        XORG_CONFIGURE_OPTIONS+=(
            "--disable-systemd-logind"
            "--disable-suid-wrapper"
            "$(use_enable suid install-setuid)"
        )
    fi


In my opinion, there should be 4 use flags, systemd, elogind, suid, suid-wrapper

systemd and elogind -- login manager runs as root, should start X without a problem
Suid -- run X as setuid root
Suid-wrapper -- this was supposed to allow non-root to start using the small setuid wrapper program.

systemd/elogind are mutually exclusive and suid/suid-wrapper should not be needed as *logind already runs as root.
suid/suid-wrapper should be mutually exclusive.
and without any of the above flags, then you should wind up with an X server without any wrapper or being suid (regular program permissions)

From the xorg.wrap man page
Quote:
The Xorg X server may need root rights to function properly. To start the Xorg X server with these rights your system is using a suid root wrapper installed as /usr/lib/xorg/Xorg.wrap which will execute the real X server which is installed as /usr/lib/xorg/Xorg.

By default Xorg.wrap will autodetect if root rights are necessary, and if not it will drop its elevated rights before starting the real X server. By default Xorg.wrap will only allow executing the real X server from login sessions on a physical console.

_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Mon Aug 03, 2020 9:37 am    Post subject: Reply with quote

Anon-E-moose wrote:
Slashbeast, I still think this is wrong, (xorg-server-1.20.8-r1.ebuild)

Code:
    if use systemd || use elogind; then
        XORG_CONFIGURE_OPTIONS+=(
            "--enable-systemd-logind"
            "--disable-install-setuid"
            "$(use_enable suid suid-wrapper)"
        )
    else
        XORG_CONFIGURE_OPTIONS+=(
            "--disable-systemd-logind"
            "--disable-suid-wrapper"
            "$(use_enable suid install-setuid)"
        )
    fi


In my opinion, there should be 4 use flags, systemd, elogind, suid, suid-wrapper


The purpose of this is that, suid is not needed unless you run some old non-KMS drivers, then suid-wrapper will use root anyway, even if logind provider is there. This is done like that to have least privileges that are needed. If you believe this is something that is wrong, please create bug on bugzilla so we can discuss and track it there.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Mon Aug 03, 2020 9:49 am    Post subject: Reply with quote

Ant P. wrote:
I thought developers were required to know why Gentoo exists and how things are run?

We already maintain a lot of things (without demanding fake authority over others), but it's hard to do so when someone with next to zero involvement in the community beyond showing up once every two years to lecture us runs in and begins kicking the sandcastle down repeatedly.


This is second time I see you making those personal remarks about me. Not sure what you mean by my supposedly lack if involvement in two years, forums is not only place that community is, check bugzilla, check irc. I've been active member of those for last 15 years or so. I'd appreciate if you could keep this antagonism of yours at minimum.

For the record, I've not come here to rain on your parade. In this thread I asked what is the drive for drm_master_util when there's already elogind and got answer that some of you prefer to not use dbus and other things when you can have small drm_master_util, I am okay with that.

Then I've explained that if you want to upstream it, have as supported in gentoo, you will need to jump guns and maintain it, adding a single package into tree is none of a problem, maintaining patched xorg and drivers however is, which I also explained reasoning behind. Simply, someone needs to deal with it, and forward port patches if they no longer fit, to not postpone updates that could include security fixes. We already had festival of issues like that on net-misc/openssh with 'hpn' patches/USE flag, and for a long time either update were postponed or you had gaps in ebuild, some versions had hpn USE flag, others did not.

Gentoo is driven by people who went and become developers and then maintain things they personally use and care about, if you wish to have drm_master_util support in Gentoo for everyone, you know how can you proceed.

The wiki page in question dates back to 2014, and your changes are not deleted, they're in history that can be forked into a new page marked as user-supported. No idea what's your issue here.
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 5:45 pm    Post subject: Reply with quote

There's another way, to patch the kernel, it may go with the new USE flag or with existing experimental flag
That way there's no need for drm_master_util and patching the drivers.

If I understand this right, there can be only one drm master and if the gpu driver becomes one then it's the only one with rights to change stuff.
The other way would be to drop master, well that one I left untouched and it still requires root privileges.
So I don't see how this approach is bad in any way, except if there's some software on the system which for some reason becomes drm master before starting Xorg

Works fine here, if anyone knows why this could be bad I would like to know.


Code:
/usr/src/linux-5.7.12-gentoo/drivers/gpu/drm/drm_ioctl.c

-   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_AUTH),
    DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY),
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4885
Location: Dallas area

PostPosted: Mon Aug 03, 2020 6:02 pm    Post subject: Reply with quote

kajzer wrote:
There's another way, to patch the kernel, it may go with the new USE flag or with existing experimental flag
That way there's no need for drm_master_util and patching the drivers.

If I understand this right, there can be only one drm master and if the gpu driver becomes one then it's the only one with rights to change stuff.
The other way would be to drop master, well that one I left untouched and it still requires root privileges.
So I don't see how this approach is bad in any way, except if there's some software on the system which for some reason becomes drm master before starting Xorg

Works fine here, if anyone knows why this could be bad I would like to know.


Code:
/usr/src/linux-5.7.12-gentoo/drivers/gpu/drm/drm_ioctl.c

-   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_AUTH),
    DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY),


It's more a way for to keep others from getting/seeing "sensitive info" on your system.
Doesn't matter to me, as I don't have any other users on my system and it's confined to the gpu/drm subsystem.

If you're going to do one, then do both, IIRC the drop part comes into play if you want to do something like swap vt's on the console.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 6:10 pm    Post subject: Reply with quote

I see, yeah doesn't matter to me as well.

I don't need to swap vt's so I'll leave drop part as root, better not to think if some app will use that function to drop master.
I'll stay with this one, currently I just changed the source directly and compiled the kernel, I will make a diff and patch future kernels.
Back to top
View user's profile Send private message
SlashBeast
Developer
Developer


Joined: 23 May 2006
Posts: 2903

PostPosted: Mon Aug 03, 2020 6:22 pm    Post subject: Reply with quote

You can always make attempt to upstream this support after all, mail patches to xorg-devel and amdgpu mailing lists, if you succeed, all you will need would be a drm_master_util in tree, which can be proxy maintained without any issue. It was the same case with elogind, some software required upstreaming support first.
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 6:30 pm    Post subject: Reply with quote

I don't know if you are talking to me or in general, I don't care about that and I'm not pushing this to get into the tree or in Wiki.
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 6:41 pm    Post subject: Reply with quote

Interestingly I just synced and I've got new kernel 5.8.0, seems like they've changed that now

Code:
DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0),
DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0),


I think it's allowed now by default.
I'm not sure what that 0 means, I will compile it like it is without patching, it should work I guess.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4885
Location: Dallas area

PostPosted: Mon Aug 03, 2020 7:11 pm    Post subject: Reply with quote

kajzer wrote:
Interestingly I just synced and I've got new kernel 5.8.0, seems like they've changed that now

Code:
DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0),
DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0),


I think it's allowed now by default.
I'm not sure what that 0 means, I will compile it like it is without patching, it should work I guess.


I believe "0" turns off all DRM_ settings.

Edit to add: the whole sticking point to rootless X was needing to be roof for the drm set/drop capabilities, it was set overly aggressive, now looks like it's going the other direction. :lol:
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 7:33 pm    Post subject: Reply with quote

Anon-E-moose wrote:

Edit to add: the whole sticking point to rootless X was needing to be roof for the drm set/drop capabilities, it was set overly aggressive, now looks like it's going the other direction. :lol:


Yeah, interesting timing btw :lol:
was looking to find some info about that change but I found no comments about it, found the change but no comments
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=faa392181a0bd42c5478175cef601adeecdc91b6
Maybe it got into this comment
Quote:
- Core DRM had a lot of refactoring around managed drm resources to make drivers simpler.


So, I just booted 5.8.0 , there's no drm_master_util in /usr/bin , no patched drivers, no patched kernel and it works :D

I guess further discussion about this (drm_util and driver patches) is pointless now, in Wiki I guess it should be mentioned that starting with kernel 5.8.0 no steps are needed.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4885
Location: Dallas area

PostPosted: Mon Aug 03, 2020 7:36 pm    Post subject: Reply with quote

kajzer wrote:
Anon-E-moose wrote:

Edit to add: the whole sticking point to rootless X was needing to be roof for the drm set/drop capabilities, it was set overly aggressive, now looks like it's going the other direction. :lol:


Yeah, interesting timing btw :lol:

So, I just booted 5.8.0 , there's no drm_master_util in /usr/bin , no patched drivers, no patched kernel and it works :D

I guess further discussion about this (drm_util and driver patches) is pointless now, in Wiki I guess it should be mentioned that starting with kernel 5.8.0 no steps are needed.


Then the only thing needed for older kernels, is to unset those perms.

Something like
Code:
diff -u /usr/src/linux-5.5/drivers/gpu/drm/drm_ioctl.c .
--- /usr/src/linux-5.5/drivers/gpu/drm/drm_ioctl.c   2020-04-18 07:17:51.832750901 -0500
+++ ./drm_ioctl.c   2020-08-03 14:16:24.895825382 -0500
@@ -599,8 +599,8 @@
    DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
    DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx, DRM_AUTH),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
-   DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0),
+   DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0),
 
    DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx, DRM_AUTH|DRM_ROOT_ONLY),
    DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),


Edit to add: Does this allow switching back to the vt???
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
kajzer
l33t
l33t


Joined: 27 Nov 2014
Posts: 815

PostPosted: Mon Aug 03, 2020 8:36 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Edit to add: Does this allow switching back to the vt???


You still have to start X with "startx -- vt1"
tty0 gives permission denied

I was able to do Ctrl-Alt-F2 , Ctrl-Alt-F1 brought back the desktop.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 6 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum