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
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-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(...))
-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
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 |
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:
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
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
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
> +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
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.
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-09-24 12:04 p.m., Raimonds Cicans wrote:
> On 24.09.2018 12:17, Michel Dänzer wrote:
>> On 2018-09-23 11:18 p.m., Raimonds Cicans wrote:
>>> Hi!
>>>
>>> I am playing with new "DRM leases" feature.
>>> I am trying to implement sin
ror: failed to load driver: radeonsi
Please attach both Xorg log files and the output of
LIBGL_DEBUG=verbose DISPLAY=:101 glxgears
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 2018-09-10 12:01 p.m., Frédéric Fauberteau wrote:
> Le 2018-09-10 09:26, Michel Dänzer a écrit :
>> On 2018-09-10 8:22 a.m., Frédéric Fauberteau wrote:
>>> Le 2018-09-01 15:16, Michel Dänzer a écrit :
>>>> On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote:
>&g
On 2018-09-10 8:22 a.m., Frédéric Fauberteau wrote:
> Le 2018-09-01 15:16, Michel Dänzer a écrit :
>> On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote:
>>>
>>> [ 5770.134] (EE) RADEON(0): Failed to make prime FD for handle: 22
>>> [ 5770.134] (EE) RADEON(
er `DestroyWindow()` so that
> `xwl_present_abort_vblank()` can still access valid memory before it's
> freed.
This last paragraph doesn't seem to match the rest of the patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
return FALSE;
> }
>
> -if (pixmap->drawable.depth == 30)
> - format = GBM_FORMAT_ARGB2101010;
> -else
> - format = GBM_FORMAT_ARGB8888;
> -
> #ifdef GBM_BO_WITH_MODIFIERS
> if (modifiers_ok && glamor_egl->dmabuf_capable) {
&
lly
https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/db28d35ce9fd07a2a4703f3df0633d4c8291ff9b
could help for this.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
On 2018-08-29 9:14 p.m., Adam Jackson wrote:
> continued from pixman@, original thread here:
>
> https://lists.freedesktop.org/archives/pixman/2018-August/004759.html
Frédéric, can you attach the full corresponding Xorg log file?
--
Earthling Michel Dänzer |
nter the same issue?
>
> BTW, could you do me a favor to help me push the patch to the master or
> other proper branch? I do not familiar with the processes that push the
> patch to Xorg.
Pushed to master, thanks guys.
To ssh://gitlab.freedesktop.org/xorg/xserver
8a3ae555e..f79e53685 master -
On 2018-08-24 1:34 a.m., Alex Goins wrote:
> Hi Adam,
>
> Can this be merged?
Pushed, thanks.
To ssh://gitlab.freedesktop.org/xorg/xserver
1fc20b985..a90f33721 master -> master
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
anything outside of your system(s). I'm looking
for a general solution, hence the patch.
Anyway, thanks for providing the information needed for diagnosing and
addressing this issue.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusias
y 'm4': No such file or directory
The plot thickens. Looks like aclocal only warns if the first directory
passed via -I doesn't exist, but errors out if the second one doesn't.
Does https://patchwork.freedesktop.org/patch/245782/ help for this issue?
--
Earthling Michel Dänzer |
'm4': No such file or directory
This is just a warning.
> configure.ac:41: error: must install xorg-macros 1.8 or later before running
> autoconf/autogen
> configure.ac:41: the top level
This looks like your problem.
--
Earthling Michel Dänzer | http:/
the full terminal output of running ./autogen.sh .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: htt
ht == screen_pixmap->drawable.height) {
> +if (new_width <= screen_pixmap->drawable.width &&
> + new_height <= screen_pixmap->drawable.height) {
> } else {
> pScrPriv->rrScreenSetSize(pScreen, new_width, new_height, 0, 0);
> }
>
Rev
if (!screen->isGPU) {
msPixmapPrivPtr ppriv =
msGetPixmapPriv(>drmmode,
ent->slave_dst->master_pixmap);
and msStartFlippingPixmapTracking and msStopFlippingPixmapTracking also
need to use ->master_pixmap instead of the slave pixmaps.
Not sure
tps://bugs.freedesktop.org/101998#c37 . I was about
to get fed up with it enough to do it myself, but I might not get around
to it for a couple of weeks.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa an
r_ctx->display = xwl_screen->egl_display;
>
>
With the above fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
against overflow of the addition and
multiplication).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Arch
e amd-gfx mailing list.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/arch
an.
The r128 repository will soon be migrated to gitlab.freedesktop.org,
then it will be easier to give you write access.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2018-07-05 05:42 PM, Tony Lindgren wrote:
> Hi,
>
> * Michel Dänzer [180705 14:21]:
>>
>> This uses the same damage region for all framebuffers, which is
>> generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
>> offset, rotation and refl
Screen, fb_id);
> +
> +skip:
> +mask &= ~(1 << i);
> }
> }
>
>
This uses the same damage region for all framebuffers, which is
generally not correct for drmmode_crtc->rotate_fb_id. The coordinate
offset, rotation and reflection need to be taken
On 2018-06-27 11:39 AM, Emil Velikov wrote:
> On 27 June 2018 at 09:40, Michel Dänzer wrote:
>> On 2018-06-26 07:11 PM, Emil Velikov wrote:
>>> On 26 June 2018 at 17:23, Michel Dänzer wrote:
>>>> On 2018-06-26 05:43 PM, Emil Velikov wrote:
>>>>>
On 2018-06-26 07:11 PM, Emil Velikov wrote:
> On 26 June 2018 at 17:23, Michel Dänzer wrote:
>> On 2018-06-26 05:43 PM, Emil Velikov wrote:
>>> On 25 June 2018 at 22:45, Zuo, Jerry wrote:
>>>> Hello all:
>>>>
>>>>
>>>>
>>&g
and mouse.
> IMHO a much better approach is to not use edid codepaths for KMS
> drivers (where AMDGPU is one).
> On those, the supported modes is advertised by the kernel module via
> drmModeGetConnector.
We are getting the modes from the kernel; the issue is they are then
pruned (presumab
On 2018-06-12 01:35 PM, Daniel Stone wrote:
> On 11 June 2018 at 11:33, Michel Dänzer wrote:
>> On 2018-06-08 08:08 PM, Adam Jackson wrote:
>>> I'd like us to start moving repos and bug tracking into gitlab.
>>> Hopefully everyone's aware that gitlab exists and why fdo
oman Gilg
Pushed with this and a Fixes: tag added, thanks Olivier and Roman!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org:
have moved to
GitLab for issue tracking, to hopefully allow moving such misfiled issues.
Adding the amd-gfx list, in cases somebody there has concerns or other
feedback.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
ther, there is really no point in passing the
> width/height around.
>
> Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by
> removing the pixmap size, and use the drawable size instead.
>
> Signed-off-by: Olivier Fourdan
Reviewed-by: Michel Dänzer
gt; _created);
>
> event->event_id = event_id;
>
Please remove the present_box local, it's unused now. With that,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
D_INVALID;
> -strides[0] = gbm_go_get_stride(xwl_pixmap->bo);
> +strides[0] = gbm_bo_get_stride(xwl_pixmap->bo);
> offsets[0] = 0;
> #endif
>
>
Pushed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
From: Michel Dänzer
The incorrect values could result in the new pixmap's contents
getting corrupted down the line.
Bugzilla: https://bugs.freedesktop.org/106841
Fixes: 029608dd8020 "present: Add window flip mode"
Signed-off-by: Michel Dänzer
---
present/present_wnmd.c | 2 ++
1 fi
On 2018-06-06 10:26 PM, Adam Jackson wrote:
> On Fri, 2018-06-01 at 11:58 +0200, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Their pFormat member is NULL, which resulted in a crash in
>> miRenderColorToPixel.
>>
>> Fixes: 8171d4c2d67b "
Behan has been looking after xf86-video-r128.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: htt
From: Michel Dänzer
Their pFormat member is NULL, which resulted in a crash in
miRenderColorToPixel.
Fixes: 8171d4c2d67b "render: Store and use all 16bpc of precision for
solid pixels (v2.1)"
Signed-off-by: Michel Dänzer
---
exa/exa_render.c | 3 ++-
1 file
On 2018-05-23 05:57 PM, Emil Velikov wrote:
> On 23 May 2018 at 10:43, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> glamor_fds_from_pixmap returns 0 on error, but we were treating that as
>> success, cont
this path just go
>> away?
>
> I guess it's needed for dri2? If all drivers using glamor are OK with
> dropping dri2, then that should be OK.
FWIW, our drivers don't use glamor_name_from_pixmap, so they can support
DRI2 regardless.
--
Earthling Michel Dänzer
From: Michel Dänzer <michel.daen...@amd.com>
glamor_fds_from_pixmap returns 0 on error, but we were treating that as
success, continuing with uninitialized stride and fd values.
Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap.
Fixes: c8c276c9569b "glamor
From: Michel Dänzer <michel.daen...@amd.com>
This matches what glamor_egl_fds_from_pixmap and dri3_fds_from_pixmap do
and what proc_dri3_buffers_from_pixmap expects.
Fixes: c8c276c9569b "glamor: Implement PixmapFromBuffers and
BuffersFromPixmap"
Signed-off-b
From: Michel Dänzer <michel.daen...@amd.com>
We don't want DRM file descriptors to leak to child processes.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
hw/xfree86/drivers/modesetting/driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Michel Dänzer <michel.daen...@amd.com>
It was passing O_CLOEXEC as permission bits instead of as a flag.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
hw/xfree86/os-support/linux/lnx_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/h
to stop using X altogether, but it's getting harder and
> harder for us to keep X alive.
FWIW, since all major Linux distros are now using Wayland by default, I
do think it's a good time to transition the Xorg DDX to more of a
maintenance mode. Any significant new functionality should be deve
tinue to be held by the same few people.
That's certainly true.
> And, personally, I've been more or less focused on xserver for well
> over a decade, and I badly need a change of scenery.
I can relate to that feeling. :)
--
Earthling Michel Dänzer |
On 2018-05-09 07:32 PM, Adam Jackson wrote:
> On Tue, 2018-05-08 at 11:42 +0200, Michel Dänzer wrote:
>
>> Idle notify events shouldn't need special treatment, since the pixmap
>> XIDs of the buffers will be different between loader_dri3_drawable
>> incarnations,
onously, but such is life.
I had an idea, at least for SBC:
In dri3_destroy_drawable, store the drawable's send_sbc value in a hash
table (keyed on the XID) in struct dri3_screen. Then in
dri3_create_drawable, if there's an entry for the drawable's XID in the
hash table, initialize send_sbc and recv_
When moving from flip to copy, we assume that we can allocate in
* a more optimal way if we don't need to cater for the display
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 2018-04-24 11:17 PM, Adam Jackson wrote:
> More bugfixes, and streams support for Xwayland. This will almost
> certainly be the last RC.
What about the Xwayland Present issue with unmapped windows (affecting
e.g. skypeforlinux)?
--
Earthling Michel Dänzer |
eturns consistent MSC values for them.
That said, maybe this is the best that can be done to address the
immediate issue, but it might be good to at least add a comment saying
this is a kludge which should be revisited after 1.20.
--
Earthling Michel Dänzer | http://ww
*y)
> *y = crtc->y;
> }
>
> -if (fb_id == 0) {
> +if (*fb_id == 0) {
> ret = drmmode_bo_import(drmmode, >front_bo,
> >fb_id);
> if (ret < 0) {
>
Reviewed-and-Tested-by: Michel Dänzer <michel.daen.
On 2018-04-05 03:58 PM, Daniel Stone wrote:
> drmmode_crtc_set_mode has a loop nested inside another loop, where both
> of them were using 'i' as the loop iterator. Rename it to avoid an
> infinite loop.
>
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> Re
ncy('glproto', version: '>= 1.4.17'),
> -dependency('gl', version: '>= 9.2.0'),
> +dependency('gl', version: '>= 17.1.0'),
> ],
> )
> endif
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer
From: Michel Dänzer <michel.daen...@amd.com>
Flagged by valgrind:
==13695== Conditional jump or move depends on uninitialised value(s)
==13695==at 0x22461C: RRNoticePropertyChange (rrproperty.c:150)
==13695==by 0x22461C: RRChangeOutputProperty (rrproperty.c:263)
==13695==by 0x
wever, since I've been unable to reproduce the issue you described
with Steam, despite kind of going out of my way to do so, I'm really
reluctant to add this workaround without getting more information about
the problem from someone who can reproduce it. Without understanding the
problem, the workaround mi
local_closure->data = data;
> +local_closure->xorg = xorg;
> +local_closure->yorg = yorg;
> +local_closure->reqType = reqType;
> +local_closure->did = did;
>
> -(void) doImageText(client, _closure);
> +(void) doImageText(cli
On 2018-02-28 07:00 PM, Roman Gilg wrote:
> On Wed, Feb 28, 2018 at 6:43 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> I'm unable to reproduce the issue you described with Steam (without this
>> patch series applied). I'd really like to know where the bogus target
>&g
From: Michel Dänzer <michel.daen...@amd.com>
They're part of the 1.20 RC1 ABI, and actually used by external drivers.
Also, requiring drivers which don't support the new functionality in
DRI3 1.2 to switch to the new interfaces seems unreasonable.
Signed-off-by: Michel Dänzer <mi
On 2018-02-28 05:36 PM, Roman Gilg wrote:
> This revision provides changes requested by Michel Dänzer. In particular
> flips without copies in window flip mode are now possible and clients can
> queue flips on Xwayland.
Thanks for that.
It would be even better if queuing flips wo
ErrorF("Client queued frame too far in the future: %lu -> %lu\n",
> xwl_window->present_msc, msc);
> +return BadRequest;
> +}
If we're going this route, let's not use an arbitrary threshold like
100, but the actual one corresponding t
1 - 100 of 1234 matches
Mail list logo
