CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #9 from Alexandre Demers 2012-01-27
21:59:44 PST ---
Here is why I thought the bug was fixed: for another reason, I booted with a
3.2 kernel instead of a 3.3-rc1. The bugs is not visible under kernel 3.2, but
is under 3.3-rc1 since t
https://bugzilla.kernel.org/show_bug.cgi?id=42672
Summary: Nouveau. Screen corruption and occasional gpu lockup
Product: Drivers
Version: 2.5
Kernel Version: 3.2.2
Platform: All
OS/Version: Linux
Tree: Mainline
Status
Both the suspend and resume functions incorrectly set psbfb =
to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
this by moving the assignment of psbfb inside the loop and removing the
initialisation of fb.
Signed-off-by: Ryan Mallon
---
diff --git a/drivers/gpu/drm/gma500/fra
The assignment of handle in vmw_framebuffer_create_handle doesn't
actually do anything useful and is incorrectly assigning an integer
value to a pointer argument. It appears that this is a typo and should
be dereferencing handle rather than assigning to it directly.
Signed-off-by: Ryan Mallon
---
On Fri, Jan 27, 2012 at 03:13:28PM +0530, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction for both map and unmap operations.
>
> Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
> a parameter.
>
> Repo
On 01/27/2012 07:25 AM, Ryan Mallon wrote:
> The assignment of handle in vmw_framebuffer_create_handle doesn't
> actually do anything useful and is incorrectly assigning an integer
> value to a pointer argument. It appears that this is a typo and should
> be dereferencing handle rather than assigni
On 01/27/2012 03:41 PM, Jakob Bornecrantz wrote:
> - Original Message -
>> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
>>> I was asking around and this seems to only be used by X when it
>>> starts and we want to preserve the contents of the screen. That
>>> feature is implemented by t
(resend: spot the difference - git url not bullshit!!)
>
> Hi Linus,
>
> This contains mainly a bunch of intel fixes, mainly fixing up the missing
> irq problems on Ivybridge, a set of exynos fixes, one gma500 and one agp.
>
> Thanks,
> Dave.
>
The following changes since commit 9f1feed2e166
Hi Linus,
This contains mainly a bunch of intel fixes, mainly fixing up the missing
irq problems on Ivybridge, a set of exynos fixes, one gma500 and one agp.
Thanks,
Dave.
The following changes since commit 9f1feed2e16652a6e599ed4a73b4c501bb3d4568:
drm/ttm: fix two regressions since move_no
https://bugs.freedesktop.org/show_bug.cgi?id=45291
--- Comment #2 from Alex Deucher 2012-01-27 07:29:50 PST
---
Do other modes besides 1920x1080 on the displayport monitor work? E.g.,
xrandr --output DisplayPort-0 --mode 1024x768
etc.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
> I was asking around and this seems to only be used by X when it
> starts and we want to preserve the contents of the screen. That
> feature is implemented by the X driver. So we need to figure how we
> want to solve it.
>
> Either way this fix shou
https://bugs.freedesktop.org/show_bug.cgi?id=45291
Alex Deucher changed:
What|Removed |Added
Attachment #56210|text/x-log |text/plain
mime type|
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
Reported-by: Tomasz Stanislawski
Signed-off-by: Sumit Semwal
---
drivers/base
Ryan,
Thanks for pointing this out. Unfortunately there seems to be two bugs
here, the one you pointed out and the fact that we set the handle to zero,
when it probably should be set to struct vmw_framebuffer::user_handle.
Jakob, can you comment on this?
/Thomas
On 01/27/2012 07:25 AM, Ryan M
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction while unmapping.
>
> Thus, the unmap dma_buf_op al
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction while unmapping.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
Reported-by: Tomasz Stanislawski
Signed-off-by: Sumit Semwal
---
drivers/base/Kconfig|2
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel at lists.freedesktop |mesa-dev at
lists.freedesktop.
The assignment of handle in vmw_framebuffer_create_handle doesn't actually do
anything useful and is incorrectly assigning an integer value to a pointer
argument. It appears that this is a typo and should be dereferencing handle
rather than assigning to it directly. This fixes a bug where an und
On -10.01.-28163 20:59, Rafa? Mi?ecki wrote:
> 2012/1/20:
>> From: Alex Deucher
>>
>> We were previously just checking for audio.
> So... Does every hdmi_monitor supports audio? Or should it rather be
> if (drm_detect_monitor_audio(radeon_connector->edid)&&
> drm_detect_hdmi_monitor(radeon_connecto
CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_
Hi, Dave.
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
the branch above is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-fixes
commit-id: 590dfe2f3eee806ee91bef68ba2a6afc1
https://bugzilla.kernel.org/show_bug.cgi?id=42672
Summary: Nouveau. Screen corruption and occasional gpu lockup
Product: Drivers
Version: 2.5
Kernel Version: 3.2.2
Platform: All
OS/Version: Linux
Tree: Mainline
Status
From: Marek Ol??k
v2: agd5f: add strmout CS checking, copy_dw register checking
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking
On Fri, 27 Jan 2012 17:28:24 +1100
Ryan Mallon wrote:
> Both the suspend and resume functions incorrectly set psbfb =
> to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
> this by moving the assignment of psbfb inside the loop and removing the
> initialisation of fb.
>
> Sign
On Wed, Jan 25, 2012 at 08:16:25AM -0800, Keith Packard wrote:
> It is never correct to use intel_crtc->bpp in intel_dp_link_required,
> so instead pass an explicit bpp in to this function. This patch
> only supports 18bpp and 24bpp modes, which means that 10bpc modes will
> be computed incorrectly
From: Marek Ol??k
v2: agd5f: add strmout CS checking, copy_dw register checking
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking
https://bugs.freedesktop.org/show_bug.cgi?id=40034
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
2012/1/20 :
> From: Alex Deucher
>
> We were previously just checking for audio.
So... Does every hdmi_monitor supports audio? Or should it rather be
if (drm_detect_monitor_audio(radeon_connector->edid) &&
drm_detect_hdmi_monitor(radeon_connector->edid))
?
Sorry, I'm not familiar enough with ED
From: Marek Olšák
v2: agd5f: add strmout CS checking, copy_dw register checking
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking
From: Marek Olšák
v2: agd5f: add strmout CS checking, copy_dw register checking
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking
On Fri, Jan 27, 2012 at 03:13:28PM +0530, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction for both map and unmap operations.
>
> Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
> a parameter.
>
> Repo
(resend: spot the difference - git url not bullshit!!)
>
> Hi Linus,
>
> This contains mainly a bunch of intel fixes, mainly fixing up the missing
> irq problems on Ivybridge, a set of exynos fixes, one gma500 and one agp.
>
> Thanks,
> Dave.
>
The following changes since commit 9f1feed2e166
Hi Linus,
This contains mainly a bunch of intel fixes, mainly fixing up the missing
irq problems on Ivybridge, a set of exynos fixes, one gma500 and one agp.
Thanks,
Dave.
The following changes since commit 9f1feed2e16652a6e599ed4a73b4c501bb3d4568:
drm/ttm: fix two regressions since move_no
On 01/27/2012 07:25 AM, Ryan Mallon wrote:
The assignment of handle in vmw_framebuffer_create_handle doesn't
actually do anything useful and is incorrectly assigning an integer
value to a pointer argument. It appears that this is a typo and should
be dereferencing handle rather than assigning to
https://bugs.freedesktop.org/show_bug.cgi?id=45291
--- Comment #2 from Alex Deucher 2012-01-27 07:29:50 PST ---
Do other modes besides 1920x1080 on the displayport monitor work? E.g.,
xrandr --output DisplayPort-0 --mode 1024x768
etc.
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=45291
Alex Deucher changed:
What|Removed |Added
Attachment #56210|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
- Original Message -
> On 01/27/2012 03:41 PM, Jakob Bornecrantz wrote:
> > - Original Message -
> >> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
> >>> I was asking around and this seems to only be used by X when it
> >>> starts and we want to preserve the contents of the scree
- Original Message -
> On 01/27/2012 03:41 PM, Jakob Bornecrantz wrote:
> > - Original Message -
> >> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
> >>> I was asking around and this seems to only be used by X when it
> >>> starts and we want to preserve the contents of the scree
On 01/27/2012 03:41 PM, Jakob Bornecrantz wrote:
- Original Message -
On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
I was asking around and this seems to only be used by X when it
starts and we want to preserve the contents of the screen. That
feature is implemented by the X driver.
- Original Message -
> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
> > I was asking around and this seems to only be used by X when it
> > starts and we want to preserve the contents of the screen. That
> > feature is implemented by the X driver. So we need to figure how we
> > want to
- Original Message -
> On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
> > I was asking around and this seems to only be used by X when it
> > starts and we want to preserve the contents of the screen. That
> > feature is implemented by the X driver. So we need to figure how we
> > want to
I was asking around and this seems to only be used by X when it
starts and we want to preserve the contents of the screen. That
feature is implemented by the X driver. So we need to figure how we
want to solve it.
Either way this fix should probably go into this RC series, not
sure if we need to s
On 01/27/2012 03:24 PM, Jakob Bornecrantz wrote:
I was asking around and this seems to only be used by X when it
starts and we want to preserve the contents of the screen. That
feature is implemented by the X driver. So we need to figure how we
want to solve it.
Either way this fix should probab
I was asking around and this seems to only be used by X when it
starts and we want to preserve the contents of the screen. That
feature is implemented by the X driver. So we need to figure how we
want to solve it.
Either way this fix should probably go into this RC series, not
sure if we need to s
Ryan,
Thanks for pointing this out. Unfortunately there seems to be two bugs
here, the one you pointed out and the fact that we set the handle to zero,
when it probably should be set to struct vmw_framebuffer::user_handle.
Jakob, can you comment on this?
/Thomas
On 01/27/2012 07:25 AM, Ryan
On -10.01.-28163 20:59, Rafał Miłecki wrote:
2012/1/20:
From: Alex Deucher
We were previously just checking for audio.
So... Does every hdmi_monitor supports audio? Or should it rather be
if (drm_detect_monitor_audio(radeon_connector->edid)&&
drm_detect_hdmi_monitor(radeon_connector->edid))
?
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Bug #: 45292
Summary: Compilation failure on d3d1x state tracker:
?ID3D10Include? has not been declared
Classification: Unclassified
Product: Mesa
Version: git
Platfor
On Fri, 27 Jan 2012 17:28:24 +1100
Ryan Mallon wrote:
> Both the suspend and resume functions incorrectly set psbfb =
> to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
> this by moving the assignment of psbfb inside the loop and removing the
> initialisation of fb.
>
> Sign
https://bugs.freedesktop.org/show_bug.cgi?id=45291
--- Comment #1 from Jon Sturm 2012-01-26 19:29:40 PST
---
Created attachment 56210
--> https://bugs.freedesktop.org/attachment.cgi?id=56210
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=45291
Bug #: 45291
Summary: No video output via DisplayPort on Mobility HD 4670.
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=40034
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, Jan 25, 2012 at 08:16:25AM -0800, Keith Packard wrote:
> It is never correct to use intel_crtc->bpp in intel_dp_link_required,
> so instead pass an explicit bpp in to this function. This patch
> only supports 18bpp and 24bpp modes, which means that 10bpc modes will
> be computed incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #1 from Ian Romanick 2012-01-26 18:02:32
PST ---
It looks like the misrendering was (briefly!) fixed by b2596c3 and broken again
by f24e106 (two commits later).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
Reported-by: Tomasz Stanislawski
Signed-off-by: Sumit Semwal
---
drivers/base
https://bugs.freedesktop.org/show_bug.cgi?id=45290
Bug #: 45290
Summary: [bisected r200] fdo23670-drawpix_stencil fails and
crashes
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
OS/Versi
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction while unmapping.
>
> Thus, the unmap dma_buf_op al
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction while unmapping.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
Reported-by: Tomasz Stanislawski
Signed-off-by: Sumit Semwal
---
drivers/base/Kconfig|2
2012/1/20 :
> From: Alex Deucher
>
> We were previously just checking for audio.
So... Does every hdmi_monitor supports audio? Or should it rather be
if (drm_detect_monitor_audio(radeon_connector->edid) &&
drm_detect_hdmi_monitor(radeon_connector->edid))
?
Sorry, I'm not familiar enough with ED
Both the suspend and resume functions incorrectly set psbfb =
to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
this by moving the assignment of psbfb inside the loop and removing the
initialisation of fb.
Signed-off-by: Ryan Mallon
---
diff --git a/drivers/gpu/drm/gma500/fra
The assignment of handle in vmw_framebuffer_create_handle doesn't
actually do anything useful and is incorrectly assigning an integer
value to a pointer argument. It appears that this is a typo and should
be dereferencing handle rather than assigning to it directly.
Signed-off-by: Ryan Mallon
62 matches
Mail list logo
