The easy part is turning on the extension, now that the X server has a patch
to send the events.
The only trick was making sure the Present extension reliably provided the
right 'sbc' count back in the event, and that's done by making sure the sbc
count is always the same as the sequence number th
This allows GL to support the GLX_INTEL_swap_event extension
Signed-off-by: Keith Packard
---
This is the X server side; the mesa patch will be sent shortly (it's tiny)
glx/Makefile.am | 3 ++-
glx/glxcmds.c | 69 +
glx/glxdri2
On Thu, Nov 21, 2013 at 03:29:55PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Too many t's.
>
> Cc: Daniel Vetter
> Cc: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Borislav Petkov
Queued for -next, thanks for the patch.
-Daniel
>
On Thu, Nov 21, 2013 at 04:49:46PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains that:
>
> drivers/gpu/drm/i915/i915_debugfs.c: In function ?display_crc_ctl_write?:
> drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ?val? may be used
> uninitialized in this functio
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
v2: Include changes to dri3_priv.h as well
src/glx/dri3_glx.c | 17 -
src/glx/dri3_priv.h | 5 -
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
Ok, so not having this in the dri3 code led to a bit of extra memory
usage in apps and the X server.
src/glx/dri3_glx.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/glx/dri3_g
libxshmfence foolishly advertises the type of a fence as 'int32_t *', which
works when the fence is a linux futex. However, that library is going to
change the exported datatype to 'struct xshmfence *', which will provide some
nice typechecking. Anticipate the change by just using 'void *' in mesa,
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the sam
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMA
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/ce2fc616/attachment.html>
On Thu, Nov 21, 2013 at 7:49 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Nov 21, 2013 at 10:25 AM, Dave Airlie wrote:
>> On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter wrote:
>>> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
5bdebb183c9702a8c57a01dff09337be3de337a6 changed th
On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter wrote:
> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
>> 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
>> also meant we no longer set the device_type field properly, so the
>> hotplug events in userspace weren'
On Thu, Nov 21, 2013 at 02:48:55AM +, Gohad, Tushar wrote:
> > On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
> > > > > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > > > > Folks,
> > > > > >
> > > > > > When filling in an HDMI AVI infoframe, how does one c
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/984546c1/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/07603cd3/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/44c63576/attachment-0001.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/5a66d434/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #14 from Shawn Starr ---
Somehow, when the CPU shifts frequency this is causing voltage changes that are
affecting the GPU's switching DPM power states.
I will be trying this week my old tests with EXA to see if this holds true but
th
On Thu, Nov 21, 2013 at 07:19:45PM +0200, Ville Syrj?l? wrote:
> > > It seems natural to extend those flags to describe the picture aspect
> > > ratio (that
> > > why dri-devel is in Cc., touching core DRM).
> >
> > To start with we can use a single bit in drm_display_mode->flags to
> > distingu
On Thu, Nov 21, 2013 at 05:10:30PM +0100, Richard Weinberger wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 6ed45a984230..1191aa47adc9 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
On Thu, Nov 21, 2013 at 4:49 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains that:
>
> drivers/gpu/drm/i915/i915_debugfs.c: In function ?display_crc_ctl_write?:
> drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ?val? may be used
> uninitialized in this function [-Wunini
From: Borislav Petkov
gcc complains that:
drivers/gpu/drm/i915/i915_debugfs.c: In function ?display_crc_ctl_write?:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ?val? may be used
uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ?val? was
Hi
On Thu, Nov 21, 2013 at 4:24 PM, Greg KH wrote:
> On Thu, Nov 21, 2013 at 10:22:55AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
>> > 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
>> > also meant we no longer set the devi
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/75b171ed/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/888e655f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #13 from Ilya Tumaykin ---
(In reply to Shawn Starr from comment #12)
Hello, Shawn.
I don't have any such daemon, but my cpufreq governor is set to conservative
both on AC and battery.
Ok, I will try your suggestion, but could you pl
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/3dbe453d/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/118bd3ca/attachment.html>
From: Borislav Petkov
Too many t's.
Cc: Daniel Vetter
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Borislav Petkov
---
drivers/gpu/drm/i915/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig
op 20-11-13 21:48, Rob Clark schreef:
> +int drm_modeset_lock_crtc(struct drm_crtc *crtc, void *state)
> +{
> + // ugg, this makes atomic_helper mandatory.. not really
> + // sure yet whether I should care, or just simplify things
> + // and require that drivers use or extend atomic_he
op 20-11-13 21:48, Rob Clark schreef:
> At the moment, this doesn't do anything. But for atomic we will have an
> ww_acquire_ctx associated with the state, to simplify the locking and
> avoid potential deadlock when we cannot control the locking order.
Nack. :-)
Please don't split this out. ww_mu
For error traces in situations that can run away, it is nice to have a
rate-limited version of DRM_ERROR() to avoid massing log flooding.
Signed-off-by: Rob Clark
---
include/drm/drmP.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> Any news here? If no - I think we need re-send patch as new..
Since the v2 patch can't apply cleanly on top of pm's -next tree, I
think it's worth a re-send, so here it comes.
---
Subject: [PATCH] ACPI / video: Add systems that should favor native ba
https://bugzilla.kernel.org/show_bug.cgi?id=61941
Shawn Starr changed:
What|Removed |Added
CC||shawn.starr at rogers.com
--- Comment #12 f
This patch releases a vma object when cleaning up userptr resources.
A new vma object was allocated and copied when getting userptr pages
so the new vma object should be freed properly if the userptr pages
aren't used anymore.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu
5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
also meant we no longer set the device_type field properly, so the
hotplug events in userspace weren't fully formed enough for drivers to care.
Reported-by: Jesse Barnes
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_sys
On Thu, Nov 21, 2013 at 07:25:39PM +1000, Dave Airlie wrote:
> On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter wrote:
> > On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
> >> 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
> >> also meant we no longer set the dev
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/dda7115a/attachment.html>
Hi
On Thu, Nov 21, 2013 at 10:58 AM, Dave Airlie wrote:
> On Thu, Nov 21, 2013 at 7:49 PM, David Herrmann
> wrote:
>> Hi
>>
>> On Thu, Nov 21, 2013 at 10:25 AM, Dave Airlie wrote:
>>> On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter wrote:
On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Air
Hi
On Thu, Nov 21, 2013 at 10:25 AM, Dave Airlie wrote:
> On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter wrote:
>> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
>>> 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
>>> also meant we no longer set the device_ty
On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
> 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
> also meant we no longer set the device_type field properly, so the
> hotplug events in userspace weren't fully formed enough for drivers to care.
>
> Reported-by:
On Thu, Nov 21, 2013 at 09:29:26AM +0100, Thomas Hellstrom wrote:
> On 11/21/2013 09:18 AM, Daniel Vetter wrote:
> >On Wed, Nov 20, 2013 at 11:35:31PM +0100, Thomas Hellstrom wrote:
> >>On 11/20/2013 03:24 PM, Daniel Vetter wrote:
> >>>On Wed, Nov 20, 2013 at 01:55:49AM -0800, Thomas Hellstrom wrot
On Thu, Nov 21, 2013 at 9:11 AM, Maarten Lankhorst
wrote:
> op 20-11-13 21:48, Rob Clark schreef:
>> At the moment, this doesn't do anything. But for atomic we will have an
>> ww_acquire_ctx associated with the state, to simplify the locking and
>> avoid potential deadlock when we cannot control
Copy-paste typo. Value should be 0-2, not 0-1.
Noticed-by: Sylvain BERTRAND
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/dri
On Wed, Nov 20, 2013 at 8:05 PM, Sylvain BERTRAND wrote:
> Hi,
> In radeon_atom_get_memory_pll_dividers, the vco_mode is forced to
> 0 or 1 instead of retaining the atombios value range of 0,1 and
> 2. Expected?
Good catch. it should be 0-2. copy paste typo. I'll send out a patch.
Alex
>
> r
On 11/21/2013 09:18 AM, Daniel Vetter wrote:
> On Wed, Nov 20, 2013 at 11:35:31PM +0100, Thomas Hellstrom wrote:
>> On 11/20/2013 03:24 PM, Daniel Vetter wrote:
>>> On Wed, Nov 20, 2013 at 01:55:49AM -0800, Thomas Hellstrom wrote:
Not sure if there are any user-space users of private bo mappin
On Wed, Nov 20, 2013 at 11:35:31PM +0100, Thomas Hellstrom wrote:
> On 11/20/2013 03:24 PM, Daniel Vetter wrote:
> >On Wed, Nov 20, 2013 at 01:55:49AM -0800, Thomas Hellstrom wrote:
> >>Not sure if there are any user-space users of private bo mappings, but
> >>if there are, or will be, zapping the
(usable)
[0.00] MTRR default type: uncachable
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/82985aea/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/ead66ad8/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/aedcc9a8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #11 from Ilya Tumaykin ---
Recently Phoronix site published a series of Radeon cards tests. Their setup
was kernel 3.12 with dpm enabled, Mesa 10.0 pre-release and Ubuntu 13.10. They
had the same problem as me [0]:
"The Radeon HD 3650
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/142048ef/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/1f26fa30/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/9a393aa4/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/5be26d31/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/830aba5c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/02a9ccdb/attachment.html>
set to 0xf has been attached. As well as
the usually required information.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/bcc7b588/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/7622f7fe/attachment.html>
On 11/20/13 19:04, Stephen Rothwell wrote:
> Hi all,
>
> Please do *not* add any v3.14 material to linux-next until after
> v3.13-rc1 is released.
>
> Changes since 20131120:
>
> Linus' tree gained a build failure for which I reverted a commit.
>
on x86_64:
CONFIG_HWMON is not enabled.
drive
On Thu, Nov 21, 2013 at 04:40:29PM +0100, David Herrmann wrote:
> Hi
>
> On Thu, Nov 21, 2013 at 4:24 PM, Greg KH
> wrote:
> > On Thu, Nov 21, 2013 at 10:22:55AM +0100, Daniel Vetter wrote:
> >> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
> >> > 5bdebb183c9702a8c57a01dff09337be3
On Thu, Nov 21, 2013 at 10:22:55AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
> > 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
> > also meant we no longer set the device_type field properly, so the
> > hotplug events in users
; of the file when
the system hanged while running quick.test piglit run.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/16e0e46a/attachment.html>
-with-llvm-shared-libs \
Is this expected from r600g implemented features?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131121/0926620e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64661
--- Comment #5 from Jason Schulz ---
(In reply to Alan from comment #4)
>4.306110] nvidia: module license 'NVIDIA' taints kernel.
> [4.306112] Disabling lock debugging due to kernel taint
> [4.312028] nvidia :01:00.0: enabling devi
> On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
> > > > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > > > Folks,
> > > > >
> > > > > When filling in an HDMI AVI infoframe, how does one correctly
> > > > > determine the "default" picture aspect ratio (and VIC)
Hi,
In radeon_atom_get_memory_pll_dividers, the vco_mode is forced to
0 or 1 instead of retaining the atombios value range of 0,1 and
2. Expected?
regards,
--
Sylvain
On Fri, 2013-11-15 at 14:07 +0800, Aaron Lu wrote:
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
> that video backlight contro
69 matches
Mail list logo