noise
--
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/20131213/e4c68e11/attachment-0001.html>
available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/ecd89f2d/attachment.pgp>
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/8ba47add/attachment.pgp>
ity Radeon HD 5650M
--
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/20131213/0a8de094/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/6561e644/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/7c5b6199/attachment.html>
On Thu, 12 Dec 2013 20:13:47 +0300
Artsiom Anikeyenka wrote:
> Hey, Pekka,
>
> Talking in scope of kmscube source code after Rob Clark. Is there
> a way to do the same using proprietary Nvidia (for example)
> drivers? Also I would really appreciate if you explained me what
> is kms (kernel mode
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131213/9eed108f/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/b1d7266f/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131213/8c35b79a/attachment.html>
On Fri, Dec 13, 2013 at 05:51:26PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> intel/test_decode.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/intel/test_decode.c b/intel/test_decode.c
> index 0fcdf3b..b710f34 100644
> --- a/intel/test_decode.c
> +++ b/intel
On Fri, Dec 13, 2013 at 05:51:25PM +, Damien Lespiau wrote:
> - *.log/*.trs are generated by make check
> - TAGS are generated by make tags
> - build-aux, config.h.in~ by autoconf
> - *.sw? are temporary files create by vim
> - name_from_fd wasn't ignored yet for some reason
>
> Signed-off-by:
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/c20ade7b/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/28e3a188/attachment.html>
On 12/13/2013 05:25 PM, Keith Packard wrote:
> libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
> works when the fence is a linux futex. However, version 1.1
> changes the exported datatype to 'struct xshmfence *'
>
> Require libxshmfence version 1.1 and switch the API around
On 11/18/2013 12:58 PM, Emil Velikov wrote:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>> ---
>>
> Hi Keith,
>
> Did you had t
On 12/13/2013 05:25 PM, Keith Packard wrote:
> These are duplicates from gl.h; I'm not sure which file they belong in, but
> you don't get to have them in both places.
>
> Signed-off-by: Keith Packard
> ---
> include/GL/glext.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/G
rg/archives/dri-devel/attachments/20131213/44d1ab62/attachment.html>
it).
Is there anything I should watch for and report ?
--
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/20131213/7ef0b47b/attachment.html>
On Fri, Dec 13, 2013 at 07:03:11PM +0100, Daniel Vetter wrote:
> On Fri, Dec 13, 2013 at 05:51:25PM +, Damien Lespiau wrote:
> > - *.log/*.trs are generated by make check
> > - TAGS are generated by make tags
> > - build-aux, config.h.in~ by autoconf
> > - *.sw? are temporary files create by vi
iving 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/20131213/aa768141/attachment.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/41ac57c4/attachment-0001.html>
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 0fcdf3b..b710f34 100644
--- a/intel/test_decode.c
+++ b/intel/test_decode.c
@@ -146,6 +146,7 @@ infer_devid(const char *batch_filename)
- *.log/*.trs are generated by make check
- TAGS are generated by make tags
- build-aux, config.h.in~ by autoconf
- *.sw? are temporary files create by vim
- name_from_fd wasn't ignored yet for some reason
Signed-off-by: Damien Lespiau
---
.gitignore | 8 +++-
1 file changed, 7 insertions(+)
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
From: Ben Skeggs
Signed-off-by: Ben Skeggs
Signed-off-by: Keith Packard
---
src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.
From: Ben Skeggs
Signed-off-by: Ben Skeggs
Signed-off-by: Keith Packard
---
src/gallium/state_trackers/dri/drm/dri2.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri
Provide the hook to pull textures out of __DRIimage structures and use them as
renderbuffers.
Signed-off-by: Keith Packard
---
src/gallium/state_trackers/dri/drm/dri2.c | 238 +-
1 file changed, 230 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_tracker
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
XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c26d6e5..7982f6b 100644
--- a/src/glx/
It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 4 ++--
src/glx/dri3_priv.h | 10 +-
2 files c
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+),
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.
This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen th
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.
Signed-off-by: Keith Packa
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard
Reviewed-by: Kenneth Graunke
---
src/glx/dri3_priv.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
ind
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
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.c
index 1834c6d..4c0dc29 100644
--- a/src/gl
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'
Require libxshmfence version 1.1 and switch the API around.
Signed-off-by: Keith Packard
---
configure.ac
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
configure.ac | 8 -
src/glx/dri3_common.c | 85 ++-
2 files changed, 50 in
These are the same address, but different types and driContextSetFlags wants
a gl_context pointer.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dr
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.
Signed-off-by: Keith Packard
---
include/GL/glext.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 7d6033e..b432d2e 100644
--
This series has a bunch of DRI3 cleanups and fixes followed by a few patches
that finish up DRI3 support in gallium.
The first two patches have nothing to do with DRI3, just some warning fixes:
[PATCH 01/18] Remove glBlendColor and glBlendEquations decls from
[PATCH 02/18] dri/swrast: Passing d
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/20131213/0cc58b63/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/fd2b954b/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/c90330c4/attachment-0001.html>
iving 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/20131213/e5b9015f/attachment.html>
never saw a 3.13 kernel build...?
--
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/20131213/9c88395b/attachment.html>
e right, and this seems to deal with Samba...
--
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/20131213/4eeda778/attachment.html>
achment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/170aed31/attachment.pgp>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/16cf828d/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/29da0482/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/d3dee8df/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/6a8aeac7/attachment-0001.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/20131213/3e6a42e5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/e5827cc9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/2ecbca71/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131213/0a2a5834/attachment.html>
On 11/25/2013 09:35 PM, Keith Packard wrote:
> Move the depth field up with width and height.
>
> Remove unused previous_time and frames fields.
>
> Signed-off-by: Keith Packard
> ---
> src/glx/dri3_priv.h | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/glx/dr
On 11/21/2013 08:12 PM, Keith Packard wrote:
> 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
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #10 from Alex Deucher ---
see also:
https://bugs.freedesktop.org/show_bug.cgi?id=71930
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=64891
--- Comment #18 from Takashi Iwai ---
Rafael, any clue?
--
You are receiving this mail because:
You are watching the assignee of the bug.
upport all those cases.
But if we need to parse the reg ourselves, and have different code paths
for #size-cells 0 and 1, I'd rather stick to the simplest model. No
point in having lots of code lines to handle different #size-cells, as
we most likely just one one VC ID.
I do agree that consecutive VC IDs sounds much more probable. However,
array of VC IDs work for all cases, but a (single) range doesn't. And we
can only have 4 VC IDs, so the biggest array would be <0 1 2 3>.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/c4ca637e/attachment-0001.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=64891
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #17 f
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/5002f75d/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131213/cfd7dd67/attachment.html>
ceiving 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/20131213/dae2a520/attachment.html>
IDs individually as I did in my recent reply,
should do the same thing as above, without ranges.
It's still open to me if that method is good or not.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/6dadf6fe/attachment-0001.pgp>
ects should be hidden within drivers. I'm thinking that
> perhaps a DSI hub could be a special type of peripheral, much like a
> bridge in PCI, with a means to instantiate children of its own (yet
> still make them children of the DSI host bus) and providing a way to
> translate between link-local (physical) and logical VC IDs.
Yes, something like that sounds good to me.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/532c9ed9/attachment-0001.pgp>
mpletely
separate ones. Or perhaps it isn't. Either way I think the binding would
support both of those cases.
I'll see if I can come up with some wording to make that a part of the
binding and perhaps mention that only one-to-one relationships are taken
into account in the binding.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/e14cac52/attachment.pgp>
On 12/12/2013 01:19 PM, Thierry Reding wrote:
> On Tue, Dec 10, 2013 at 11:19:54AM +0200, Tomi Valkeinen wrote:
>> On 2013-12-09 18:10, Thierry Reding wrote:
>>
>> Btw, about single linux device handling multiple VC IDs: I noticed that
>> the DSI spec has an example, in which a DSI peripheral recei
}
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/bcbc18f3/attachment.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=64891
Takashi Iwai changed:
What|Removed |Added
Component|Sound(ALSA) |Video(DRI - non Intel)
Assignee|
On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake wrote:
> Lets just accept the fact that the first line of the output image is
> rendered badly. Specifically, it has 257 black pixels added onto the
> end of it. The following rows do not exhibit that problem.
>
> To accept and ignore this oddity, I wa
On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake wrote:
> What I feel we are missing here is an explanation for why the first
> row of pixels is treated differently from the rest. Every value that I
> tweak seems to have an effect on the first line (which was rendered
> OK) as well as all the others
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/908881ff/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/352befdc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/f7f817a0/attachment.html>
ad spectrum disabled).
It happened before that my system would not hang for some reason once in many
boots, maybe that's what happened.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
&l
=) at
chrome/app/chrome_exe_main_gtk.cc:43
--
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/20131213/11d5c716/attachment-0001.html>
Hi
On Thursday 12 December 2013, Gerd Hoffmann wrote:
> DRM driver for (virtual) vga cards using the bochs dispi
> interface, such as the qemu standard vga (qemu -vga std).
>
> Don't bother supporting anything but 32bpp for now, even
> though the virtual hardware is able to do that.
>
> Known is
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/20131213/87672e29/attachment.html>
.
Sorry for bringing bad news.
--
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/20131213/9eba2ff8/attachment.html>
On (12/12/13 23:29), Deucher, Alexander wrote:
> Fix is already queued in my next -fixes pull. Thanks!
>
Nice. Thanks!
-ss
> Alex
>
> > -Original Message-
> > From: Sergey Senozhatsky [mailto:sergey.senozhatsky at gmail.com]
> > Sent: Thursday, December 12, 2013 6:26 PM
> > To
Since ec39f64bba radeon_hwmon_init() is using
hwmon_device_register_with_groups(), which sets `rdev' as a device
private driver_data, while hwmon_attributes_visible() and
radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
fix them by using dev_get_drvdata():
BUG: unable to handle
85 matches
Mail list logo
