<beerman>
jaeger xorg-xwayland and waylandpp depend on egl-wayland, if I can install those without having to install the nvidia package I don't really care. I have no system with nvidia stuff right now and I intent on keeping it that way
groovy2shoes has quit [Ping timeout: 250 seconds]
groovy2shoes has joined #crux-devel
jue has quit [Ping timeout: 248 seconds]
groovy3shoes has joined #crux-devel
groovy2shoes has quit [Ping timeout: 268 seconds]
<jaeger>
I might just make nvidia skip installing the lib if egl-wayland is installed
<beerman>
i have no idea what would make more sense
<beerman>
something tells me that nvidia might ship more up to date stuff in their driver package, but I wouldn't want to download the full nvidia driver package if all i want is to satisify the dependency
<beerman>
i'll look around how other packagers handle this
<jaeger>
Worth noting that the egl-wayland package installs more than just the lib, whereas nvidia only does that
<jaeger>
So maybe nicer to have the egl-wayland package for pkgconf support, etc.
<beerman>
yeah
chrcav has quit [Ping timeout: 268 seconds]
<jaeger>
And I agree it wouldn't make any sense to install nvidia on a system without any nvidia hardware, so I'll go the route of making nvidia skip the lib if egl-wayland is installed already.
<beerman>
jaeger how would making nvidia depend on egl-wayland on wayland systems sound?
<jaeger>
Something like "if wayland is installed, tell the user to install egl-wayland"?
chrcav has joined #crux-devel
<beerman>
yeah, I mean, thats the best we could do at this point
<beerman>
no idea if its not working properly without that, so if an early exit of the build() would work. I do that, e.g. in libreoffice, because the build would just fail "later on", so I thought this might safe somebody some unneeded compile-time
<jaeger>
Not sure which way I prefer... making nvidia skip the lib if egl-wayland is installed is simple and stays out of the user's way, but on the flip side, if they install egl-wayland AFTER nvidia it creates a conflict
<beerman>
i can't make the decision for you, but I would opt for the less painful way and get it out of the way with the check and an early exit
<jaeger>
Another option would be to just skip it entirely in the nvidia port... because wayland itself doesn't require egl-wayland, only xorg-xwayland and waylandpp.
<jaeger>
If you're installing either of those you're gonna get it via depinst anyway
<beerman>
Like I said, I have no idea what meaning it has for a wayland session with nvidia drivers.. no idea what we are "loosing"
<jaeger>
Same... I'm not even sure (at the moment) how one runs a wayland session with an nvidia GPU
<jaeger>
yeah, that's already part of my local nvidia port... would still install only that file
<beerman>
thats somethign I could include with the port, I don't see why it wouldn't be part of it. I'd also be fine with "giving it away" to somebody that can actually make use of it
<beerman>
but it actually raises the question for me: how much of a hard dependency is it for both ports that pull it..
<jaeger>
all good, it comes with the nvidia source
<jaeger>
the symlink is there but the lib is not installed
<jaeger>
yes
<beerman>
ah, well, that is worth a try 🙂
<beerman>
man, that PKGBUILD makes me appreciate amdgpu so much more
<jaeger>
amdgpu is great... the old AMD fglrx shit was way worse than this even
<beerman>
i am old enough to know that what you say about fglrx is very true 😄
<beerman>
i dunno when they switched to gpu exactly, I just know that it was the right decision
<jaeger>
nvidia improved a LOT with libglvnd doing away with the need for stuff like gl-select... but it's still a mess
<beerman>
i do remember that script as well 😆 and the "new kernel - nvidia broke" game that i suspect to still hold some truth, but I dunno
<jaeger>
you still need to rebuild nvidia with a kernel change but it's far less annoying now
<jaeger>
without the gl-select dance
<beerman>
gotcha, at least there is that
<beerman>
i suspect that multi monitor support is still crap if you are a 3+ kinda person
<beerman>
but i dunno how future proof that is, with whats available today..
<jaeger>
I use 2 monitors so not sure about 3+
<beerman>
last time when I was out to buy a new one I've read the driver even craps out on windows with quadro cards... 3+ seems to be the number things can get extremely funny with nvidia. black screens on bios etc
<jaeger>
weird
<jaeger>
You'd think that would be a solved problem by now, heh
<beerman>
i was shopping whenever the rx580 was already the second pick, I dunno, but it still serves me very well
<beerman>
just to rate where i stopped caring about nvidia, so anything I say can be outdated etc 😄
<beerman>
anyway, it would be nice to have it running on nvidia
<beerman>
so.. on arch it looks like the nvidia package is heavily split, but they all depend on the one I formerly linked to. This only installs the gbm libs, not the egl libs, but for that it depends on egl-wayland..
<jaeger>
Well, still no luck with sway/sway-nvidia at all, but I think fixing up the issues with the nvidia Pkgfile is a good thing either way
<jaeger>
I might end up compressing other lib/symlink install sections into loops like the one for the component libraries...
<beerman>
usr/lib/libEGL_nvidia.so.525.89.02 do we have that file as well?
<beerman>
i only see that one symlink in your diff: ln -s libEGL_nvidia.so.$version $PKG/usr/lib/libEGL_nvidia.so.0
<beerman>
oh wait, i am stupid, nevermind
<jaeger>
Yeah, it's in there
<jaeger>
diff not showing the entire picture :)
<beerman>
yeah 😄 but well, I dunno really... did you already start sway with debug and verbose and looked if that told a new clue on whats going on?
<beerman>
e.g. like this `exec dbus-run-session -- sway -d -V 2> /tmp/sway.log`
<jaeger>
That's next, keep getting pulled back and forth for work stuff
<beerman>
Heh, I know that feeling as well..
<beerman>
just asking the most obvious and I dunno if I ever did: you do have seatd installed and running? launching sway with the dbus env? I also have this in my sway config: `exec "/usr/bin/dbus-update-activation-environment DISPLAY SWAYSOCK WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway"`
<jaeger>
yeah, can't even start sway on a non-nvidia system without seatd running
<beerman>
yeah, makes sense, its needed to avoid setting the suid-bit on the executable
<beerman>
ok.. this sorta bums me out. didn't danny say he used wayland now?
<beerman>
the diff looks good, i just don't know what else is missing
<jaeger>
Not sure how to tell if this is in the release or not
<jaeger>
0.16.2 is newer than that merge request, at least
<jaeger>
may need to rebuild wlroots
<beerman>
it is, but i don't see it in the changelog, at least its not obvious to me
<jaeger>
No luck. Rebuilding wlroots after installation of vulkan-validation-layers does produce a new footprint but no change in behavior, even after also rebuilding sway packages as well.
<beerman>
does this have two monitors connected?
<jaeger>
no
<beerman>
darn it
<jaeger>
Romster: if you're running a wayland session on nvidia hardware can you share some details? Like what compositor/WM/session and how
<beerman>
i know he was looking at wayfire at some time
<jaeger>
Yeah, I check those two sections of the README periodically but not much there as you've seen
darfo has quit [Ping timeout: 268 seconds]
<beerman>
i hope that romster can shed some light on what might be missing
<beerman>
i asked chatgpt and it answered that: https://dpaste.com/2GFSXFERN the sway config looks a bit weird, but still, not too shabby for chatgpt 😄
<beerman>
you can ask it for instructions to do that on CRUX and it starts with prt-get depinst mesa-dri 😬 oh well 😄
<beerman>
but anyway, eglstreams is basically what made ddevault hate nvidia so much that he had that weird "--next-time-i-wont-buy-nvidia" flag in sway 😄 gbm support is what you should try to focus on, as much as i can see it.