I just tagged a 1.1.1 release for libglvnd with the AARCH64 and PPC64LE fixes:
https://github.com/NVIDIA/libglvnd/releases/tag/v1.1.1
If you're switching from 1.0.0, note that the dispatch table order
changed between v1.0.0 and v1.1.0, so you'll need matching builds of
libGLdispatch.so,
The actual release tag (plus tarball and release notes) is here:
https://github.com/NVIDIA/libglvnd/releases/tag/v1.1.0
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libglvnd in Ubuntu.
https://bugs.launchpad.net/bugs/1782285
Title:
The other libglvnd libraries would already cause a conflict with
nvidia-340, wouldn't they?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libglvnd in Ubuntu.
https://bugs.launchpad.net/bugs/1782285
Title:
Add missing libGLESv1_CM.so
Liblgnvd has a new 1.1.0 point release, which includes that fix (as well
as an assortment of others).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libglvnd in Ubuntu.
https://bugs.launchpad.net/bugs/1780039
Title:
Khronos CTS
Also, while GLESv1 is the fixed-pipeline stuff, libGLESv1_CM.so just
provides a set of forwarder functions. Libglvnd forwards those calls to
a vendor library based on the current context, so it's up to the vendor
library what to do with them. If a vendor doesn't provide a function to
forward to,
Just because Mesa doesn't provide GLESv1 doesn't mean other vendor
libraries can't. It certainly isn't any reason to prohibit GLESv1
support if a vendor library would otherwise be able to support it.
Conversely, having the full set of libglvnd libraries (including
libGLESv1_CM.so) doesn't require
That sounds like it's probably a different bug that's been uncovered by
this change, so I think a separate bug would be appropriate. If you've
still got a system handy that can reproduce it, the log from nvidia-bug-
report.sh would also be helpful.
--
You received this bug notification because
Public bug reported:
The script that starts Chromium has a section that's supposed to check
whether the environment variable CHROMIUM_USER_FLAGS is defined, as if
so, use it rather than CHROMIUM_FLAGS.
However, the script checks if the length of the string (not the
variable) CHROMIUM_USER_FLAGS
I don't see any changes that would have fixed it, but it's quite
possible that other changes could adjust the timing such that the bug is
harder to reproduce.
I've got a Q600 handy, though, so give me a few minutes to load up Saucy
onto my test system and I'll check.
--
You received this bug
Just tested on 13.10, and I can still reproduce the problem. It's less
frequent on my system than it did on 12.04, but it still shows up every
so often.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu.
This is very likely the same race condition as bug #269904.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu.
https://bugs.launchpad.net/bugs/861268
Title:
text corruption in terminals (xterm, urxvt)
11 matches
Mail list logo