Hi, Dave.
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Saturday, October 01, 2011 3:07 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> kyungmin.p...@samsung.com
> Subject: Re: [RESEND] An inquiry about DRM Driver for Samsung SoC E
>
> You can refer to these patches I sent from links below.
> v1: < https://lwn.net/Articles/454380/ >
> v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
> v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >
> v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >
>
Hi, Dave.
I am very sorry for html type used before so I am re-sending this e-mail. I
wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC
Exynos4210 a week ago but we have not received any comments from you.
You can refer to these patches I sent from links below.
v1: < htt
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #23 from Benoit Jacob 2011-09-30 21:22:05 PDT
---
(In reply to comment #22)
> Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
> allocation size 2 bytes, which is broken.
This sounds like something that
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #23 from Benoit Jacob 2011-09-30 21:22:05
PDT ---
(In reply to comment #22)
> Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
> allocation size 2 bytes, which is broken.
This sounds like something that
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #22 from Nicholas Miell 2011-09-30 21:08:50 PDT
---
Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
allocation size 2 bytes, which is broken.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #22 from Nicholas Miell 2011-09-30 21:08:50
PDT ---
Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
allocation size 2 bytes, which is broken.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
On Thu, Sep 29, 2011 at 06:09:53PM -0700, Keith Packard wrote:
> If the panel is powered up, there's no need to delay for the 'off'
> interval when turning the panel on.
>
> Signed-off-by: Keith Packard
I'll hold off carefully checking this one until the previous patches
settle. Especially when
On Thu, Sep 29, 2011 at 06:09:52PM -0700, Keith Packard wrote:
> This eliminates a fairly long delay when power sequencing newer
> hardware
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
On Thu, Sep 29, 2011 at 06:09:51PM -0700, Keith Packard wrote:
> Using the same basic plan as the VDD force delayed power off, make
> turning the panel power off asynchronous.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 71
> +
On Thu, Sep 29, 2011 at 06:09:50PM -0700, Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then re
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #21 from Nicholas Miell 2011-09-30 20:45:37 PDT
---
It isn't a bug, it is a perfectly valid and entirely safe optimization.
Valgrind supplies its own overrides for the string functions that don't do this
optimization specifically to
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #21 from Nicholas Miell 2011-09-30 20:45:37
PDT ---
It isn't a bug, it is a perfectly valid and entirely safe optimization.
Valgrind supplies its own overrides for the string functions that don't do this
optimization specifically to
On Fri, 30 Sep 2011 20:16:44 +0200, Daniel Vetter wrote:
> Awesome patch description and the code agrees with what I've cross-checked
> on bspec. The only fear I have is that we currently ignore the backlight
> on/off timings and some panel probably relies on use waiting for backlight
> on/off +
doesn't impact the source at all.
Ok, so a bit more whacking of code and I'll post an updated patch that
uses all of these values as above.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/p
On Thu, Sep 29, 2011 at 06:09:49PM -0700, Keith Packard wrote:
> We need to check eDP VDD force and panel on in several places, so
> create some simple helper functions to avoid duplicating code.
>
> Signed-off-by: Keith Packard
Ah, here's the code that kills my "... instead of re-reading PP_CON
On Thu, Sep 29, 2011 at 06:09:48PM -0700, Keith Packard wrote:
> The return value was unused, so just stop doing that.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
On Thu, Sep 29, 2011 at 06:09:47PM -0700, Keith Packard wrote:
> This value doesn't come directly from the VBT, and so is rather
> specific to the particular DP output.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 5
On Thu, Sep 29, 2011 at 06:09:46PM -0700, Keith Packard wrote:
> Store the panel power sequencing delays in the dp private structure,
> rather than the global device structure. Who knows, maybe we'll get
> more than one eDP device in the future.
>
> Look at both the current hardware register setti
On Fri, Sep 30, 2011 at 11:01:06AM -0700, Keith Packard wrote:
> Should I bother to include this patch in the series at all? It's purely
> for diagnostics to make sure the panel is powered during all aux channel
> transactions.
I'd say yes, imo paranoia in modesetting code is justified ;-)
-Daniel
On Fri, Sep 30, 2011 at 07:58:21PM +0200, Daniel Vetter wrote:
> On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote:
> > On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter
> > wrote:
> >
> > > Can you elaborate a bit why this is no longer needed? Jesse seems to have
> > > introduced th
On Thu, Sep 29, 2011 at 06:09:45PM -0700, Keith Packard wrote:
> This ensures that the panel power sequencing is complete before
> attempting to communicate over the aux channel.
>
> Signed-off-by: Keith Packard
Looks like a patch useful for fixing up this mess, but I don't quite see
the point of
On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter wrote:
>
> > Can you elaborate a bit why this is no longer needed? Jesse seems to have
> > introduced this spefically for edp panels in d209848d61794968. If this
> > becomes rendunda
On Fri, Sep 30, 2011 at 10:44:22AM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 18:20:48 +0200, Daniel Vetter wrote:
>
> > Shouldn't we mask/ack south DE irqs before before we mask DE irqs to avoid
> > races, i.e. move this new code up?
>
> I don't know. What about the GT interrupts? I jus
On Thu, Sep 29, 2011 at 06:09:44PM -0700, Keith Packard wrote:
> Any call to intel_dp_sink_dpms must ensure that the panel has power so
> that the DP_SET_POWER operation will be correctly received. The only
> one missing this was in intel_dp_prepare.
>
> Signed-off-by: Keith Packard
If I understa
On Thu, Sep 29, 2011 at 06:09:42PM -0700, Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Dan
On Thu, Sep 29, 2011 at 06:09:43PM -0700, Keith Packard wrote:
> The DP i2c initialization code does a couple of i2c transactions,
> which means that an eDP panel must be powered up.
>
> Signed-off-by: Keith Packard
Ah, here's the code I've been looking for when reviewing patch 9.
Reviewed-by: D
On Thu, Sep 29, 2011 at 06:09:41PM -0700, Keith Packard wrote:
> On eDP, DDC requires panel power, but turning that on uses the panel
> power sequencing timing values fetch from the DPCD data.
>
> Signed-off-by: Keith Packard
Can't really check more than what the patch does what it claims to do,
On Fri, 30 Sep 2011 11:01:06 -0700, Keith Packard wrote:
Non-text part: multipart/signed
> On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote:
>
> > Use pp_control instead of re-reading?
>
> Could, but you'll note a later patch eliminates both pp_status and
> pp_control local variables, so
On Thu, Sep 29, 2011 at 06:09:40PM -0700, Keith Packard wrote:
> The VDD force bit is turned on before touching the panel, but if it
> was enabled, there was no call to turn it back off. Add a call.
>
> Signed-off-by: Keith Packard
Nice catch of in inbalanced on/off.
Reviewed-by: Daniel Vetter
-
On Thu, Sep 29, 2011 at 06:09:39PM -0700, Keith Packard wrote:
> Cleans up code dealing with eDP VDD a bit. Remove redundant checks in
> callers
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 20 ++--
> 1 files changed, 10 insertions(+), 10 deletion
On Thu, Sep 29, 2011 at 06:09:38PM -0700, Keith Packard wrote:
> Avoid any question about locked registers by just writing the unlock
> pattern with every write to the register.
>
> Signed-off-by: Keith Packard
grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
dpms functions
On Thu, Sep 29, 2011 at 06:09:37PM -0700, Keith Packard wrote:
> Verify that the eDP VDD is on, either with the panel being on or with
> the VDD force-on bit being set.
>
> This demonstrates that in many instances, VDD is not on when needed,
> which leads to failed EDID communications.
>
> Signed
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #4 from Michael Lothian 2011-09-30 18:49:01
PDT ---
I start smplayer with LD_LIBRARY_PATH=/usr/lib/vdpau VDPAU_DRIVER=r600 smplayer
If there is anything else I can provide to help debug this please let me know
the sample mpeg video
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #4 from Michael Lothian 2011-09-30
18:49:01 PDT ---
I start smplayer with LD_LIBRARY_PATH=/usr/lib/vdpau VDPAU_DRIVER=r600 smplayer
If there is anything else I can provide to help debug this please let me know
the sample mpeg video
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #3 from Michael Lothian 2011-09-30 18:43:54
PDT ---
Created an attachment (id=51831)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51831)
Screen shot of garbled picture
--
Configure bugmail: https://bugs.freedesktop.org/user
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #3 from Michael Lothian 2011-09-30
18:43:54 PDT ---
Created an attachment (id=51831)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51831)
Screen shot of garbled picture
--
Configure bugmail: https://bugs.freedesktop.org/user
mainline.
Thanks,
Inki Dae.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/5b6dca18/attachment.htm>
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #2 from Michael Lothian 2011-09-30 18:41:17
PDT ---
Created an attachment (id=51829)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51829)
mplayer2 log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #1 from Michael Lothian 2011-09-30 18:40:52
PDT ---
Created an attachment (id=51828)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51828)
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #2 from Michael Lothian 2011-09-30
18:41:17 PDT ---
Created an attachment (id=51829)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51829)
mplayer2 log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #1 from Michael Lothian 2011-09-30
18:40:52 PDT ---
Created an attachment (id=51828)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51828)
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41375
Summary: VDPAU not working on RS880
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41375
Summary: VDPAU not working on RS880
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
be applied to mainline.
Thanks,
Inki Dae.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/946a407d/attachment.html>
On Thu, Sep 29, 2011 at 06:09:36PM -0700, Keith Packard wrote:
> We're going to assume that EDID is more reliable than the VBT tables
> for eDP panels, which is notably true on MacBook machines where the
> VBT contains completely bogus data.
>
> Signed-off-by: Keith Packard
Ok, this is way over m
On Thu, Sep 29, 2011 at 06:09:35PM -0700, Keith Packard wrote:
> There's no reason to enforce a 300ms delay during eDP mode setting.
>
> Signed-off-by: Keith Packard
Can you elaborate a bit why this is no longer needed? Jesse seems to have
introduced this spefically for edp panels in d209848d617
On Thu, Sep 29, 2011 at 06:09:34PM -0700, Keith Packard wrote:
> This masks out all interrupts and ack's any pending ones at IRQ
> uninstall time to make sure we don't receive any unexpected interrupts
> later on.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/i915_irq.c |4 ++
On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote:
> We were relying on the BIOS to set these bits, which doesn't always
> happen.
>
> Signed-off-by: Keith Packard
Ok, I'll try to increase our review-bandwidth for modesetting stuff by
jumping into this maze myself. For the moment I'l
https://bugs.freedesktop.org/show_bug.cgi?id=41373
--- Comment #1 from Boram Park 2011-09-30 17:32:09
PDT ---
Created an attachment (id=51824)
View: https://bugs.freedesktop.org/attachment.cgi?id=51824
Review: https://bugs.freedesktop.org/review?bug=41373&attachment=51824
another patch for me
https://bugs.freedesktop.org/show_bug.cgi?id=41373
--- Comment #1 from Boram Park 2011-09-30
17:32:09 PDT ---
Created an attachment (id=51824)
View: https://bugs.freedesktop.org/attachment.cgi?id=51824
Review: https://bugs.freedesktop.org/review?bug=41373&attachment=51824
another patch for me
From: Michel D?nzer
Apart from the obvious cleanup, this should make the line
cursor_end = x - xorigin + w;
correct now.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletion
From: Michel D?nzer
Fixes cursor disappearing prematurely when moving off a top/left edge which
is not located at the desktop top/left edge.
Signed-off-by: Michel D?nzer
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_cursor.c | 12 +++-
1 files changed, 7 insertions(+), 5
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_cursor.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index c495575..bac8ee7 100644
--- a/drive
While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
potential bug fixed by patch 3) and opportunities for cleanup.
Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch
along
On 09/30/2011 08:16 AM, Michel Dänzer wrote:
> While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
> off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
> potential bug fixed by patch 3) and opportunities for cleanup.
>
> Patch 1 is based on Nicholas
On 09/30/2011 08:16 AM, Michel D?nzer wrote:
> While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
> off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
> potential bug fixed by patch 3) and opportunities for cleanup.
>
> Patch 1 is based on Nicholas
On Fri, 30 Sep 2011 19:09:46 +0200, Daniel Vetter wrote:
> grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
> dpms functions - any reasons these two writes are left out?
Upon a bit of review:
The bspec makes it clear that this write protect key only needs to
be written
e: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0630fac5/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #18 from Martin Stolpe 2011-09-30 16:07:30
PDT ---
Hello,
I've found the problem why it didn't work. I didn't know that the entry funtion
(or whatever it is called) has to have the same name as the driver. After
creating a xorg.conf
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #18 from Martin Stolpe 2011-09-30
16:07:30 PDT ---
Hello,
I've found the problem why it didn't work. I didn't know that the entry funtion
(or whatever it is called) has to have the same name as the driver. After
creating a xorg.conf
https://bugs.freedesktop.org/show_bug.cgi?id=41373
Summary: memory leak when drmModeRes is freed.
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41373
Summary: memory leak when drmModeRes is freed.
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #17 from Martin Stolpe 2011-09-30 16:01:36
PDT ---
Created an attachment (id=51821)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51821)
Xorg log file for r600 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Martin Stolpe changed:
What|Removed |Added
Attachment #51820|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #17 from Martin Stolpe 2011-09-30
16:01:36 PDT ---
Created an attachment (id=51821)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51821)
Xorg log file for r600 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #16 from Martin Stolpe 2011-09-30 16:00:31
PDT ---
Created an attachment (id=51820)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51820)
Xorg log file for r300 card when 2d acceleration is enabled
--
Configure bugmail: https
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Martin Stolpe changed:
What|Removed |Added
Attachment #51820|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #15 from Martin Stolpe 2011-09-30 16:00:06
PDT ---
Created an attachment (id=51819)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51819)
Xorg log file for r300 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #16 from Martin Stolpe 2011-09-30
16:00:31 PDT ---
Created an attachment (id=51820)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51820)
Xorg log file for r300 card when 2d acceleration is enabled
--
Configure bugmail: https
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #15 from Martin Stolpe 2011-09-30
16:00:06 PDT ---
Created an attachment (id=51819)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51819)
Xorg log file for r300 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #14 from Martin Stolpe 2011-09-30 15:59:24
PDT ---
Created an attachment (id=51818)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51818)
Xorg configuration for r300 card
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #14 from Martin Stolpe 2011-09-30
15:59:24 PDT ---
Created an attachment (id=51818)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51818)
Xorg configuration for r300 card
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #13 from Martin Stolpe 2011-09-30 15:58:30
PDT ---
Created an attachment (id=51817)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51817)
Configuration for r600 card
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #13 from Martin Stolpe 2011-09-30
15:58:30 PDT ---
Created an attachment (id=51817)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51817)
Configuration for r600 card
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #12 from Martin Stolpe 2011-09-30 15:57:48
PDT ---
Created an attachment (id=51816)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51816)
Screenshot of Firefox when 2d acceleration is enabled
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #11 from Martin Stolpe 2011-09-30 15:57:21
PDT ---
Created an attachment (id=51815)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51815)
Screenshot of Firefox when 2d acceleration is disabled
--
Configure bugmail: https://bu
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #12 from Martin Stolpe 2011-09-30
15:57:48 PDT ---
Created an attachment (id=51816)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51816)
Screenshot of Firefox when 2d acceleration is enabled
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #11 from Martin Stolpe 2011-09-30
15:57:21 PDT ---
Created an attachment (id=51815)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51815)
Screenshot of Firefox when 2d acceleration is disabled
--
Configure bugmail: https://bu
On Don, 2011-09-29 at 19:07 -0700, Nicholas Miell wrote:
> The mouse cursor hotspot calculation when the cursor is partially off the
> top or left side of the screen was off by one.
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158
>
> Signed-off-by: Nicholas Miell
> ---
> drivers/g
On Fri, Sep 30, 2011 at 01:56:09PM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter wrote:
>
> > A cancel_work might be good here, not point in waking up the cpu for no
> > reason. And can you add "panel off timer: " to the deboug output?
>
> No, that's not correct
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #5 from Gustav Näslund 2011-09-30 14:45:03
PDT ---
Success! it works as it should
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #5 from Gustav N?slund 2011-09-30 14:45:03
PDT ---
Success! it works as it should
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #22 from chrisdh...@googlemail.com 2011-09-30 14:41:56 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > Does:
> >
> > Option "ColorTiling" "false"
> >
> > in the device section of your xorg.conf help? If so, you may
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #22 from chrisdhaag at googlemail.com 2011-09-30 14:41:56 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > Does:
> >
> > Option "ColorTiling" "false"
> >
> > in the device section of your xorg.conf help? If so, you
On Fri, 30 Sep 2011 20:55:24 +0200, Daniel Vetter wrote:
> If it's not too annoying to do, can you move this to the previous patch?
> Dito for the s/panel_vdd_work/panel_work/.
Yeah, that was a bit of sloppy patch mangling.
> Same comment as in the previous patch: I think the
> intel_dp->want_p
ntel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/e51a4a29/attachment.pgp>
On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter wrote:
> A cancel_work might be good here, not point in waking up the cpu for no
> reason. And can you add "panel off timer: " to the deboug output?
No, that's not correct, this is run before turning the panel back on and
must check that enough t
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0d46736e/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Leann Ogasawara changed:
What|Removed |Added
CC||leann.ogasawara@canonical.c
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Leann Ogasawara changed:
What|Removed |Added
CC||leann.ogasawara at canonical.c
On 30/09/11 12:59, Alex Deucher wrote:
> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
>> Looking at it with a nights sleep, it's obvious the code path in
>> aux_native_write is ok. Is this a bit cleaner than the last patch?
>
> Looks pretty good. I was thinking of something more like this (sorr
On Thu, Sep 29, 2011 at 06:09:53PM -0700, Keith Packard wrote:
> If the panel is powered up, there's no need to delay for the 'off'
> interval when turning the panel on.
>
> Signed-off-by: Keith Packard
I'll hold off carefully checking this one until the previous patches
settle. Especially when
On Thu, Sep 29, 2011 at 06:09:52PM -0700, Keith Packard wrote:
> This eliminates a fairly long delay when power sequencing newer
> hardware
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
On Thu, Sep 29, 2011 at 06:09:51PM -0700, Keith Packard wrote:
> Using the same basic plan as the VDD force delayed power off, make
> turning the panel power off asynchronous.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 71
> +
On Thu, Sep 29, 2011 at 06:09:50PM -0700, Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then re
On Fri, 30 Sep 2011 20:16:44 +0200, Daniel Vetter wrote:
> Awesome patch description and the code agrees with what I've cross-checked
> on bspec. The only fear I have is that we currently ignore the backlight
> on/off timings and some panel probably relies on use waiting for backlight
> on/off +
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/37da8c13/attachment.pgp>
On Fri, 30 Sep 2011 20:01:11 +0200, Daniel Vetter wrote:
> Looks like a patch useful for fixing up this mess, but I don't quite see
> the point of merging this given that you fix things for real in the next
> one ...
Good point. In the development process, this was the patch which made
things wo
ot available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/05aa4fc0/attachment.pgp>
1 - 100 of 185 matches
Mail list logo
