[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #18 from Nickolay --- I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M APU. I've attached dmesg and lspci output of my laptop. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #19 from Nickolay --- Created attachment 73234 --> https://bugs.freedesktop.org/attachment.cgi?id=73234&action=edit a10-4600m_lspci -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #20 from Nickolay --- Created attachment 73235 --> https://bugs.freedesktop.org/attachment.cgi?id=73235&action=edit a10-4600m dmesg -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #21 from Nickolay --- (In reply to comment #18) > I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M > APU. I've attached dmesg and lspci output of my laptop. P.S. Kernel version 3.7.3 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] video: Add generic HDMI infoframe helpers
On Wed, Jan 16, 2013 at 03:27:14PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> > Add generic helpers to pack HDMI infoframes into binary buffers.
[...]
> > +/**
> > + * hdmi_avi_infoframe_init() - initialize an HDMI AVI infoframe
> > + * @frame: HDMI AVI infoframe
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
> > +{
> > + if (!frame)
> > + return -EINVAL;
>
> There's quite a bit of error checking all around which seems a bit
> pointless since this is all internal stuff. Any errors are bugs in
> some driver code, so just letting the thing oops would be fine in my
> opinion.
Okay, I can remove some of the more obvious checks. Checking for space
requirements might still be useful, so I'll leave that in.
> > +ssize_t hdmi_spd_infoframe_pack(struct hdmi_spd_infoframe *frame, void
> > *buffer,
> > + size_t size)
[...]
> > + for (i = 0; i < sizeof(frame->vendor); i++)
> > + ptr[i] = frame->vendor[i];
> > +
> > + for (i = 0; i < sizeof(frame->product); i++)
> > + ptr[8 + i] = frame->product[i];
>
> memcpy()
Done.
> > +enum hdmi_spd_sdi {
> > + HDMI_SPD_SDI_UNKNOWN,
> > + HDMI_SPD_SDI_DSTB,
> > + HDMI_SPD_SDI_DVDP,
> > + HDMI_SPD_SDI_DVHS,
> > + HDMI_SPD_SDI_HDDVR,
> > + HDMI_SPD_SDI_DVC,
> > + HDMI_SPD_SDI_DSC,
> > + HDMI_SPD_SDI_VCD,
> > + HDMI_SPD_SDI_GAME,
> > + HDMI_SPD_SDI_PC,
> > + HDMI_SPD_SDI_BD,
> > + HDMI_SPD_SDI_SCD,
>
> I believe SACD is a more correct name.
Done.
> HD DVD and PMP are missing from this list.
I can't find any reference to those in CEA-861-D. HDMI 1.4 doesn't have
them either. Can you provide any pointers?
> > +enum hdmi_audio_coding_type {
> > + HDMI_AUDIO_CODING_TYPE_STREAM,
> > + HDMI_AUDIO_CODING_TYPE_IEC_60958,
> > + HDMI_AUDIO_CODING_TYPE_AC3,
> > + HDMI_AUDIO_CODING_TYPE_MPEG1,
> > + HDMI_AUDIO_CODING_TYPE_MP3,
> > + HDMI_AUDIO_CODING_TYPE_MPEG2,
> > + HDMI_AUDIO_CODING_TYPE_AAC,
> > + HDMI_AUDIO_CODING_TYPE_DTS,
> > + HDMI_AUDIO_CODING_TYPE_ATRAC,
> > + HDMI_AUDIO_CODING_TYPE_ONE_BIT_AUDIO,
> > + HDMI_AUDIO_CODING_TYPE_DOLBY_DIGITAL_PLUS,
> > + HDMI_AUDIO_CODING_TYPE_DTS_HD,
> > + HDMI_AUDIO_CODING_TYPE_MAT_MLP,
> > + HDMI_AUDIO_CODING_TYPE_DST,
> > + HDMI_AUDIO_CODING_TYPE_WMPRO,
>
> These don't always quite match the names in CEA-861-E. Wouldn't it
> be better to use matching names?
Are HD-DVD and PMP above listed in CEA-861-E? I'll need to find a copy
of it and will go over this again and match the names to those in the
document.
> Also the audio coding extension type is missing.
I assume this is also part of CEA-861-E as I can't find a reference in
-D?
Thanks for reviewing,
Thierry
pgpGQwcfUT4FI.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > Since the variable's value is the size of an array, we can assume that
> > > > it will never be negative.
> > > >
> > > > Signed-off-by: Thierry Reding
> > > > ---
> > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > index 5dbf7d2..d65d863 100644
> > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > edid_cea_modes[] = {
> > > >2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > };
> > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > +static const unsigned int drm_num_cea_modes =
> > > > ARRAY_SIZE(edid_cea_modes);
> > >
> > > Why do we even have these num_foo things? I think it would be clearer to
> > > use ARRAY_SIZE(foo) directly where appropriate.
> >
> > Actually I was thinking about maybe writing a patch to move the table
> > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > easy to create duplicates of the table. In that case, using the
> > ARRAY_SIZE macro directly wouldn't be an option.
>
> Well drm_edid.c is the only one accessing these tables anyway, so it
> they would be in drm_edid.c and static, you could still use
> ARRAY_SIZE().
>
> Not that I really like the idea of polluting drm_edid.c with all these
> massive tables.
There's also the possibility to put the tables along with the functions
that access them into a drm_edid_modes.c.
> Too bad cpp doesn't support this kind of thing:
> #if __BASE_FILE__ != "drm_edid.c"
> #error ...
> #endif
We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
is included.
Thierry
pgpXsXveURgKX.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] video: Add generic HDMI infoframe helpers
On Fri, Jan 18, 2013 at 09:56:36AM +0100, Thierry Reding wrote:
> On Wed, Jan 16, 2013 at 03:27:14PM +0200, Ville Syrjälä wrote:
> > On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> > > Add generic helpers to pack HDMI infoframes into binary buffers.
> [...]
> > > +/**
> > > + * hdmi_avi_infoframe_init() - initialize an HDMI AVI infoframe
> > > + * @frame: HDMI AVI infoframe
> > > + *
> > > + * Returns 0 on success or a negative error code on failure.
> > > + */
> > > +int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
> > > +{
> > > + if (!frame)
> > > + return -EINVAL;
> >
> > There's quite a bit of error checking all around which seems a bit
> > pointless since this is all internal stuff. Any errors are bugs in
> > some driver code, so just letting the thing oops would be fine in my
> > opinion.
>
> Okay, I can remove some of the more obvious checks. Checking for space
> requirements might still be useful, so I'll leave that in.
>
> > > +ssize_t hdmi_spd_infoframe_pack(struct hdmi_spd_infoframe *frame, void
> > > *buffer,
> > > + size_t size)
> [...]
> > > + for (i = 0; i < sizeof(frame->vendor); i++)
> > > + ptr[i] = frame->vendor[i];
> > > +
> > > + for (i = 0; i < sizeof(frame->product); i++)
> > > + ptr[8 + i] = frame->product[i];
> >
> > memcpy()
>
> Done.
>
> > > +enum hdmi_spd_sdi {
> > > + HDMI_SPD_SDI_UNKNOWN,
> > > + HDMI_SPD_SDI_DSTB,
> > > + HDMI_SPD_SDI_DVDP,
> > > + HDMI_SPD_SDI_DVHS,
> > > + HDMI_SPD_SDI_HDDVR,
> > > + HDMI_SPD_SDI_DVC,
> > > + HDMI_SPD_SDI_DSC,
> > > + HDMI_SPD_SDI_VCD,
> > > + HDMI_SPD_SDI_GAME,
> > > + HDMI_SPD_SDI_PC,
> > > + HDMI_SPD_SDI_BD,
> > > + HDMI_SPD_SDI_SCD,
> >
> > I believe SACD is a more correct name.
>
> Done.
>
> > HD DVD and PMP are missing from this list.
>
> I can't find any reference to those in CEA-861-D. HDMI 1.4 doesn't have
> them either. Can you provide any pointers?
CEA-861-E has them.
>
> > > +enum hdmi_audio_coding_type {
> > > + HDMI_AUDIO_CODING_TYPE_STREAM,
> > > + HDMI_AUDIO_CODING_TYPE_IEC_60958,
> > > + HDMI_AUDIO_CODING_TYPE_AC3,
> > > + HDMI_AUDIO_CODING_TYPE_MPEG1,
> > > + HDMI_AUDIO_CODING_TYPE_MP3,
> > > + HDMI_AUDIO_CODING_TYPE_MPEG2,
> > > + HDMI_AUDIO_CODING_TYPE_AAC,
> > > + HDMI_AUDIO_CODING_TYPE_DTS,
> > > + HDMI_AUDIO_CODING_TYPE_ATRAC,
> > > + HDMI_AUDIO_CODING_TYPE_ONE_BIT_AUDIO,
> > > + HDMI_AUDIO_CODING_TYPE_DOLBY_DIGITAL_PLUS,
> > > + HDMI_AUDIO_CODING_TYPE_DTS_HD,
> > > + HDMI_AUDIO_CODING_TYPE_MAT_MLP,
> > > + HDMI_AUDIO_CODING_TYPE_DST,
> > > + HDMI_AUDIO_CODING_TYPE_WMPRO,
> >
> > These don't always quite match the names in CEA-861-E. Wouldn't it
> > be better to use matching names?
>
> Are HD-DVD and PMP above listed in CEA-861-E? I'll need to find a copy
> of it and will go over this again and match the names to those in the
> document.
Great.
> > Also the audio coding extension type is missing.
>
> I assume this is also part of CEA-861-E as I can't find a reference in
> -D?
Yeah, I only checked against CEA-861-E.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Fri, Jan 18, 2013 at 11:30:04AM +0100, Thierry Reding wrote:
> On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrjälä wrote:
> > On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > > Since the variable's value is the size of an array, we can assume that
> > > > > it will never be negative.
> > > > >
> > > > > Signed-off-by: Thierry Reding
> > > > > ---
> > > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > > index 5dbf7d2..d65d863 100644
> > > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > > edid_cea_modes[] = {
> > > > > 2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > > > DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > > };
> > > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > > +static const unsigned int drm_num_cea_modes =
> > > > > ARRAY_SIZE(edid_cea_modes);
> > > >
> > > > Why do we even have these num_foo things? I think it would be clearer to
> > > > use ARRAY_SIZE(foo) directly where appropriate.
> > >
> > > Actually I was thinking about maybe writing a patch to move the table
> > > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > > easy to create duplicates of the table. In that case, using the
> > > ARRAY_SIZE macro directly wouldn't be an option.
> >
> > Well drm_edid.c is the only one accessing these tables anyway, so it
> > they would be in drm_edid.c and static, you could still use
> > ARRAY_SIZE().
> >
> > Not that I really like the idea of polluting drm_edid.c with all these
> > massive tables.
>
> There's also the possibility to put the tables along with the functions
> that access them into a drm_edid_modes.c.
>
> > Too bad cpp doesn't support this kind of thing:
> > #if __BASE_FILE__ != "drm_edid.c"
> > #error ...
> > #endif
>
> We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
> and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
> is included.
Yeah, I suppose there's no better way to do that. It's a bit ugly
though.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Fri, Jan 18, 2013 at 12:51:11PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 18, 2013 at 11:30:04AM +0100, Thierry Reding wrote:
> > On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > > > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrjälä wrote:
> > > > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > > > Since the variable's value is the size of an array, we can assume
> > > > > > that
> > > > > > it will never be negative.
> > > > > >
> > > > > > Signed-off-by: Thierry Reding
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > > > index 5dbf7d2..d65d863 100644
> > > > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > > > edid_cea_modes[] = {
> > > > > >2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > > > >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > > > };
> > > > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > > > +static const unsigned int drm_num_cea_modes =
> > > > > > ARRAY_SIZE(edid_cea_modes);
> > > > >
> > > > > Why do we even have these num_foo things? I think it would be clearer
> > > > > to
> > > > > use ARRAY_SIZE(foo) directly where appropriate.
> > > >
> > > > Actually I was thinking about maybe writing a patch to move the table
> > > > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > > > easy to create duplicates of the table. In that case, using the
> > > > ARRAY_SIZE macro directly wouldn't be an option.
> > >
> > > Well drm_edid.c is the only one accessing these tables anyway, so it
> > > they would be in drm_edid.c and static, you could still use
> > > ARRAY_SIZE().
> > >
> > > Not that I really like the idea of polluting drm_edid.c with all these
> > > massive tables.
> >
> > There's also the possibility to put the tables along with the functions
> > that access them into a drm_edid_modes.c.
> >
> > > Too bad cpp doesn't support this kind of thing:
> > > #if __BASE_FILE__ != "drm_edid.c"
> > > #error ...
> > > #endif
> >
> > We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
> > and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
> > is included.
>
> Yeah, I suppose there's no better way to do that. It's a bit ugly
> though.
What about moving them to a separate file altogether? It would involve
moving the do_cea_modes() as well, but that would need to be called from
drm_edid.c, so it isn't very pretty either.
Thierry
pgpVfEy3Aip_A.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon HDMI question
Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan: Hi, I experience a strange problem, I don't know whether it's a feature or a bug, and if it's a bug, where. I have a Radeon HD6570. A monitor via DVI and an LCD TV via HDMI are connected. Fedora 18/x86_64 is installed on the computer. (Previously it was F17, F16 and F14.) When playing videos via Xine, all videos with 5.1 sound works nicely via the HDMI, the sound output is on the TV. However, when only stereo or mono sound is present in the video, the sound doesn't go out to the TV. I have an internal soundcard and speakers are connected. Pulseaudio on modern Linuxen has the feature to switch the audio output device on the fly and per-application, so I can switch between the outputs. Is is possible to make mono and stereo audio work via HDMI? Hi Zoltán, that just sounds like a mis configured Xine to me. Xine can be configured to use different outputs for Mono/Stero and 5.1 sounds. You can also configure ALSA to route the audio differently depending on the number of channels, but that isn't the default and if you configured it like this you probably would remember it :) I can't really see a way how this can be a hardware problem either, cause 5.1 audio pass through is handled mostly the same as Stereo. I suggest that you check your Xine configuration, you should find multiple setting for selection the output device (Mono/Stereo/5.1/7.1 etc...) make sure that they all point to the correct hardware device. Regards, Christian. Thanks in advance, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] man: Fix typo and use $() for make expressions
Due to the typo, none of the .xml files would end up in the release
tarball and cause make distcheck as well as builds from the tarball to
fail.
Using $() isn't strictly necessary but other variables and expressions
use that variant already so it makes the usage consistent.
Signed-off-by: Thierry Reding
---
man/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/man/Makefile.am b/man/Makefile.am
index 25202e2..d25a293 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -17,7 +17,8 @@ MANPAGES_ALIASES = \
drm-ttm.7
XML_FILES = \
- ${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubs %.7,%.xml,$(MANPAGES)
+ $(patsubst %.1,%.xml,$(patsubst %.3,%.xml,$(patsubst
%.5,%.xml,$(patsubst %.7,%.xml,$(MANPAGES)
+
EXTRA_DIST = $(XML_FILES)
CLEANFILES = $(MANPAGES) $(MANPAGES_ALIASES) .man_fixup
man_MANS =
--
1.8.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] tests: Include string.h for strlen() and memset()
The setversion and getversion tests use these functions so make sure they are included to avoid compiler warnings. Signed-off-by: Thierry Reding --- tests/drmtest.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/drmtest.h b/tests/drmtest.h index 55bb446..731d1a7 100644 --- a/tests/drmtest.h +++ b/tests/drmtest.h @@ -27,6 +27,7 @@ #include #include +#include #include #include #include -- 1.8.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe
On Thu, Jan 17, 2013 at 04:31:31PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 [1] we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
> bits in the AVI inforframe.
>
> [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
>
> v2: Give the Q bits better names, add spec chapter information
>
> Reviewed-by: Paulo Zanoni
> Signed-off-by: Ville Syrjälä
Entire series queued for -next, thanks for patches&review.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_drv.h |4
> drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a698c6..aeff0d1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -289,6 +289,9 @@ struct cxsr_latency {
> #define DIP_LEN_AVI 13
> #define DIP_AVI_PR_10
> #define DIP_AVI_PR_21
> +#define DIP_AVI_RGB_QUANT_RANGE_DEFAULT (0 << 2)
> +#define DIP_AVI_RGB_QUANT_RANGE_LIMITED (1 << 2)
> +#define DIP_AVI_RGB_QUANT_RANGE_FULL (2 << 2)
>
> #define DIP_TYPE_SPD 0x83
> #define DIP_VERSION_SPD 0x1
> @@ -347,6 +350,7 @@ struct intel_hdmi {
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> + bool rgb_quant_range_selectable;
> void (*write_infoframe)(struct drm_encoder *encoder,
> struct dip_infoframe *frame);
> void (*set_infoframes)(struct drm_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index db67be6..d53b731 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> *encoder,
> static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
>struct drm_display_mode *adjusted_mode)
> {
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> .ver = DIP_VERSION_AVI,
> @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
>
> + if (intel_hdmi->rgb_quant_range_selectable) {
> + if (adjusted_mode->private_flags &
> INTEL_MODE_LIMITED_COLOR_RANGE)
> + avi_if.body.avi.ITC_EC_Q_SC |=
> DIP_AVI_RGB_QUANT_RANGE_LIMITED;
> + else
> + avi_if.body.avi.ITC_EC_Q_SC |=
> DIP_AVI_RGB_QUANT_RANGE_FULL;
> + }
> +
> avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
>
> intel_set_infoframe(encoder, &avi_if);
> @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_hdmi->has_hdmi_sink = false;
> intel_hdmi->has_audio = false;
> + intel_hdmi->rgb_quant_range_selectable = false;
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> intel_hdmi->has_hdmi_sink =
> drm_detect_hdmi_monitor(edid);
> intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
> + intel_hdmi->rgb_quant_range_selectable =
> + drm_rgb_quant_range_selectable(edid);
> }
> kfree(edid);
> }
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 3e34a35..f01063a 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -126,6 +126,7 @@ struct intel_sdvo {
> bool is_hdmi;
> bool has_hdmi_monitor;
> bool has_hdmi_audio;
> + bool rgb_quant_range_selectable;
>
> /**
>* This is set if we detect output of sdvo device as LVDS and
> @@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
> *intel_sdvo,
> &tx_rate, 1);
> }
>
> -static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
> +static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
> + const struct drm_display_mode
> *adjusted_mode)
> {
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> @@ -956,6 +958,13 @@ static bool
Re: [PATCH 08/35] drm/: Unified handling of unimplemented fb->create_handle
On Thu, Jan 10, 2013 at 09:47:49PM +0100, Daniel Vetter wrote: [...] > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 8d665fa..a9abf49 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -2384,7 +2384,10 @@ int drm_mode_getfb(struct drm_device *dev, > r->depth = fb->depth; > r->bpp = fb->bits_per_pixel; > r->pitch = fb->pitches[0]; > - fb->funcs->create_handle(fb, file_priv, &r->handle); > + if (fb->funcs->create_handle) > + ret = fb->funcs->create_handle(fb, file_priv, &r->handle); > + else > + ret = -ENODEV; Should this perhaps be -ENOSYS? Thierry pgpywmky3DOds.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #8 from smoki --- Fails on ambient light and that check_material hack from r200_state. If i excluded that material check this test passed and supertuxkart get correct colors. But performance is like swtcl without that check... that need to be fixed somehow as comment there says ;). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #9 from smoki --- Also infinite-spot-light piglit test fails because of this, it also pass if i exclude that material check. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #12 from Anthony Waters --- I have been able to get rid of the flood, the message appears some times in dmesg so there is some other bug that exists. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #10 from Roland Scheidegger --- (In reply to comment #8) > Fails on ambient light and that check_material hack from r200_state. If i > excluded that material check this test passed and supertuxkart get correct > colors. > But performance is like swtcl without that check... that need to be fixed > somehow > as comment there says ;). When you say you excluded the test did you assume always true or always false? If it works both ways then the fallback itself would cause the trouble (wouldn't be terribly surprising). I think fixing this to not require a fallback would require quite a bit of work, the wiring necessary is probably ugly. I think not many apps actually change materials inside begin/end. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] man: Fix typo and use $() for make expressions
Hi Thierry
On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
wrote:
> Due to the typo, none of the .xml files would end up in the release
> tarball and cause make distcheck as well as builds from the tarball to
> fail.
>
> Using $() isn't strictly necessary but other variables and expressions
> use that variant already so it makes the usage consistent.
That's weird. "make distcheck" should not be able to build the
manpages if the XML files are not available. Also ${} is pretty
standard in makefiles, isn't it? I wonder what the problem here is. At
least distcheck runs fine on my machine.
Regards
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] man: Fix typo and use $() for make expressions
On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
wrote:
> Hi Thierry
>
> On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
> wrote:
>> Due to the typo, none of the .xml files would end up in the release
>> tarball and cause make distcheck as well as builds from the tarball to
>> fail.
>>
>> Using $() isn't strictly necessary but other variables and expressions
>> use that variant already so it makes the usage consistent.
>
> That's weird. "make distcheck" should not be able to build the
> manpages if the XML files are not available. Also ${} is pretty
> standard in makefiles, isn't it? I wonder what the problem here is. At
> least distcheck runs fine on my machine.
Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
distcheck works here. But the patch looks fine. Thanks!
> Regards
> David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #11 from smoki --- With always true it pass or opside out, with always false or what is now it fails. I think most if not every racing games fail to render correctly because of this, bugs like missing wheels will be there i guess, or loosed color somewhere, etc. Anyway proper lighting is broken there. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #13 from Alexandre Demers --- (In reply to comment #12) > I have been able to get rid of the flood, the message appears some times in > dmesg so there is some other bug that exists. I agree with you on that point, Thomas and I are also experiencing gpu faults in some cases. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Inline memcmp() for RLE compression of xfer
As we use a variable length the compiler does not realise that it is a
fixed value of either 2 or 4 bytes. Instead of performing the inline
comparison itself, the compiler inserts a function call to the generic
memcmp routine which is optimised for long comparisons of variable
length. That turns out to be quite expensive...
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/udl/udl_transfer.c | 46 ++--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index 142fee5..f343db7 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -75,15 +75,19 @@ static int udl_trim_hline(const u8 *bback, const u8
**bfront, int *width_bytes)
}
#endif
-static inline u16 pixel32_to_be16p(const uint8_t *pixel)
+static inline u16 pixel32_to_be16(const uint32_t pixel)
{
- uint32_t pix = *(uint32_t *)pixel;
- u16 retval;
+ return (((pixel >> 3) & 0x001f) |
+ ((pixel >> 5) & 0x07e0) |
+ ((pixel >> 8) & 0xf800));
+}
- retval = (((pix >> 3) & 0x001f) |
- ((pix >> 5) & 0x07e0) |
- ((pix >> 8) & 0xf800));
- return retval;
+static bool pixel_repeats(const void *pixel, const uint32_t repeat, int bpp)
+{
+ if (bpp == 2)
+ return *(const uint16_t *)pixel == repeat;
+ else
+ return *(const uint32_t *)pixel == repeat;
}
/*
@@ -152,29 +156,33 @@ static void udl_compress_hline16(
prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
while (pixel < cmd_pixel_end) {
- const u8 * const repeating_pixel = pixel;
-
- if (bpp == 2)
- *(uint16_t *)cmd = cpu_to_be16p((uint16_t
*)pixel);
- else if (bpp == 4)
- *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16p(pixel));
+ const u8 *const start = pixel;
+ u32 repeating_pixel;
+
+ if (bpp == 2) {
+ repeating_pixel = *(uint16_t *)pixel;
+ *(uint16_t *)cmd = cpu_to_be16(repeating_pixel);
+ } else {
+ repeating_pixel = *(uint32_t *)pixel;
+ *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16(repeating_pixel));
+ }
cmd += 2;
pixel += bpp;
if (unlikely((pixel < cmd_pixel_end) &&
-(!memcmp(pixel, repeating_pixel, bpp {
+(pixel_repeats(pixel, repeating_pixel,
bpp {
/* go back and fill in raw pixel count */
- *raw_pixels_count_byte = (((repeating_pixel -
+ *raw_pixels_count_byte = (((start -
raw_pixel_start) / bpp) + 1) &
0xFF;
- while ((pixel < cmd_pixel_end)
- && (!memcmp(pixel, repeating_pixel,
bpp))) {
+ while ((pixel < cmd_pixel_end) &&
+ (pixel_repeats(pixel, repeating_pixel,
bpp))) {
pixel += bpp;
}
/* immediately after raw data is repeat byte */
- *cmd++ = (((pixel - repeating_pixel) / bpp) -
1) & 0xFF;
+ *cmd++ = (((pixel - start) / bpp) - 1) & 0xFF;
/* Then start another raw pixel span */
raw_pixel_start = pixel;
@@ -223,6 +231,8 @@ int udl_render_hline(struct drm_device *dev, int bpp,
struct urb **urb_ptr,
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb->transfer_buffer + urb->transfer_buffer_length;
+ BUG_ON(!(bpp == 2 || bpp == 4));
+
line_start = (u8 *) (front + byte_offset);
next_pixel = line_start;
line_end = next_pixel + byte_width;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] man: Fix typo and use $() for make expressions
On Fri, 18 Jan 2013 17:01:59 +0100
David Herrmann wrote:
> On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
> wrote:
> > Hi Thierry
> >
> > On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
> > wrote:
> >> Due to the typo, none of the .xml files would end up in the release
> >> tarball and cause make distcheck as well as builds from the tarball to
> >> fail.
> >>
> >> Using $() isn't strictly necessary but other variables and expressions
> >> use that variant already so it makes the usage consistent.
> >
> > That's weird. "make distcheck" should not be able to build the
> > manpages if the XML files are not available. Also ${} is pretty
> > standard in makefiles, isn't it? I wonder what the problem here is. At
> > least distcheck runs fine on my machine.
>
> Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
> distcheck works here. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #12 from Roland Scheidegger --- Hmm maybe there are bugs in lighting model state somewhere I dunno. But since for this test case the material doesn't actually matter and the wiring looks ok to me (everything wired to vertex color 0) there must be some error elsewhere. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek wrote: > Hi, > > I am playing with llvm/clang v3.2 and mesa. > > It's annoying to see these hundreds of warnings... > > clang: warning: argument unused during compilation: '-fno-builtin-memcmp' > > NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. > > I have done here a brutal solution, maybe someone else has a more elegant one. > > Thanks. > > Regards, > - Sedat - > mesa3d-...@lists.sourceforge.net Please send to mesa-...@lists.freedesktop.org and not the sourceforge list. -fno-builtin-memcmp is added to CFLAGS inside a block that checks if the compiler is gcc: dnl Add flags for gcc and g++ if test "x$GCC" = xyes; then ... CFLAGS_FOR_BUILD="$CFLAGS_FOR_BUILD -fno-builtin-memcmp" CFLAGS="$CFLAGS -fno-builtin-memcmp" ... fi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/35] drm/: Unified handling of unimplemented fb->create_handle
On Fri, Jan 18, 2013 at 4:00 PM, Thierry Reding wrote: > On Thu, Jan 10, 2013 at 09:47:49PM +0100, Daniel Vetter wrote: > [...] >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c >> index 8d665fa..a9abf49 100644 >> --- a/drivers/gpu/drm/drm_crtc.c >> +++ b/drivers/gpu/drm/drm_crtc.c >> @@ -2384,7 +2384,10 @@ int drm_mode_getfb(struct drm_device *dev, >> r->depth = fb->depth; >> r->bpp = fb->bits_per_pixel; >> r->pitch = fb->pitches[0]; >> - fb->funcs->create_handle(fb, file_priv, &r->handle); >> + if (fb->funcs->create_handle) >> + ret = fb->funcs->create_handle(fb, file_priv, &r->handle); >> + else >> + ret = -ENODEV; > > Should this perhaps be -ENOSYS? I tend to just randomly picked an errno which shouldn't ever show up when using this ioctl on a driver which implements the callback. If ENOSYS is the popular choice, I'll change it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56918] [R350] Black labels on MapsGL
https://bugs.freedesktop.org/show_bug.cgi?id=56918 madbiologist changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from madbiologist --- Only 2 days waiting for a response before closing this bug? I think someone might be trigger happy. My comment 8 was referring to the fact that I had uploaded an attachment with the wrong MIME type, and that Alex Deucher was good enough to change the MIME type to the correct one. This issue is still occurring on Firefox 18.0 and continues to occur after updating to the xorg-edgers PPA. This PPA has Mesa 9.1~git20130104.r1.b8b1d61e-0ubuntu0ricotz~precise -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i915: Fix %z from last patch.
Hmm, for whatever reason, my gcc doesn't complain about this, so I am not really sure what's going on. Fix for [drm-intel:drm-intel-next-queued 17/20] drivers/gpu/drm/i915/i915_debugfs.c:263:6: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'long unsigned int' Found by Fenguang's 0-DAY kernel build testing Recommend to squash this in to, since it is not on an upstream branch yet. commit 00fc2c3c53d7bfc9a29e5f4bdf2677f0c399f3bc Author: Ben Widawsky Date: Thu Jan 17 12:45:14 2013 -0800 drm/i915: Remove gtt_mappable_total Cc: dri-devel@lists.freedesktop.org Cc: Fenguang Wu Cc: Daniel Vetter Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 773b23e..90a6fc5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -258,7 +258,7 @@ static int i915_gem_object_info(struct seq_file *m, void* data) seq_printf(m, "%u fault mappable objects, %zu bytes\n", count, size); - seq_printf(m, "%zu [%zu] gtt total\n", + seq_printf(m, "%zu [%lu] gtt total\n", dev_priv->gtt.total, dev_priv->gtt.mappable_end - dev_priv->gtt.start); -- 1.8.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #13 from smoki --- I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3, 6.5.1 mesa - that is oldest i could run, and this never worked :(. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #14 from Marek Olšák --- (In reply to comment #13) > I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3, > 6.5.1 mesa - that is oldest i could run, and this never worked :(. Yes, the test was fixed fairly recently in core Mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=1bc16bf98a1b5a4cca0c0ae2a80ba7982c6e4651 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #15 from smoki --- Thanks Marek, i already run these piglit tests with current (today) mesa master and current piglit, they does work and pass but on swtcl only. On tcl they fail, and supertuxkart gives incorrect colors. I just go to debian stable to test supertuxkart in hope that with some older UMS mesas somehow i can get correct colors, but nope :(. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58839] errors about too many fences printed while playing neverball
https://bugs.freedesktop.org/show_bug.cgi?id=58839 --- Comment #5 from almos --- There are only 'skip'ped commits left to test. The first bad commit could be any of: 4003961fbf7e59de4b95448eada569adb91e5852 4a486f8bf2ca3d88228f8313282289abe78bc2f8 3039addf9363dbae1bbad1cd75d32e0013038c08 We cannot bisect more! With 4003961f and 4a486f8b it segfaults immediately, since 3039addf9 it prints the errors. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #16 from smoki --- OMG, i managed to fix it somehow :). I put in the end of r200UpdateMaterial function r200ColorMaterial( ctx, 0, 0 ); call and removed it from case GL_COLOR_MATERIAL: That fixed supertuxkart colors and dlist-color-material now passed ;). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #17 from smoki --- Clean mesa up to git-commit 1ec1b577f726a70dd787227260e61928e97474e5 No regression with piglit quick-driver.tests, just passed dlist-color-material and fix supertuxkart colors;). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 --- Comment #2 from Mike Lothian --- I've bisected it back to: b07ae05a3dccef620c716e821c647413b951051 is the first bad commit commit ab07ae05a3dccef620c716e821c647413b951051 Author: Matt Turner Date: Wed Sep 5 11:12:29 2012 -0700 targets/dri-r600: Convert to automake v2: Andreas Boll - Provide compatibility with scripts for the old Mesa build system :100644 100644 9c9791b5137525bb22de3439806d565411a698aa bb287d776c71a849f627af941bdbe0d514282ea1 M configure.ac :04 04 097ecdc98b02d01f522d90cae259f846fac14d64 c3659daefaf1f71454c058590a87603c250d4458 M src But I don't think that's much of a surprise and might be a bit of a red herring I've got a feeling the -m32 probably isn't being passed somewhere -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #18 from smoki --- Created attachment 73272 --> https://bugs.freedesktop.org/attachment.cgi?id=73272&action=edit proposed patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed
https://bugzilla.kernel.org/show_bug.cgi?id=30102 maolihappy <506330...@qq.com> changed: What|Removed |Added CC||506330...@qq.com --- Comment #5 from maolihappy <506330...@qq.com> 2013-01-19 05:51:34 --- I have this problem either.my kernel version is 3.0.34. can anyone help? thanks a lot. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 17/20] drivers/gpu/drm/i915/i915_debugfs.c:263:6: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'long unsigned int'
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 30335dc87a460e36a3b630e329bdcf8537f67eff
commit: 00fc2c3c53d7bfc9a29e5f4bdf2677f0c399f3bc [17/20] drm/i915: Remove
gtt_mappable_total
config: i386-randconfig-b063 (attached as .config)
All warnings:
drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_gem_object_info':
>> drivers/gpu/drm/i915/i915_debugfs.c:263:6: warning: format '%zu' expects
>> argument of type 'size_t', but argument 4 has type 'long unsigned int'
>> [-Wformat]
vim +263 drivers/gpu/drm/i915/i915_debugfs.c
247 ++mappable_count;
248 }
249 if (obj->madv == I915_MADV_DONTNEED) {
250 purgeable_size += obj->base.size;
251 ++purgeable_count;
252 }
253 }
254 seq_printf(m, "%u purgeable objects, %zu bytes\n",
255 purgeable_count, purgeable_size);
256 seq_printf(m, "%u pinned mappable objects, %zu bytes\n",
257 mappable_count, mappable_size);
258 seq_printf(m, "%u fault mappable objects, %zu bytes\n",
259 count, size);
260
261 seq_printf(m, "%zu [%zu] gtt total\n",
262 dev_priv->mm.gtt_total,
> 263 dev_priv->mm.gtt_mappable_end -
> dev_priv->mm.gtt_start);
264
265 mutex_unlock(&dev->struct_mutex);
266
267 return 0;
268 }
269
270 static int i915_gem_gtt_info(struct seq_file *m, void* data)
271 {
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.8.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_FHANDLE=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FANOUT_EXACT=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROU
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #2 from Roland Scheidegger --- (In reply to comment #1) > So default command like > > glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE) > > never worked quite right on tcl. How did you arrive at this conclusion? You could try some things (like throwing out the dlist stuff) and see if that improves things. Or figure out if actually all of the subtests don't pass to narrow it down. -- 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/20130118/78476236/attachment.html>
[Bug 54133] [radeon][RV620] Resuming from suspend/hibernation randomly fails since kernel 3.5.0
https://bugs.freedesktop.org/show_bug.cgi?id=54133 --- Comment #6 from Ash --- I am using kernel 3.7.2-201.fc18.x86_64 (Fedora 18) and no libdrm_radeon and am also experiencing this problem. Problem not present in Fedora 17. -- 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/20130118/76620293/attachment.html>
mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
Hi, with the following patchset (13 patches) I was able to build mesa-8.0.5 with LLVM v3.2. There is one big fat patch called "gallivm,draw,llvmpipe: Support wider native registers." [1] which makes backporting hard. Jose? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for the hint via IRC #llvm on irc.oftc.net For more details see [1] and followup [2] discussion (Thanks Johannes Obermayr again)! [1] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html [2] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] 920a940 gallivm: Fix createOProfileJITEventListener namespace with llvm-3.1. d998daf gallivm: Add constructor for raw_debug_ostream. af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about missing implementation. ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. 395c791 gallivm: Fix method overriding in raw_debug_ostream. 557632f gallivm: Use InitializeNativeTargetDisassembler(). 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* 192859a gallivm: Fix LLVM-2.7 build. 2dfd7e5 Initialize only native LLVM Disassembler. [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] abd8713 dri/nouveau: don't use nested functions - EOT -
mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
On Fri, Jan 18, 2013 at 12:44 AM, Brian Paul wrote: > On 01/17/2013 04:23 PM, Sedat Dilek wrote: >> >> Hi, >> >> with the following patchset (13 patches) I was able to build >> mesa-8.0.5 with LLVM v3.2. >> >> There is one big fat patch called "gallivm,draw,llvmpipe: Support >> wider native registers." [1] which makes backporting hard. >> Jose? >> >> Regards, >> - Sedat - >> >> [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 >> >> P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 >> >> [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] >> 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for >> the hint via IRC #llvm on irc.oftc.net >> >> For more details see [1] and followup [2] discussion (Thanks Johannes >> Obermayr again)! >> [1] >> http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html >> [2] >> http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html >> >> [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] >> 920a940 gallivm: Fix createOProfileJITEventListener namespace with >> llvm-3.1. >> d998daf gallivm: Add constructor for raw_debug_ostream. >> af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about >> missing implementation. >> ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. >> 395c791 gallivm: Fix method overriding in raw_debug_ostream. >> 557632f gallivm: Use InitializeNativeTargetDisassembler(). >> 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. >> 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. >> 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* >> 192859a gallivm: Fix LLVM-2.7 build. >> 2dfd7e5 Initialize only native LLVM Disassembler. >> >> [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] >> abd8713 dri/nouveau: don't use nested functions >> >> - EOT - > > > Why are you using mesa 8.0.5? Wouldn't it be better to get into 9.x or > master (aka 9.1)? > As pointed out in my other email, I am here on Ubuntu/precise AMD64 which runs mesa-8.0.x. The simplest way was to install the so-called build-deps and build mesa-8.0.5 after that. Switching to a higher mesa-version results here in circular build-dependencies. For example: mesa-9.x wants a higher libdrm-version and I don't know what libdrm requires for new build-deps to be resolved. Finally, I have to bump my complete Linux graphics stack - I wanted to avoid this! - Sedat - > -Brian >
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #3 from smoki --- Created attachment 73222 --> https://bugs.freedesktop.org/attachment.cgi?id=73222&action=edit swtcl -- 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/20130118/7132ea08/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #4 from smoki --- Created attachment 73223 --> https://bugs.freedesktop.org/attachment.cgi?id=73223&action=edit swtcl -- 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/20130118/aa7cd3de/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #5 from smoki --- Created attachment 73224 --> https://bugs.freedesktop.org/attachment.cgi?id=73224&action=edit tcl -- 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/20130118/b8fae222/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #6 from smoki --- Created attachment 73226 --> https://bugs.freedesktop.org/attachment.cgi?id=73226&action=edit tcl -- 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/20130118/f11aabdf/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #7 from smoki --- Supertuxkart game use irlicht engine and ECM_DIFFUSE_AND_AMBIENT command for the material color, which use vertex color for both diffuse and ambient light. That irlicht command is actualy glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE). mb->getMaterial().ColorMaterial = video::ECM_DIFFUSE_AND_AMBIENT; http://sourceforge.net/apps/trac/supertuxkart/browser/main/trunk/src/graphics/material_manager.cpp And i get this results (see attached pictures) when i use tcl or tcl_mode=0. It get correct lighting with swtcl and incorrect with tcl. -- 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/20130118/2f040baf/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 smoki changed: What|Removed |Added Attachment #73223|text/plain |image/png mime type|| -- 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/20130118/59ffc996/attachment.html>
[PATCH v2 2/5] drm/tegra: Add plane support
On 01/15/2013 06:50 PM, Lucas Stach wrote:
> Am Dienstag, den 15.01.2013, 17:53 +0800 schrieb Mark Zhang:
>> On 01/15/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor.
>>
>> I think "hardware cursor" has specific meaning for Tegra(e.g: Tegra30
>> has a 32x32 24bpp or 64x64 2bpp hardware cursor). So you may change it
>> to "hardware accelerated cursor"?
>>
> According to the TRM no Tegra has ARGB hardware cursor support, but only
> 2-color. So we talked about doing the hardware cursor by using a plane.
> If the TRM is wrong in this regard and we can get a ARGB cursor on Tegra
> 3 it would be nice to know.
>
Lucas, yes, TRM says "Hardware cursor is supported for 32x32 or for
64x64 2-bpp cursor.", but just as you can see, we can set cursor's
foreground & background color by register "DC_DISP_CURSOR_FOREGROUND_0
" & "DC_DISP_CURSOR_BACKGROUND_0".
So I asked the expert in nvidia and here is the explanation of the
hardware cursor:
"each pixel in the cursor is encoded by 2 bits.
only 3 values are used per pixel: transparent, foreground, background.
when pixel is transparent - no pixel is displayed. (also known as a mask)
when pixel is foreground - color of pixel is 24-bit value in
DC_DISP_CURSOR_FOREGROUND_0.
when pixel is background - color of pixel is 24-bit value in
DC_DISP_CURSOR_BACKGROUND_0.
So I would still phrase it as a 2-bit cursor. It's a palette with 2
colors plus a 1-bit alpha. The palette entries are 24-bit."
Mark
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>> [...]
>>> +};
>>> +
>>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
>>> +{
>>> + unsigned int i;
>>> + int err = 0;
>>> +
>>> + for (i = 0; i < 2; i++) {
>>> + struct tegra_plane *plane;
>>> +
>>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>>> + if (!plane)
>>> + return -ENOMEM;
>>> +
>>> + plane->index = i;
>>
>> I suggest to change this line to: "plane->index = i + 1;". This makes
>> the plane's index be consistent with Tegra's windows number. And also we
>> don't need to worry about passing "plane->index + 1" to some functions
>> which need to know which window is operating on.
>>
> Again, if we make WIN_C the root window, we can keep the plane index
> assignment as is and get rid of the "index + 1" passing.
>
>
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
Hi, I am playing with llvm/clang v3.2 and mesa. It's annoying to see these hundreds of warnings... clang: warning: argument unused during compilation: '-fno-builtin-memcmp' NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. I have done here a brutal solution, maybe someone else has a more elegant one. Thanks. Regards, - Sedat -
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #18 from Nickolay --- I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M APU. I've attached dmesg and lspci output of my laptop. -- 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/20130118/e6fce750/attachment.html>
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #19 from Nickolay --- Created attachment 73234 --> https://bugs.freedesktop.org/attachment.cgi?id=73234&action=edit a10-4600m_lspci -- 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/20130118/75a61259/attachment.html>
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #20 from Nickolay --- Created attachment 73235 --> https://bugs.freedesktop.org/attachment.cgi?id=73235&action=edit a10-4600m dmesg -- 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/20130118/6aaa4702/attachment.html>
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #21 from Nickolay --- (In reply to comment #18) > I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M > APU. I've attached dmesg and lspci output of my laptop. P.S. Kernel version 3.7.3 -- 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/20130118/3548de13/attachment.html>
[PATCH v3 3/9] video: Add generic HDMI infoframe helpers
On Wed, Jan 16, 2013 at 03:27:14PM +0200, Ville Syrj?l? wrote:
> On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> > Add generic helpers to pack HDMI infoframes into binary buffers.
[...]
> > +/**
> > + * hdmi_avi_infoframe_init() - initialize an HDMI AVI infoframe
> > + * @frame: HDMI AVI infoframe
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
> > +{
> > + if (!frame)
> > + return -EINVAL;
>
> There's quite a bit of error checking all around which seems a bit
> pointless since this is all internal stuff. Any errors are bugs in
> some driver code, so just letting the thing oops would be fine in my
> opinion.
Okay, I can remove some of the more obvious checks. Checking for space
requirements might still be useful, so I'll leave that in.
> > +ssize_t hdmi_spd_infoframe_pack(struct hdmi_spd_infoframe *frame, void
> > *buffer,
> > + size_t size)
[...]
> > + for (i = 0; i < sizeof(frame->vendor); i++)
> > + ptr[i] = frame->vendor[i];
> > +
> > + for (i = 0; i < sizeof(frame->product); i++)
> > + ptr[8 + i] = frame->product[i];
>
> memcpy()
Done.
> > +enum hdmi_spd_sdi {
> > + HDMI_SPD_SDI_UNKNOWN,
> > + HDMI_SPD_SDI_DSTB,
> > + HDMI_SPD_SDI_DVDP,
> > + HDMI_SPD_SDI_DVHS,
> > + HDMI_SPD_SDI_HDDVR,
> > + HDMI_SPD_SDI_DVC,
> > + HDMI_SPD_SDI_DSC,
> > + HDMI_SPD_SDI_VCD,
> > + HDMI_SPD_SDI_GAME,
> > + HDMI_SPD_SDI_PC,
> > + HDMI_SPD_SDI_BD,
> > + HDMI_SPD_SDI_SCD,
>
> I believe SACD is a more correct name.
Done.
> HD DVD and PMP are missing from this list.
I can't find any reference to those in CEA-861-D. HDMI 1.4 doesn't have
them either. Can you provide any pointers?
> > +enum hdmi_audio_coding_type {
> > + HDMI_AUDIO_CODING_TYPE_STREAM,
> > + HDMI_AUDIO_CODING_TYPE_IEC_60958,
> > + HDMI_AUDIO_CODING_TYPE_AC3,
> > + HDMI_AUDIO_CODING_TYPE_MPEG1,
> > + HDMI_AUDIO_CODING_TYPE_MP3,
> > + HDMI_AUDIO_CODING_TYPE_MPEG2,
> > + HDMI_AUDIO_CODING_TYPE_AAC,
> > + HDMI_AUDIO_CODING_TYPE_DTS,
> > + HDMI_AUDIO_CODING_TYPE_ATRAC,
> > + HDMI_AUDIO_CODING_TYPE_ONE_BIT_AUDIO,
> > + HDMI_AUDIO_CODING_TYPE_DOLBY_DIGITAL_PLUS,
> > + HDMI_AUDIO_CODING_TYPE_DTS_HD,
> > + HDMI_AUDIO_CODING_TYPE_MAT_MLP,
> > + HDMI_AUDIO_CODING_TYPE_DST,
> > + HDMI_AUDIO_CODING_TYPE_WMPRO,
>
> These don't always quite match the names in CEA-861-E. Wouldn't it
> be better to use matching names?
Are HD-DVD and PMP above listed in CEA-861-E? I'll need to find a copy
of it and will go over this again and match the names to those in the
document.
> Also the audio coding extension type is missing.
I assume this is also part of CEA-861-E as I can't find a reference in
-D?
Thanks for reviewing,
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/20130118/8d8550e5/attachment.pgp>
[PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrj?l? wrote:
> On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrj?l? wrote:
> > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > Since the variable's value is the size of an array, we can assume that
> > > > it will never be negative.
> > > >
> > > > Signed-off-by: Thierry Reding
> > > > ---
> > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > index 5dbf7d2..d65d863 100644
> > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > edid_cea_modes[] = {
> > > >2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > };
> > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > +static const unsigned int drm_num_cea_modes =
> > > > ARRAY_SIZE(edid_cea_modes);
> > >
> > > Why do we even have these num_foo things? I think it would be clearer to
> > > use ARRAY_SIZE(foo) directly where appropriate.
> >
> > Actually I was thinking about maybe writing a patch to move the table
> > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > easy to create duplicates of the table. In that case, using the
> > ARRAY_SIZE macro directly wouldn't be an option.
>
> Well drm_edid.c is the only one accessing these tables anyway, so it
> they would be in drm_edid.c and static, you could still use
> ARRAY_SIZE().
>
> Not that I really like the idea of polluting drm_edid.c with all these
> massive tables.
There's also the possibility to put the tables along with the functions
that access them into a drm_edid_modes.c.
> Too bad cpp doesn't support this kind of thing:
> #if __BASE_FILE__ != "drm_edid.c"
> #error ...
> #endif
We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
is included.
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/20130118/50bc6a3e/attachment-0001.pgp>
[PATCH v3 3/9] video: Add generic HDMI infoframe helpers
On Fri, Jan 18, 2013 at 09:56:36AM +0100, Thierry Reding wrote:
> On Wed, Jan 16, 2013 at 03:27:14PM +0200, Ville Syrj?l? wrote:
> > On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> > > Add generic helpers to pack HDMI infoframes into binary buffers.
> [...]
> > > +/**
> > > + * hdmi_avi_infoframe_init() - initialize an HDMI AVI infoframe
> > > + * @frame: HDMI AVI infoframe
> > > + *
> > > + * Returns 0 on success or a negative error code on failure.
> > > + */
> > > +int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
> > > +{
> > > + if (!frame)
> > > + return -EINVAL;
> >
> > There's quite a bit of error checking all around which seems a bit
> > pointless since this is all internal stuff. Any errors are bugs in
> > some driver code, so just letting the thing oops would be fine in my
> > opinion.
>
> Okay, I can remove some of the more obvious checks. Checking for space
> requirements might still be useful, so I'll leave that in.
>
> > > +ssize_t hdmi_spd_infoframe_pack(struct hdmi_spd_infoframe *frame, void
> > > *buffer,
> > > + size_t size)
> [...]
> > > + for (i = 0; i < sizeof(frame->vendor); i++)
> > > + ptr[i] = frame->vendor[i];
> > > +
> > > + for (i = 0; i < sizeof(frame->product); i++)
> > > + ptr[8 + i] = frame->product[i];
> >
> > memcpy()
>
> Done.
>
> > > +enum hdmi_spd_sdi {
> > > + HDMI_SPD_SDI_UNKNOWN,
> > > + HDMI_SPD_SDI_DSTB,
> > > + HDMI_SPD_SDI_DVDP,
> > > + HDMI_SPD_SDI_DVHS,
> > > + HDMI_SPD_SDI_HDDVR,
> > > + HDMI_SPD_SDI_DVC,
> > > + HDMI_SPD_SDI_DSC,
> > > + HDMI_SPD_SDI_VCD,
> > > + HDMI_SPD_SDI_GAME,
> > > + HDMI_SPD_SDI_PC,
> > > + HDMI_SPD_SDI_BD,
> > > + HDMI_SPD_SDI_SCD,
> >
> > I believe SACD is a more correct name.
>
> Done.
>
> > HD DVD and PMP are missing from this list.
>
> I can't find any reference to those in CEA-861-D. HDMI 1.4 doesn't have
> them either. Can you provide any pointers?
CEA-861-E has them.
>
> > > +enum hdmi_audio_coding_type {
> > > + HDMI_AUDIO_CODING_TYPE_STREAM,
> > > + HDMI_AUDIO_CODING_TYPE_IEC_60958,
> > > + HDMI_AUDIO_CODING_TYPE_AC3,
> > > + HDMI_AUDIO_CODING_TYPE_MPEG1,
> > > + HDMI_AUDIO_CODING_TYPE_MP3,
> > > + HDMI_AUDIO_CODING_TYPE_MPEG2,
> > > + HDMI_AUDIO_CODING_TYPE_AAC,
> > > + HDMI_AUDIO_CODING_TYPE_DTS,
> > > + HDMI_AUDIO_CODING_TYPE_ATRAC,
> > > + HDMI_AUDIO_CODING_TYPE_ONE_BIT_AUDIO,
> > > + HDMI_AUDIO_CODING_TYPE_DOLBY_DIGITAL_PLUS,
> > > + HDMI_AUDIO_CODING_TYPE_DTS_HD,
> > > + HDMI_AUDIO_CODING_TYPE_MAT_MLP,
> > > + HDMI_AUDIO_CODING_TYPE_DST,
> > > + HDMI_AUDIO_CODING_TYPE_WMPRO,
> >
> > These don't always quite match the names in CEA-861-E. Wouldn't it
> > be better to use matching names?
>
> Are HD-DVD and PMP above listed in CEA-861-E? I'll need to find a copy
> of it and will go over this again and match the names to those in the
> document.
Great.
> > Also the audio coding extension type is missing.
>
> I assume this is also part of CEA-861-E as I can't find a reference in
> -D?
Yeah, I only checked against CEA-861-E.
--
Ville Syrj?l?
Intel OTC
[PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Fri, Jan 18, 2013 at 11:30:04AM +0100, Thierry Reding wrote:
> On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrj?l? wrote:
> > On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrj?l? wrote:
> > > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > > Since the variable's value is the size of an array, we can assume that
> > > > > it will never be negative.
> > > > >
> > > > > Signed-off-by: Thierry Reding
> > > > > ---
> > > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > > index 5dbf7d2..d65d863 100644
> > > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > > edid_cea_modes[] = {
> > > > > 2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > > > DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > > };
> > > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > > +static const unsigned int drm_num_cea_modes =
> > > > > ARRAY_SIZE(edid_cea_modes);
> > > >
> > > > Why do we even have these num_foo things? I think it would be clearer to
> > > > use ARRAY_SIZE(foo) directly where appropriate.
> > >
> > > Actually I was thinking about maybe writing a patch to move the table
> > > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > > easy to create duplicates of the table. In that case, using the
> > > ARRAY_SIZE macro directly wouldn't be an option.
> >
> > Well drm_edid.c is the only one accessing these tables anyway, so it
> > they would be in drm_edid.c and static, you could still use
> > ARRAY_SIZE().
> >
> > Not that I really like the idea of polluting drm_edid.c with all these
> > massive tables.
>
> There's also the possibility to put the tables along with the functions
> that access them into a drm_edid_modes.c.
>
> > Too bad cpp doesn't support this kind of thing:
> > #if __BASE_FILE__ != "drm_edid.c"
> > #error ...
> > #endif
>
> We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
> and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
> is included.
Yeah, I suppose there's no better way to do that. It's a bit ugly
though.
--
Ville Syrj?l?
Intel OTC
[PATCH v3 1/9] drm: Make drm_num_cea_modes unsigned
On Fri, Jan 18, 2013 at 12:51:11PM +0200, Ville Syrj?l? wrote:
> On Fri, Jan 18, 2013 at 11:30:04AM +0100, Thierry Reding wrote:
> > On Mon, Jan 14, 2013 at 05:47:13PM +0200, Ville Syrj?l? wrote:
> > > On Mon, Jan 14, 2013 at 04:06:13PM +0100, Thierry Reding wrote:
> > > > On Mon, Jan 14, 2013 at 04:42:39PM +0200, Ville Syrj?l? wrote:
> > > > > On Mon, Jan 14, 2013 at 03:30:20PM +0100, Thierry Reding wrote:
> > > > > > Since the variable's value is the size of an array, we can assume
> > > > > > that
> > > > > > it will never be negative.
> > > > > >
> > > > > > Signed-off-by: Thierry Reding
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_edid_modes.h | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_edid_modes.h
> > > > > > b/drivers/gpu/drm/drm_edid_modes.h
> > > > > > index 5dbf7d2..d65d863 100644
> > > > > > --- a/drivers/gpu/drm/drm_edid_modes.h
> > > > > > +++ b/drivers/gpu/drm/drm_edid_modes.h
> > > > > > @@ -771,4 +771,4 @@ static const struct drm_display_mode
> > > > > > edid_cea_modes[] = {
> > > > > >2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> > > > > >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> > > > > > };
> > > > > > -static const int drm_num_cea_modes = ARRAY_SIZE(edid_cea_modes);
> > > > > > +static const unsigned int drm_num_cea_modes =
> > > > > > ARRAY_SIZE(edid_cea_modes);
> > > > >
> > > > > Why do we even have these num_foo things? I think it would be clearer
> > > > > to
> > > > > use ARRAY_SIZE(foo) directly where appropriate.
> > > >
> > > > Actually I was thinking about maybe writing a patch to move the table
> > > > out of the header and into drm_edid.c (or drm_cea.c?) to make it less
> > > > easy to create duplicates of the table. In that case, using the
> > > > ARRAY_SIZE macro directly wouldn't be an option.
> > >
> > > Well drm_edid.c is the only one accessing these tables anyway, so it
> > > they would be in drm_edid.c and static, you could still use
> > > ARRAY_SIZE().
> > >
> > > Not that I really like the idea of polluting drm_edid.c with all these
> > > massive tables.
> >
> > There's also the possibility to put the tables along with the functions
> > that access them into a drm_edid_modes.c.
> >
> > > Too bad cpp doesn't support this kind of thing:
> > > #if __BASE_FILE__ != "drm_edid.c"
> > > #error ...
> > > #endif
> >
> > We could fake that by protecting the tables using #ifdef NEED_CEA_MODES
> > and define NEED_CEA_MODES in drm_edid.c before the drm_edid_modes.h file
> > is included.
>
> Yeah, I suppose there's no better way to do that. It's a bit ugly
> though.
What about moving them to a separate file altogether? It would involve
moving the do_cea_modes() as well, but that would need to be called from
drm_edid.c, so it isn't very pretty either.
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/20130118/dad33036/attachment.pgp>
Radeon HDMI question
Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan: > Hi, > > I experience a strange problem, I don't know whether > it's a feature or a bug, and if it's a bug, where. > > I have a Radeon HD6570. A monitor via DVI and an LCD TV > via HDMI are connected. Fedora 18/x86_64 is installed on > the computer. (Previously it was F17, F16 and F14.) > > When playing videos via Xine, all videos with 5.1 sound > works nicely via the HDMI, the sound output is on the TV. > However, when only stereo or mono sound is present in > the video, the sound doesn't go out to the TV. > > I have an internal soundcard and speakers are connected. > Pulseaudio on modern Linuxen has the feature to switch the > audio output device on the fly and per-application, so I can > switch between the outputs. > > Is is possible to make mono and stereo audio work via HDMI? Hi Zolt?n, that just sounds like a mis configured Xine to me. Xine can be configured to use different outputs for Mono/Stero and 5.1 sounds. You can also configure ALSA to route the audio differently depending on the number of channels, but that isn't the default and if you configured it like this you probably would remember it :) I can't really see a way how this can be a hardware problem either, cause 5.1 audio pass through is handled mostly the same as Stereo. I suggest that you check your Xine configuration, you should find multiple setting for selection the output device (Mono/Stereo/5.1/7.1 etc...) make sure that they all point to the correct hardware device. Regards, Christian. > > Thanks in advance, > Zolt?n B?sz?rm?nyi > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH] man: Fix typo and use $() for make expressions
Due to the typo, none of the .xml files would end up in the release
tarball and cause make distcheck as well as builds from the tarball to
fail.
Using $() isn't strictly necessary but other variables and expressions
use that variant already so it makes the usage consistent.
Signed-off-by: Thierry Reding
---
man/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/man/Makefile.am b/man/Makefile.am
index 25202e2..d25a293 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -17,7 +17,8 @@ MANPAGES_ALIASES = \
drm-ttm.7
XML_FILES = \
- ${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubs %.7,%.xml,$(MANPAGES)
+ $(patsubst %.1,%.xml,$(patsubst %.3,%.xml,$(patsubst
%.5,%.xml,$(patsubst %.7,%.xml,$(MANPAGES)
+
EXTRA_DIST = $(XML_FILES)
CLEANFILES = $(MANPAGES) $(MANPAGES_ALIASES) .man_fixup
man_MANS =
--
1.8.1.1
[PATCH] tests: Include string.h for strlen() and memset()
The setversion and getversion tests use these functions so make sure they are included to avoid compiler warnings. Signed-off-by: Thierry Reding --- tests/drmtest.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/drmtest.h b/tests/drmtest.h index 55bb446..731d1a7 100644 --- a/tests/drmtest.h +++ b/tests/drmtest.h @@ -27,6 +27,7 @@ #include #include +#include #include #include #include -- 1.8.1.1
[PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe
On Thu, Jan 17, 2013 at 04:31:31PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 [1] we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
> bits in the AVI inforframe.
>
> [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
>
> v2: Give the Q bits better names, add spec chapter information
>
> Reviewed-by: Paulo Zanoni
> Signed-off-by: Ville Syrj?l?
Entire series queued for -next, thanks for patches&review.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_drv.h |4
> drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a698c6..aeff0d1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -289,6 +289,9 @@ struct cxsr_latency {
> #define DIP_LEN_AVI 13
> #define DIP_AVI_PR_10
> #define DIP_AVI_PR_21
> +#define DIP_AVI_RGB_QUANT_RANGE_DEFAULT (0 << 2)
> +#define DIP_AVI_RGB_QUANT_RANGE_LIMITED (1 << 2)
> +#define DIP_AVI_RGB_QUANT_RANGE_FULL (2 << 2)
>
> #define DIP_TYPE_SPD 0x83
> #define DIP_VERSION_SPD 0x1
> @@ -347,6 +350,7 @@ struct intel_hdmi {
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> + bool rgb_quant_range_selectable;
> void (*write_infoframe)(struct drm_encoder *encoder,
> struct dip_infoframe *frame);
> void (*set_infoframes)(struct drm_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index db67be6..d53b731 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> *encoder,
> static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
>struct drm_display_mode *adjusted_mode)
> {
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> .ver = DIP_VERSION_AVI,
> @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
>
> + if (intel_hdmi->rgb_quant_range_selectable) {
> + if (adjusted_mode->private_flags &
> INTEL_MODE_LIMITED_COLOR_RANGE)
> + avi_if.body.avi.ITC_EC_Q_SC |=
> DIP_AVI_RGB_QUANT_RANGE_LIMITED;
> + else
> + avi_if.body.avi.ITC_EC_Q_SC |=
> DIP_AVI_RGB_QUANT_RANGE_FULL;
> + }
> +
> avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
>
> intel_set_infoframe(encoder, &avi_if);
> @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_hdmi->has_hdmi_sink = false;
> intel_hdmi->has_audio = false;
> + intel_hdmi->rgb_quant_range_selectable = false;
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> intel_hdmi->has_hdmi_sink =
> drm_detect_hdmi_monitor(edid);
> intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
> + intel_hdmi->rgb_quant_range_selectable =
> + drm_rgb_quant_range_selectable(edid);
> }
> kfree(edid);
> }
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 3e34a35..f01063a 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -126,6 +126,7 @@ struct intel_sdvo {
> bool is_hdmi;
> bool has_hdmi_monitor;
> bool has_hdmi_audio;
> + bool rgb_quant_range_selectable;
>
> /**
>* This is set if we detect output of sdvo device as LVDS and
> @@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
> *intel_sdvo,
> &tx_rate, 1);
> }
>
> -static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
> +static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
> + const struct drm_display_mode
> *adjusted_mode)
> {
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> @@ -956,6 +958,13 @@ static
[PATCH 08/35] drm/: Unified handling of unimplemented fb->create_handle
On Thu, Jan 10, 2013 at 09:47:49PM +0100, Daniel Vetter wrote: [...] > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 8d665fa..a9abf49 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -2384,7 +2384,10 @@ int drm_mode_getfb(struct drm_device *dev, > r->depth = fb->depth; > r->bpp = fb->bits_per_pixel; > r->pitch = fb->pitches[0]; > - fb->funcs->create_handle(fb, file_priv, &r->handle); > + if (fb->funcs->create_handle) > + ret = fb->funcs->create_handle(fb, file_priv, &r->handle); > + else > + ret = -ENODEV; Should this perhaps be -ENOSYS? 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/20130118/8c533d1b/attachment.pgp>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #8 from smoki --- Fails on ambient light and that check_material hack from r200_state. If i excluded that material check this test passed and supertuxkart get correct colors. But performance is like swtcl without that check... that need to be fixed somehow as comment there says ;). -- 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/20130118/9cd1c3c9/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #9 from smoki --- Also infinite-spot-light piglit test fails because of this, it also pass if i exclude that material check. -- 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/20130118/0e68ca29/attachment.html>
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #12 from Anthony Waters --- I have been able to get rid of the flood, the message appears some times in dmesg so there is some other bug that exists. -- 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/20130118/87b8e767/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #10 from Roland Scheidegger --- (In reply to comment #8) > Fails on ambient light and that check_material hack from r200_state. If i > excluded that material check this test passed and supertuxkart get correct > colors. > But performance is like swtcl without that check... that need to be fixed > somehow > as comment there says ;). When you say you excluded the test did you assume always true or always false? If it works both ways then the fallback itself would cause the trouble (wouldn't be terribly surprising). I think fixing this to not require a fallback would require quite a bit of work, the wiring necessary is probably ugly. I think not many apps actually change materials inside begin/end. -- 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/20130118/55efedd0/attachment.html>
[PATCH] man: Fix typo and use $() for make expressions
Hi Thierry
On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
wrote:
> Due to the typo, none of the .xml files would end up in the release
> tarball and cause make distcheck as well as builds from the tarball to
> fail.
>
> Using $() isn't strictly necessary but other variables and expressions
> use that variant already so it makes the usage consistent.
That's weird. "make distcheck" should not be able to build the
manpages if the XML files are not available. Also ${} is pretty
standard in makefiles, isn't it? I wonder what the problem here is. At
least distcheck runs fine on my machine.
Regards
David
[PATCH] man: Fix typo and use $() for make expressions
On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
wrote:
> Hi Thierry
>
> On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
> wrote:
>> Due to the typo, none of the .xml files would end up in the release
>> tarball and cause make distcheck as well as builds from the tarball to
>> fail.
>>
>> Using $() isn't strictly necessary but other variables and expressions
>> use that variant already so it makes the usage consistent.
>
> That's weird. "make distcheck" should not be able to build the
> manpages if the XML files are not available. Also ${} is pretty
> standard in makefiles, isn't it? I wonder what the problem here is. At
> least distcheck runs fine on my machine.
Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
distcheck works here. But the patch looks fine. Thanks!
> Regards
> David
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #11 from smoki --- With always true it pass or opside out, with always false or what is now it fails. I think most if not every racing games fail to render correctly because of this, bugs like missing wheels will be there i guess, or loosed color somewhere, etc. Anyway proper lighting is broken there. -- 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/20130118/9712f7e3/attachment-0001.html>
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #13 from Alexandre Demers --- (In reply to comment #12) > I have been able to get rid of the flood, the message appears some times in > dmesg so there is some other bug that exists. I agree with you on that point, Thomas and I are also experiencing gpu faults in some cases. -- 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/20130118/0bb2397f/attachment.html>
[PATCH] drm/udl: Inline memcmp() for RLE compression of xfer
As we use a variable length the compiler does not realise that it is a
fixed value of either 2 or 4 bytes. Instead of performing the inline
comparison itself, the compiler inserts a function call to the generic
memcmp routine which is optimised for long comparisons of variable
length. That turns out to be quite expensive...
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/udl/udl_transfer.c | 46 ++--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index 142fee5..f343db7 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -75,15 +75,19 @@ static int udl_trim_hline(const u8 *bback, const u8
**bfront, int *width_bytes)
}
#endif
-static inline u16 pixel32_to_be16p(const uint8_t *pixel)
+static inline u16 pixel32_to_be16(const uint32_t pixel)
{
- uint32_t pix = *(uint32_t *)pixel;
- u16 retval;
+ return (((pixel >> 3) & 0x001f) |
+ ((pixel >> 5) & 0x07e0) |
+ ((pixel >> 8) & 0xf800));
+}
- retval = (((pix >> 3) & 0x001f) |
- ((pix >> 5) & 0x07e0) |
- ((pix >> 8) & 0xf800));
- return retval;
+static bool pixel_repeats(const void *pixel, const uint32_t repeat, int bpp)
+{
+ if (bpp == 2)
+ return *(const uint16_t *)pixel == repeat;
+ else
+ return *(const uint32_t *)pixel == repeat;
}
/*
@@ -152,29 +156,33 @@ static void udl_compress_hline16(
prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
while (pixel < cmd_pixel_end) {
- const u8 * const repeating_pixel = pixel;
-
- if (bpp == 2)
- *(uint16_t *)cmd = cpu_to_be16p((uint16_t
*)pixel);
- else if (bpp == 4)
- *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16p(pixel));
+ const u8 *const start = pixel;
+ u32 repeating_pixel;
+
+ if (bpp == 2) {
+ repeating_pixel = *(uint16_t *)pixel;
+ *(uint16_t *)cmd = cpu_to_be16(repeating_pixel);
+ } else {
+ repeating_pixel = *(uint32_t *)pixel;
+ *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16(repeating_pixel));
+ }
cmd += 2;
pixel += bpp;
if (unlikely((pixel < cmd_pixel_end) &&
-(!memcmp(pixel, repeating_pixel, bpp {
+(pixel_repeats(pixel, repeating_pixel,
bpp {
/* go back and fill in raw pixel count */
- *raw_pixels_count_byte = (((repeating_pixel -
+ *raw_pixels_count_byte = (((start -
raw_pixel_start) / bpp) + 1) &
0xFF;
- while ((pixel < cmd_pixel_end)
- && (!memcmp(pixel, repeating_pixel,
bpp))) {
+ while ((pixel < cmd_pixel_end) &&
+ (pixel_repeats(pixel, repeating_pixel,
bpp))) {
pixel += bpp;
}
/* immediately after raw data is repeat byte */
- *cmd++ = (((pixel - repeating_pixel) / bpp) -
1) & 0xFF;
+ *cmd++ = (((pixel - start) / bpp) - 1) & 0xFF;
/* Then start another raw pixel span */
raw_pixel_start = pixel;
@@ -223,6 +231,8 @@ int udl_render_hline(struct drm_device *dev, int bpp,
struct urb **urb_ptr,
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb->transfer_buffer + urb->transfer_buffer_length;
+ BUG_ON(!(bpp == 2 || bpp == 4));
+
line_start = (u8 *) (front + byte_offset);
next_pixel = line_start;
line_end = next_pixel + byte_width;
--
1.7.10.4
[PATCH] man: Fix typo and use $() for make expressions
On Fri, 18 Jan 2013 17:01:59 +0100
David Herrmann wrote:
> On Fri, Jan 18, 2013 at 5:00 PM, David Herrmann
> wrote:
> > Hi Thierry
> >
> > On Fri, Jan 18, 2013 at 1:22 PM, Thierry Reding
> > wrote:
> >> Due to the typo, none of the .xml files would end up in the release
> >> tarball and cause make distcheck as well as builds from the tarball to
> >> fail.
> >>
> >> Using $() isn't strictly necessary but other variables and expressions
> >> use that variant already so it makes the usage consistent.
> >
> > That's weird. "make distcheck" should not be able to build the
> > manpages if the XML files are not available. Also ${} is pretty
> > standard in makefiles, isn't it? I wonder what the problem here is. At
> > least distcheck runs fine on my machine.
>
> Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
> distcheck works here. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #12 from Roland Scheidegger --- Hmm maybe there are bugs in lighting model state somewhere I dunno. But since for this test case the material doesn't actually matter and the wiring looks ok to me (everything wired to vertex color 0) there must be some error elsewhere. -- 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/20130118/1dba4ef2/attachment.html>
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek wrote: > Hi, > > I am playing with llvm/clang v3.2 and mesa. > > It's annoying to see these hundreds of warnings... > > clang: warning: argument unused during compilation: '-fno-builtin-memcmp' > > NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. > > I have done here a brutal solution, maybe someone else has a more elegant one. > > Thanks. > > Regards, > - Sedat - > mesa3d-dev at lists.sourceforge.net Please send to mesa-dev at lists.freedesktop.org and not the sourceforge list. -fno-builtin-memcmp is added to CFLAGS inside a block that checks if the compiler is gcc: dnl Add flags for gcc and g++ if test "x$GCC" = xyes; then ... CFLAGS_FOR_BUILD="$CFLAGS_FOR_BUILD -fno-builtin-memcmp" CFLAGS="$CFLAGS -fno-builtin-memcmp" ... fi
[PATCH 08/35] drm/: Unified handling of unimplemented fb->create_handle
On Fri, Jan 18, 2013 at 4:00 PM, Thierry Reding wrote: > On Thu, Jan 10, 2013 at 09:47:49PM +0100, Daniel Vetter wrote: > [...] >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c >> index 8d665fa..a9abf49 100644 >> --- a/drivers/gpu/drm/drm_crtc.c >> +++ b/drivers/gpu/drm/drm_crtc.c >> @@ -2384,7 +2384,10 @@ int drm_mode_getfb(struct drm_device *dev, >> r->depth = fb->depth; >> r->bpp = fb->bits_per_pixel; >> r->pitch = fb->pitches[0]; >> - fb->funcs->create_handle(fb, file_priv, &r->handle); >> + if (fb->funcs->create_handle) >> + ret = fb->funcs->create_handle(fb, file_priv, &r->handle); >> + else >> + ret = -ENODEV; > > Should this perhaps be -ENOSYS? I tend to just randomly picked an errno which shouldn't ever show up when using this ioctl on a driver which implements the callback. If ENOSYS is the popular choice, I'll change it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 56918] [R350] Black labels on MapsGL
https://bugs.freedesktop.org/show_bug.cgi?id=56918 madbiologist changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from madbiologist --- Only 2 days waiting for a response before closing this bug? I think someone might be trigger happy. My comment 8 was referring to the fact that I had uploaded an attachment with the wrong MIME type, and that Alex Deucher was good enough to change the MIME type to the correct one. This issue is still occurring on Firefox 18.0 and continues to occur after updating to the xorg-edgers PPA. This PPA has Mesa 9.1~git20130104.r1.b8b1d61e-0ubuntu0ricotz~precise -- 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/20130118/3538d726/attachment-0001.html>
[PATCH 1/5] drm/i915: Fix %z from last patch.
Hmm, for whatever reason, my gcc doesn't complain about this, so I am not really sure what's going on. Fix for [drm-intel:drm-intel-next-queued 17/20] drivers/gpu/drm/i915/i915_debugfs.c:263:6: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'long unsigned int' Found by Fenguang's 0-DAY kernel build testing Recommend to squash this in to, since it is not on an upstream branch yet. commit 00fc2c3c53d7bfc9a29e5f4bdf2677f0c399f3bc Author: Ben Widawsky Date: Thu Jan 17 12:45:14 2013 -0800 drm/i915: Remove gtt_mappable_total Cc: dri-devel at lists.freedesktop.org Cc: Fenguang Wu Cc: Daniel Vetter Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 773b23e..90a6fc5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -258,7 +258,7 @@ static int i915_gem_object_info(struct seq_file *m, void* data) seq_printf(m, "%u fault mappable objects, %zu bytes\n", count, size); - seq_printf(m, "%zu [%zu] gtt total\n", + seq_printf(m, "%zu [%lu] gtt total\n", dev_priv->gtt.total, dev_priv->gtt.mappable_end - dev_priv->gtt.start); -- 1.8.1.1
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #13 from smoki --- I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3, 6.5.1 mesa - that is oldest i could run, and this never worked :(. -- 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/20130118/b461aeec/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #14 from Marek Ol??k --- (In reply to comment #13) > I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3, > 6.5.1 mesa - that is oldest i could run, and this never worked :(. Yes, the test was fixed fairly recently in core Mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=1bc16bf98a1b5a4cca0c0ae2a80ba7982c6e4651 -- 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/20130118/56a8748a/attachment.html>
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
On Fri, Jan 18, 2013 at 5:19 AM, Sedat Dilek wrote: > Hi, > > I am playing with llvm/clang v3.2 and mesa. > > It's annoying to see these hundreds of warnings... > > clang: warning: argument unused during compilation: '-fno-builtin-memcmp' > > NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. > > I have done here a brutal solution, maybe someone else has a more elegant one. > > Thanks. > [ CCing LLVMLinux ] OK, there exists smarter solutions like this... ### Export compiler settings (here: clang) export CC=clang export CXX=clang++ export CFLAGS="-Qunused-arguments" export CXXFLAGS="$CFLAGS" ...but we do not live only in a GCC world :-). I would like to see a fix in mesa (XORG) world. - Sedat - > Regards, > - Sedat -
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
On Fri, Jan 18, 2013 at 6:25 PM, Matt Turner wrote: > On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek wrote: >> Hi, >> >> I am playing with llvm/clang v3.2 and mesa. >> >> It's annoying to see these hundreds of warnings... >> >> clang: warning: argument unused during compilation: '-fno-builtin-memcmp' >> >> NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. >> >> I have done here a brutal solution, maybe someone else has a more elegant >> one. >> >> Thanks. >> >> Regards, >> - Sedat - > >> mesa3d-dev at lists.sourceforge.net > > Please send to mesa-dev at lists.freedesktop.org and not the sourceforge list. > > -fno-builtin-memcmp is added to CFLAGS inside a block that checks if > the compiler is gcc: > > dnl Add flags for gcc and g++ > if test "x$GCC" = xyes; then > ... > CFLAGS_FOR_BUILD="$CFLAGS_FOR_BUILD -fno-builtin-memcmp" > CFLAGS="$CFLAGS -fno-builtin-memcmp" > ... > fi YUPP, I had a look at configure.ac and other files. For clang -fno-builtin-memcmp is added to compiler-flags anyway and flooded my build-log. Dunno, how to fix it... - Sedat -
[PATCH] udl: zero out struct fb_deferred_io on allocation
Ensure all fields of the struct fb_deferred_io are zeroed out on init,
otherwise the fbdefio->first_io function pointer can contain garbage,
and fb_deferred_io_mkwrite() will end up jumping to this garbage address.
Signed-off-by: Nickolai Zeldovich
---
drivers/gpu/drm/udl/udl_fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d4ab3be..40503ba 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -301,7 +301,7 @@ static int udl_fb_open(struct fb_info *info, int user)
struct fb_deferred_io *fbdefio;
- fbdefio = kmalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
+ fbdefio = kzalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
if (fbdefio) {
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
--
1.7.10.4
