[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 --- Comment #1 from Philipp Klaus Krause [EMAIL PROTECTED] 2008-11-02 06:14:51 PST --- [EMAIL PROTECTED] schrieb: - intelFinish() does a bit more than is necessary, since it waits for rendering to all color buffers to finish, not just

Re: Resume issues with 2.6.28

On Wed, Oct 29, 2008 at 9:30 PM, Stephen Hemminger [EMAIL PROTECTED] wrote: On my desktop with Intel graphics ( 82G33/G31 ), I noticed some problems when doing resume from ram. The system takes some key strokes to come back correctly: Resume (power button) 1) LCD comes up in a resolution

[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 --- Comment #2 from Owen Taylor [EMAIL PROTECTED] 2008-11-02 08:58:11 PST --- In further testing, the patch works as advertised for direct rendering but when running inside the server (AIGLX) seems to have no effect. My only idea is that the

[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ---

[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 --- Comment #4 from Owen Taylor [EMAIL PROTECTED] 2008-11-02 11:15:52 PST --- Any advice about how to investigate further? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail

[Bug 11938] Switch to VESA mode hangs on HD4850

http://bugzilla.kernel.org/show_bug.cgi?id=11938 --- Comment #2 from [EMAIL PROTECTED] 2008-11-02 11:21 --- Yes, I am quite surprised at this behaviour myself. By now I would agree this could be some obscure hardware problem that does not manifest istelf under XP. Still, with 2.6.19

[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 --- Comment #5 from Owen Taylor [EMAIL PROTECTED] 2008-11-02 14:26:28 PST --- Turns out after discussion on IRC that the mesa patch here is a red herring. The problem is basically what is discussed in:

[Bug 18347] intelReadPixels needs to wait for hardware

http://bugs.freedesktop.org/show_bug.cgi?id=18347 Owen Taylor [EMAIL PROTECTED] changed: What|Removed |Added Attachment #20001|0 |1 is obsolete|

[git pull] drm fixes for 2.6.28-rc4

Hi Linus, Please pull the 'drm-next' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next Intel: One build fix and a new API needed to make GEM work properly. radeon: fix a regression is the bus mastering patches on rs480. Dave.

[PATCH] [drm/i915] Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45

This register is set by the 2D driver to prevent lockups, and so it needs to be preserved across suspend/resume too. This makes my X200s work. Signed-off-by: Keith Packard [EMAIL PROTECTED] --- drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_reg.h |3 +++

[PATCH] [drm/i915] Clean up sarea pointers on leavevt

Just NULL out the sarea pointers when the X server has destroyed it. I think this is the right place to do that. Signed-off-by: Keith Packard [EMAIL PROTECTED] --- drivers/gpu/drm/i915/i915_dma.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git

[PATCH] [drm] Mark DDX as supporting modeset notify ioctls on the first call

The initial mode setting from the 2D driver is done before drm_vblank_init is called, which means that vblank_disable_allow isn't set. This prevents the kernel from disabling vblank interrupts after they are first turned on. Signed-off-by: Keith Packard [EMAIL PROTECTED] ---

[PATCH] [drm/i915] Add support for creating an fb device using one pipe

This takes an existing configured pipe/plane and allocates a new frame buffer for it, then it hooks that up to the framebuffer driver to create an fb device. Suitable hacks to the X server to leave the vt in KD_TEXT mode and you can use this fb device with fbcon to show console messages while X is