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
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
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
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
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 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
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=40034
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 -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))
?
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 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
- 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
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: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
https://bugs.freedesktop.org/show_bug.cgi?id=45292
Alex Deucher changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
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=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
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
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
(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
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
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
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
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_
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
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://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
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
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=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=45292
Bug #: 45292
Summary: Compilation failure on d3d1x state tracker:
?ID3D10Include? has not been declared
Classification: Unclassified
Product: Mesa
Version: git
Platfor
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
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
---
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
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
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
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 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
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=40034
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 -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
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
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
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
- 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
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
- 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
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.
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=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 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
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
(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
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
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
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
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_
62 matches
Mail list logo
