On Thursday, July 31, 2008 3:25 pm Jesse Barnes wrote:
Given the way master is now, would this be a simpler fix?
It basically just makes drivers responsible for doing vblank init
cleanup. They can move it to load/unload or irq install/uninstall whenever
they want.
Oops, ignore that, I
On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote:
Well, if the overhead of merging upstream is a concern, then how about
not worrying about bc at all and let people who want to back port deal
with it? Oh, and what about just keeping the drm drivers in a linux
kernel tree? That'll
As we discussed on IRC last night, I think these changes are perfectly
reasonable (in fact just what I'd expect if we moved to this model).
Sure, it will force contributors to be more disciplined, but that's
probably a good thing anyway. I'd still like to hear from the BSD guys
about
of by the
parent do_mmap_pgoff function. I think that would mean messing with shmem.c
though, since it won't pass down an mmap call for us...
On the plus side, these patches seem to work and bring performance on
modesetting-gem back to reasonable levels.
--
Jesse Barnes, Intel Open Source
On Thursday, August 21, 2008 2:27 pm Jesse Barnes wrote:
Here's what I've been hacking on wrt GTT mapping. The kernel's mmap_region
function was almost exactly what we needed, but it doesn't give us a way to
avoid the backing store for the attached file, thus the new function. It
would
makes it easier
to share this file with BSD.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b032808..c4bbda6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -3,7 +3,8 @@
# Direct
Author: Zhenyu Wang [EMAIL PROTECTED]
i915: official name for GM45 chipset
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
Acked-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a82b487..71326ca 100644
--- a/drivers/gpu/drm
it.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 61ed515..d6d6be4 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -132,7 +132,6 @@ static int drm_irq_install(struct drm_device * dev)
/* Expose
(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 16829fb..3daefef 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -125,7 +125,7 @@ int drm_setunique(struct drm_device *dev, void
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver when to register its interrupt handler and on what IRQ
On Tuesday, August 26, 2008 12:23 pm Thomas Hellström wrote:
Jesse Barnes wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver when to register its interrupt handler and on what IRQ.
This is a really bad idea for several reasons, and fortunately I
cause for
complaint. However, I haven't done that. Nor has this gone into the Linux
tree, so things aren't out of sync, so let's keep this in perspective.
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net
On Tuesday, August 26, 2008 1:28 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model... Things are actually worse than I
thought
doing this carefully for each driver
first, and only then ripping out the core code. I think we could manage this
in i915 fairly easily at least, but even then I don't think we'd want to do
it until the vblank-rework stuff is upstream (which I'm working on now).
Thanks,
--
Jesse Barnes, Intel
it working well;
fixing this particular problem should be fairly easy w/o having to rip out
all the IRQ stuff (though I was kinda hoping that would be the solution, Dave
is right that it's just a bunch of regressions waiting to happen).
--
Jesse Barnes, Intel Open Source Technology Center
topic branches that may or may not get into the next
Linus release in order to get build (some) test coverage.
Overall this looks really good to me; it seems like it will address the
weaknesses I've seen with the current model.
--
Jesse Barnes, Intel Open Source Technology Center
On Tuesday, August 26, 2008 9:03 pm Robert Noland wrote:
On Tue, 2008-08-26 at 18:02 -0700, Jesse Barnes wrote:
On Tuesday, August 26, 2008 5:13 pm Robert Noland wrote:
I kinda prompted this topic to come back to life... I'm less concerned
with the IRQ bits than I am with the vblank
On Saturday, August 30, 2008 1:20 am Maksym Veremeyenko wrote:
Jesse Barnes написав(ла):
On Wednesday, August 27, 2008 1:20 pm Jesse Barnes wrote:
Here's a tested (on i915) patch for vblank-rework against drm-next with
my
Could you give a hint how to apply this patch, what git repo should
On Wednesday, September 03, 2008 6:11 am Stefano Avallone wrote:
On Wednesday 03 September 2008 13:36:21 Maksym Veremeyenko wrote:
Jesse Barnes написав(ла):
[...]
I am very interesting in getting drmWaitVBlank works on 945GME...
It's against Dave's upstream DRM repo:
git
On Wednesday, September 03, 2008 4:29 pm Dave Airlie wrote:
Right; the vblank patch also depends on the other patches I posted
(suspend/resume, GM45 and irq field removal). It may apply with some
fuzz if you don't have those patches but I don't know if it'll work.
I've applied the
On Thursday, September 04, 2008 7:25 am Maksym Veremeyenko wrote:
Michel Dänzer написав(ла):
[...]
where it submits crtc==0 - index of first available pipe instead of
index of first active pipe. perhaps if enabled only one pipe it assume
that it has index 0 (FIX ME)
The crtc value is
want to do it by default.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/src/i830_exa.c b/src/i830_exa.c
index fd29df1..8213242 100644
--- a/src/i830_exa.c
+++ b/src/i830_exa.c
@@ -767,7 +767,7 @@ i830_uxa_prepare_access (PixmapPtr pixmap, uxa_access_t access
On Thursday, September 11, 2008 11:03 pm Nick Piggin wrote:
On Thu, Sep 11, 2008 at 06:16:21PM -0700, Jesse Barnes wrote:
Here's an updated set of GTT mapping patches against Eric's drm-gem-merge
branch from earlier today and DRM master for the libdrm bits. I fixed up
a couple of bugs
(). What are the intended fork() semantics for a
GTT mapped GEM object?
Oh, I hadn't thought about that case; I'll have to create a list of VMAs and
maybe take an appropriate mutex.
Thanks a lot for looking it over.
--
Jesse Barnes, Intel Open Source Technology Center
Like the last patch but adds a macro to get at the irq value instead of
dereferencing pdev directly. Should make things easier for the BSD guys and
if we ever support non-PCI devices.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm
Ok, here's an updated patch (note: only compile tested!) which I think
addresses all of the comments I received. I switched over to using
dev_mapping for unmapping and tried to cleanup the mm mmap private fields a
bit.
How does it look?
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_bufs.c
On Wednesday, September 17, 2008 5:48 am Thomas Hellström wrote:
Jesse Barnes wrote:
Ok, here's an updated patch (note: only compile tested!) which I think
addresses all of the comments I received. I switched over to using
dev_mapping for unmapping and tried to cleanup the mm mmap private
includes my GTT mapping stuff)
to Eric's patchset; hope you can do that soon so we can get a libdrm with the
new APIs released soon.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored
On Wednesday, September 17, 2008 5:48 am Thomas Hellström wrote:
Jesse Barnes wrote:
Ok, here's an updated patch (note: only compile tested!) which I think
addresses all of the comments I received. I switched over to using
dev_mapping for unmapping and tried to cleanup the mm mmap private
On Friday, October 3, 2008 1:40 pm Thomas Hellström wrote:
Jesse Barnes wrote:
On Wednesday, September 17, 2008 5:48 am Thomas Hellström wrote:
Jesse Barnes wrote:
Ok, here's an updated patch (note: only compile tested!) which I think
addresses all of the comments I received. I switched
On Thursday, October 16, 2008 5:24 pm Jesse Barnes wrote:
Ok this one has locking fence register allocation. I'm still trying to
figure out why things get mapped cached though, clearly something is going
wrong with my vm_insert_pfn; it's acting like I'm mapping the wrong offset
since fencing
); sorry.
That said, this code was far from untested, even though it did contain a few
compile warnings, so I think Linus's complaint about UNTESTED CRAP was at
least half wrong.
--
Jesse Barnes, Intel Open Source Technology Center
Ok, this one actually works w/o corrupting your display. However, after
running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm
hoping someone can tell me where I messed up the list handling (the change in
i915_gem_retire_request tries to deal with that, since the flushing list
On Wednesday, October 22, 2008 3:08 pm Jesse Barnes wrote:
Fairly straightforward aside from the aforementioned question about how to
set tiling stride values for a given object.
Oops, need to init the bufmgr pointer before using it.
Jesse
diff --git a/libdrm/intel/intel_bufmgr.c b/libdrm
On Thursday, October 23, 2008 3:11 am Steven J Newbury wrote:
On Wed, 2008-10-22 at 15:20 -0700, Jesse Barnes wrote:
On Wednesday, October 22, 2008 3:08 pm Jesse Barnes wrote:
Fairly straightforward aside from the aforementioned question about how
to set tiling stride values for a given
On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote:
Ok, this one actually works w/o corrupting your display. However, after
running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm
hoping someone can tell me where I messed up the list handling (the change
On Thursday, October 23, 2008 5:09 pm Jesse Barnes wrote:
On Thursday, October 23, 2008 3:51 pm Jesse Barnes wrote:
On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote:
Ok, this one actually works w/o corrupting your display. However,
after running for awhile I end up hitting
On Thursday, October 23, 2008 3:51 pm Jesse Barnes wrote:
On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote:
Ok, this one actually works w/o corrupting your display. However, after
running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm
hoping someone can tell me
On Thursday, October 23, 2008 5:20 pm Jesse Barnes wrote:
Ugg, get_fence was pretty broken in the !reg case... fixing that makes
things a bit more stable...
And here's one that's actually pretty solid. It doesn't try to unbind from
get_fence (should be safe, but we don't want to do it anyway
since the new code
won't be used unless applications actually call the GTT mapping ioctl.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bde64b8..9916366 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers
On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
Ok this one doesn't crash and doesn't leave the flushing list full at
leavevt time, so I think it's ready for some actual review.
I'm using the patch I posted to intel-gfx@ to do tiled EXA pixmaps, but I
think my approach of faulting
On Monday, October 27, 2008 11:27 am Jesse Barnes wrote:
On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
Ok this one doesn't crash and doesn't leave the flushing list full at
leavevt time, so I think it's ready for some actual review.
I'm using the patch I posted to intel-gfx
On Tuesday, October 28, 2008 4:55 pm Eric Anholt wrote:
On Tue, 2008-10-28 at 14:37 -0700, Jesse Barnes wrote:
On Monday, October 27, 2008 11:27 am Jesse Barnes wrote:
On Friday, October 24, 2008 2:57 pm Jesse Barnes wrote:
Ok this one doesn't crash and doesn't leave the flushing list
Ok here's an updated patch set that takes into account most of your comments.
There are still a few open issues though:
- fence register allocation for pre-965 buffer execution
- unmap_mapping_range cost (it looked like the function would short-circuit
if there was nothing to do, but I
Author: Jesse Barnes [EMAIL PROTECTED]
Date: Wed Oct 29 15:16:52 2008 -0700
DRM: add core GEM memory map support
Add support for memory mapping of GEM objects, re-using some TTM code. The
basic approach is the same as TTM: create a fake offset for your object,
add
Author: Jesse Barnes [EMAIL PROTECTED]
Date: Wed Oct 29 15:19:37 2008 -0700
DRM: i915: add support for memory mapping GEM objects
Add support to the i915 driver for mapping GEM objects. A new ioctl, the
GTT mapping ioctl, takes care of allocating a fake offset for a given
be included in the next
post, so feel free to send me feedback.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux
On Thursday, October 30, 2008 2:03 pm Jesse Barnes wrote:
In the hopes of getting the kernel mode setting stuff in shape for the
2.6.29 merge window I've been trying to get things into shape. This patch
set is a very rough start at getting things merge-ready. There's still a
lot left to do
On Friday, October 31, 2008 4:01 am Thomas Hellström wrote:
Jesse Barnes wrote:
This commit adds the core mode setting routines for use by DRM drivers to
manage outputs and displays. Originally based on the X.Org Randr 1.2
implementation, the code has since been heavily changed by Dave
On Friday, October 31, 2008 2:18 pm Dave Airlie wrote:
On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Friday, October 31, 2008 4:01 am Thomas Hellström wrote:
Jesse Barnes wrote:
This commit adds the core mode setting routines for use by DRM drivers
to manage
On Monday, November 3, 2008 8:26 am Jesse Barnes wrote:
On Friday, October 31, 2008 2:18 pm Dave Airlie wrote:
On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Friday, October 31, 2008 4:01 am Thomas Hellström wrote:
Jesse Barnes wrote:
This commit adds
into a _DRM_DRIVER one so that the core won't remove it at
lastclose time.
Fixes (at least partially) kernel bz #11891.
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 0738948..abdc1ae 100644
--- a/drivers/gpu/drm/radeon
Here's an updated patch set for core DRM + i915 mode setting. I spent a
good part of the day trying to reduce the size of the patches against
the core, so things should be nearly reviewable now. I'm still tracking
down the unload/load bug (was hoping the diff reduction + audit would
magically
Add support for mapping of GEM objects if the underlying driver supports it.
---
drivers/gpu/drm/drm_bufs.c|6 ++
drivers/gpu/drm/drm_drv.c |6 ++
drivers/gpu/drm/drm_fops.c| 12 -
drivers/gpu/drm/drm_gem.c | 109 +
Use the new core GEM object mapping code to allow GTT mapping of GEM objects
on i915. The fault handler will make sure a fence register is allocated too,
if the object in question is tiled.
---
Makefile |2 +-
drivers/gpu/drm/i915/i915_dma.c|1 +
On Wednesday, November 5, 2008 6:07 pm Eric Anholt wrote:
On Wed, 2008-11-05 at 16:49 -0800, Jesse Barnes wrote:
Use the new core GEM object mapping code to allow GTT mapping of GEM
objects on i915. The fault handler will make sure a fence register is
allocated too, if the object
On Wednesday, November 5, 2008 4:49 pm Jesse Barnes wrote:
Here's an updated patch set for core DRM + i915 mode setting. I spent a
good part of the day trying to reduce the size of the patches against
the core, so things should be nearly reviewable now. I'm still tracking
down the unload
Add support for mapping of GEM objects if the underlying driver supports it.
---
drivers/gpu/drm/drm_bufs.c|6 ++
drivers/gpu/drm/drm_drv.c |6 ++
drivers/gpu/drm/drm_fops.c| 12 -
drivers/gpu/drm/drm_gem.c | 109 +
Use the new core GEM object mapping code to allow GTT mapping of GEM objects
on i915. The fault handler will make sure a fence register is allocated too,
if the object in question is tiled.
---
Makefile |2 +-
drivers/gpu/drm/i915/i915_dma.c|1 +
Note the cc on the original message. It seems that git send-email doesn't
parse options very well...
Anyway, this is an updated patch set with the master rework stuff split out,
and a few more diff reductions. Passes the load/unload torture test on my
machine.
Jesse
On Friday, November 7, 2008 5:44 pm Keith Packard wrote:
Addresses in the hardware status page below index 0x20 are reserved for use
by the hardware. The legacy breadcrumb was sitting at index 5. Move it to
index 0x21, and make sure everyone uses the defined value instead of
hard-coded
On Tuesday, November 11, 2008 12:37 am Dave Airlie wrote:
On Tue, Nov 11, 2008 at 6:29 PM, Andrew Morton
[EMAIL PROTECTED] wrote:
On Tue, 11 Nov 2008 08:15:26 + (GMT) Dave Airlie [EMAIL PROTECTED]
wrote:
commit 78538bf14995a136c2d9a22159ada49937359119
Author: Dave Airlie [EMAIL
On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote:
Add support for the GEM object GTT mapping ioctl.
---
libdrm/intel/intel_bufmgr.h |9
libdrm/intel/intel_bufmgr_gem.c | 81
+++ shared-core/drm.h |
2 +-
shared-core
On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote:
+struct drm_i915_gem_mmap_gtt {
+ /** Handle for the object being mapped. */
+ uint32_t handle;
+ uint32_t pad;
+ /**
+ * Fake offset to use for subsequent mmap call
On Tuesday, November 11, 2008 4:55 pm Eric Anholt wrote:
On Tue, 2008-11-11 at 16:48 -0800, Jesse Barnes wrote:
On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote:
+struct drm_i915_gem_mmap_gtt {
+ /** Handle for the object being mapped. */
+ uint32_t handle
On Tuesday, November 11, 2008 9:59 pm Eric Anholt wrote:
On Tue, 2008-11-11 at 17:15 -0800, Jesse Barnes wrote:
On Tuesday, November 11, 2008 4:55 pm Eric Anholt wrote:
On Tue, 2008-11-11 at 16:48 -0800, Jesse Barnes wrote:
On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote
patching using your klm-7 directory of patches onto
drm-intel-next but they're out of sync.
Can you please push a git repo of it to freedesktop so people can
pull it down easily?
thanks
Tom.
--
Jesse Barnes, Intel Open Source Technology Center
PROTECTED]
Acked-by: Jesse Barnes [EMAIL PROTECTED]
This looks correct (in fact we used to do it this way but somehow it made it
upstream in a different form; I know because this was explicitly tested last
time we did validation). It'll also fix the suspend/resume case.
Thanks,
Jesse
On Tuesday, November 18, 2008 12:17 pm Jesse Barnes wrote:
On Tuesday, November 18, 2008 9:48 am Keith Packard wrote:
This should fix the compiz issues across vt switch (works for me).
From 087e40e095de737d948f26bb1c28bba34a274fdb Mon Sep 17 00:00:00 2001
From: Keith Packard [EMAIL
.
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize
On Tuesday, November 18, 2008 5:27 pm Keith Packard wrote:
On Tue, 2008-11-18 at 13:00 -0800, Jesse Barnes wrote:
Just remembered that other drivers will need updates here too, otherwise
they may leak memory due to multiple drm_vblank_init calls on every IRQ
postinstall.
Here's
the compositor has its own copy of things, so it can simply
allow the swap to continue once it has a copy of the latest buffer.
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored by the Moblin Your
On Tuesday, November 25, 2008 11:44 am Eric Anholt wrote:
On Tue, 2008-11-25 at 11:31 -0800, Jesse Barnes wrote:
DRI2 is about to land in the Intel driver, so we've been thinking about
how to deal with the last missing piece: vertical blank synchronized
buffer swaps. I think
On Tuesday, November 25, 2008 12:18 pm Jesse Barnes wrote:
On Tuesday, November 25, 2008 11:44 am Eric Anholt wrote:
I don't like this plan. If my app has a new frame all ready to go, I
want it to get displayed the next time the compositor wakes up to do a
vblank-synced composite, not wait
On Wednesday, November 19, 2008 6:45 pm Eric Anholt wrote:
On Fri, 2008-11-07 at 15:31 -0800, Jesse Barnes wrote:
[Justify this massive code drop here.]
Don't forget this bit :)
Heh, will fix. Thanks a ton for looking through this; I know it's huge and in
some places hard to follow
On Wednesday, November 19, 2008 10:07 pm Eric Anholt wrote:
On Wed, 2008-11-05 at 16:49 -0800, Jesse Barnes wrote:
Adds support for DRM based mode setting on Intel integrated graphics
chips.
Might be nice to note what hardware is/isn't supported and tested here.
For example, native HDMI
On Wednesday, November 26, 2008 1:14 pm Jesse Barnes wrote:
Here's an updated set that incorporates Eric's feedback, along with a
few other fixes:
- lastclose now correctly restores the mode (useful for if an
application crashes or doesn't clean up after itself)
- SysRq-g allows you
rebase all the time.
--
Jesse Barnes, Intel Open Source Technology Center
Jesse Barnes (3):
DRM: rework master design
DRM: add mode setting support
DRM: i915: add mode setting support
drivers/gpu/drm/Kconfig| 11 +
drivers/gpu/drm/Makefile |3 +-
drivers
things.
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand
to
handle a vblank event at that point.
--
Jesse Barnes, Intel Open Source Technology Center
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin
On Wednesday, December 3, 2008 10:18 am Eric Anholt wrote:
On Thu, 2008-11-27 at 09:16 -0800, Jesse Barnes wrote:
Add mode setting support to the DRM layer.
This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities
On Wednesday, December 3, 2008 11:07 am Jesse Barnes wrote:
On Wednesday, December 3, 2008 10:18 am Eric Anholt wrote:
On Thu, 2008-11-27 at 09:16 -0800, Jesse Barnes wrote:
Add mode setting support to the DRM layer.
This is a fairly big chunk of work that allows DRM drivers to provide
.
--
Jesse Barnes, Intel Open Source Technology Center
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way
On Thursday, December 11, 2008 4:16 pm vehemens wrote:
On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote:
...
New commits:
commit 9583c099b4a08b49e03f7b461c344b6d277fd262
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed Dec 10 15:47:28 2008 -0800
Revert Merge
be awesome)
Good point, I'll fix the copyright and add some info. And add a Makefile
while I'm at it. :)
--
Jesse Barnes, Intel Open Source Technology Center
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
On Saturday, December 13, 2008 6:17 am Pekka Paalanen wrote:
On Thu, 11 Dec 2008 15:11:23 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
Initially I thought the merge of the KMS bits into libdrm would be as
easy as merging the modesetting-gem branch into master. But that branch
has
On Tuesday, December 16, 2008 9:51 pm Eric Anholt wrote:
On Tue, 2008-12-16 at 16:36 -0800, Jesse Barnes wrote:
Here's an updated patch. Changes from last time:
- removed irrelevant diffs (TTM removal, bits of libdrm_intel code)
- copyright fixups/license additions
- fixup tests
not used elsewhere, iirc it's not).
--
Jesse Barnes, Intel Open Source Technology Center
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us
;
+ unsigned int lvds_dither:1;
+ unsigned int lvds_vbt:1;
+ unsigned int int_crt_support:1;
struct drm_i915_fence_reg fence_regs[16]; /* assume 965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes
add my
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
If you want to use EXA and not UXA you'll want my EXA pixmap patch (old
version attached, refreshing now to current xf86-video-intel).
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/src/i830.h b/src/i830.h
index
uninstall path.
This patch fixes fdo bug #18879, so hopefully we can apply it or another
fix for this problem soon.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1e787f8..e2f5d23 100644
--- a/drivers/gpu/drm/drm_irq.c
getting reset under us; I'm not sure if that's
safe everywhere and a simpler method is probably possible too...
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am
index eb63abe..71a8718 100644
--- a/libdrm/Makefile.am
+++ b/libdrm/Makefile.am
happily submit a bug but thought the code was a little too
new to harp on about especially if this is a known issue
Let me know if I can help further
Looks like the 3D driver init failed... Maybe you need to rebuild your DRI
driver as well against the same libdrm?
--
Jesse Barnes, Intel Open
On Tuesday, January 6, 2009 3:53 pm Mike Lothian wrote:
2009/1/6 Jesse Barnes jbar...@virtuousgeek.org:
On Tuesday, January 6, 2009 2:35 pm Mike Lothian wrote:
Hi there
Thought I'd send in some info about Xorg with a KMS kernel, libdrm and
xf86-video-intel
I've attached my dmesg
On Wednesday, January 7, 2009 10:36 am Michel Dänzer wrote:
On Wed, 2009-01-07 at 10:15 -0800, Jesse Barnes wrote:
On Wednesday, January 7, 2009 9:49 am Michel Dänzer wrote:
On Tue, 2009-01-06 at 22:49 -0800, Keith Packard wrote:
On Tue, 2009-01-06 at 10:41 -0800, Jesse Barnes wrote
On Wednesday, January 7, 2009 9:49 am Michel Dänzer wrote:
On Tue, 2009-01-06 at 22:49 -0800, Keith Packard wrote:
On Tue, 2009-01-06 at 10:41 -0800, Jesse Barnes wrote:
This patch adds a sanity check to drmWaitVBlank to prevent hangs.
Since the server interrupts syscalls pretty
On Wednesday, January 7, 2009 10:54 am Keith Packard wrote:
On Wed, 2009-01-07 at 10:15 -0800, Jesse Barnes wrote:
Ok; I messed with drmIoctl because I thought I remembered you saying we
shouldn't put the retry code there but rather in the individual ioctls
that needed it. We should
On Wednesday, January 7, 2009 11:34 am Eric Anholt wrote:
On Wed, 2009-01-07 at 11:11 -0800, Jesse Barnes wrote:
On Wednesday, January 7, 2009 10:54 am Keith Packard wrote:
On Wed, 2009-01-07 at 10:15 -0800, Jesse Barnes wrote:
Ok; I messed with drmIoctl because I thought I remembered
On Tuesday, January 6, 2009 10:21 am Jesse Barnes wrote:
In the absence of kernel mode setting, many drivers disable IRQs across VT
switch. The core DRM vblank code is missing a check for this case however;
even after IRQ disable, the vblank code will still have the vblank_enabled
flag set
In some cases we might try to wait on vblank events from pipes that aren't
actually enabled. We shouldn't allow this, so return -EINVAL if the pipe
isn't on.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
201 - 300 of 693 matches
Mail list logo
