| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems to be quite a few issues and may not be trivial to fix, upstream
already has some sanity checks to pickup that conftests failed and it
should be fixed properly in time.
Using KERNEL_CC to ensure it's used everywhere for modules, esp.
conftest.sh. Non-modules parts seems fine with c23.
For 390/470, just add it to the list of other permanent (ugly)
workarounds and update's 470 comment given it's no longer supported.
Due for removal from the tree in roughly 2 years or less and so just
need to hold on until then.
Closes: https://bugs.gentoo.org/944092
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
|
|
|
| |
6.12 fixes (and probably sec fixes too) haven't made it in,
this just adds the two latest vulkan extensions
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Would make it a hard failure (no ~) given a NVIDIA sanity check already
causes the build to fail, but there is a variable to override that.
Doesn't hurt to do our own standard check, mention the variable, and
warn that using it is unsupported given the increasing amount of users
jumping on PREEMPT_RT (that for most they likely do not need nor
understand for who it's useful for, and notably that it will also hurt
performance).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
incl. proper upstream testing & fix for kernel 6.12, would recommend
this version over the 565.57.01 beta if want to use 6.12 (albeit beta
should be ok with the patch too, just no guarantees that it isn't
missing something).
Also newly needs a minor workaround given NVIDIA newly expects ARCH
to be set to x86_64 while tc-arch-kernel sets x86 (with the rationale
that it makes no difference for the kernel). There is however little
reason to "assume" that the kernel (or modules) sees it the same way
and maybe tc-arch-kernel should pass x86_64... but for now change it
here if USE=amd64 given unsure if want to look into other potential
implications of changing this.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
NVIDIA's support seemingly has ended, as such this will never
go up anymore (unless we patch it, which there is no plans to
support). It does not make sense to list a non-LTS branch that's
not even in the tree anymore there.
Also add a warning similar to 390.x, the date is the same given
both 6.1.x and 6.6.x kernels are going away at same time.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't really recommend 6.12 yet, but it *should* mostly work.
There *may* be issues for which it is unclear if they were
limited to older 6.12-rc1 or so and not the actual 6.12.
It's possible that some issues only surface with specific
kernel configs and so they're hard to pick up.
Normally don't do patches, but in this case it compiles even
though it's going to be semi-broken without it at runtime.
FOP_UNSIGNED_OFFSET is unset for <6.12 so this should have
no impact for older kernels.
0/vulkan fails to build, and 0/470 was already broken with 6.10.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Kind of forgot that was still there.
Still applied given it changes the code in the "if not 6.7" conditional
that nvidia started using (meaning harmless unused code).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/875233
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise system may fail to resume from sleep for some nvidia users.
Have not tried to reproduce myself, but given Debian, Arch, and likely
other distros have done this and systemd itself recommends doing with
nvidia, plus a forum users confirmed it helps, let's just do it.
Kind of wonder how it took until stable to get someone mentioning
issues? Maybe only cause problems for some specific setups.
Hopefully doing this here is temporary, kind of feel like systemd
upstream could handle this better (nvidia does not seem to be the
only case where this can cause problems), or maybe something can
be done from nvidia's side.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
|
|
|
| |
All done wrt bug #942031.
Bug: https://bugs.gentoo.org/942031
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/942031
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/942031
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not particularly happy about this (esp. given this version is
meant to be used with egl-wayland-1.1.17 and this enables explicit
sync that may still cause some applications to crash), but with
560 being vulnerable and 550 not working so well for "some" users
on wayland (presumably those with hybrid graphics?), guess we need it
albeit this may solve issues for some and cause more for others...
If have problems, please downgrade to stable 550, can also downgrade
egl-wayland albeit that may hurt xwayland performance or cause visual
glitches with egl-x11.
For Xorg users, 565 or 550 should make close to no difference though,
may potentially have an impact on suspend/resume (good or bad).
Closes: https://bugs.gentoo.org/941991
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both branch are unsupported and so did not get security updates.
560 had short support due to being a New Feature Branch (NFB).
Users of ~testing 560.35.03-r1 are expected to downgrade to the
(newer) 550.127.05 version which is the next stable candidate if
no problems.
If for one reason or another the 550 branch was problematic for a user,
they may optionally want to opt-in the ~565.57.01 beta instead which is
not vulnerable (we do not keyword betas, see bug #941991 comment #1 --
but it can be manually accepted).
Users of 525.x are on their own, if *really* need that version and
cannot upgrade due to regressions then will have to keep it in a local
overlay. Alternatively the still supported 470.x may still be usable.
(there are still other vulnerable versions to drop but these are
awaiting stabilizations)
Bug: https://bugs.gentoo.org/942031
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
On second thought, decided it's better off split now so
it can be tested before a keyworded version.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon closer look, this should only be for xwayland, so can skip
a few dependencies for pure X users. Pure wayland users (no
xwayland), also shouldn't need it.
Should likely package this separately like egl-wayland too, but
currently egl-x11 has no releases and little activity not sure
if we should be using it yet. Overall it'd be simpler to just use
the provided egl-gbm/wayland/x11 but this is about building from
source when we can.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|