s than I have.
There was an independently-developed GLX implementation (Utah-GLX). If
worst came to worst, that could be revived. I'm not at all convinced this
is the case or will become the case.
I'd like someone to convince me there was a problem before any actual
steps are taken.
Keit
On Wed, 2009-02-25 at 11:42 -0800, Jesse Barnes wrote:
> Ok, I'll pull that bit out... but doing that introduces a small race. If we
> lose the race (the flip happens immediately and we get interrupted before
> adding the object to the vblank queue) the object will be stalled for one
> extra
On Sat, 2009-02-28 at 00:47 -0800, Andrew Morton wrote:
> The kernel deadlocked on struct_mutex, did it not? That's a kernel bug
> regardless of what userspace you're running.
No, it didn't deadlock on struct_mutex, it deadlocked because the
hardware got wedged, and we still don't know how to un
On Fri, 2009-03-06 at 15:19 -0800, Eric Anholt wrote:
> Given that these functions aren't actually hooked up to anything, I'm
> not sure if there's any value here. It sounds like we're going to go to
> using the resume_force_mode function for suspend/resume, which means
> we'd never use these.
I
On Wed, 2009-03-25 at 23:30 +, Dave Airlie wrote:
>
> I've no idea when a fault is likely in the fast case, i.e. will it happen
> usually on the first page etc, because if it happens on the last page and
> you fallback and restart the whole copy, I would think that would be
> sub-optimal, gr
On Wed, 2009-04-01 at 13:27 -0700, Eric Anholt wrote:
> I'm not really sold on the whole idea of the kernel generating these
> fake modes for LVDS, given that we can support any size and that the
> refresh rate is a lie since we're always using the fixed mode. Any
> other opinions on this?
It wo
On Fri, 2009-04-03 at 17:03 -0700, Eric Anholt wrote:
> + obj_priv->bit_17 = kmalloc(page_count, GFP_KERNEL);
seems like you could save a bit of memory here by using 1 bit per page
instead of a byte.
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed
On Sat, 2009-04-04 at 10:25 -0700, Eric Anholt wrote:
> Before, I was figuring it was better to have easy code than memory
> optimal code in my infrequently-tested workaround. Since recent notes
> about kmalloc limits, I'll switch to using bitmap.h.
Yeah, a single page of bits will cover 32k of
Digital Enterprise Group (DEG) & Software Solutions Group (SSG)
_
FROM:
Angela Gill (Visual Computing Group), and Keith Packard (Open
Source Technology Center)
DATE:
April 15, 2009
Transitions to TILING_NONE skipped the call to unbind the object, which left
the fence register set and caused future CPU access through the GTT to
access the object in tiled mode.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem_tiling.c |1 -
1 files changed, 0 insertions
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/Makefile|1
On Thu, 2009-04-30 at 13:45 -0700, Dan Nicholson wrote:
> I don't think you meant to include this.
oops. wrong branch. Correct patch coming in a moment.
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |7
On Thu, 2009-04-30 at 14:01 -0700, Dan Nicholson wrote:
> This still has an invalid "val" argument in the fallback READ64.
heh. uncompiled code is even worse than untested code (yes, building on
32-bit now).
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed mess
i386 has inline code for writeq and readq, so just use those instead of ugly
macros which evaluate arguments multiple times.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915
This makes software fallbacks not do tiling wrong on i965 and later after
resume. It also should fix 945 performance reduction after resume which
would have disabled tiling without causing any visible effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers
Lower level functions will destroy objects that are managed by the DRM
allocator, so make sure those are done before the allocator shuts down.
Signed-off-by: Keith Packard
---
src/i830_driver.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/i830_driver.c b/src
On Wed, 2009-05-06 at 09:03 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This just tries EDID detection, then falls back to the slow path code.
> I think this is should detect most monitors currently available.
I need to rework the I2C stuff so that it doesn't require the bit-bang
i2c algo;
On Wed, 2009-05-06 at 03:12 +0100, Dave Airlie wrote:
> Well if you just call the get_edid and ignore all the setscl crap that
> this code does, then you should be able to just implement a new i2c algo,
> and have it all just work.
Not completely; the rest of the DDC stack assumes that the unde
---
src/i810_reg.h | 42 ++
src/i830_debug.c |8
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/src/i810_reg.h b/src/i810_reg.h
index 8d4e641..cb33784 100644
--- a/src/i810_reg.h
+++ b/src/i810_reg.h
@@ -2214,6 +2214,43 @@ S
Signed-off-by: Keith Packard
---
src/i830_driver.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index 1887a51..3d7b51a 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -1009,6 +1009,14 @@ static Bool
While the VT is inactive, pI830->batch_bo will be NULL, so use that as a
simple check for when to not use the accelerator. The alternative is to
ignore VT switch and just keep drawing, which would also be fine.
Signed-off-by: Keith Packard
---
src/i830_exa.c |5 +
1 files changed
On Thu, 2009-05-07 at 17:18 -0500, Robert Noland wrote:
> Isn't this going to be linux specific?
that function is already XXX'd as 'linux specific'. It's just a hack
though, I think what we want is to enable DRM as soon as the driver
loads so we can use the existing module loading code and check
Scanout buffers need to be freed through the kernel as it holds a reference
to them; exposing this API allows applications allocating scanout buffers to
flag them as not reusable.
Signed-off-by: Keith Packard
---
libdrm/intel/intel_bufmgr.c |7 +++
libdrm/intel/intel_bufmgr.h
Buffers referenced by the kernel for scanout or cursor display should not be
reused by the driver. Use the new drm API to disable reuse of these buffers.
Signed-off-by: Keith Packard
---
src/i830.h|1 +
src/i830_memory.c |7 ++-
2 files changed, 7 insertions(+), 1 deletions
On Tue, 2009-05-12 at 14:42 -0700, Eric Anholt wrote:
> On Mon, 2009-05-11 at 13:51 -0700, Keith Packard wrote:
> > Scanout buffers need to be freed through the kernel as it holds a reference
> > to them; exposing this API allows applications allocating scanout buffers to
>
New API, new version.
Signed-off-by: Keith Packard
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 19d9c9c..e8cce3b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -19,7 +19,7 @@
# CONNECTION WITH THE SOFTWARE OR THE
Scanout buffers need to be freed through the kernel as it holds a reference
to them; exposing this API allows applications allocating scanout buffers to
flag them as not reusable.
Signed-off-by: Keith Packard
---
libdrm/intel/intel_bufmgr.c |7 +++
libdrm/intel/intel_bufmgr.h
eft PLLs, pipes
and planes running while in DPMS_OFF mode or even while they were unused.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c|7 ++-
drivers/gpu/drm/drm_crtc_helper.c | 109 -
drivers/gpu/drm/i915/intel_crt.c |6 +--
dri
Without initializing the sysfs attributes for the edid file,
it was created with mode 0, making it difficult for applications to use.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_sysfs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c
Note that this does not re-train the link, so it will not actually work
---
drivers/gpu/drm/i915/i915_drv.h | 11 +++
drivers/gpu/drm/i915/i915_suspend.c | 34 +-
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i9
---
drivers/gpu/drm/i915/intel_display.c | 91 +++-
drivers/gpu/drm/i915/intel_dp.c | 62 +-
drivers/gpu/drm/i915/intel_dp.h | 16 ++--
drivers/gpu/drm/i915/intel_dp_i2c.c | 157 ++
drivers/gpu/drm/i915/intel_drv.h |
This allows each output to deal with plug/unplug events as needed
(cherry picked from commit 08d57f21d1042153ebc26465be85d7e166008a14)
---
drivers/gpu/drm/i915/i915_irq.c |8
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/dri
This code depends on the underlying I2C adapter using the bit-banging algo,
which may not be the case. If specific encoders require this mechanism, they
should build a custom I2C algo that implements this workaround, rather than
having it in the general path.
Signed-off-by: Keith Packard
When a DP monitor is plugged back in, it needs to be retrained if it was
active before.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
We can safely assume that cursor addresses will not extend beyond the
addressable screen dimensions; setting the additional bits is harmless in
any case.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 56b0119..c9dd28b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 11 +-
drivers/gpu/drm/i915/intel_dp.c | 967 +-
drivers/gpu/drm/i915/intel_dp.h | 11 +
drivers/gpu/drm/i915/inte
HDMI and DVI both require DDC/EDID on monitors, so use
that to know when a monitor is connected as the hot-plug
pins are shared with SDVO and DisplayPort
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_hdmi.c | 25 +++--
1 files changed, 15 insertions(+), 10
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_display.c | 13 +-
drivers/gpu/drm/i915/intel_dp.c | 840 ++
drivers/gpu/drm/i915/intel_dp.h | 133 ++
drivers/gpu/drm/i915/intel_drv.h
eft PLLs, pipes
and planes running while in DPMS_OFF mode or even while they were unused.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c|7 ++-
drivers/gpu/drm/drm_crtc_helper.c | 109 -
drivers/gpu/drm/i915/intel_crt.c |6 +--
dri
This adds the register definitions for the display port enable register
along with those for the GMCH and Link M/N ratios required to drive display
port outputs.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 163 +++
1 files changed, 163
The contents of various simple text files in sysfs should end with
a newline to make them easier to read from the console.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_sysfs.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b
The display port link must be re-trained when
a monitor is plugged in.
---
drivers/gpu/drm/i915/intel_dp.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ed3c7de..56b0119 100644
-
the slave address into the output private
structures.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/dvo.h |4 +-
drivers/gpu/drm/i915/dvo_ch7017.c | 20 +++--
drivers/gpu/drm/i915/dvo_ch7xxx.c | 25
drivers/gpu/drm/i915/dvo_ivch.c| 21
Suspend/resume of display port links really wants to just run through the
mode set code so that link training happens.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_suspend.c | 56 +-
1 files changed, 41 insertions(+), 15 deletions(-)
diff --git a
On Fri, 2009-06-05 at 13:15 +, Eric Anholt wrote:
> s-o-b? also, a weird cherry-pick message here.
operator error.
> Seems like #10 was "Import DisplayPort" code and this is something
else?
Yeah, I've gone ahead and just merged all of the 'add display port' into
one giant patch.
> No // c
When a DP monitor is plugged back in, it needs to be retrained if it was
active before.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
This allows each output to deal with plug/unplug events as needed
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |8
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b
This adds the register definitions for the display port enable register
along with those for the GMCH and Link M/N ratios required to drive display
port outputs.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 163 +++
1 files changed, 163
Signed-off-by: Keith Packard
---
A replacement patch which doesn't leave // comments in intel_dp_i2c.c
drivers/gpu/drm/i915/Makefile|2 +
drivers/gpu/drm/i915/i915_drv.h | 12 +
drivers/gpu/drm/i915/i915_suspend.c | 34 +-
drivers/gpu/drm/i915/intel_display.c |
With the DRM-driven DPMS code, encoders are considered idle unless a
connector is hooked to them, so mode setting is skipped. This makes load
detection fail as none of the hardware is enabled.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 files changed, 2
Paul McKenney reminds me that submissions for the X track at Plumbers
are due shortly (Monday, 15 June 2009 PDT); I'd love to hear from anyone
interested in helping with a presentation or other content for our slot.
I'm interested in hearing about presentations, demonstrations and topics
for discu
On Mon, 2009-06-08 at 22:26 -0700, Corbin Simpson wrote:
> As somebody who can't keep his mouth shut, would any of the following be
> interesting/"Oh hey, you'll talk about it? Then I don't have to!":
I'm supposed to be emceeing this event, not doing a solo...
> - omapfb, DSS/DSS2, and why embe
For operations requiring GEM interfaces in the kernel, and which do not
depend on whether the driver offers DRI2 to X applications.
I think I got all of the right tests, but additional eyeballs would be
appreciated here.
Signed-off-by: Keith Packard
---
src/i830_accel.c |2 +-
src
On Fri, 2009-06-12 at 09:23 +0200, Michel Dänzer wrote:
> The DRM_IOCTL_MODESET_CTL ioctl has nothing to do with GEM. It probably
> shouldn't be called with KMS, but maybe i830_modeset_ctl() won't be
> called in that case anyway.
The only kernel API the intel driver supports now is GEM, so 'have_
Mac Mini's have a single GPIO line on the DVI connector, shared between the
analog link and the digital link. So, if DDC isn't detected on GPIOE (the
usual SDVO DDC link), try GPIOA (the usual VGA DDC link) when there isn't a
VGA monitor connected.
Signed-off-by: Keith Packard
-
Eliminate the copy of i2c_bus in sdvo_priv.
Eliminate local copies of i2c_bus and ddcbus.
Eliminate unused settings of slave_addr.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_sdvo.c | 54 ++--
1 files changed, 21 insertions(+), 33 deletions
For some reason, the DP clocks were based off a 100MHz reference instead of
the standard 96MHz reference. This caused some DP monitors to fail to lock
to the signal.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 21 +
1 files changed, 9 insertions
The change from bitfields to masks was done incorrectly for the misc flags
byte.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_edid.c | 19
include/drm/drm_edid.h | 66 ++--
2 files changed, 57 insertions(+), 28 deletions
On Thu, 2009-06-25 at 16:50 -0700, Jesse Barnes wrote:
> Is this mixing up the pixel block definition of sync vs the basic
> block definition (which has all the composite, green etc bits)?
The VESA spec seems to allow detailed modes to send sync signals in
different ways -- embedded with the anal
On Thu, 2009-06-25 at 18:44 -0700, Jesse Barnes wrote:
> Ok cool, I didn't have it in front of me so I wasn't sure of the
> encoding in the detailed timing vs basic block section.
Any X.org member can get a complete copy of the VESA specs. Recommended
for review of spec-related patches. This may
Convert many printk calls to DRM_DEBUG calls to reduce kernel log noise
for normal activities. Switch other printk calls to DRM_ERROR or DRM_INFO.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm
On Tue, 2009-06-30 at 09:33 +0800, yakui_zhao wrote:
> > DRM_DEBUG(fmt, args...)
> > DRM_DEBUG_DRIVER(prefix, fmt, args...)
> > DRM_DEBUG_KMS(prefix, fmt, args...)
> > DRM_DEBUG_MODE(prefix, fmt, args...)
> > but that should probably be done as a separate patch.
> A
On Mon, 2009-07-06 at 23:14 +0200, Marc Elser wrote:
> When I try to compile the newest intel driver from git repository, I
> always get a compiler error when it compiles i830_dri.o:
>
> i830_dri.c: In function ‘I830DRI2CreateBuffer’:
> i830_dri.c:224: error: ‘struct ’ has no member named ‘format’
KMS mode does not call I830AccelMethodInit as that does a ton of random
device initialization, but that means that the NoAccel and DRI options
were ignored. Split out the option parsing from I830AccelMethodInit and
have both KMS and UMS invoke it.
Signed-off-by: Keith Packard
---
src
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything. When not running UXA, GEM will not get used, and so no space
is needed there either.
Signed-off-by: Keith Packard
---
src/i830_driver.c
When running GEM, any buffer objects can only be pinned using dri_bo_pin,
they shouldn't be pinned through the GART directly.
Also, when running with KMS but without UXA, make sure frame buffers get
pinned when allocated so that the screen pixmap can be set at that time.
Signed-off-by:
Under KMS, the whole frame buffer is never allocated to the X server, and so
accessing the frame buffer must be done by directly mapping it using
drm_intel_gem_bo_map_gtt when it is created.
Signed-off-by: Keith Packard
---
src/drmmode_display.c | 16 ++--
1 files changed, 14
Always setting the pixmap devPrivate.ptr to point at the new bits means not
having to check whether UXA is running or not as NoAccel requires the
pointer in all cases.
Signed-off-by: Keith Packard
---
src/i830_driver.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git
tions
involving the 3D engine.
Signed-off-by: Keith Packard
---
src/i830_driver.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index db00af8..067a098 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -1691,11 +1
The frame buffer address is not set until it is mapped to the server address
space, which happens after fb is initialized. Just pass NULL instead of
computing garbage.
Signed-off-by: Keith Packard
---
src/i830_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
The scanout hardware can handle up to this size, so there's no reason to
restrict it to 2048x2048.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dr
On Wed, 2009-07-08 at 18:08 -0700, Eric Anholt wrote:
> The only thing I'm concerned about is proper handling of 3D drawing to
> that big. What happens?
It shouldn't work. We could require (in the X server) that DRI be
disabled to allocate a larger frame buffer if you like, but there's no
reason
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't (until today) supported under KMS in any case.
Signed-off-by: Keith Packard
---
src/drmmode_display.c | 74 +++--
src/i830.h| 15 +--
On Wed, 2009-07-08 at 18:13 -0700, Eric Anholt wrote:
> Binding pixmaps on behalf of KMS is broken, and the init sequence should
> be fixed if that's required :P
Hrm. I need to mmap_gtt the framebuffer for the no-accel case; I guess
that shouldn't require binding though.
--
keith.pack...@intel.c
On Wed, 2009-07-08 at 18:13 -0700, Eric Anholt wrote:
> Binding pixmaps on behalf of KMS is broken, and the init sequence should
> be fixed if that's required :P
Right, my remove-noaccel patch changes this to:
if (pI830->use_drm_mode)
return TRUE;
if (pI830->have_gem && mem->bo !
:00:00 2001
From: Keith Packard
Date: Wed, 8 Jul 2009 13:06:47 -0700
Subject: [PATCH 3/7] i830_bind_memory: Under UMS: Bind GEM bos with dri_bo_pin,
else through the GART
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for u
On Wed, 2009-07-08 at 20:28 +0100, Julien Cristau wrote:
> DRI2 init can fail for various reasons, and it's easier to test if you
> don't have to hack the driver. No particular opinion on kms without
> uxa, though.
Right, which is why I also fixed the DRI option parsing in the KMS case
(which wa
On Thu, 2009-07-09 at 11:37 -0400, Alex Deucher wrote:
> Might be useful to bring up a shadowfb or noaccel X if the user is
> having accel problems, just to have a desktop.
That's been the traditional answer, but at this point, NoAccel is a
completely separate path through our driver as it requir
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything.
Signed-off-by: Keith Packard
---
src/i830_driver.c |8 +--
src/i830_memory.c | 135
-by: Keith Packard
---
src/i830_driver.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index ee39a1b..e5e5fd7 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -880,7 +880,6 @@ i830_xf86crtc_resize (ScrnInfoPtr
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard
---
src/drmmode_display.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard
---
src/i830_uxa.c | 11
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
---
src/i830_memory.c | 14 ++
i830_user_modesetting_init to reflect what it actually does.
Signed-off-by: Keith Packard
---
src/i830_driver.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index cc0a1f6..ee39a1b 100644
--- a/src/i830_driver.c
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't supported under KMS in any case.
Signed-off-by: Keith Packard
---
src/drmmode_display.c | 16 --
src/i830.h| 15 +
src/i830_accel.c | 11
On Fri, 2009-07-10 at 12:35 -0700, Ian Romanick wrote:
> > + pointer *data;
>
> Is 'pointer *' actually what you wanted here? Either 'pointer' or plain
> old 'void *' should be fine.
heh. yeah, pointer would be correct. Note that the updated patch
sequence doesn't use a temporary variable
On Fri, 2009-07-10 at 17:25 -0700, Eric Anholt wrote:
> This one and #3 seem to be in disagreement. Perhaps some squashing?
This one is KMS, where we never need the screen pixmap to hold a
pointer. #3 was for UMS, where we do.
> Other than that, it looks fine to me.
Ok, I'll go ahead and push
out engine.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 508838e..7b49809 100644
--- a/drivers/gpu/drm/i915/intel_displ
ne wanting to use this module.
A handful would include:
-- draw a triangle
-- draw a textured triangle
-- draw a triangle using indexed vertices
-- some sort of occlusion query
At least then there would be some concrete examples of this in use so
that an interested party wouldn't later
s should be used? None
of these can be user defined as they all come from looking at just the
hardware.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_modes.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes
This synchronizes the X EDID data with the kernel EDID data each time the
kernel data may have changed. Otherwise, X ends up stuck with the first EDID
data it sees, failing to accomodate to different monitors.
Signed-off-by: Keith Packard
---
src/drmmode_display.c |3 +--
1 files changed, 1
On Wed, 2009-07-22 at 09:51 +0800, Zhenyu Wang wrote:
> Look nice to me.
Pushed, thanks for your review.
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
--
--
gt; > >>>>
> > >>>> Thomas what do you think about that ?
> > >>>>
> > >>>> Cheers,
> > >>>> Jerome
> > >>>>
> > >>> Attach
and userspace
can execute multiple times.
Keith
On Sat, 2009-08-08 at 05:43 -0700, Dave Airlie wrote:
> On Sat, Aug 8, 2009 at 7:51 AM, Jerome Glisse wrote:
> > Investigating where time is spent in radeon/kms world when doing
> > rendering leaded me to question the design of CS
rm fd, it should be fine.
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 8:31 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corr
kernel memory manager & other actors shouldn't be
double-guessing that.
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 11:46 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subjec
No, I'm fine. I don't have the patch in front of me but it doesn't sound like
it precludes these types of changes in the future.
Keith
From: Jesse Barnes [jbar...@virtuousgeek.org]
Sent: Tuesday, August 18, 2009 1:23 PM
To: Keith Whitwe
this.
>
> I can confirm that this fixes the same problem in tuxracer and other
> apps, but I'm hesitant to commit it because I don't understand why. :/
>
How do other drivers handle the same point?
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
1 - 100 of 2060 matches
Mail list logo
