Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On Wed, Jul 26, 2017 at 8:29 AM, Michel Dänzer wrote: > On 25/07/17 05:28 PM, Nicolai Hähnle wrote: >> On 22.07.2017 14:00, Daniel Stone wrote: >>> >>> I don't have any great solution off the top of my head, but I'd be >>> inclined to bundle stride in with placement. TTBOMK

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

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: I don't have any great solution off the top of my head, but I'd be inclined to bundle stride in with placement. TTBOMK (from having looked at radv), buffers shared

[PATCH xserver v2 2/2] glamor: Avoid overflow between box32 and box16 box

glamor_compute_transform_clipped_regions() uses a temporary box32 internally which is copied back to a box16 to init the regions16, thus causing a potential overflow. If an overflow occurs, the given region is invalid and the pixmap init region will fail. Simply check that the coordinates won't

[PATCH v5] Add xdg-output protocol

This protocol aims at describing outputs in way which is more in line with the concept of an output on desktop oriented systems. Some information are more specific to the concept of an output for a desktop oriented system and may not make sense in other applications, such as IVI systems for

Re: [PATCH xserver v2 2/2] glamor: Avoid overflow between box32 and box16 box

On 26/07/17 04:51 PM, Olivier Fourdan wrote: > glamor_compute_transform_clipped_regions() uses a temporary box32 > internally which is copied back to a box16 to init the regions16, > thus causing a potential overflow. > > If an overflow occurs, the given region is invalid and the pixmap > init

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On 25/07/17 05:28 PM, Nicolai Hähnle wrote: > On 22.07.2017 14:00, Daniel Stone wrote: >> >> I don't have any great solution off the top of my head, but I'd be >> inclined to bundle stride in with placement. TTBOMK (from having >> looked at radv), buffers shared cross-GPU also need to be allocated

Re: [PATCH xserver v2 2/2] glamor: Avoid overflow between box32 and box16 box

Hi Michel, > > > glamor_compute_transform_clipped_regions() uses a temporary box32 > > > internally which is copied back to a box16 to init the regions16, > > > thus causing a potential overflow. > > > > > > If an overflow occurs, the given region is invalid and the pixmap > > > init region will

Re: [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On 26/07/17 10:48 AM, Michel Dänzer wrote: > On 26/07/17 06:20 AM, Eric Anholt wrote: >> Daniel Stone writes: >> >>> + combined to specify a single logical source for pixel >>> + sampling: 'num_buffers' may be set from 1 (single buffer, >>> + akin to PixmapFromBuffer)

Re: [PATCH xserver v2 2/2] glamor: Avoid overflow between box32 and box16 box

Hi Michel, > > glamor_compute_transform_clipped_regions() uses a temporary box32 > > internally which is copied back to a box16 to init the regions16, > > thus causing a potential overflow. > > > > If an overflow occurs, the given region is invalid and the pixmap > > init region will fail. > >

[PATCH xserver 1/2 v2] glamor: handle NULL source picture

COMPOSITE_REGION() can pass NULL as a source picture, make sure we handle that nicely in both glamor_composite_clipped_region() and glamor_composite_choose_shader(). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894 Signed-off-by: Olivier Fourdan --- v2: Make sure

[PATCH xserver 2/2 v3] glamor: Avoid overflow between box32 and box16 box

glamor_compute_transform_clipped_regions() uses a temporary box32 internally which is copied back to a box16 to init the regions16, thus causing a potential overflow. If an overflow occurs, the given region is invalid and the pixmap init region will fail. Simply check that the coordinates won't

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On 26.07.2017 19:42, Marek Olšák wrote: On Wed, Jul 26, 2017 at 7:05 PM, Alex Deucher wrote: On Wed, Jul 26, 2017 at 8:15 AM, 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

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On Wed, Jul 26, 2017 at 8:15 AM, 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: I don't have any great solution off the top of my head, but I'd

Re: [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

Michel Dänzer writes: > [ Unknown signature status ] > On 26/07/17 06:20 AM, Eric Anholt wrote: >> Daniel Stone writes: >> >>> DRI3 version 1.1 adds support for explicit format modifiers, including >>> multi-planar buffers. >> >> I still want proper

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

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 grand glorious allocator, rather than

Re: [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On 27/07/17 07:38 AM, Eric Anholt wrote: > Michel Dänzer writes: > >> [ Unknown signature status ] >> On 26/07/17 06:20 AM, Eric Anholt wrote: >>> Daniel Stone writes: >>> DRI3 version 1.1 adds support for explicit format modifiers, including