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
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
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
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
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
e use wayland-info instead",
upstream weston 11 will no longer ship weston-info. wayland-info has been (and
will continue to be) extended to print more information than weston-info.
--
Earthling Michel Dänzer| https://redhat.com
Libre software
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,
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
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
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
?id=1912159 "pidgin crashes
with mesa-vulkan-drivers-20.3.2-1.fc33".
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
der/mesa just need to be fixed.
--
t
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-06-05 4:44 a.m., Nicholas D Steeves wrote:
> Michel Dänzer writes:
>> On 2020-05-31 12:16 a.m., Nicholas D Steeves wrote:
>>
>>> The only thing I'm not sure about is if additional Xorg
>>> components wo
MD for their new phase of GPL-friendly driver development.
>
> This will also require a backport of llvm-10-toolchain.
FWIW, Navi GPUs can work with LLVM 9.
> The only thing I'm not sure about is if additional Xorg components
> would additionally need to be backported.
None, but ke
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
.org/~doko/logs/gcc10-20200225/xserver-xorg-video-ati_19.1.0-1_unstable_gcc10.log
> The last lines of the build log are at the end of this report.
This is fixed upstream by
https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/commit/f223035f4ffcff2a9296d1e907a5193f8e8845a3
.
--
Earthling
bdrm
> * libclc
> * libglvnd
>
>
> There is few changes to made:
> - Rebase llvm-9 to llvm-8 in related packages
> - Same for clang
Mesa 19 adds support for AMD Navi cards, which require LLVM 9.
Therefore, it would make more sense to backport LLVM 9 as well.
--
Earthlin
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
engine...' on Rage 128 PF/PRO AGP 4x TMDS rev 0
> Added tag(s) pending.
Oops? :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
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
string: 1.30
> OpenGL context flags: (none)
> OpenGL extensions:
> OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.0.6
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
> OpenGL ES profile extensions:
>
> What is installed :
>
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
red by the
> mesa update
> - i think it's appearing only on large displays like 2560x1440.
> - i don't know how to get logs from previous boots with journalctl
>
> I remember something about "cs ring radeon", etc..
Sounds like https://bugs.freedesktop.org/105381 , fi
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
be given as a number 0 to ,, and this will be the
> power of two in MBytes.On another place it is written that MBytes shall
> be given straight.
The vramlimit parameter only affects how much of the reserved memory is
actually used by the driver. The remaining reserved memo
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
u
provide the terminal output of e.g. mplayer when there is tearing in
fullscreen?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
or even pure
X11)
3. Enabling TearFree
Note that 1.+2. are not sufficient when using rotation or other
transforms via the RandR extension.
Does your setup fall under any of these cases? If not, you may just have
gotten lucky before.
--
Earthling Michel Dänzer |
On 16/07/17 07:04 PM, Ivan Sergio Borgonovo wrote:
On 07/16/2017 05:56 PM, Michel Dänzer wrote:
Hmm, the string "EGL search path is" and the corresponding code was
removed upstream for Mesa 10.6. Look for instances of libEGL.so.1*
other than /usr/lib/x86_64-linux-gnu/libEGL.so.
1 - 100 of 2997 matches
Mail list logo
