Tested in a clean focal chroot. The dependency resolution works as
expected, allowing the package to be installed without pulling in all of
GNOME, but only if the "universe" repository component is enabled. If I
have only "main" enabled, then dependency resolution fails with the
following:
# apt i
Public bug reported:
In Bionic, screen-resolution-extra has a dependency on policykit-1-gnome
| polkit-1-auth-agent. Focal replaces this with a dependency on gnome-
shell | policykit-1-gnome | polkit-1-auth-agent. As a result, when
install screen-resolution-extra (e.g. as a dependency of nvidia-
s
Public bug reported:
In newer Ubuntu 18.04 HWE kernels, it is possible for GPU HDA
controllers to be dynamically runtime-suspended if the HDA's
power/control mode is set to "auto". However, pm-utils explicitly sets
this to "on" when resuming, which prevents runtime power management of
these device
Is there any plan to add this functionality to the 18.04 HWE stack?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg-server in Ubuntu.
https://bugs.launchpad.net/bugs/1839555
Title:
X server backports for PRIME render offloading
S
Public bug reported:
Configuring PRIME render offloading requires changes to the X server
which have been accepted upstream but are not yet present in any
release. These changes do not break the driver ABI and should be safe to
backport to existing X servers shipped in distributions like Ubuntu.
Would it be possible to change the "intel" profile to no longer alias
the nvidia.ko and nvidia-uvm.ko modules to "off"? The blacklisting can
remain, and would prevent the modules from being loaded automatically in
response to the device being present, but wouldn't prevent them from
being explicitly
It's unlikely to be due a change in the NVIDIA driver, since we (NVIDIA)
have not yet identified a root cause for the touchpad freeze.
As this problem is highly sporadic, and can take several hours in some
cases to reproduce, if it reproduces at all, we should probably wait for
more confirmations
Moving this bug from nvidia-prime to nvidia-graphics-drivers-331, since
the fix goes in the NVIDIA driver, and not nvidia-prime.
FWIW, the attached patch has been formatted for use with the NVIDIA .run
installer's "--apply-patch" option, but it should be usable for DKMS,
since DKMS uses patchlevel
@Alberto:
Here's a patch that adds calls into pm_vt_switch_{required,unregister}()
to the NVIDIA driver. It resolves the corruption issue on my test
system. This change will be included with the next release of the 331
series drivers.
** Patch added: "NVIDIA driver patch for pm_vt_switch_required
@Alberto: that's essentially the change which I tested successfully on a
laptop I have which reproduces the issue, but some of my colleagues have
suggested calling into pm_vt_switch_*() elsewhere in the driver. I would
prefer if you could wait for an official patch and/or driver update,
which we'll
It looks like this is a consequence of recent changes in the kernel that
allow the system to optionally skip VT switches on suspend and resume:
24576d2 drm/i915: enable VT switchless resume v3
3cf2667 fb: add support for drivers not needing VT switch at suspend/resume
time
f43f627 PM: make VT sw
Public bug reported:
The BusID string created by prime-xconfig could be incorrect in any of
the following cases:
a) Any numeric component of the bus ID is greater than 9: prime-xconfig will
write a hexadecimal value, but X will parse it as decimal.
b) The system has more than one PCI domain: `ls
Note that X can parse hexadecimal values in the BusID string if they're
prepended with "0x", since xf86ParsePciBusString() uses atoi(3) to parse
each field; however, the comment at the top of xf86ParsePciBusString()
explicitly states that a decimal value is expected.
--
You received this bug noti
Hi Alberto,
One of our GL driver engineers looked into this a bit, and it actually
seems to be a linker regression that is exposed when linking an
application against the Mesa libGL, and then running it against the
NVIDIA one. He is gathering some more information before filing a bug,
but in the m
Apologies for the duplicated post: I neglected to include the attachment
the first time around, and when I attempted to add it later, it resulted
in the text of my previous update being posted again.
--
You received this bug notification because you are a member of Desktop
Packages, which is subs
Hi Alberto,
One of our GL driver engineers looked into this a bit, and it actually
seems to be a linker regression that is exposed when linking an
application against the Mesa libGL, and then running it against the
NVIDIA one. He is gathering some more information before filing a bug,
but in the m
The problem described in this bug is due to a confirmed regression in
the NVIDIA driver. If you are seeing a similar symptom on Intel, that
should probably be tracked in a separate bug.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvid
Sorry, at the moment we don't have an ETA for a fix. It's not likely to
be fixed in the immediate future. I've added a note to the bug report on
the NVIDIA bug tracker as a reminder to update this Launchpad thread
when we have a fix in hand.
The only workaround I'm currently aware of is to use an
Sorry, I don't have any ideas. I don't think we've seen anything like
this either; we'd probably need a machine that uses the same touchpad or
touchpad driver.
If the Nouveau driver also supports the RandR 1.4 provider source
capability, it might be an interesting experiment to configure PRIME
wit
Not to my knowledge: that changelog entry refers to adding an additional
interface via the NV-CONTROL API to the existing backlight
functionality. The problem is that the existing backlight functionality
is now broken on some laptops, so it doesn't make a difference whether
it's exposed through a n
It's not explicitly stated anywhere in this bug report, but due to the
bug being assigned to "nvidia-prime" and the attached bug reports
apparently coming from systems with PRIME configured, can it be assumed
that this bug happens specifically on systems with RandR 1.4 display
offloading configured
It looks like we're tracking a similar bug report about broken
brightness controls on HP EliteBook 8560w in the 319 and later drivers
in the NVIDIA internal bug tracker. That bug tracker is not visible to
the public, but in case you want to check with NVIDIA support on the
status of the bug, the bu
Public bug reported:
This bug is well described on the freedesktop.org bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=54654
In short, the cursor can't move beyond one screen when a server is
running multiple X screens. The bug has been fixed upstream; the fix
should be applied to all Ubun
Hi Steve,
While the NVIDIA driver often happens to work with consoles other than
the standard VGA text mode console without any user-visible symptoms,
any console configuration besides VGA text mode is not supported by the
driver, and use of any alternative consoles is directly linked, in many
cas
Public bug reported:
The NVIDIA driver does not interact well with consoles other than plain
VGA text consoles, such as vesafb. NVIDIA recommends that users run VGA
text consoles in conjunction with the NVIDIA driver.
Many distributions, such as Ubuntu, enable a framebuffer console by
default. It
If it's true that similar issues show up in Nouveau, and on AMD boards
(radeon? fglrx?), then it probably makes the most sense to track down
the regression better first. There's still a chance that there could be
bugs in all of the affected drivers that are causing this, but it would
be great if we
26 matches
Mail list logo
