Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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)

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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

Re: [PATCH xserver 14/15] dri3: s/intersect/window/ to match the names used in caller

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

Re: [PATCH xserver 05/15] dri3: annotate {s, }proc_dri3_vector as static const

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

Re: [PATCH xserver 2/3] meson: Distribute more SDK headers

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

Re: [PATCH xserver 15/15] dri3: correctly handle failed get_supported_modifiers requests

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: > -

Re: [PATCH xserver] modesetting: Fix page flipping harder under DRI 3.2.

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. >

Re: [PATCH xserver 1/2] modesetting: Use atomic modesetting to set DPMS mode

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

Re: [PATCH xserver 0/7] Fix modifier server / non-mod client

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

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

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

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

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

Re: [PATCH xserver 1/2] modesetting: Use atomic modesetting to set DPMS mode

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

Re: [PATCH xserver] modesetting: Fix page flipping harder under DRI 3.2.

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

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

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

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

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:

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

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

[PATCH xserver 5/7] glamor: Reallocate pixmap storage without modifiers if necessary

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

[PATCH xserver 6/7] glamor: Fall back to non-modifier allocations

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

[PATCH xserver 7/7] glamor: Add fd_from_pixmap hook

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

[PATCH xserver 4/7] glamor: Push make_exportable into callers

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:

[PATCH xserver 3/7] glamor: Track if BO allocation used modifiers

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

[PATCH xserver 2/7] drmmode: Track if BO allocation used modifiers

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

[PATCH xserver 0/7] Fix modifier server / non-mod client

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

[PATCH xserver 1/7] dri3: Use single-FD screen call for single-FD request

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

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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.

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per 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: > >> >> -

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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", >> >> -

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

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:

Re: [PATCH xserver 01/15] dri3: annotate the dri3_screen_info data as const

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

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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

Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

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.

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

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;