On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner wrote:
> Can I consider this a Reviewed-by?
Essentially it was just a drive-by bikeshed ;-) I think it'd be good
if Maarten takes a look at this and checks whether it complies with
his massive prime/dma_buf rework to use fences and ticketing
reserv
On Fri, 11 Jan 2013, Laurent Pinchart wrote:
> Would anyone be interested in meeting at the FOSDEM to discuss the Common
> Display Framework ? There will be a CDF meeting at the ELC at the end of
> February, the FOSDEM would be a good venue for European developers.
Yes, count me in,
Jani.
On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
Hi
2013/1/16 :
> 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 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula
wrote:
> On Fri, 11 Jan 2013, Laurent Pinchart
> wrote:
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the FOSDEM would be a good ve
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > 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 we must first check whether the display repo
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in
I noticed that bsp, vp and ppp had no interrupt handler after investigating why
15% of my cpu time went to interrupts.
nouveau was silent about it, but it should be an error since we have no way of
acking in that case.
Signed-off-by: Maarten Lankhorst
---
fwiw, the interrupt was 10, the exi
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode
Hi Dave
More important fixes for 3.9:
- error_state improvements to help debug the new scanline wait code added
for gen6+ - bug reports started popping up :( patch from Chris Wilson.
- fix a panel power sequence confusion between the eDP and lvds detection
code resulting in black screens - reg
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
___
dri-devel mailing list
dri-devel@lists.fr
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
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 inforfram
On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
wrote:
> On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
>> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
>>
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #19 from Jerome Glisse ---
Updated patch
http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
Still weird that you point to same commit and first patch did not solve it.
--
You are
On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=59521
Priority: medium
Bug ID: 59521
Assignee: dri-devel@lists.freedesktop.org
Summary: [Serious Sam 3] Missing textures with R600g
Severity: normal
Classification: Unclassified
OS
https://bugs.freedesktop.org/show_bug.cgi?id=59521
--- Comment #1 from Alex Deucher ---
If the game uses compressed textures, make sure you have libtxc-dxtn installed.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=59521
--- Comment #2 from Laurent carlier ---
Of course, lib32-libtxc_dxtn is installed:
$ pacman -Qs lib32-libtxc_dxtn
local/lib32-libtxc_dxtn 1.0.1-3
Texture compression library for Mesa (32-bit)
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #38 from Thomas Rohloff ---
(In reply to comment #37)
> This patch might help:
I applied it to a 3.8-rc3 kernel and while I didn't see the message spam till
now the GPU crashes extremely often (so often that this might be the case I'
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #7 from Roland Scheidegger ---
Looks to me like the offsets for the stipple pattern are wrong.
These are set in r200UpdateViewportOffset - which has no callers. I noted this
in bug 57842, and tried to address it there though the patch
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
wrote:
> On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
>> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>>
From: Alex Deucher
1440x900 (native) monitor contains a bogus 1400x1050@75Hz
mode in the standard timings and fails to flag the first
detailed mode as preferred. As such, X picks 1400x1050@75Hz
which fails to display.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=59211
Signed-off-by: Ale
On 2013.01.17 at 12:55 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote
From: Michel Dänzer
Very similar to Evergreen, but slightly different rules for tile / slice
alignment. Fortunately, these map quite naturally onto the previous fixes for
linear aligned layout on SI.
2D tiling still needs more work here and possibly in the kernel.
Signed-off-by: Michel Dänzer
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #8 from smoki ---
I was tested your patch from bug 57842 when you posted it there, but as i
remember many random mesa demos i tried started to segfault with it.
--
You are receiving this mail because:
You are the assignee for the b
On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> Actually, the code path affected by your patch is not executed in UMS mode
> at all. Notice that radeon_cs_parser_fini is only called from
> radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
>
> The equivalent of the fix you ar
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
wrote:
> On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
>> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>>
One more fix on top. Just a revert of the bo placement patch that has
been causing corruption for a number of people.
Revert "drm/radeon: do not move bo to different placement at each cs"
This reverts commit d025e9e2b890db679f1246037bf65bd4be512627.
This causes corruption for a numb
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #39 from Alexandre Demers ---
(In reply to comment #38)
> (In reply to comment #37)
> > This patch might help:
>
> I applied it to a 3.8-rc3 kernel and while I didn't see the message spam
> till now the GPU crashes extremely often (s
On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #9 from smoki ---
Created attachment 73194
--> https://bugs.freedesktop.org/attachment.cgi?id=73194&action=edit
ums and mesa 7.5.2 r200 render
But overal, it is not quite correct but polys renders better now then it was
with UMS.
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #20 from Bryan Quigley ---
This last patch (0001-drm-radeon-exclude-system-placement-when-validating)
creates a full Xorg freeze:
Form xorg.log:
[ 207.780] (WW) RADEON(0): flip queue failed: Invalid argument
[ 207.781] (WW) RADEON
This might be responsible for the bad r300g MSAA performance results
on Phoronix. I have no other explanation.
There is an optimization in r300g which forces the VRAM domain for
non-staging CB and DB only. Other than that, VRAM|GTT is the default
for all textures and GTT is the default for all buf
https://bugzilla.kernel.org/show_bug.cgi?id=52491
--- Comment #15 from Bruno Jacquet 2013-01-17 19:26:36 ---
(In reply to comment #14)
> Better to try this patch instead first :
> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
With this
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #40 from Thomas Rohloff ---
(In reply to comment #39)
> Does it do the same thing without the patch?
It has random crashes without, too, yes. But way less frequent. In fact I had
to revert that patch to be able to use my desktop for
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 vi
On Fri, Jan 11, 2013 at 09:27:03PM +0100, Laurent Pinchart wrote:
> Would anyone be interested in meeting at the FOSDEM to discuss the Common
> Display Framework ? There will be a CDF meeting at the ELC at the end of
> February, the FOSDEM would be a good venue for European developers.
We are in
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #8 from Chris Rankin ---
Still broken as of git HEAD:
commit ca39c0f94a4e3cc25b6cc9507fb729b85140733a
Author: Ian Romanick
Date: Wed Jan 16 15:34:49 2013 -0800
mesa/es3: Don't check dimensions in _mesa_es3_error_check_format_
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #9 from Marek Olšák ---
Could you please attach a screenshot showing the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #10 from Chris Rankin ---
(In reply to comment #9)
> Could you please attach a screenshot showing the issue?
Sorry, the corruption is not showing up which I press the "Print Screen"
button. I shall attempt to describe instead:
Imagi
On 01/17/2013 02:14 PM, Sedat Dilek wrote:
Hi
I am playing again with llvm/clang v3.2 and patches I adapted from
LLVMLinux project.
I wanted to test my new toolchain before doing a rough testing of the
mainline Linux-kernel.
I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise
AM
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
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 co
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 b
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Upstream commit-id: a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e
Tested on stable 3.7
Hi
I am playing again with llvm/clang v3.2 and patches I adapted from
LLVMLinux project.
I wanted to test my new toolchain before doing a rough testing of the
mainline Linux-kernel.
I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise
AMD64 here by making me and my build-deps happy
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=
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 regist
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.
__
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.
__
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.
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.
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_
https://bugs.freedesktop.org/show_bug.cgi?id=59492
smoki changed:
What|Removed |Added
Attachment #73223|text/plain |image/png
mime type|
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
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 h
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
head: bef8f38486aaeef0818d0b79c797b0d6bbb1ce06
commit: 3f43d56a721d4f2ed29218bb365edc7a2b5a7a25 [150/152] Merge
remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly
config: x86_64-allyesdebian (attache
On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote:
> >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote:
> >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrot
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/37aa5577/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=52491
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/74c00f48/attachment.html>
dri-devel/attachments/20130117/dc247a23/attachment.html>
h.
--
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/20130117/4317e866/attachment.html>
ing the patched module dmesg | grep
TITITOTO
should tell you if it's the case.
--
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/attach
eedesktop.org/archives/dri-devel/attachments/20130117/b6961e8a/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/b74c59e7/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/a27371e9/attachment.html>
report.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/f4fc2342/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/785e88ea/attachment-0001.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4cf8dfd4/attachment.html>
On 01/16/2013 07:53 PM, Lucas Stach wrote:
> Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang:
>> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
>> doesn't work(LVDS only is OK). I'll let you know if I get something.
>>
> Just to provide another data point: I'm runnin
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4d08701d/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/0a72a81e/attachment.html>
On 01/15/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case easily be implemented on top.
>
> Signed-off-by: Thierry Reding
[...]
> +
> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_f
On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner
wrote:
> Can I consider this a Reviewed-by?
Essentially it was just a drive-by bikeshed ;-) I think it'd be good
if Maarten takes a look at this and checks whether it complies with
his massive prime/dma_buf rework to use fences and ticketing
reser
On Fri, 11 Jan 2013, Laurent Pinchart
wrote:
> Would anyone be interested in meeting at the FOSDEM to discuss the Common
> Display Framework ? There will be a CDF meeting at the ELC at the end of
> February, the FOSDEM would be a good venue for European developers.
Yes, count me in,
Jani.
On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
Hi
2013/1/16 :
> 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 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula
wrote:
> On Fri, 11 Jan 2013, Laurent Pinchart
> wrote:
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the FOSDEM would be a good ve
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > 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 we must first check whether the display repo
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in
I noticed that bsp, vp and ppp had no interrupt handler after investigating why
15% of my cpu time went to interrupts.
nouveau was silent about it, but it should be an error since we have no way of
acking in that case.
Signed-off-by: Maarten Lankhorst
---
fwiw, the interrupt was 10, the exi
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode
Hi Dave
More important fixes for 3.9:
- error_state improvements to help debug the new scanline wait code added
for gen6+ - bug reports started popping up :( patch from Chris Wilson.
- fix a panel power sequence confusion between the eDP and lvds detection
code resulting in black screens - reg
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
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 inforfram
On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
wrote:
> On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
>> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
>>
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/20130117/77c82471/attachment.html>
On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/546d8237/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/d25e29cc/attachment.html>
1 - 100 of 127 matches
Mail list logo
