riant from a wrong search path, it'd break lots of other things anyway.
In summary, Simon's option 2 seems like the clear winner. As he pointed out, it
matches what's already being done for libEGL_mesa.so.0 shipped in libegl-mesa0,
with no known issues.
--
Earthling Michel
r about the inability to tell ELF headers apart
> and the real problems observed in trying to do so, I have a preference
> for the first option.
Given that different variants of libvulkan_*.so are located in separate search
paths, is there any scenario other than a system misconfiguration
performance when
mesa-vulkan-drivers is installed for multiple architectures, because the Vulkan
loader won't waste cycles trying to load ICDs that can't work.
It also avoids warning messages from the loader (or the dynamic linker?) when
trying to load ICDs that can't work.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
On 2025-04-04 20:42, Helmut Grohne wrote:
> On Fri, Jan 15, 2021 at 12:06:14PM +0100, Michel Dänzer wrote:
>> On 2021-01-15 12:02 p.m., Thorsten Glaser wrote:
>>> Package: mesa-vulkan-drivers
>>> […]
>>> Multi-Arch: same
>>>
>>> The file
On 2025-04-04 20:42, Helmut Grohne wrote:
> On Fri, Jan 15, 2021 at 12:06:14PM +0100, Michel Dänzer wrote:
>> On 2021-01-15 12:02 p.m., Thorsten Glaser wrote:
>>> Package: mesa-vulkan-drivers
>>> […]
>>> Multi-Arch: same
>>>
>>> The file
s.so. Xwayland's signal
handler then calls abort() to terminate the process.
Looks like you need to report this to Nvidia.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
rks and shuts down the
> system as usual.
> I did not find any bug report for bookworm-backports so I decided to create
> another one. Please see attached the backtraces with dbgsyms.
This is https://bugs.debian.org/1081941 , a kwin issue exposed by libwayland
1.23. Xwayland is just
fore the header
which defines Atom to ensure it gets the correct definition.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
packages/o/openscad/testing/s390x/47689316/
>
> This is fixed in upstream commit 5ca85d75c05de9df7c3170122dfdb04bc795b43a
> ("dri: Fix BGR format exclusion"), which I attached for your convenience.
Beware that this commit caused a regression on little endian platfors:
https://gitlab.freedesktop.org/mesa/mesa/-/issues
On 2024-03-08 11:44, Michel Dänzer wrote:
>
> My working theory is that it's due to some kernel build configuration change
> in my self-built kernels compared to Debian ones.
My second guess was a winner: CONFIG_EFI_DISABLE_PCI_DMA breaks booting with
GRUB 2.12 on this machine.
.
Should have tried this earlier. :(
My working theory is that it's due to some kernel build configuration change in
my self-built kernels compared to Debian ones. I'll try narrowing it down,
though if you happen to know of any kernel build configuration no longer
supported wi
On 2023-09-11 11:28, Michel Dänzer wrote:
> Package: grub-efi
> Version: 2.12~rc1-9
> Severity: important
>
>
> After upgrading to 2.12~rc1, any boot entry hangs after 'Loading initial
> ramdisk ...'. I'll attach a photo showing the debug=all output when i
Package: gdm3
Version: 45~beta-1
Severity: normal
Dear Maintainer,
After upgrading to 45~beta-1, the system suspends after 15 minutes at
the login screen. This did not happen with older versions up to and
including 44.1-2. This is a desktop machine which is always connected to
AC.
Setting both
On 9/11/23 11:28, Michel Dänzer wrote:
>
> After upgrading to 2.12~rc1, any boot entry hangs after 'Loading initial
> ramdisk ...'. I'll attach a photo showing the debug=all output when it hangs.
>
> Downgrading to 2.06-13 avoids the issue.
2.06-14 works fine a
es it?
> https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/821
However, 'spirv-as -h' still says:
'If no file is specified, [...] then the assembly text is read from standard
input.'
So this does seem like a spirv-tools bug, and my piglit change is a wo
ing the store or the library).
Could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 fixed by
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086 .
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
r to set up the EGL/GLX
context, and the latter should not rely on libepoxy pulling in the
corresponding libraries.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
n
network_handler="network-manager"
elif [[ -x $dracutsysrootdir$systemdutildir/systemd-networkd ]]; then
network_handler="systemd-networkd"
With this, I no longer need to explicitly add the network-manager module in a
/etc/dracut
Package: dracut-network
Version: 056-3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/usr/lib/dracut/modules.d/35network-manager/module-setup.sh and
/usr/lib/dracut/modules.d/35network-manager/nm-lib.sh look for
nm-initrd-generator in /usr/libexec and /usr/lib. However, network-
force Nvidia Vulkan driver.
It's rather doubtful that there's a bug here.
Without setting VK_ICD_FILENAMES, there's no well-defined order in which Vulkan
devices are enumerated. Most Vulkan applications just use the first enumerated
device, so if the enumeration order changes,
Package: stgit
Version: 0.19-1
Severity: wishlist
Tags: upstream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
See https://github.com/stacked-git/stgit .
Current upstream release as of this writing is 1.3.
- -- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
AP
atic.
> Given the length of this mail, I guess nobody makes it to the end. I can
> write arbitrary nonsense here and nobody will notice.
Nice try. :)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2021-08-21 4:58 p.m., Kari Pahula wrote:
> On Sat, Aug 21, 2021 at 12:17:02PM +0200, Michel Dänzer wrote:
>>> DRM Information from dmesg:
>>> ---
>>>
>>>
>>
>> Since there are no DRM driver related messages in dmes
ing
is preventing the radeon kernel driver from loading at all. If you're passing
nomodeset on the kernel command line, remove that. Otherwise, full dmesg output
would be needed to diagnose.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
By reverting the following files to the versions from 20210315:
amdgpu/picasso_sdma.bin
amdgpu/raven_sdma.bin
amdgpu/raven2_sdma.bin
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Package: llvm-12-tools
Version: 1:12.0.1~+rc4-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
llvm-12-tools requires python3 packages from the same architecture. This
prevents installing llvm-12-tools (and by extension llvm-12-dev) for a foreign
architecture.
E.g. trying to in
perations may also cause this problem.
I'd be interested in more examples, I've been unable to reproduce this so far.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Package: dracut
Version: 051-1
Severity: normal
Dear Maintainer,
when the dracut package is upgraded, its postinst script currently
automatically updates initramfs for all installed kernel versions.
If there's an issue in the newly generated initramfs, this can result in
all installed kernel ver
uot;: "1.2.145",
"library_path": "/usr/lib/x86_64-linux-gnux32/libvulkan_intel.so"
},
"file_format_version": "1.0.0"
}
This file must be moved out of /usr/share and into a multiarch library
path.
Looks to me like the filename is wrong on x32.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Package: clevis-systemd
Version: 15-4
Severity: important
The clevis-luks-askpass script is shipped without execute permissions:
-rw-r--r-- root/root 2343 2021-01-04 22:50
./usr/libexec/clevis-luks-askpass
This breaks the clevis-luks-askpass.service systemd unit, and by
extension automatic
ch is only writable by the user
running the session.
I suggest filing an issue upstream at
https://gitlab.gnome.org/GNOME/mutter/-/issues .
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
/xorg/xserver/-/merge_requests ?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
cated in [1], caused by "xf86_platform_devices[i].pdev"
containing a null pointer.
[1]
https://sources.debian.org/src/xorg-server/2:1.20.9-1/hw/xfree86/common/xf86platformBus.c/#L367
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/508 should
help then.
--
Earthlin
unit=gnome-shell-wayland.service
this is more likely an issue in a GNOME component, e.g. libmutter-6-0 or
gnome-shell.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
.cmake
sed -i '/libkms/d' targets/surfaceless/surfaceless.cmake
sed -i '/libgbm/d' targets/surfaceless/surfaceless.cmake
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
ys on is most likely an amdgpu kernel
driver issue and should be reported at
https://gitlab.freedesktop.org/drm/amd/-/issues .
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
sakura)
> works.
> My Nvidia card is affected too. Until now I have no soultion for this.
Sounds like https://gitlab.freedesktop.org/xorg/xserver/-/issues/1011 .
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
ce, but the log excerpt above looks like the fixes
from https://gitlab.freedesktop.org/xorg/xserver/merge_requests/135
might help, so I added them to
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/391 and they
will hopefully be in the upcoming 1.20.8 release.
--
Earthling Michel Dänzer
I do, besides switch to the proprietary driver? Perhaps with
> fbdev or modesetting? (That would probably lose me OpenGL performance?)
You're probably using the modesetting driver already, since the Xorg
nouveau driver doesn't support glamor. The fundamental problem is in the
kernel
sa:amd64 19.3.1-3 amd64free
> implementation of the GL API -- shared library
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
70] (EE) modeset(0): Failed to initialize glamor at ScreenInit()
> time.
> [ 455.570] (EE)
> Fatal server error:
> [ 455.570] (EE) AddScreen/ScreenInit failed for driver 0
On this machine, you need to add
Option "AccelMethod" "none"
to Section "Devic
On 2019-10-31 8:36 p.m., Petra R.-P. wrote:
> Am Do., 31. Okt. 2019, um 18:01 +0100 schrieb Michel Dänzer
> :
>> On 2019-10-30 2:15 p.m., Petra R.-P. wrote:
>
>> This happens when HW acceleration is disabled. If you can't or don't
>> want to enable HW acc
HW acceleration, the radeon
driver doesn't really provide much if any benefit over modesetting.
Section "Device"
Identifier "whateveryoulike"
Driver "modesetting"
EndSection
--
Earthling Michel Dänzer | https://re
s, at some point it won't be able to continue if no memory
can be allocated, so it's better to address the leak.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
nel amdgpu driver issue, not an xserver-xorg-video-amdgpu
one.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
../dix/gc.c:814
Unfortunately that's where my expertise ends.
Thanks for tracking down the problem. Can you file an upstream issue at
https://gitlab.freedesktop.org/xorg/xserver/issues ?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
; (u_pipe_screen_get_param_defaults+0x176) [0x7f52f39b46e6]
/usr/local/lib/x86_64-linux-gnu/dri/radeonsi_dri.so presumably isn't
from a Debian package, does moving that away help?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
much; the goal should be
to enable HW acceleration again.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
ktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
>>
>
> Do you plan to backport this commit for Debian's packages?
I'm not involved in Debian packaging.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
kernel one. And yes, it's been merged to upstream Git master:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
ck for EXA support
spuriously failed.
https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/merge_requests/1
fixes this.
Meanwhile, you can try enabling Option "shadow_fb", or using
xserver-xorg-video-fbdev instead of xserver-xorg-video-mach64 (as was
the case with Debian 8).
--
Ear
12:08:56 mymachine kernel: kernel BUG at
> drivers/gpu/drm/radeon/radeon_asic.c:55!
This is a kernel issue, not a Xorg driver one.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
#x27;s in whatever wrote
the mangled /etc/X11/Xwrapper.config file.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
uld be (related to)
https://gitlab.freedesktop.org/xorg/xserver/issues/11 , which is said to
be fixed with Xwayland 1.20.4. Have you tried that?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2019-04-25 5:06 p.m., - wrote:
>
> So what would be your suggestion on how to proceed? Are there any
> promising paths I could follow to narrow down the issues?
You should probably file a separate report against the chromium package
about the chromium crash.
--
Earthling Mich
fore I am asking.
Looks like that was a red herring, in the form of GDM terminating its
own GNOME session for the login screen while another VT is active.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
org.
> The flickering is much less disturbing if the moved window is a simple
> one, like xterm, so it might have some connection to the drawing
> performance?
It might be related to GPU load, e.g. to the GPU memory clock being
changed dynamically. You could try if forcing the clock to a certain
value avoids the problem.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
:
> Application 'org.gnome.SettingsDaemon.A11ySettings.desktop' killed by
> signal 15
> [...]
Signal 15 is SIGTERM, so this looks like something terminates a lot
(most / all?) of processes in your session. Maybe Xwayland is another
victim of that. There is no eviden
bian-t470 org.gnome.Shell.desktop[1387]: (EE) 4:
> /usr/bin/Xwayland (glamor_egl_fd_from_pixmap+0x637) [0x560ec4e22a67]
FWIW, these symbols are probably bogus, as glamor_egl_fd_from_pixmap in
Xwayland is a stub which just returns -1, no way it ends up calling
present_* func
nableIOPorts: failed to setIOPL for I/O (Operation not permitted)
>
>
> With the nouveau driver, I get:
>
>
> Error allocating PGRAPH context for M2MF
These are thus likely red herrings.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
; disabled the videos display correctly.
>
> Definitely the case for xfce4.
It's an xfwm4 (configuration) issue then.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
is a regression [...]
It is, thanks for the report. Fixed by
https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/79bc0e054f37026377d54cac6cd8127d4aa9baca
.
That said, I recommend against forcing EXA, unless there's a good reason
for it. glamor generally works better these days.
Also, FWIW, TearFree no longer needs
On 2019-01-30 10:34 a.m., Michel Dänzer wrote:
> On 2019-01-29 10:39 p.m., Lasse Flygenring-Harrsen wrote:
>> Package: xorg
>> Version: 1:7.7+19
>> Severity: critical
>> Justification: breaks the whole system
>>
>> Dear Maintainer,
>>
>> I have
Looks like there are no input drivers that Xorg can use. Is either
xserver-xorg-input-libinput or xserver-xorg-input-evdev installed?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
een
RandR and Xinerama which just doesn't exist (yet, assuming it's possible
at all), at least not in the X.org reference implementation.
I do suspect Xephyr should also disable RandR when Xinerama is enabled,
maybe this bug report can be re-purposed for tha
physical" outputs.
Using Xephyr? Not sure how it could ever have worked like that.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
extra) display is not
> properly advertised or registered. Perhaps the RANDR extension is not working
> properly?
Xinerama and RandR are generally incompatible. The Xorg server
completely disables RandR when Xinerama is enabled. I suspect Xephyr
leaves it enabled by accident, not intentionally.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
eems the title
> bar is always affected.
>From the screenshot, it looks more likely to be a driver issue than an
Xwayland one.
Please provide the corresponding output of glxinfo.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
ears the 'xserver-xorg-vide-amdgpu' driver crashes the whole system,
> [...]
This is more likely an issue in Mesa or the kernel. The Xorg driver
doesn't have any GPU specific code which could cause something like this
anymore.
--
Earthling Michel Dänzer |
th side note which
doesn't apply here elided) in the manpage is:
The default is glamor with R600 or newer [...], otherwise EXA.
> I cannot test the patch for you.
No problem. I'll send out the patch for review anyway, it's pretty
likely it'll fix the crash.
--
Earthling M
t would be the best solution for you.
> So it is my fault. Sorry.
The crash is still a bug, even though EXA & DRI3 isn't recommended,
because it can't work correctly in some cases.
Any chance you can test if the attached patch fixes the crash?
--
Earthling Michel Dänze
th the name of the suite you're using in your main
repository entry.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
ess 0x0
Please make sure the xserver-xorg-video-radeon-dbgsym and
xserver-xorg-core-dbgsym packages are installed, and either get a
backtrace with gdb or another log file.
Does the problem also happen without Option "AccelMethod" "EXA"? That's
the default and recommended con
On 2018-08-16 10:27 AM, Simon Polack wrote:
> The issue seems to be not limited to ATI/AMD graphics, as i face it on
> intel aswell.
That's probably a separate bug in the modesetting driver, which might
indeed be fixed in upstream xserver 1.20.1.
--
Earthling Mi
er-xorg-video-radeon.
Anyway, this looks like another instance of
https://bugs.freedesktop.org/105381 , fixed in upstream xf86-video-ati
Git master. Meanwhile, you can avoid the problem with
Option "AccelMethod" "EXA"
or the modesetting driver.
--
Earthling Michel D
iable is a Mesa feature,
it's usually only needed to work around application / framework issues.
In this particular case, it's probably a known issue with the way
clutter does hit testing, which needs to be adapted to work with 10 bits
per component colour formats. This has been fixed in t
is particular bug, though, as
it's an xf86-video-ati bug.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
m menu seem not influented by the transparent layer
>
> The problem occur after recent actualization of xserver-xorg.
This should be fixed in upstream xf86-video-ati Git master. In the
meantime, you should be able to avoid the problem with
Option "Acce
1 , fixed in upstream
xf86-video-ati Git master.
Meanwhile, you can try
Option "AccelMethod" "EXA"
as a workaround.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Package: valgrind
Version: 1:3.13.0-2+b1
Followup-For: Bug #701480
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This has gotten worse with current binutils, now valgrind seems unable to make
use of even uncompressed debugging symbols.
Is there a solution in sight?
- -- System Information:
D
es it:
https://patchwork.freedesktop.org/series/45979/
I'm planing to merge it upstream next week.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-07-05 02:04 AM, Bjarni Ingi Gislason wrote:
> On Fri, Jun 29, 2018 at 10:56:39AM +0200, Michel Dänzer wrote:
>>
>> Every item listed in Bjarni's report is logically a separate change.
>> Mixing up logically separate changes (especially such a large number)
>
27;s not specific to 2:1.20.0-3, you're just lucky when
not hitting this issue with any Xorg 1.20.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-06-28 03:58 PM, G. Branden Robinson wrote:
> At 2018-06-28T11:31:30+0200, Michel Dänzer wrote:
>>
>> Please send this kind of change directly upstream to the
>> amd-...@lists.freedesktop.org list for review, split up into one patch
>> per logical change.
>
that?
> Add a comma after "e.g.".
That looks odd to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-06-04 02:11 PM, Agustin Martin wrote:
> On Fri, Jun 01, 2018 at 12:00:37PM +0200, Michel Dänzer wrote:
>> On 2018-06-01 10:10 AM, Agustin Martin Domingo wrote:
>>> Package: xserver-xorg-core
>>> Version: 2:1.20.0-2
>>> Severity: important
>>>
rty(props);
> break;
> }
> drmModeFreeProperty(props);
> }
> }
>
> Examining some variables:
>
> (gdb) p i
> $7 = 0
>
> (gdb) p koutput
&g
use, with a a fatal interaction
> between the "compositor" option of xfwm4 and xorg-server-1.20.0. It is also
> noted that this may be a problem not only with the nouveau driver, but also
> with radeon driver, both with xfce4.
It would happen with anything using EXA.
https://patchwork.freedesktop.org/patch/226573/ fixes it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
m fix (in Mesa, where the bug was) is
https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458
.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
nel modesetting driver (using the intel driver) solves the
>porblem for my system.
The freezes are due to a Mesa bug, fixed by
https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458
.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
et
> for testing purposes before, but removing it did not change the
> behavior.
That's because DC is enabled by default for you, you need amdgpu.dc=0 to
disable it. This is a DC issue which is fixed in current 4.16.y upstream.
--
Earthling Michel Dänzer
ny evidence of an xserver-xorg-video-amdgpu bug (or even that it or
Xorg is used at all).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
sscanf(devices[i]->d_name, "%x:%02x:%02x.%1u",
> & dom, & bus, & dev, & func);
>
> device->base.domain = dom;
>
Doing it like this breaks ABI. This is fixed in libpciaccess 0.14 by
https://cgit.freedesktop.org/xorg/lib/libpciaccess/
loaded, so the system use
> vesa
> instead.
The bug above only happens when using Wayland, in which case Xorg isn't
used.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
sting IB on
> ring 11 (-110).
> [drm:amdgpu_device_init [amdgpu]] *ERROR* ib ring test failed (-110).
>
> sometimes the pc crashes, I think it's due to these errors, because
> they're the only ones I have in the log about the graphics card
Those are from the kernel, not f
gt; Linux anymore.
Speaking as somebody working for AMD on open source GPU driver support,
that's a demonstrably false statement. If you're interested, take a look
at articles this year on Phoronix and other sites about our drivers.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Can you use git bisect to determine which change introduced the problem?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
displays
Looks like this might be due to the environment variable GDK_BACKEND
being set to an invalid value.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2017-11-28 05:18 PM, Thomas Blanc wrote:
> Le 28/11/2017 à 16:47, Michel Dänzer a écrit :
>> On 2017-11-28 04:34 PM, Thomas Blanc wrote:
>>> Package: libinput-bin
>>> Version: 1.9.2-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>
HP EliteBook Folio 9470m. I don't know what information
> you need if you want to investigate but I would be happy to provide them.
Assuming this only happens while the laptop is docked, it's a kernel bug
fixed by
https://marc.info/?l=linux-kernel&m=151188228819123&w=2
--
E
1 - 100 of 1718 matches
Mail list logo
