On 2018-02-01 04:45 PM, Michel Dänzer wrote:
> On 2018-01-29 06:15 PM, Roman Gilg wrote:
>> This is a RFC on a follow-up patch to my recently posted patch series on the
>> xorg-devel mailing list to enable per window flips of Present Pixmaps to
>> Wayland surfaces:
>> ht
efresh rate from the returned UST values?
That's one possibility, which is used e.g. by the Mesa
src/gallium/auxiliary/vl/vl_winsys_dri3.c code. Another possibility
might be determining the refresh rate e.g. via RandR.
--
Earthling Michel Dänzer | http://www.amd.com
flips, while
> giving the driver the flip pixmap provided by the application,
What are the reasons for always copying back to the original pixmap? I
don't think that should be necessary.
--
Earthling Michel Dänzer | http://www.amd.com
Libre soft
a series I just sent, as 8bpp display is quite broken
> otherwise. I'm a bit impressed so much time went by without anyone
> noticing...
FWIW, 8-bit pseudocolor works fine with our hardware and drivers.
--
Earthling Michel Dänzer | http://www.amd.com
Libr
From: Hawking Zhang <hawking.zh...@amd.com>
Signed-off-by: Hawking Zhang <hawking.zh...@amd.com>
[ Michel Dänzer: Adapt to glamor changes since 1.19 ]
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
glamor/glamor_egl.c | 7 +--
glamor/glamor_fbo.c
driver using a given range cannot be disabled.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Org support
Archives: http://li
From: Michel Dänzer <michel.daen...@amd.com>
Fixes double-free later in xf86XvMCCloseScreen, which would generally
cause fireworks.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
hw/xfree86/common/xf86xvmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xf
ntel Gen5 (Arrendale) procudes results consistent with
> radeonsi/llvmpipe.
> So it seems the shader is the culprit.
Yeah, then it sounds like an issue either in glamor or in common Mesa code.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 2018-01-23 05:36 PM, Jeffrey Smith wrote:
> On Tue, Jan 23, 2018 at 10:27 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 2018-01-23 04:26 PM, Chris Wilson wrote:
>>> Quoting Jeffrey Smith (2018-01-23 15:15:10)
>>>> On Mon, Jan 22, 2018 at 3:01 PM, Ch
26 +0100, Clemens Eisserer wrote:
>>>>> Hi there,
>>>>>
>>>>> Glamor's gradient acceleration code is broken in case RepeatReflect is
>>>>> used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
>>>>&
gt; +if (rotation & (RR_Rotate_90 | RR_Rotate_270)) {
> source_width = mode->mode.height;
> source_height = mode->mode.width;
> }
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
ractice, but that is why there are two different paths here.
Sounds like we only want patch 1 then?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
source_width = mode->mode.height;
> -source_height = mode->mode.width;
> -}
> +RRCrtcGetScanoutSize(crtc, _width, _height);
>
> if (crtc->x + source_width > stuff->width ||
> crt
cluded from the
> + * desktop when there are other viable outputs to use
> + */
> +Bool non_desktop;
Can we also bump XF86_CRTC_VERSION, so out-of-tree drivers can know when
this field is available?
--
Earthling Michel Dänzer | http://www.amd.com
you use git bisect to determine which change introduced the problem?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing list
xo
On 2017-12-20 12:18 PM, Pekka Paalanen wrote:
>
> - What X11 applications would be good to analyze for the drawing (damage) they
> produce?
Some xscreensaver hacks can cause lots of tiny damage rectangles, e.g.
interaggregate or cloudlife.
--
Earthling Mich
around to trying it with the
> autotools build yet, nor adding -Werror=strict-aliasing and rebuilding
> the world, but that would obviously be prerequisite for releasing a
> version of util-macros with this change in it.
I don't think compilers can reliably warn about all strict aliasing
vio
On 2017-12-13 04:43 PM, Adam Jackson wrote:
> On Tue, 2017-12-12 at 22:18 +0100, Tomasz Śniatowski wrote:
>> On 8 December 2017 at 16:46, Michel Dänzer <mic...@daenzer.net> wrote:
>>>
>>> Hmm. My initial answer was no, since ComputeLocalClient should only
rom other places, there might be an issue. Anyway,
that's not something introduced by this patch but could be addressed in
another patch. This patch is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
>> Signed-off-by: Tomasz Śniatowski <kailo...@gmail.com>
>> ---
>>
DX driver which is implemented on top of whatever
> driver provides OpenGL functional.
The modesetting driver can only provide hardware acceleration via
glamor, which requires decent EGL and OpenGL support, which is unlikely
to exist for this GPU.
--
Earthling Michel Dänzer |
good catch.
Please take a look at
https://www.x.org/wiki/Development/Documentation/SubmittingPatches/ for
how to properly create a patch and send it for review.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X deve
From: Michel Dänzer <michel.daen...@amd.com>
We were sending the events to all clients listening for them on the
window. But clients can get confused by events from another client, and
I can't imagine any case where receiving events from other clients would
be required.
v2:
* Also re
On 14/11/17 09:59 PM, Adam Jackson wrote:
> If the context is direct none of the GL commands were issued by this
> process, the server couldn't flush them even if it wanted to.
>
> v2: Fix embarassingly obvious boolean inversion (Michel Dänzer)
>
> Signed-off-by: Adam Jackso
On 09/11/17 08:09 PM, Alex Goins wrote:
>> On 09/11/17 02:34 AM, Alex Goins wrote:
>>> On Wed, 8 Nov 2017, Michel Dänzer wrote:
>
>> I'm asking this to avoid ending up in a similar situation as with the
>> PRIME synchronization functionality, where it seems like t
s context if needed.
> */
> -Bool need_flush = GL_TRUE;
> +Bool need_flush = prevglxc->isDirect;
Should be
Bool need_flush = !prevglxc->isDirect;
to match the commit log?
--
Earthling Michel Dänzer | http://www.amd.
overlay in some generic place so it works with all the drivers is a better
> solution then allowing drivers to opt-out.
Unfortunately, that's not really possible, because at least
xf86-video-intel doesn't use PixmapSyncDirtyHelper. So even if that is
made to handle this transparen
On 09/11/17 02:34 AM, Alex Goins wrote:
> On Wed, 8 Nov 2017, Michel Dänzer wrote:
>
>>> Change 7b634067 added HW cursor support for PRIME by removing the
>>> pixmap_dirty_list check from xf86CursorSetCursor() and making the requisite
>>> cursor functions se
rendering
infrastructure. We used to have the same issue with DRI1, but no more
with DRI2/DRI3 (we still have an intermittent cursor flickering issue
though, but not corruption).
--
Earthling Michel Dänzer | http://www.amd.com
Libre
k_flip needs to set a reason value even if the driver
doesn't provide the check_flip2 hook.
> diff --git a/present/present.h b/present/present.h
> index aab2e168a..094946a7c 100644
> --- a/present/present.h
> +++ b/present/present.h
> @@ -27,6 +27,9
> if (strcmp(extensions[i]->name, __DRI2_FLUSH_CONTROL) == 0) {
> __glXEnableExtension(screen->glx_enable_bits,
> - "GLX_ARB_context_flush_control\n");
> + "GLX_ARB_context_flush_control&q
t; actually interpolate the missing entries as described by Aaron?
> Need get confirm from DCE and kernel guys.
Internal discussion revealed that the kernel driver is currently not
enabling any hardware gamma functionality at depth 30, so instead of
this patch, the Xorg driver will just not call xf8
programs 256 gamma CLUT entries, does the hardware
actually interpolate the missing entries as described by Aaron? Does
this allow displaying gradients without banding, whereas the same
gradients show banding at depth 24?
--
Earthling Michel Dänzer |
, because the hardware gamma CLUT we've been using has 10 R/G/B
bits per entry.
If we're going to change xserver code, I'd make xf86CrtcCreate choose
gamma_size based on the screen depth in the first place.
--
Earthling Michel Dänzer |
c gamma_size, if palette size go back to <= 256,
> shrink it to 256
AFAIK the screen depth and by extension palette size can never change
during the server's lifetime.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
e fixed then, and the userspace driver should probably
>> only allow setting depth 30 when it knows the kernel driver can handle it.
> That's the DDX work. For amdgpu, seems we can support it in DC KMS.
Right, let's handle this in the driver, and drop this patch.
--
robably
only allow setting depth 30 when it knows the kernel driver can handle it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org:
ma_size should always be >= palette_size.
Specifically, if the gamma ramp only has 256 entries, what's the benefit
of having 1024 entries in the palette?
What's the exact configuration in which you hit this?
--
Earthling Michel Dänzer | http://www.amd.com
L
On 20/10/17 09:58 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> We were sending the events to all clients listening for them on the
>> window. But clients can get confused by
On 20/10/17 09:58 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> We were sending the events to all clients listening for them on the
>> window. But clients can get confused by
events specifically. In contrast to those,
with PresentCompleteKindPixmap I can at least imagine a use for seeing
events from other clients, e.g. so multiple clients can consistently
count the number of presentations performed to a window.
--
Earthling Michel Dänzer | http:
ging either clobbered the hardware gamma values from the
other one.
Now, all of those things are fixed, the colormap and various gamma
values are correctly combined with each other.
> So I'm not sure. Is this a correct way to fix it?
Yes, it is.
Reviewed-by: Michel Dänzer
From: Michel Dänzer <michel.daen...@amd.com>
We were sending the events to all clients listening for them on the
window. But clients can get confused by events from another client, and
I can't imagine any case where reciving events from other clients would
be required.
Signed-off-by:
pleteModeSuboptimalCopy will break clients which don't
know about it. There needs to be some kind of handshake to know that the
client can handle it. E.g. via a new PresentOption, or via the minor
version passed in by the client in the PresentQueryVersion request
p;&
> +window_pixmap != screen_priv->flip_pixmap &&
> + window_pixmap != present_flip_pending_pixmap(screen))
> +return FALSE;
Could short-cut this a little if the window is already flipping:
window_pixmap = screen->GetWindowPixmap(window);
i
On 17/10/17 10:48 AM, Michel Dänzer wrote:
> On 17/10/17 06:52 AM, Keith Packard wrote:
>>
>> PresentOptionRelative
>>
>> If 'options' contains PresentOptionRelative, then the most
>> recent actual MSC for a PresentPixmap request to the same
>>
e target MSC values will
trail the drawable's current MSC, and the application's presentation
timing may be "different" until it catches up.
How about this instead: If there are pending PresentPixmap requests for
the window, the relative target will be adde
Xorg normally works fine without a
configuration file these days. If it doesn't on this setup, share the
corresponding log file.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
nfo and) see the rest of this call
>>> trace? I suspect the value of 'dev' being passed into
>>> pci_device_vgaarb_set_target is just bogus, but without the call trace
>>> up through Xorg it's hard to see how that could happen.
>>>
>>> - ajax
>>
ide the terminal output of e.g. mplayer when there is tearing in
fullscreen?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing l
or even pure
X11)
3. Enabling TearFree
Note that 1.+2. are not sufficient when using rotation or other
transforms via the RandR extension.
Does your setup fall under any of these cases? If not, you may just have
gotten lucky before.
--
Earthling Michel Dänzer |
mpting that over SSH just results in the connection hanging. Is
there any way to detect that passing file descriptors doesn't work?
FWIW, xserver >= 1.18.4 detects SSH connections via the client's process
name, treats them as remote and doesn't expose DRI3 on them.
--
Earthling Michel Dänzer
On 02/10/17 08:28 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> No, but mode changes are also irrelevant for whether or not page
>> flipping can be used.
>
> What about changing the size of the CRTC that the application is
> disp
t;
That could be due to X server bugs fixed by:
https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.19-branch=358f0bcd4f6703302b8895e42e20d1cbdfff102e
https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.19-branch=0934d56dc804780f3e83ae0153c797d392e6faba
-
On 29/09/17 10:55 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Or maybe it would be sufficient for clients to simply re-query the
>> modifiers in response to PresentConfigureNotify events?
>
> Would that also get sent when modes are
PresentCompleteNotifyMask | \
> PresentIdleNotifyMask | \
> -PRESENT_REDIRECT_NOTIFY_MASK)
> +PRESENT_REDIRECT_NOTIFY_MASK | \
> +PresentWindowCrtcNotifyMask)
&
The window was flipping but no longer can (e.g. from
present_unflip)
Or maybe it would be sufficient for clients to simply re-query the
modifiers in response to PresentConfigureNotify events?
--
Earthling Michel Dänzer | http://www.amd.com
Li
it log needs to be updated for the current hook names
(can_wait_fence, wait_fence).
P.S. It would be nice to have a changelog in each patch describing what
(if anything) changed between v1 and v2.
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
> xorg_list_for_each_entry(vblank, _flip_queue, event_queue) {
> if (vblank->event_id == event_id) {
>
This is a bug fix which is independent of the rest of the series, so it
should be submitted separately and applied for an upcoming 1.19.4 release.
Reviewed-by: Michel Dänzer <mi
if (ret == 0) {
> +if (msc_queued)
> +*msc_queued = ms_kernel_msc_to_crtc_msc(crtc,
> vbl.reply.sequence);
> +return TRUE;
> + }
> +#ifdef DRM_IOCTL_CRTC_QUEUE_SEQUENCE
> +check:
> +#endif
The DRM_IOCTL_CRTC_QUEUE_SEQUENCE pa
ot;xfree86/modes: Use RRTransformEqual in
xf86RandR12CrtcSet")
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org
Anholt (1):
Use plain glamor_egl_create_textured_screen().
Martin Peres (1):
modesetting: re-set the crtc's mode when link-status goes BAD
Michel Dänzer (46):
Post-release version bump
manpage: Don't put "'" at the beginning of a line
Don't set mo
Anholt (1):
Use plain glamor_egl_create_textured_screen().
Martin Peres (1):
modesetting: re-set the crtc's mode when link-status goes BAD
Michel Dänzer (46):
Post-release version bump
manpage: Don't put "'" at the beginning of a line
Don't set mo
(1):
Use plain glamor_egl_create_textured_screen().
Martin Peres (1):
modesetting: re-set the crtc's mode when link-status goes BAD
Michel Dänzer (45):
Post-release version bump
manpage: Don't put "'" at the beginning of a line
Don't set mo
(1):
Use plain glamor_egl_create_textured_screen().
Martin Peres (1):
modesetting: re-set the crtc's mode when link-status goes BAD
Michel Dänzer (45):
Post-release version bump
manpage: Don't put "'" at the beginning of a line
Don't set mo
RFC.
>
> Not to mention that this is an ABI break ;-)
Indeed, and the sync_flip parameter is used by the xf86-video-intel SNA
driver.
In general, it's not hard to imagine that a driver's return value for
this hook could depend on the sync_flip value, so I don't think this is
a good idea.
--
Earthling
On 30/08/17 06:15 PM, Roman Gilg wrote:
> On Wed, Aug 30, 2017 at 4:42 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>> wrote:
> On 30/08/17 12:24 AM, Roman Gilg wrote:
> >
> > Originating from the bug report
> >
> &
On 30/08/17 06:14 PM, Roman Gilg wrote:
> On Wed, Aug 30, 2017 at 4:35 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>> wrote:
>
> On 30/08/17 12:24 AM, Roman Gilg wrote:
> > This patch adds a new mode to the internal flip mode API, t
X11
request using a window eventually uses its window pixmap to access the
window contents.
> On Wed, Aug 30, 2017 at 4:10 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>> wrote:
>
> On 30/08/17 12:24 AM, Roman Gilg wrote:
> > This patch
; @@ -388,7 +458,10 @@ static present_screen_info_rec ms_present_screen_info = {
> #ifdef GLAMOR_HAS_GBM
> .check_flip = ms_present_check_flip,
> .flip = ms_present_flip,
> +.flip_with_fence = ms_present_flip_with_fence,
> .unflip = ms_present_unflip,
> +.can_wait = ms_present_can_wai
;event_id == event_id) {
>
Hmm, I guess this can happen if present_flip() fails in
present_execute()? Do you have a reproducible way to trigger a problem
without this change?
Should the same code in present_abort_vblank() be removed as well?
--
Earthling Michel Dänzer |
+ 20 unused
> +
> + 4 ListOfCARD32modifiers[2*num_modifiers]
> +└───
... or here.
It doesn't seem to get assigned by the xserver code either. A leftover?
(I just happened to notice this, there might be other similar issues)
--
ionAsync, the
intention is for the presentation frame rate to match the scanout
refresh rate.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xor
ely when
the flip completes for the target CRTC and when the previous buffer can
be re-used.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lis
instead only called
present_event_notify once it's received some kind of feedback from the
Wayland compositor that it has processed the "flip". There's no such
thing as an "immediate flip".
--
Earthling Michel Dänzer | http://www.a
'm afraid I have to NAK this patch in this form.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: ht
he MSB set to a signed variable
well-defined in C?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives
can reproduce this needs to trace the code execution from
amdgpu_kernel_mode_enabled returning TRUE to xf86BusConfig printing "No
devices detected." to find out what goes wrong in between.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
On 11/08/17 12:04 AM, Pekka Paalanen wrote:
> On Mon, 7 Aug 2017 17:36:27 +0900
> Michel Dänzer <mic...@daenzer.net> wrote:
>> On 04/08/17 06:57 PM, Roman Gilg wrote:
>>> On Fri, Aug 4, 2017 at 8:44 AM, Michel Dänzer <mic...@daenzer.net
>>> <mailto:mic...
On 13/07/17 05:27 PM, Michel Dänzer wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>> ---
>>
>> Chris / Ilia / Ben, this should be
On 04/08/17 06:57 PM, Roman Gilg wrote:
> On Fri, Aug 4, 2017 at 8:44 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>> wrote:
>
> On 03/08/17 09:11 PM, Roman Gilg wrote:
> > On Wed, Aug 2, 2017 at 11:36 AM, Michel Dänzer <
On 03/08/17 09:11 PM, Roman Gilg wrote:
> On Wed, Aug 2, 2017 at 11:36 AM, Michel Dänzer <mic...@daenzer.net
> <mailto:mic...@daenzer.net>> wrote:
>
> On 02/08/17 03:53 AM, Roman Gilg wrote:
> >
> > Overview of differences in Rootless mode:
>
On 03/08/17 01:19 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Shouldn't this be done at a higher level instead?
>
> Thanks for a really good question.
>
> The X server doesn't touch cursors when turning off crtcs that aren't in
On 02/08/17 07:42 PM, Keith Packard wrote:
> This makes sure the cursor doesn't appear on the output at some later
> time, as when leased by an X client.
Shouldn't this be done at a higher level instead?
--
Earthling Michel Dänzer | http://www.amd.com
Libre so
> ---
> Open Questions:
> ---
>
> * For (4) is the Composite extension the only explanation for the region
> of the xwl_window to differ from the presenting child window? Are there
> other cases I don't yet know about that I have to
for (int i = 0; i < nrect; i++)
> +glamor_bounds_union_rect(, [i]);
> +}
Did your testing hit the nrect == 99 cases? I'd expect those to have the
most potential impact on throughput.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
trictions don't seem to be biting anyone:
> I haven't seen any demand for extended formats.
As explained in other posts, there is no fixed format
mapping/restriction with DRI3 v1.0 anyway. It can support all formats
that can be stored as integer values of n bits, where n matches (or is
e
On 28/07/17 07:39 PM, Daniel Stone wrote:
> On 28 July 2017 at 09:54, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 28/07/17 05:03 PM, Daniel Stone wrote:
>>> By implementation if not spec, DRI3 v1.0 enforces that depth 16 is
>>> RGB565, depth 24 is X
On 28/07/17 04:14 PM, Daniel Stone wrote:
> On 26 July 2017 at 07:21, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 26/07/17 10:48 AM, Michel Dänzer wrote:
>>> On 26/07/17 06:20 AM, Eric Anholt wrote:
>>>> Daniel Stone <dani...@collabora.com>
r Pixmaps is the best thing.
>
> tl;dr: we could replace FourCC with depth as the format determinant to
> better match DRI3 v1.0, or just declare that doing anything with those
> Pixmaps other than displaying them to a Window with a compatible
> Visual results in undefined
On 27/07/17 04:08 PM, Nicolai Hähnle wrote:
> On 27.07.2017 03:14, Michel Dänzer wrote:
>> On 26/07/17 09:15 PM, Nicolai Hähnle wrote:
>>> On 26.07.2017 08:29, Michel Dänzer wrote:
>>>> On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
>>>>> On 22.07.2017 1
On 27/07/17 07:38 AM, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> [ Unknown signature status ]
>> On 26/07/17 06:20 AM, Eric Anholt wrote:
>>> Daniel Stone <dani...@collabora.com> writes:
>>>
>>>> DRI3 versi
On 26/07/17 09:15 PM, Nicolai Hähnle wrote:
> On 26.07.2017 08:29, Michel Dänzer wrote:
>> On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
>>> On 22.07.2017 14:00, Daniel Stone wrote:
>>>>
>>>> Given that, I'm fairly inclined to punt those until we have the
.@redhat.com>
> ---
> v2: Make sure we have (x1,y1) < (x2,y2) in case of overflow to avoid an
> empty region.
An empty region actually seems more appropriate to me in that case.
Maybe just don't call RegionInitBoxes if short_box is empty?
--
Earthling Michel Dänzer
er, we could have a stride requirement in elements or pixels
> instead of bytes.
Interesting idea. FWIW, I suspect we'd need to support specifying the
requirement in both bytes or pixels, since one or the other alone may
not be sufficient to describe the constraints of all hardware.
On 26/07/17 10:48 AM, Michel Dänzer wrote:
> On 26/07/17 06:20 AM, Eric Anholt wrote:
>> Daniel Stone <dani...@collabora.com> writes:
>>
>>> + combined to specify a single logical source for pixel
>>> + sampling: 'num_buffers' may be set from 1 (single b
ying how the depth of the Pixmap is determined from
> the fourcc? Should we be specifying if X11 rendering works on various
> fourccs, and between pixmaps of different fourccs? It's not clear to me
> what glamor would need to be able to do with these pixmaps (can I
> CopyArea between XRGB
What happened when you tried? I guess it might be related to rootless.
> I change the Window Pixmaps currently directly in the Xwayland DDX
> without traversing the tree:
> https://github.com/subdiff/xserver/blob/presentInXwayland/hw/xwayland/xwayland-present.c
es, it would be good to include that fix (and a bunch of others) in any
future 1.19.y release.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel
the scope of this extension.
+
+ If buffers cannot be exported from the the screen associated
+ with 'pixmap', a Match error is returned.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X
On 15/07/17 07:24 AM, Ivan Sergio Borgonovo wrote:
On 07/15/2017 05:29 AM, Michel Dänzer wrote:
On 15/07/17 07:10 AM, Ivan Sergio Borgonovo wrote:
On 07/10/2017 04:03 AM, Michel Dänzer wrote:
On 09/07/17 03:06 AM, Ivan Sergio Borgonovo wrote:
Please provide the output of the following
201 - 300 of 2518 matches
Mail list logo
