e 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
_
address 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 configur
;> sync-to-vblank).
>
> Couldn't we extend modesetting in addition to Martin's TearFree patch the
> same way you did here for Radeon?:
>
> https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=798c4fd16d339b1ad5fd729cc884be084c60e38b
Yeah, something like that would be
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
__
335] (II) Server terminated successfully (0). Closing log file.
Looks like Xorg shut down cleanly. Either this was the wrong log file,
or you have to look for the problem on the client side.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
drmmode_crtc_scanout_free
Keith Packard (3):
modesetting: Record non-desktop kernel property at PreInit time
modesetting: Create CONNECTOR_ID properties for outputs [v2]
Add RandR leases support
Michel Dänzer (55):
Bail from dri2_create_buffer2 if we can't get a pixmap
glamor: Bail
on output_get_property
Enable setting of color properties via RandR
Compose non-legacy with legacy regamma LUT
Also compose LUT when setting legacy gamma
Michel Dänzer (48):
Post-release version bump
Ignore AMDGPU_DRM_QUEUE_ERROR (0) in amdgpu_drm_abort_entry
Track DRM event
drmmode_crtc_scanout_free
Keith Packard (3):
modesetting: Record non-desktop kernel property at PreInit time
modesetting: Create CONNECTOR_ID properties for outputs [v2]
Add RandR leases support
Michel Dänzer (55):
Bail from dri2_create_buffer2 if we can't get a pixmap
glamor: Bail
on output_get_property
Enable setting of color properties via RandR
Compose non-legacy with legacy regamma LUT
Also compose LUT when setting legacy gamma
Michel Dänzer (48):
Post-release version bump
Ignore AMDGPU_DRM_QUEUE_ERROR (0) in amdgpu_drm_abort_entry
Track DRM event
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(
ent() and relying on hotplug events to
> trigger re-polling. Now, maybe the X server shouldn't print the modes
> in the log when that happens, [...]
FWIW, it probably shouldn't indeed, at least not at the default log
verbosity.
--
Earthling Michel Dänzer |
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 |
not 4480x1440
It's up to your desktop environment. Xorg merely sends hotplug events to
interested clients, it doesn't automatically change the configuration in
any way.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | M
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
ation from 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
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
__
be fixed?:
>
> a) Should my DRM driver allow to move the HW cursor buffer partially
> outside the frambuffer?
Yes. That's how this is working with other drivers.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
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
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)
>>
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-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.
>
> 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
___
xorg-driver-ati mailing list
xorg-dri
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
the last client
disconnects)
* The Xorg process could crash when multiple primary screens are
configured in xorg.conf.
* TearFree could trigger debugging messages in the pixman library
Michel Dänzer (4):
Only change Set/MoveCursor hooks from what we expect
Wrap the whole
messages in the pixman library
Michel Dänzer (3):
Wrap the whole miPointerScreenFuncRec, instead of only Set/MoveCursor
Pass extents to radeon_scanout_do_update by value
Bump version for 18.0.1 release
git tag: xf86-video-ati-18.0.1
https://xorg.freedesktop.org/archive
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
Skip xf86HandleColormaps() at color depth 30. (v2)
Support exa screen color depth 30 on Linux 3.16 and later. (v2)
Add missing depth 30 -> cpp=4 handling for DRI2.
Make XvMC extension initialize at depth 30.
Michel Dänzer (23):
Fix VT switching with ShadowFB
P
Skip xf86HandleColormaps() at color depth 30. (v2)
Support exa screen color depth 30 on Linux 3.16 and later. (v2)
Add missing depth 30 -> cpp=4 handling for DRI2.
Make XvMC extension initialize at depth 30.
Michel Dänzer (23):
Fix VT switching with ShadowFB
P
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
Packard (2):
modesetting: Skip no-longer-present connectors when resetting BAD links
modesetting: Update property values at detect and uevent time
Mario Kleiner (1):
Define per x-screen individual drmmode_crtc_funcs
Michel Dänzer (20):
Post-release version bump
Fix VT
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
On 2018-02-28 05:27 PM, Adam Jackson wrote:
> On Wed, 2018-02-28 at 16:35 +0100, Michel Dänzer wrote:
>> On 2018-02-12 10:51 PM, Keith Packard wrote:
>>> Tracks changes to the non-desktop property so that when non-zero,
>>> outputs will always appear to be disco
output->connection,
> .connection = output->connection,
BTW, I don't think this was intended to leave the existing connection
initializer line, clobbering the new one?
--
Earthling Michel Dänzer | http://www.amd.com
p=) at ../../dix/main.c:193
#13 0x758a3f2a in __libc_start_main (main=0x5559a3f0 ,
argc=4, argv=0x7fffeb08, init=, fini=,
rtld_fini=, stack_end=0x7fffeaf8) at ../csu/libc-start.c:310
#14 0x00005559a42a in _start ()
--
Earthling Michel Dänzer |
From: Michel Dänzer <michel.daen...@amd.com>
These guards were dropped by the commit below, but it turns out they're
needed. Fixes crash on VT switch.
Fixes: d8ec33fe0542 ("glx: Use vnd layer for dispatch (v4)")
Bugzilla: https://bugs.freedesktop.org/105233
Signed-off-b
On 2018-02-26 04:33 PM, Adam Jackson wrote:
> This plumbs the full width color for solid pictures through to fb, exa,
> and glamor. External drivers and acceleration code may wish to make a
> similar change for sufficiently new servers.
>
> v2: Don't break ABI (Michel Dänzer)
-video-ati's EXA code (and other drivers maybe?) needs to be adapted
for this. Do you have patches for that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
On 2018-02-24 12:58 AM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> On 2018-02-22 10:53 PM, Adam Jackson wrote:
>>> "depth" for a picture format is the sum of bits of a/r/g/b, and not x.
>>> The default format list was crea
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
__
mat at depth 30, which is nonsense.
Actually, the former isn't wrong, and the latter might not be either, I
think. These are the constraints:
* The sizes of a/x+r+g+b must equal bpp
* The sizes of a+r+g+b must be <= depth (or == ?)
--
Earthling Michel Dänzer | http://w
BTW, drmmode_load_palette is never called, since
xf86CrtcFuncsRec::gamma_set is always non-NULL; it can be removed.
Doesn't have to be done by this patch, of course.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mes
On 2018-02-13 07:34 PM, Lukas F. Hartmann wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>> On 2018-02-13 04:23 PM, Lukas F. Hartmann wrote:
>>>
>>> - Xwayland/glamor registers its gbm buffer with wl_drm_create_prime_buffer
>>> (passing a fd
he same BO.
Can you test Xorg with DRI3? Do OpenGL apps work correctly with that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.o
On 2018-02-09 07:24 AM, Mario Kleiner wrote:
> On 02/08/2018 03:55 PM, Michel Dänzer wrote:
>> On 2018-02-08 12:14 PM, Mario Kleiner wrote:
>>> As it turns out, doing so will make any gamma table updates
>>> silently fail, because xf86HandleColorMaps() hooks th
nto the driver
to set their LUTs, with no coordination between them, so whichever calls
into the driver last wins and clobbers the HW LUT.
It would be better to fix xf86RandR12CrtcComputeGamma instead.
--
Earthling Michel Dänzer | http
On 2018-02-07 12:35 AM, Roman Gilg wrote:
> On Fri, Feb 2, 2018 at 5:11 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> Taking a step back, do we even need to keep around the original pixmap
>> and unflip to it at all? I had a chat on IRC about this with Keith a
>> whil
On 2018-02-05 09:08 PM, Adam Jackson wrote:
> On Mon, 2018-02-05 at 12:53 +0100, Michel Dänzer wrote:
>
>>>> The inability to queue a presentation to the next MSC is more of a step
>>>> back compared to the status quo.
>>>
>>> I'm about to go w
On 2018-02-05 08:09 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Ignoring the Security extension, the client has the same control over
>> the contents of another application's window *using* the X protocol,
>> doesn't it?
>
> Yeah
On 2018-02-02 11:11 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> But this seems irrelevant for per-window flips. In this case, the window
>> pixmap isn't used for anything else after flipping, so having direct
>> access to the pixmap
On 2018-02-02 09:56 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> On 2018-02-02 10:42 AM, Roman Gilg wrote:
>>> It's because of what you made me aware of in the previous patch set:
>>> the window original pixmap needs to have t
On 2018-02-02 12:08 PM, Michel Dänzer wrote:
> On 2018-02-02 10:42 AM, Roman Gilg wrote:
>
>> I also tried to not copy, but set the window pixmap to the flip
>> pixmap. The problem I encountered here, is that the window original
>> pixmap can be controlled
to queue a presentation to the next MSC is more of a step
back compared to the status quo.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@
101 - 200 of 2518 matches
Mail list logo
