amp;selectionEvents; (e = *prev); prev = &e->next) {
AFAICT this would end up creating a struct _SelectionEvent with member
selection=NULL, which would later match for any non-existing selection_name. I
doubt that works as intended.
--
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
&g
7;s no point in 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
propose the 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 bran
not? 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 w
ipped in a new pixmap, and the client may already 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
le.com>> 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 f
44
> --- a/meson.build
> +++ 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
) + ((1) * 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/xwa
milestone 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 |
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. P
son);
> +if(ret = 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_presen
-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
l
> 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 |
ered 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
_
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
--
Earth
ot;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
t;
> Implicit sync really means that 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 kern
isn't enough 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/a
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
.
Not sure what difference it 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
be only triggered 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
___
which is 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
an one which is already 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
using 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
Arch
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
or in the
DRM_IOCTL_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 refuse
t, not 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.
--
Ea
_19_000
- xserver 19.0.1 → 1_20_19_001
- xserver 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 develop
in autotools and 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 ent
ut);
> +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.
E_FLUSH_* flags
(not) 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-deve
l driver is 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 Miche
;s great that you're 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 enthusia
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
>>> Xorg GLX module?
OpenGL 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@l
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 single
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(
esent_cleanup()` after `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.c
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 |
encounter 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..f79e
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
solve 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 sof
ectory '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 Miche
ectory '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 |
ase provide 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 developmen
_height == 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);
> }
>
ad of the slave pixmaps.
Not sure about the defer_dirty_update related code, that might only make
sense in the slave.
The more I look at this PRIME synchronization related code, the more I
wonder if it was ever tested with master and slave screens using
different drivers...
--
Ea
er could fix https://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 |
glamor_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
_
check 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
reviewed on the 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://l
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
ty_fb_id(pScreen, 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
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
ke a
> endless game of cat 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
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 a
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:
til at least the X server and Mesa 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 s
r, 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
Since
.height,
> &buffer_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 | ht
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 ++
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 "rend
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 wrote:
>> From: Michel Dänzer
>>
>> glamor_fds_from_pixmap returns 0 on error, but we were treating that as
>> success, continuing with uninitialized stride and fd values.
>>
&
anyway. Could 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.
--
From: Michel Dänzer
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: Implement PixmapFromB
From: Michel Dänzer
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-by: Michel Dänzer
---
glamo
From: Michel Dänzer
We don't want DRM file descriptors to leak to child processes.
Signed-off-by: Michel Dänzer
---
hw/xfree86/drivers/modesetting/driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/dr
From: Michel Dänzer
It was passing O_CLOEXEC as permission bits instead of as a flag.
Signed-off-by: Michel Dänzer
---
hw/xfree86/os-support/linux/lnx_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os
yet ready 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 signi
x27;t think it's healthy for the same
> roles to continue 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 f
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
>> incarnat
can lose drawables asynchronously, 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
/* 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 |
d returns 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 |
> -if (fb_id == 0) {
> +if (*fb_id == 0) {
> ret = drmmode_bo_import(drmmode, &drmmode->front_bo,
> &drmmode->fb_id);
> if (ret < 0) {
>
Reviewed-and-Tested-by: Michel Dänzer
--
Earthling Michel Dänzer
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
> Reported-by: Michel Dänzer
dl_dep,
> dependency('glproto', version: '>= 1.4.17'),
> -dependency('gl', version: '>= 9.2.0'),
> +dependency('gl', version: '>= 17.1.0'),
> ],
> )
> endif
>
From: Michel Dänzer
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 0x222FC4: RROutputSetNonDesktop
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
+local_closure->xorg = xorg;
> +local_closure->yorg = yorg;
> +local_closure->reqType = reqType;
> +local_closure->did = did;
>
> -(void) doImageText(client, &local_closure);
> +(void) doImageText(client, local_closure);
> +free(l
On 2018-02-28 07:00 PM, Roman Gilg wrote:
> On Wed, Feb 28, 2018 at 6:43 PM, Michel Dänzer 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
>> MSC values you&
From: Michel Dänzer
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
---
glamor/glamor.
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 worked
1 - 100 of 1388 matches
Mail list logo
