2013/3/3 Rob Clark :
> On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote:
>> Actually, we have already implemented the EXA part of X server and
>> that has being used on our linux platform. But I think we could more
>> improvement this. So are you writting user side g2d drivers for Chrome
>> book(bas
On Tue, Mar 05, 2013 at 10:07:36PM +0100, Paul Bolle wrote:
> Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic
> HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
> Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
> statement for that
qxl wants to use io mapping like i915 gem does, for now
just export the symbols so the driver can implement atomic
page maps using io mapping.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +
include/drm/ttm/ttm_bo_driver.h | 4
2 files changed, 13 ins
Hi,
This is a KMS driver for the QXL virtual hw device shipped in qemu.
The first patch just adds some ttm symbol exports, the second contains
the driver.
Its also in my git repo here
http://cgit.freedesktop.org/~airlied/linux/log/?h=qxl-upstream
The userspace driver is here
http://cgit.freedes
Calculate the correct address offset values for alpha and color key
control registers and clear size control register for window 0
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
From: Randy Dunlap
Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to
kernel-doc to match the rest of the file's documentation.
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for p
On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote:
> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote:
>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher wrote:
>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote:
On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher
wrote:
> ca5
On 03/05/2013 11:08:16 AM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to
> kernel-doc to match the rest of the file's documentation.
I've been feeding this stuff through trivial at kernel.org. (I just got my
kernel.org account re-
Hi
On Tue, Mar 5, 2013 at 5:47 PM, Joonyoung Shim wrote:
> On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote:
>>
>> Hi,
>>
>> On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim
>> wrote:
>>>
>>> Hi Leela,
>>>
>>>
>>> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
Calculate the corr
Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.
What was needed to use HDMI functionality
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/20130305/7701a6b9/attachment.html>
On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote:
> Hi,
>
> On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim
> wrote:
>> Hi Leela,
>>
>>
>> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
>>> Calculate the correct address offset values for alpha and color key
>>> control registers
>>>
>>> S
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130305/1fbb94ab/attachment.html>
Hi Leela,
On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
> Calculate the correct address offset values for alpha and color key
> control registers
>
> Signed-off-by: Leela Krishna Amudala
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 +
> 1 file changed, 5 insertions(+), 4
On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson :
> > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
> >> wrote:
> >> > Hi,
> >> >
> >> > I am seeing this also on Linux-Next.
> >> >
> >> > /va
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro
> > horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
https://bugzilla.kernel.org/show_bug.cgi?id=52121
--- Comment #21 from Konrad Rzeszutek Wilk
2013-03-05 20:16:12 ---
Well not forever. Daniel (lets see if I can add him on this bug) is looking at
getting the EFI parts working.
The VGA part is on the list but we haven't yet touched it.
--
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DS
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of
These are misc fixes and improvements within omapdrm. There is one minor
omapdss fix here too, we get problems in omapdrm without it. The fixes do the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that omapdrm is functional for OMAP platfor
On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote:
> modeset_init iterates through all the registered omapdss devices and has some
> initial checks to see if the panel has a driver and the required driver ops
> for
> it to be usable by omapdrm.
>
> The function bails out from modeset_init if a
s 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/20130305/6e9362e7/attachment.html>
Hi,
2013-01-18 13:04 keltez?ssel, Christian K?nig ?rta:
> 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 HD
https://bugs.freedesktop.org/show_bug.cgi?id=61419
Alexandre Demers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote:
> nv50_vblank_enable/disable got switched from
> NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is
> wrong.
>
> 4 << head is the correct value.
>
> Fixes regression with vblanking since 1d7c71a3e2f77 "drm/
Hi Daniel Vetter,
I'm working on touch devices Chromium OS, and I've noticed a
regression between 3.8 and 3.9-rc1, which was posted yesterday.
The hardware in question is a Chromebook Pixel. For this device, we
have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s
touchscreen. The tou
Hi Daniel Vetter,
I'm working on touch devices Chromium OS, and I've noticed a
regression between 3.8 and 3.9-rc1, which was posted yesterday.
The hardware in question is a Chromebook Pixel. For this device, we
have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s
touchscreen. The tou
https://bugs.freedesktop.org/show_bug.cgi?id=61883
Priority: medium
Bug ID: 61883
Assignee: dri-devel@lists.freedesktop.org
Summary: wine shader_generate_glsl_declarations fail
Severity: normal
Classification: Unclassified
OS
Hi,
On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim
wrote:
> Hi Leela,
>
>
> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
>>
>> Calculate the correct address offset values for alpha and color key
>> control registers
>>
>> Signed-off-by: Leela Krishna Amudala
>> ---
>> drivers/gpu/drm/
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
> New -rc1, so let the stabilization games begin.
>
> I see the following on rc1, let me kno
On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote:
> modeset_init iterates through all the registered omapdss devices and has some
> initial checks to see if the panel has a driver and the required driver ops
> for
> it to be usable by omapdrm.
>
> The function bails out from modeset_init if a
On 03/05/2013 11:41 AM, Daniel Vetter wrote:
> against DRI -> DRM(Intel) and attach the files there together with
> your quick description of the regression above.
>
> Thanks, Daniel
np :
https://bugs.freedesktop.org/show_bug.cgi?id=61861
--
MfG/Sincerely
Toralf F?rster
pgp finger print: 7B1A
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130305/90695a7a/attachment.html>
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
...
linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
Maybe get_maintainer.pl patterns ne
nv50_vblank_enable/disable got switched from
NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is wrong.
4 << head is the correct value.
Fixes regression with vblanking since 1d7c71a3e2f77 "drm/nouveau/disp: port
vblank handling to event interface"
Signed-off-by: Maarten La
https://bugzilla.kernel.org/show_bug.cgi?id=52491
Bruno Jacquet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
While using chrome, I got the following. It was able to render the bug
to the screen, so at least something was working (and it also made it
to my logs).
[223614.867297] BUG: unable to handle kernel paging request at c90013a0
[223614.867372] IP: [] iowrite32+0x12/0x33
[223614.867427] PGD 1
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #157 from Trey Ramsay ---
In regards to comment 145, is it recommended to use SNA? We are not using SNA
and have seen GPU hangs on the 845G. Is it better to use SNA and apply the
SNA patch to xorg-x11-drv-intel?
--
You are recei
Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.
What was needed to use HDMI functionality
https://bugs.freedesktop.org/show_bug.cgi?id=61690
LukK changed:
What|Removed |Added
Version|9.1 |9.0
--- Comment #5 from LukK ---
OK, bisected.
My nv96 claims to have a DCB_OUTPUT_TV, which is currently not implemented for
nv50, this triggers the following oops:
[ 30.110017] nouveau W[ DRM] failed to create encoder 0/1/0: -19
[ 30.110020] nouveau W[ DRM] TV-1 has no encoders, removing
[ 30.134089] BUG: unable to handle kern
https://bugzilla.kernel.org/show_bug.cgi?id=52121
--- Comment #21 from Konrad Rzeszutek Wilk 2013-03-05
20:16:12 ---
Well not forever. Daniel (lets see if I can add him on this bug) is looking at
getting the EFI parts working.
The VGA part is on the list but we haven't yet touched it.
--
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130305/36572fa6/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nv40-therm-improve-selection-between-the-old-and.patch
Type: text/x-patch
Size: 30
On Mon, Mar 4, 2013 at 10:47 PM, Toralf F?rster
wrote:
> It is a (small) regression to 3.7.10 with intel integrated graphics i915
> - but nevertheless :
>
> With an external VGA display (1680x1050) and a closed internal LVDS1
> display (1440x900) the external display starts X11 with 1440x900 - fo
While using chrome, I got the following. It was able to render the bug
to the screen, so at least something was working (and it also made it
to my logs).
[223614.867297] BUG: unable to handle kernel paging request at c90013a0
[223614.867372] IP: [] iowrite32+0x12/0x33
[223614.867427] PGD 1
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #42 from Alexandre Demers ---
(In reply to comment #41)
> Just as information: I just built 3.9-rc1 and the corruption is still
> present and looking exactly the same.
Same here, tested yesterday.
--
You are receiving this mail bec
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro
> > horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
Hi,
2013-01-18 13:04 keltezéssel, Christian König írta:
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.
On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer wrote:
> On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote:
>> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote:
>>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher
>>> wrote:
On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote:
> On Thu, Fe
On Tue, Mar 05, 2013 at 12:13:57PM +0100, Martin Peres wrote:
> On 04/03/2013 22:41, Konrad Rzeszutek Wilk wrote:
> >Pls CC me in case you would like me also to test them with the
> >mdelay patch.
>
> Hi Konrad,
>
> Marcin proposed me another explanation for the issue you are seeing
> and it made
On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson :
> > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
> >> wrote:
> >> > Hi,
> >> >
> >> > I am seeing this also on Linux-Next.
> >> >
> >> > /va
Hi!
On Wed, Feb 27, 2013 at 06:13:49PM +0200, Tomi Valkeinen wrote:
> On 2013-02-27 18:05, Steffen Trumtrar wrote:
> > Ah, sorry. Forgot to answer this.
> >
> > On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
> >> Ping.
> >>
> >> On 2013-02-18 16:09, Tomi Valkeinen wrote:
> >>> Hi
ANGE_16_235;
else
intel_sdvo->color_range = 0;
}
-- 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/20130305/230b0145/attachment-0001.pgp>
On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote:
> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote:
>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher
>> wrote:
>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote:
On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher
wrote:
>
On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote:
> nv50_vblank_enable/disable got switched from
> NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is
> wrong.
>
> 4 << head is the correct value.
>
> Fixes regression with vblanking since 1d7c71a3e2f77 "drm/
From: Randy Dunlap
Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to
kernel-doc to match the rest of the file's documentation.
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for p
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
> New -rc1, so let the stabilization games begin.
>
> I see the following on rc1, let me kno
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #41 from Jakob Nixdorf ---
Just as information: I just built 3.9-rc1 and the corruption is still present
and looking exactly the same.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer wrote:
> On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote:
>> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote:
>>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher
>>> wrote:
On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote:
> On Thu, Fe
On 03/05/2013 11:41 AM, Daniel Vetter wrote:
> against DRI -> DRM(Intel) and attach the files there together with
> your quick description of the regression above.
>
> Thanks, Daniel
np :
https://bugs.freedesktop.org/show_bug.cgi?id=61861
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A
https://bugzilla.kernel.org/show_bug.cgi?id=52491
Bruno Jacquet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can
Calculate the correct address offset values for alpha and color key
control registers
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DS
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of
These are misc fixes and improvements within omapdrm. There is one minor
omapdss fix here too, we get problems in omapdrm without it. The fixes do the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that omapdrm is functional for OMAP platfor
nv50_vblank_enable/disable got switched from
NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is wrong.
4 << head is the correct value.
Fixes regression with vblanking since 1d7c71a3e2f77 "drm/nouveau/disp: port
vblank handling to event interface"
Signed-off-by: Maarten La
On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote:
Hi,
On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim wrote:
Hi Leela,
On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
Calculate the correct address offset values for alpha and color key
control registers
Signed-off-by: Leela Krishna A
Hi,
On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim wrote:
> Hi Leela,
>
>
> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
>>
>> Calculate the correct address offset values for alpha and color key
>> control registers
>>
>> Signed-off-by: Leela Krishna Amudala
>> ---
>> drivers/gpu/drm/e
My nv96 claims to have a DCB_OUTPUT_TV, which is currently not implemented for
nv50, this triggers the following oops:
[ 30.110017] nouveau W[ DRM] failed to create encoder 0/1/0: -19
[ 30.110020] nouveau W[ DRM] TV-1 has no encoders, removing
[ 30.134089] BUG: unable to handle kern
Hi Leela,
On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:
Calculate the correct address offset values for alpha and color key
control registers
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(
On 04/03/2013 22:41, Konrad Rzeszutek Wilk wrote:
Pls CC me in case you would like me also to test them with the mdelay
patch.
Hi Konrad,
Marcin proposed me another explanation for the issue you are seeing and
it made me look again at the code.
I don't have enough nv4x hw to test all the c
Calculate the correct address offset values for alpha and color key
control registers
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers
On Mon, Mar 4, 2013 at 10:47 PM, Toralf Förster wrote:
> It is a (small) regression to 3.7.10 with intel integrated graphics i915
> - but nevertheless :
>
> With an external VGA display (1680x1050) and a closed internal LVDS1
> display (1440x900) the external display starts X11 with 1440x900 - for
Hi!
On Wed, Feb 27, 2013 at 06:13:49PM +0200, Tomi Valkeinen wrote:
> On 2013-02-27 18:05, Steffen Trumtrar wrote:
> > Ah, sorry. Forgot to answer this.
> >
> > On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
> >> Ping.
> >>
> >> On 2013-02-18 16:09, Tomi Valkeinen wrote:
> >>> Hi
On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrj?l? wrote:
> On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote:
> > Hi
> >
> > 2013/2/25 Rodrigo Vivi :
> > > PSR is an eDP feature that allows power saving even with static image at
> > > eDP screen.
> > >
> > > v3: Accepted many sug
81 matches
Mail list logo
