Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
Source: mesa Version: 22.2.0~rc1-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, After updating to mesa 22.2.0~rc1-1 on my 2008 Dell Precision laptop with a Quadro FX 1700M GPU, I began experiencing artifacts [1] as soon as lightdm started, and they still remained after launching Xfce [2]. I also updated my Debian virtual machine in UTM on macOS, which uses VirtIO graphics, and LightDM is just completely black there except for a cursor. After updating to 22.2.0~rc2-1, the nouveau laptop's artifacts were limited to only foreground objects, such as the login box of lightdm [3] or the menu and panel of Xfce [4]. The virtual machine stayed the same. - -- Ben Westover [1] https://i.ibb.co/mcw7phd/IMG-20220816-231123.jpg [2] https://i.ibb.co/QpRZMwV/IMG-20220816-231401.jpg [3] https://i.ibb.co/y5F1dsJ/IMG-20220816-233627.jpg [4] https://i.ibb.co/7z3X5sy/IMG-20220816-233611.jpg - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmL8ZzkACgkQwxHF9U6J tphg4A/9Fv5e8+V6K2BAXqeoJQPI+JPRWEqe4dW7XnEkvZAWPDw9t6SG9bJYZMwK axwxL+Iobj90WyxGtsUbAjXjFbNJJ0gPorgA/0d83KpPzLwJEDgk1yZKs/vraO64 secD1BBQ04X07NEhZoTzNKbqrUCJUmgZk7R21OfAzTBXdYmMk7CAa4WVoVSgYNcu VP0+GsvmQhETgidDFa4QfrzT4bKEzWo/Vcp3jXWM6u+ovrVtYKvbovE9/M3kRMyJ 0PEZfMYxkq54ggIdT4dEbh7wYN1eGvfubodQ6pDyk+lxaZ00dVZdBcmGhH3RQGLz AClLDr7ZQ+dXz6/HZgd1KXx1PEteI7Cx58yUbJkDcGXS9ddbwfXDLdJYZ9rFYWet CMFuBILn15FxzpjObNjQANzc8xzFAUwMGjq5g0HcAByTslvDipkZtz1Gc5lRyygs ixH8WKWh6dJv54n8KMppjLsr9miJq5Azf82x2AlD5A2Z4xN1zAkagjeijZVZGJwn t8gy2TwK0GsJET2M/hlLRD/1qbPpB4BrUJJIqSTMuNOPUQyRvu0MlcQv8rVYmXCi E9I6o8nG/4k/MeSh/YFXdk49iet1w1fbwQ2GaIvA8FdS/kd7AEQD5p1rW4hcIbBQ ogaKc+2IP2ZHjsr1i5oH7eaE3GgYLRR8Ym5oKKh8Z4fh5oiMiCM= =DQZd -END PGP SIGNATURE-
Bug#1016687: Clarification Needed
On Tue, 16 Aug 2022 at 14:44, Timo Aaltonen wrote: > Dan Letzeisen kirjoitti 15.8.2022 klo 0.10: > > I realize this is a tricky situation with dfsg, but is there any intent > > to fix this bug at Debian distro level or should we look at building our > > own mesa? > > > > Also, the bug should be retitled. It doesn't just affect VA-API > > encoding. It affects VA-API/VDPAU/Vulkan decoding and encoding of the > > codecs in question. > > > > Thank you > > > > I don't think this can be enabled, since Debian does not allow distributing > software encumbered by patents: > > https://www.debian.org/legal/patent In that case intel-media-va-driver and i965-va-driver wouldn't be distributed either. If I understand correctly, they are distributed because they don't contain the codec logic, only the data structures. The logic is defined somewhere else (gpu firmware or other blobs). vmjl > > > > -- > t > > -- > To unsubscribe, send mail to 1016687-unsubscr...@bugs.debian.org. >
Bug#1016687: Clarification Needed
Dan Letzeisen kirjoitti 15.8.2022 klo 0.10: I realize this is a tricky situation with dfsg, but is there any intent to fix this bug at Debian distro level or should we look at building our own mesa? Also, the bug should be retitled. It doesn't just affect VA-API encoding. It affects VA-API/VDPAU/Vulkan decoding and encoding of the codecs in question. Thank you I don't think this can be enabled, since Debian does not allow distributing software encumbered by patents: https://www.debian.org/legal/patent -- t
Processed: Re: Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el
Processing control commands: > reassign -1 src:mesa Bug #993550 [src:gtk4] gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el Bug reassigned from package 'src:gtk4' to 'src:mesa'. No longer marked as found in versions gtk4/4.4.0+ds1-3. Ignoring request to alter fixed versions of bug #993550 to the same values previously set > affects -1 + src:gtk4 Bug #993550 [src:mesa] gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el Added indication that 993550 affects src:gtk4 -- 993550: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993550 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1003348: gtk4: Background blend mode clip interaction not working as intended on mips*el
Processing control commands: > reassign -1 src:mesa Bug #1003348 [src:gtk4] gtk4: Background blend mode clip interaction not working as intended on mips*el Bug reassigned from package 'src:gtk4' to 'src:mesa'. No longer marked as found in versions gtk4/4.6.0+ds1-1. Ignoring request to alter fixed versions of bug #1003348 to the same values previously set > affects -1 + src:gtk4 Bug #1003348 [src:mesa] gtk4: Background blend mode clip interaction not working as intended on mips*el Added indication that 1003348 affects src:gtk4 -- 1003348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003348 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el
Control: reassign -1 src:mesa Control: affects -1 + src:gtk4 On Fri, 03 Sep 2021 at 00:19:29 +0100, Simon McVittie wrote: > GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL > preferred implementation and a Cairo fallback. Its regression tests draw > various combinations of "render nodes" and check the results against > reference PNG images. > > When using the "new" OpenGL renderer, "ngl", there's a weird rendering > glitch on mips*el on two tests involving repeating a pattern: the top > left pixel in each 2x2 block is darker than the other three. > For more details and comparison images: > https://gitlab.gnome.org/GNOME/gtk/-/issues/4228 > > Is there anything unusual about the OpenGL implementation on mips*el > that would cause this sort of thing? It seems to be using Mesa swrast_dri.so > (which I think is llvmpipe?), the same as any other machine without a GPU. This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe and LIBGL_ALWAYS_SOFTWARE=true in the environment. I've set up the GTK build to use GALLIUM_DRIVER=softpipe and LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to investigate this further from GTK's point of view. Investigation by the mips porting team would be appreciated. smcv
Re: Bug#1003348: gtk4: Background blend mode clip interaction not working as intended on mips*el
Control: reassign -1 src:mesa Control: affects -1 + src:gtk4 On Sat, 08 Jan 2022 at 18:35:20 +, Simon McVittie wrote: > Similar to #993550, GTK 4 has a new test failure on mips*el. > Please see https://gitlab.gnome.org/GNOME/gtk/-/issues/4618 for details. This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe and LIBGL_ALWAYS_SOFTWARE=true in the environment. I've set up the GTK build to use GALLIUM_DRIVER=softpipe and LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to investigate this further from GTK's point of view. Investigation by the mips porting team would be appreciated. smcv
libdrm_2.4.112-3ubuntu1_source.changes REJECTED
No target suite found. Please check your target distribution and that you uploaded to the right archive. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Processing of libdrm_2.4.112-3ubuntu1_source.changes
libdrm_2.4.112-3ubuntu1_source.changes uploaded successfully to localhost along with the files: libdrm_2.4.112-3ubuntu1.dsc libdrm_2.4.112-3ubuntu1.debian.tar.xz libdrm_2.4.112-3ubuntu1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
