Re: [PATCH 7/8] glamor: add core profile support to EGL glamor. (v2)

On 19.01.2016 16:02, Dave Airlie wrote: > From: Dave Airlie > > This breaks ABI unfortunately as we have to pass the core profile > info from the egl part of glamor to the glamor part of glamor. Drop this paragraph. > @@ -798,12 +807,21 @@ glamor_egl_init(ScrnInfoPtr scrn,

Re: glamor core profile support

On Tue, Jan 19, 2016 at 1:56 AM, Dave Airlie wrote: > This series implements support for glamor in ephyr/EGL/Xwayland > to use GL core profile when it can. > > This required 4 main changes: > a) stop using client ptrs everywhere, I found 3 places left, > gradient, picture and

Re: [PATCH v2 xserver] glamor: Disable debugging messages other than GL API errors

Michel Dänzer writes: > From: Michel Dänzer > > According to Nicolai Hähnle, the relevant specification says "All > messages are initially enabled unless their assigned severity is > DEBUG_SEVERITY_LOW", so we need to explicitly disable the messages

Re: [PATCH] glamor: don't do copy if we have 0 boxes to copy.

On 20 January 2016 at 03:56, Eric Anholt wrote: > Dave Airlie writes: > >> From: Dave Airlie >> >> This happens if you run twm + mplayer + xclock and drag >> the clock over the mplayer. If we don't catch it, we cause >> an illegal draw

Re: [PATCH] glamor: don't do copy if we have 0 boxes to copy.

Dave Airlie writes: > From: Dave Airlie > > This happens if you run twm + mplayer + xclock and drag > the clock over the mplayer. If we don't catch it, we cause > an illegal draw elements command to be passed to GL. What exactly is the error? I was

[PATCH evdev 2/2] Don't reset the other axis on wheel emulation scroll buildup

The idea was that of a direction lock: as we move vertically we should not build up any horizontal scroll motion even if we move slightly diagonally. The effect was though that the axis would be reset completely as soon as an event from the other axis occured. With the default threshold of 10, if

Re: [PATCH 3/8] glamor: Use vertex arrays

Dave Airlie writes: > From: Keith Packard > > Core contexts require the use of vertex arrays, so switch both glamor > and ephyr/glamor over. > > Signed-off-by: Keith Packard > Signed-off-by: Dave Airlie commit

[PATCH evdev 1/2] Restore wheel emulation for absolute devices

Wheel emulation relies on oldVals, which stopped updating in 3dcf6f123c5. Since wheel emulation may filter the abs event, store the event before we do anything with it. If we really want the abs_event, abs_queued will be set to 1, otherwise the value will be ignored. And now that we know

Re: [PATCH 6/8] ephyr: Create 3.3 core profile context if possible (v3)

On Mon, Jan 18, 2016 at 11:02 PM, Dave Airlie wrote: > From: Keith Packard > > On desktop GL, Ask for a 3.3 core profile context if that's available, > otherwise create a generic context. > > v2: tell glamor the profile is a core one. > v2.1: add/use GL

[PATCH] glx: don't force version == 2.0 for ES2 GLX context creation

dEQP tests request a specific version. The EXT spec has been updated to allow other versions, so allow anything >= 2.0 to be requested. Signed-off-by: Ilia Mirkin --- glx/createcontext.c | 23 --- 1 file changed, 4 insertions(+), 19 deletions(-) diff

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

On 16.01.2016 02:03, Keith Packard wrote: > Michel Dänzer writes: > >> From: Michel Dänzer >> >> When a window moves from one CRTC to another, present_window_to_crtc_msc >> updates window_priv->msc_offset according to the delta between the >> current

Re: [PATCH xserver] present: Handle wraparound when comparing MSC values

On 15/01/16 19:03, Keith Packard wrote: Michel Dänzer writes: From: Michel Dänzer When a window moves from one CRTC to another, present_window_to_crtc_msc updates window_priv->msc_offset according to the delta between the current MSC values of the

Re: [PATCH 3/8] glamor: Use vertex arrays

Dave Airlie writes: > From: Keith Packard > > Core contexts require the use of vertex arrays, so switch both glamor > and ephyr/glamor over. I had been thinking of doing serious VAO usage, where each path set up its VAO so that the driver could precompute

Re: [PATCH 4/8] glamor: Use GL_RED instead of GL_ALPHA if we have texture_swizzle

Dave Airlie writes: > From: Keith Packard > > GL_RED is supported by core profiles while GL_ALPHA is not; use GL_RED > for one channel objects (depth 1 to 8), and then swizzle them into the > alpha channel when used as a mask. > > [airlied: updated to

Re: [PATCH 5/8] glamor: add core profile support.

Dave Airlie writes: > From: Dave Airlie > > This adds a new flag to glamor_init to denote the context is > core profile. > > This flag is used to disable quads for rendering. > > Signed-off-by: Dave Airlie > --- > glamor/glamor.c | 3

Re: [PATCH 6/8] ephyr: Create 3.3 core profile context if possible (v2)

Dave Airlie writes: > From: Keith Packard > > On desktop GL, Ask for a 3.3 core profile context if that's available, > otherwise create a generic context. > > v2: tell glamor the profile is a core one. > > Signed-off-by: Keith Packard >

Re: glamor core profile support

r<#secure method=pgpmime mode=sign> Marek Olšák writes: > On Tue, Jan 19, 2016 at 1:56 AM, Dave Airlie wrote: >> This series implements support for glamor in ephyr/EGL/Xwayland >> to use GL core profile when it can. >> >> This required 4 main changes: >> a)