Hi
I've just tested with those patches, it still doesn't work without that revert
If you're testing this on kwin can you make sure you're using one of
the OpenGL options on the renderer rather than XRender
Thanks
Mike
On 4 April 2018 at 17:17, Daniel Stone wrote:
> Hi Mike,
>
> On 4 April 201
On Wed, 2018-04-04 at 21:30 +0200, Giuseppe Bilotta wrote:
> On Wed, Apr 4, 2018 at 5:12 PM, Adam Jackson wrote:
> > On Tue, 2018-04-03 at 22:15 +0200, Pali Rohár wrote:
> > > Gently reminder of this patch. Can you comment/review it?
> >
> > Nack. The whole point of (that part of) xdpyinfo is to
On Wed, Apr 4, 2018 at 5:12 PM, Adam Jackson wrote:
> On Tue, 2018-04-03 at 22:15 +0200, Pali Rohár wrote:
>> Gently reminder of this patch. Can you comment/review it?
>
> Nack. The whole point of (that part of) xdpyinfo is to show you what
> was sent in the initial connection block. xrandr alread
On Mon, 2018-04-02 at 16:41 +0100, Emil Velikov wrote:
> @@ -217,44 +217,44 @@ dri3_get_supported_modifiers(ScreenPtr screen,
> DrawablePtr drawable,
> }
>
> /* We're allocating slightly more memory than necessary but it reduces
> - * the complexity of finding the intersection set
On Mon, 2018-04-02 at 16:41 +0100, Emil Velikov wrote:
> diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
> index fc258711b..7ced6747c 100644
> --- a/dri3/dri3_request.c
> +++ b/dri3/dri3_request.c
> @@ -32,6 +32,9 @@
> #include
> #include
>
> +/* Should be provided by the guts of X */
On Tue, 2018-04-03 at 12:16 +0200, Thierry Reding wrote:
> Yeah, looking more closely at the automake file it has XORG guards
> around all of the SDK headers. There's also some inconsistencies there
> with regards to which files are included depending on other extensions
> being enabled. For examp
On Mon, 2018-04-02 at 16:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently depending on the code path hit, the helper will set some of
> the output values and not others.
>
> It could also leak memory ;-)
>
> At the same time the caller was:
> - working around the broken behavio
On Wed, 2018-04-04 at 17:20 +0100, Daniel Stone wrote:
> On 4 April 2018 at 02:49, Mario Kleiner wrote:
> > Non-atomic kms drivers like radeon-kms (or nouveau-kms with
> > default setting of "atomic ioctl disabled") don't export
> > any formats, so num_formats == 0.
> >
> > Some atomic drivers (n
On Wed, 2018-04-04 at 17:21 +0100, Daniel Stone wrote:
> Hi Louis-Francis,
>
> On 4 April 2018 at 05:01, Louis-Francis Ratté-Boulianne
> wrote:
> > CRTCs and outputs needs to be enabled/disabled when the current
> > DPMS mode is changed. We also try to do it in an atomic commit
> > when possible.
On Wed, 2018-04-04 at 16:16 +0100, Daniel Stone wrote:
> Hi,
> This series fixes running a modifier-aware server with a
> non-modifier-aware DRI3 compositing manager. We'd thought of and dealt
> with the case where we had legacy/non-modifier-aware clients, but
> slipped up with non-modifier-aware c
Hi Mario,
On 4 April 2018 at 17:40, Mario Kleiner wrote:
> On Wed, Apr 4, 2018 at 6:19 PM, Daniel Stone wrote:
>> Ugh. I've applied your pageflip patch, lfrb's two-patch atomic fix
>> series and my fix-old-clients series, which for me fixes KDE running
>> with both old and new Mesa. That's just
On Wed, Apr 4, 2018 at 6:19 PM, Daniel Stone wrote:
> Hi Mario,
>
> On 4 April 2018 at 06:22, Mario Kleiner wrote:
>> Ok, so it's probably a mesa bug in the egl dri3 backend caused by the
>> new DRI3.1 multibuffers support.
>>
>> If on current mesa master, in egl_dri2.c:dri2_setup_extensions(), i
Hi Louis-Francis,
On 4 April 2018 at 05:01, Louis-Francis Ratté-Boulianne
wrote:
> CRTCs and outputs needs to be enabled/disabled when the current
> DPMS mode is changed. We also try to do it in an atomic commit
> when possible.
It would be really nice to separate the code motion from the change
On 4 April 2018 at 02:49, Mario Kleiner wrote:
> Non-atomic kms drivers like radeon-kms (or nouveau-kms with
> default setting of "atomic ioctl disabled") don't export
> any formats, so num_formats == 0.
>
> Some atomic drivers (nouveau-kms with boot param nouveau.atomic=1,
> or intel-kms on, e.g.
Hi Mario,
On 4 April 2018 at 06:22, Mario Kleiner wrote:
> Ok, so it's probably a mesa bug in the egl dri3 backend caused by the
> new DRI3.1 multibuffers support.
>
> If on current mesa master, in egl_dri2.c:dri2_setup_extensions(), i
> force dri2_dpy->multibuffers_available = false; to disable
Hi Mike,
On 4 April 2018 at 09:12, Mike Lothian wrote:
> Kwin doesn't seem to start with the following commit:
>
> commit abb9b58d1af9a0286162e52ef9db390d0c950fc1
> Author: Thierry Reding
> Date: Fri Mar 16 14:24:21 2018 +0100
>
> present: Advertise protocol version 1.2
>
> [...]
>
> T
Hi Emil
I'm running the latest everything from git and have that commit
Regards
Mike
On Wed, 4 Apr 2018 at 12:50 Emil Velikov wrote:
> Hi Mike,
>
> On 4 April 2018 at 09:12, Mike Lothian wrote:
> > Hi
> >
> > Kwin doesn't seem to start with the following commit:
> >
> > commit abb9b58d1af9a0
If we try to allocate with particular modifiers but it fails, try to
fall back to non-modifier allocations.
Signed-off-by: Daniel Stone
Reported-by: Adam Jackson
---
glamor/glamor_egl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_
If we need a pixmap's storage to be exported to a context in which we
aren't aware of modifiers, reallocate the buffer again without
modifiers.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic mod
Add a fd_from_pixmap (singular) hook to go with fds_from_pixmap, which
will ensure that the pixmap is allocated without modifiers and is thus
exportable to non-modifier-aware clients.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates
Rather than calling make_exportable from the get_bo entrypoint, make
sure that someone has already explicitly requested the pixmap be
exportable.
This is technically an ABI break in that it changes observable
behaviour, but no driver other than modesetting has ever used get_bo.
Signed-off-by: Dan
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a composit
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a composit
Hi,
This series fixes running a modifier-aware server with a
non-modifier-aware DRI3 compositing manager. We'd thought of and dealt
with the case where we had legacy/non-modifier-aware clients, but
slipped up with non-modifier-aware compositing managers.
Glamor would allocate pixmaps with the full
When importing client buffers into Pixmaps, we can use the fds_to_pixmap
hook for both single-FD and multi-FD client requests without any harm.
For the other direction of exporting Pixmap buffers to client FDs,
create a new helper which calls the old pixmap_to_fd hook if available.
This allows the
On Tue, 2018-04-03 at 22:15 +0200, Pali Rohár wrote:
> Gently reminder of this patch. Can you comment/review it?
Nack. The whole point of (that part of) xdpyinfo is to show you what
was sent in the initial connection block. xrandr already exists, and
code exists that depends on xdpyinfo's output.
On Wednesday 04 April 2018 13:59:15 Giuseppe Bilotta wrote:
> Hello,
>
> I took the liberty of moving the last paragraph of your email to the
> top because the reply I'm giving to that part covers both.
>
> On Wed, Apr 4, 2018 at 11:26 AM, Pali Rohár wrote:
> >> >> -printf (" dimensions:
Hello,
I took the liberty of moving the last paragraph of your email to the
top because the reply I'm giving to that part covers both.
On Wed, Apr 4, 2018 at 11:26 AM, Pali Rohár wrote:
>> >> -printf (" dimensions:%dx%d pixels (%dx%d millimeters)\n",
>> >> - XDisplayWidth (dpy,
Hi Mike,
On 4 April 2018 at 09:12, Mike Lothian wrote:
> Hi
>
> Kwin doesn't seem to start with the following commit:
>
> commit abb9b58d1af9a0286162e52ef9db390d0c950fc1
> Author: Thierry Reding
> Date: Fri Mar 16 14:24:21 2018 +0100
>
> present: Advertise protocol version 1.2
>
> Ever
On 2 April 2018 at 20:34, Adam Jackson wrote:
> On Mon, 2018-04-02 at 16:41 +0100, Emil Velikov wrote:
>
>> Why do we have the explicit _rec and _ptr typecasts to begin with?
>
> Convention, mostly. The typedef for the struct is because 'struct' is a
> dumb word to need to say all the time. The ty
Hi!
On Wednesday 04 April 2018 09:47:59 Giuseppe Bilotta wrote:
> Hello Pali,
>
> I like the idea of this patch, wasn't aware of its existence, thanks
> for pinging me about it. A few comments below:
>
> On Tue, Apr 3, 2018 at 10:15 PM, Pali Rohár wrote:
> >> @@ -455,27 +462,75 @@ print_screen_
Hi
Kwin doesn't seem to start with the following commit:
commit abb9b58d1af9a0286162e52ef9db390d0c950fc1
Author: Thierry Reding
Date: Fri Mar 16 14:24:21 2018 +0100
present: Advertise protocol version 1.2
Everything is implemented to support protocol version 1.2. Make it
official
Hello Pali,
I like the idea of this patch, wasn't aware of its existence, thanks
for pinging me about it. A few comments below:
On Tue, Apr 3, 2018 at 10:15 PM, Pali Rohár wrote:
>> @@ -455,27 +462,75 @@ print_screen_info(Display *dpy, int scr)
>> double xres, yres;
>> int ndepths = 0,
33 matches
Mail list logo