or transparency /
translucency, if the destination window uses the ARGB visual, and the source
pixmap has depth 32.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2024-02-06 12:19, Enrico Weigelt, metux IT consult wrote:
> On 06.02.24 10:07, Michel Dänzer wrote:
>
>>> #4 xorg master and xwayland have massively diverged, pretty much a fork
>>
>> Not sure what you mean by that. If you're looking at the xwayland-2x.y
>>
aligning with Xwayland, which is
released separately anyway.
> * work trough differences between master and xwayland branch and try
> to align them to each other (at some point in the future they should
> be pretty much equal
Per above, nothing to do here.
--
Earth
e following:
>
> * July 19th, 2023: Xwayland 23.2.0 RC1
> * August 2nd, 2023: Xwayland 23.2.0 RC2
> * August 16th, 2023: Xwayland 23.2.0
Sounds great to me. Hopefully we can merge
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1131 before
cutting the branch, assumi
If not, why not?
ComputeLocalClient attempts to detect SSH clients and treats them as non-local.
Maybe this isn't working on macos for some reason?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2022-10-18 16:14, Po Lu wrote:
> Michel Dänzer writes:
>
>> The problem with this is that there's no explicit transfer of
>> ownership of the window pixmap between the compositor and other
>> entities. So the compositor may end up reading from a stale window
be drawing a new
frame to the pixmap used by the compositor, resulting in visual artifacts.
(Xwayland can do essentially what you're describing, since it has an explicit
transfer of ownership via Wayland)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ad this when it still had autotools support, that can still
be inspected in the Git history as well.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
m>> wrote:
>>> On Jun 20, 2022, at 02:09, Michel Dänzer >> <mailto:michel.daen...@mailbox.org>> wrote:
>>>
>>> [0] That said, if the Xquartz build could be tested as part of the GitLab
>>> CI pipeline, that could be useful for yo
+++ b/meson.build
> @@ -4,7 +4,7 @@ project('xserver', 'c',
> 'c_std=gnu99',
> ],
> version: '21.1.99.1',
> -meson_version: '>= 0.47.0',
> +meson_version: '>= 0.50.0',
> )
> release_date = '2021-07-05'
>
--
Earthli
sions of meson react to trying to set unknown options.
Removing the libkms line from /meson-private/cmd_line.txt (or
just not passing -Dlibkms=[...] to meson) should overcome this.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
10) + ((1) * 1000) + 0)
>
> and have found no issue yet. What was the need for this "backward
> compatibility" ?
Mainly for clients doing things like
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8999#note_799189 I
think.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2021-10-12 02:03, Felix Miata wrote:
> Is there an IRC channel somewhere for amdgpu display driver issues? I couldn't
> find one on libera or oftc, and freenode won't let me join.
It's #radeon on OFTC.
--
Earthling Michel Dänzer| https://redhat.com
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
I'm pleased to announce the Xwayland 21.1.2 release.
The only change compared to the release candidate is a fix for a long standing
issue where Xwayland wouldn't send events to notify clients of RandR
configuration changes in some cases.
Michel Dänzer (3):
randr: Bail from
I'm pleased to announce the Xwayland 21.1.2 release.
The only change compared to the release candidate is a fix for a long standing
issue where Xwayland wouldn't send events to notify clients of RandR
configuration changes in some cases.
Michel Dänzer (3):
randr: Bail from
backed pixmaps
xwayland/eglstream: flush stream after eglSwapBuffers
glx: don't create implicit GLXWindow if one already exists
Michel Dänzer (1):
Bump version to 21.1.1.901
Olivier Fourdan (22):
xwayland: Move dmabuf interface to common glamor code
xwayland/eglstream
backed pixmaps
xwayland/eglstream: flush stream after eglSwapBuffers
glx: don't create implicit GLXWindow if one already exists
Michel Dänzer (1):
Bump version to 21.1.1.901
Olivier Fourdan (22):
xwayland: Move dmabuf interface to common glamor code
xwayland/eglstream
The Xwayland 21.1.1 release contains just the fix for CVE-2021-3472 /
ZDI-CAN-1259.
Matthieu Herrb (1):
Fix XChangeFeedbackControl() request underflow
Michel Dänzer (1):
Bump version for Xwayland 21.1.1 release
git tag: xwayland-21.1.1
https://xorg.freedesktop.org/archive
an xwayland.pc file which helps discovering the
path of the installed Xwayland binary and the features it supports
* Only meson is supported for building
* Only Xwayland and Xvfb can be built, only Xwayland can be installed
Michel Dänzer (2):
meson: Make sure XKM_OUTPUT_DIR has a trailing
an xwayland.pc file which helps discovering the
path of the installed Xwayland binary and the features it supports
* Only meson is supported for building
* Only Xwayland and Xvfb can be built, only Xwayland can be installed
Michel Dänzer (2):
meson: Make sure XKM_OUTPUT_DIR has a trailing
as well.
Adam Jackson (1):
meson.build: Keep the protocol version looking like xserver 1.20.x did
Michel Dänzer (1):
Bump version to 21.0.99.902
Olivier Fourdan (1):
xwayland: Delay cursor visibility update
git tag: xwayland-21.0.99.902
https
as well.
Adam Jackson (1):
meson.build: Keep the protocol version looking like xserver 1.20.x did
Michel Dänzer (1):
Bump version to 21.0.99.902
Olivier Fourdan (1):
xwayland: Delay cursor visibility update
git tag: xwayland-21.0.99.902
https
tion
Michal Srb (3):
xfree86: Only switch to original VT if it is active.
dix/window: Use ConfigureWindow instead of MoveWindow
xkb: Fix heap overflow caused by optimized away min.
Michał Górny (1):
xfree86: Makefile shouldn't rely on superuser being named 'r
tion
Michal Srb (3):
xfree86: Only switch to original VT if it is active.
dix/window: Use ConfigureWindow instead of MoveWindow
xkb: Fix heap overflow caused by optimized away min.
Michał Górny (1):
xfree86: Makefile shouldn't rely on superuser being named 'r
On 2021-01-28 6:52 p.m., Michel Dänzer wrote:
Per my plan discussed at
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/582, I'm
proposing the following schedule:
* February 3rd: Create xwayland-21.1 branch
Done: https://gitlab.freedesktop.org/xorg/xserver/-/commits/xwayland
one should be set on issues / MRs which need to be addressed
or at least considered before the 21.1.0 release.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X
on the merge request page.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
6/drivers/modesetting/drmmode_display.c
> mode change 100644 => 100755 hw/xfree86/drivers/modesetting/drmmode_display.h
> mode change 100644 => 100755 hw/xfree86/drivers/modesetting/present.c
Looks like you've set the executable permission bits for these files in
your xserver tree. Please
et = ms_present_check_unflip(crtc, window, pixmap, sync_flip,
> reason))
> +{
> +ms->flip_window = window;
> +}
> +
> +return ret;
This doesn't match the style of the existing code very well. I'd write
it as:
if (!ms_present_check_unflip(...))
or directory
Both Mesa and libdrm have dropped autotools support in favour of meson.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Or
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 |
On 2020-04-17 1:14 p.m., Matthias Klose wrote:
> Package: src:xserver-xorg-video-ati
> Version: 1:19.1.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-04-14 7:46 p.m., Matthieu Herrb wrote:
> On Tue, Apr 14, 2020 at 11:12:37AM +0200, Michel Dänzer wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 2020-04-13 7:52 p.m., Matthieu Herrb wrote:
>>> Hi
; Thibault |Date: Tue Oct 30
> 18:43:51 2018 +0100 | |dix: do not send focus event when grab
> actually does not change
>
> Thanks in advance.
Can you create a GitLab merge request for server-1.20-branch?
- --
Earthling Michel Dänzer |
jobs don't exist at all in the pipeline, so they can't
be triggered by any means. :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@li
would be to find out why the FBO status is incomplete.
The crash is a consequence of this (glamor can't work without an FBO).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earthling
;should we enable this by default or not" question in a
> consistent way.
Even stock Debian stable has 0.49.2 (backports has 0.52.1), so 0.49
seems fair game.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
thing needed for the built-in GPU should be available in
buster-backports, no need for testing.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg
apps and compositors don't sync, so
> the driver has to guess when it should sync.
Making implicit sync work correctly is ultimately the kernel driver's
responsibility. It sounds like radeonsi is having to work around the
amdgpu/radeon kernel driver(s) not fully living up to this responsib
ugh with amdgpu)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-de
On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
>> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
>>> The synchronization works because the Mesa driver waits for idle (drains
>>> the GFX pipeline) at the end of command
would make, since the same thing needs to be
done for explicit fences as well, doesn't it?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-de
red manually instead of automatically on every push.
That would again break Marge Bot.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lis
somewhat more robust:
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569
>
> I'm not sure it's more robust, but yeah that a useful tool too.
>
> The reason I'm skeptical about the robustness is that we'll miss
> testing if this misses a path.
Surely missing a pat
ady caught earlier.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
the intel driver, not modesetting.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives:
ght of?
I reckon it should be relatively easy to make this work with Xwayland.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Org s
On 2020-02-12 6:42 p.m., Carsten Haitzler wrote:
> On Wed, 12 Feb 2020 16:45:50 +0100 Michel Dänzer said:
>
>> On 2020-02-12 4:34 p.m., Carsten Haitzler wrote:
>>> On Wed, 12 Feb 2020 15:36:06 +0100 Michel Dänzer said:
>>>
>>>> On 2020-02-12 2:06 p.m.
On 2020-02-12 4:34 p.m., Carsten Haitzler wrote:
> On Wed, 12 Feb 2020 15:36:06 +0100 Michel Dänzer said:
>
>> On 2020-02-12 2:06 p.m., Carsten Haitzler wrote:
>>> On Wed, 12 Feb 2020 13:23:28 +0200 Pekka Paalanen
>>> said:
>>>
>>>> On We
TL_WAIT_VBLANK ioctl. How do yo know which CRTC to pick?
> I have found x present XPresentNotifyMSC() to be unreliable where the
> drm back-door above is far more reliable. For example - on my amdgpu driver
> here it just refuses to produce any eve
On 2020-01-21 12:31 a.m., Danie Wessels wrote:
> On 20/01/2020 15:39, Michel Dänzer wrote:
>> On 2020-01-20 6:37 a.m., Danie Wessels wrote:
>>> On 17/01/2020 13:16, Michel Dänzer wrote:
>>>> On 2020-01-16 10:49 p.m., Danie Wessels wrote:
>>>>> Hi
&
t directly
with the CPU on the client side. So you could use a normal pixmap and
copy from that to the window with XCopyArea. That'll also work on setups
which actually don't support SHM pixmaps, e.g. Xwayland or Xorg with
EXA, and as a bonus should even perform better.
--
Earthling Michel
On 2020-01-20 6:37 a.m., Danie Wessels wrote:
> On 17/01/2020 13:16, Michel Dänzer wrote:
>> On 2020-01-16 10:49 p.m., Danie Wessels wrote:
>>> Hi
>>>
>>> I have just upgraded Centos 7 to 8 on this same hardware and previous
>>> gnome installation
why the radeon kernel driver didn't
initialize HW acceleration.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Org support
Arc
RI2 and DRI3 in Xorg to fix the issue. I don't see any errors
> anywhere in logs either. Is this a bug in Xorg?
More likely in the Mesa/kernel drivers you're using.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
5.570] (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 acceleration,
ation, 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://redhat.com
Li
request in any case
Michel Dänzer (9):
Retry get_fb_ptr in get_fb
dri3: Always flush glamor before sharing pixmap storage with clients
dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL
Remove dri2_drawable_crtc parameter consider_disabled
present
request in any case
Michel Dänzer (9):
Retry get_fb_ptr in get_fb
dri3: Always flush glamor before sharing pixmap storage with clients
dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL
Remove dri2_drawable_crtc parameter consider_disabled
present
in any case
Michel Dänzer (13):
Retry get_fb_ptr in get_fb
dri3: Always flush glamor before sharing pixmap storage with clients
dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL
Remove dri2_drawable_crtc parameter consider_disabled
present: Check
in any case
Michel Dänzer (13):
Retry get_fb_ptr in get_fb
dri3: Always flush glamor before sharing pixmap storage with clients
dri2: Re-use previous CRTC when possible if pick_best_crtc returns NULL
Remove dri2_drawable_crtc parameter consider_disabled
present: Check
ver 19.1.0 → 1_20_19_100
- xserver 20.0.0 → 1_20_20_000
And then 1_21_*_* as of 21.x.y? Either way, sounds good.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
__
nd can be ignored. This
happens at some point during make distcheck, but (with
xf86-video-amdgpu/ati) it works fine at another point, and the file is
included in the generated tarballs.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast
some configurations, in
particular if the radeonsi driver is enabled. If you don't need that
driver, you can try disabling it.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
> +RRPostPendingProperties(output->randr_output);
> +}
> +}
> +
> return 1;
>
> out_free_encoders:
>
Reviewed-by: Michel Dänzer
P.S. xserver patches are now being reviewed as GitLab merge requests:
https://gitlab.freedesktop.org/x
) set corresponding to glFlush, but not for other internal flushes.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org
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
rote
the mangled /etc/X11/Xwrapper.config file.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
bugs.freedesktop.org/show_bug.cgi?id=32430
> that tells me I have to have a ServerLayout for DisplaySize and at least one
> other
> option to be able to work.
Note that ServerLayout != MonitorLayout, and ServerLayout should only be
necessary if multiple "Device" /
eference to `xcb_poll_for_event'
Static linking requires linking all of libX11's dependencies statically
as well.
pkg-config --libs --static x11
should print the linker flags needed for that.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthu
On 2019-05-05 3:06 a.m., Qu Wenruo wrote:
> On 2019/4/29 下午10:11, Michel Dänzer wrote:
>> On 2019-04-29 3:04 p.m., Qu Wenruo wrote:
>>
>>> Is it possible to disable Intel one completely at X start time?
>>>
>>> Just regular xorg.conf.d with amdgpu onl
On 2019-04-29 3:04 p.m., Qu Wenruo wrote:
> On 2019/4/29 下午6:41, Michel Dänzer wrote:
>> On 2019-04-28 2:02 a.m., Qu Wenruo wrote:
>>> Hi,
>>>
>>> When tweaking eGPU under Linux, I hit one strange behavior.
>>>
>>> The integrated GPU is Intel
y of them for timing purposes, so it falls back to
a 1 Hz timer for presentation.
Potential workarounds:
Disable DRI3.
Force-enable the laptop's internal output while the lid is closed, e.g.
using xrandr.
--
Earthling Michel Dänzer | https://www.amd.com
Libre sof
rrors are similar to the ones described in this thread:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=104598
This was reported against 1.19.6, so probably not the same issue.
--
Earthling Michel Dänzer | https://www.amd.com
Libre softwa
; 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
_
re the Xorg log and xorg.conf files corresponding to that problem.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Org support
PLAY=:0.1 urxvt &
This is because your xorg.conf sets up both GPUs as primary screens
(so-called "traditional multihead", as this was the first kind of
multi-GPU configuration supported by X).
In order to use the second GPU as an RandR provider, you need to leave
it unconfigured in
, allowing monitors using
DisplayPort Multi Stream Transport tiling to work better out of the
box.
Thanks to everybody who contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (1):
Bump version for the 19.0.1 release
git tag
, allowing monitors using
DisplayPort Multi Stream Transport tiling to work better out of the
box.
Thanks to everybody who contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (1):
Bump version for the 19.0.1 release
git tag
contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (3):
Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"
Use radeon_finish in drmmode_crtc_scanout_update
Bump version for 19.0.1 release
git
contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (3):
Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"
Use radeon_finish in drmmode_crtc_scanout_update
Bump version for 19.0.1 release
git
On 2019-03-13 11:28 p.m., Antonio Ospite wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:19.0.0-1
> Severity: minor
>
> Dear Maintainer,
>
> when upgrading from 18.1.0-1 to 18.1.99+git20190207-1 (or 19.0.0-1) Xorg
> failed to start on my system with the following error in the logs:
>
>
From: Michel Dänzer
radeon_glamor_finish only works if we're using glamor, otherwise it'll
crash.
Fixes: ce7db51020d3 "Cancel pending scanout update in
drmmode_crtc_scanout_update"
Bug: https://bugs.debian.org/924540
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2
e flipping in multi-X-Screen/Zaphod mode
Michel Dänzer (30):
dri3: Handle radeon_get_pixmap_bo returning NULL
Handle pending scanout update in drmmode_crtc_scanout_free
Make wait_pending_flip / handle_deferred symmetric in set_mode_major
Allow up to six instances in Zaphod mode
Plus other improvements and fixes. Thanks to everybody who contributed
to this release in any way!
Mario Kleiner (1):
Fix crash when page flipping in multi-X-Screen/Zaphod mode
Michel Dänzer (53):
Post-release version bump
Convert README to markdown
Handle pending scan
Plus other improvements and fixes. Thanks to everybody who contributed
to this release in any way!
Mario Kleiner (1):
Fix crash when page flipping in multi-X-Screen/Zaphod mode
Michel Dänzer (53):
Post-release version bump
Convert README to markdown
Handle pending scan
s allowing DRI2/Present page flipping
while there's an SW cursor? That cannot work correctly, as the SW cursor
image is missing in the newly flipped pixmap, and the SW cursor code
will restore stale background contents to it when the cursor has to be
drawn again.
--
Earthling Michel Dänzer
making a 1.20.4 release!
FWIW, might be worth pulling in
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/127 as well,
so you can use make distcheck.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2019-02-11 5:18 p.m., Andy Ritger wrote:
> On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
>> On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
>>>
>>> Also, is Mesa the only client-side vendor library that works with the
>>>
L driver can work with the Xorg GLX module
(or its own forked version of it).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.
mally discussed on the amd-gfx mailing
list at lists.freedesktop.org .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing list
On 2018-11-28 5:12 a.m., Manoj Gupta wrote:
> Hello all,
>
> if there are no objections to this patch, can someone merge it?
Adam merged it last week:
https://gitlab.freedesktop.org/xorg/xserver/commit/82f8cf8990009f6cac567814dd6b7fd41cfad82d
--
Earthling Mich
On 2018-11-19 1:15 p.m., Qu Wenruo wrote:
> On 2018/11/19 下午7:40, Michel Dänzer wrote:
>>
>> Otherwise, you can prevent Xorg from using the eGPU directly via
>>
>> Section "ServerFlags"
>>Option "AutoAddGPU" "off"
Option "AutoAddGPU" "off"
EndSection
in /etc/X11/xorg.conf . Render offloading with DRI_PRIME still works via
DRI3.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | M
de 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 Michel Dänzer
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änzer
1 - 100 of 2518 matches
Mail list logo
