At XDS and on IRC we've been discussing how to deal with backward
compatibility (i.e. old Mesa X on new DRM) once we have things like
full TTM and modesetting support in the kernel.
The preferred option at this point seems to be to add a new kernel
config option, e.g. CONFIG_DRM_MODESETTING
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I have to admit that I haven't been keeping as up to date with this
thread as I should have. I've blocked off some time tomorrow morning
to fully review this patch and the discussion. I'll probably have
some questions for you, if
In one of my overzealous pipe/plane mapping patches, I renamed the pipes
field in drm_i915_flip_t to planes, since it's really dealing with
planes and so seemed to make sense.
However, drm_i915_flip_t has different compatibility requirements than
the i915 sarea private. The sarea private is
On Thursday, September 27, 2007 3:35:22 pm Jesse Barnes wrote:
In one of my overzealous pipe/plane mapping patches, I renamed the pipes
field in drm_i915_flip_t to planes, since it's really dealing with
planes and so seemed to make sense.
However, drm_i915_flip_t has different compatibility
On Friday, September 28, 2007 9:27 am Brian Paul wrote:
1. The Mesa 7.0.2 branch doesn't build with drm/master.
Compiling dri_bufmgr.c:
../common/dri_bufmgr.c: In function ‘driFenceBuffers’:
../common/dri_bufmgr.c:102: warning: passing argument 3 of
‘drmFenceBuffers’ makes integer from
On Friday, September 28, 2007 11:02 am Ian Romanick wrote:
Jesse Barnes wrote:
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I do have one question now. What happens (or is intended to
happen) if the currently bound drawable is not a window?
Any thoughts on this?
No, I'm
On Friday, September 28, 2007 12:51 pm Ian Romanick wrote:
No, I'm not sure what should happen in this case. Doing a vblank
sync'd buffer swap or vblank wait on an offscreen drawable doesn't
make much sense does it? In what cases might those calls occur?
The spec doesn't say that an
On Monday, October 1, 2007 2:07:44 am Michel Dänzer wrote:
On Fri, 2007-09-28 at 12:31 -0700, Jesse Barnes wrote:
Ok, this version includes the changes suggested by Michel and Ian.
- update ABI version
- fixup glXGetVideoSyncSGI and glXWaitVideoSyncSGI semantics
Do you mean making
On Saturday, September 29, 2007 6:47:51 am Dave Airlie wrote:
The preferred option at this point seems to be to add a new kernel
config option, e.g. CONFIG_DRM_MODESETTING or similar. Enabling the
option would prevent old X servers and Mesa from working with the DRM,
but they'd be
On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote:
Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error -
bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read
EDID block. Oct 2 00:32:19 coreduo i915 :00:02.0: TMDS-1: no
EDID data
This is probably the
On Tuesday, October 2, 2007 10:49 am Philippe Gaultier wrote:
2007/10/2, Jesse Barnes [EMAIL PROTECTED]:
On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote:
Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error -
bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable
On Thursday, October 4, 2007 8:55 pm Dave Airlie wrote:
Overall, looks nice.
At a high level, I'm wondering if something like this could be made more
generic... It seems like other GPUs will need similar relocation processing
so maybe the DRM should grow some generic reloc processing code?
On Sunday, October 7, 2007 4:26 pm Dave Airlie wrote:
At a high level, I'm wondering if something like this could be made
more generic... It seems like other GPUs will need similar
relocation processing so maybe the DRM should grow some generic
reloc processing code? Much of this stuff
On Monday, October 8, 2007 2:14 pm Dave Airlie wrote:
On Monday, October 8, 2007 10:13 am Keith Whitwell wrote:
Neither 42 nor 256 are very good - the number needs to be dynamic.
Think about situations where an app has eg. one glyph per texture
and is doing font rendering... Or any
On Monday, October 8, 2007 2:00 pm Philippe Gaultier wrote:
Hi,
I tried to check the timing stuff but (as I'm not a real developper)
I don't know how to test my timings easily.
Until now, I did several tries with no luck...
In fact, for each try, I have to compile the module, load it, check
We seem to see a lot of bug reports along the lines of, my machine
resumes but I can't see X or, I can see X but only with a bright
flashlight, etc. These sorts of problems are due to the fact that
the X server isn't designed to do full state save/restore, and none
of the available kernel drivers
On Thursday, October 18, 2007 2:01 pm Jesse Barnes wrote:
We seem to see a lot of bug reports along the lines of, my machine
resumes but I can't see X or, I can see X but only with a bright
flashlight, etc. These sorts of problems are due to the fact that
the X server isn't designed to do
On Friday, October 19, 2007, Jesse Barnes wrote:
Dave can you take a look at the new flag and also see what you think
about supporting suspend/resume in the event X hasn't started yet?
There's some #if 0'd code to support that case, but I haven't tested
it.
Ok Dave, this one's been updated
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined above?
You snipped out the reasons: we'll get bad behavior of
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined
On Tuesday, October 23, 2007 12:54 am Dave Airlie wrote:
shared-core/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
New commits:
commit a294aa724a1e932fb6017383e08532bfcc914df0
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Oct 23 17:54:07 2007 +1000
i915: require mfence
On Wednesday, October 24, 2007 6:35:14 am Pavel Machek wrote:
Hi!
We seem to see a lot of bug reports along the lines of, my machine
resumes but I can't see X or, I can see X but only with a bright
flashlight, etc. These sorts of problems are due to the fact that
the X server isn't
On Wednesday, October 24, 2007 1:17 pm Adrian Bunk wrote:
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt Intel 830M, 845G, 852GM, 855GM, 865G
On Tuesday, October 23, 2007 10:32 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad
Oops, this one fixes a couple of places where I was miscalculating the
actual MSC value.
Jesse
diff --git a/configs/default b/configs/default
index 620445f..3874dc7 100644
--- a/configs/default
+++ b/configs/default
@@ -79,8 +79,8 @@ APP_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GLUT_LIB) -l$(GLU_LIB)
On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote:
It still has some bugs. When moving windows between screens, Mesa
seems to lose track of the right vblank count to sync against
sometimes, so my test app's calls to glXWaitVideoSyncSGI return
immediately. Moving the window back
The vblank-rework tree has been sitting around with ported radeon and
i915 drivers for some time now, but users aren't seeing the power
saving benefits because it hasn't been merged upstream yet.
Several drivers still need to be ported, but I don't have the test
hardware:
mach64 (?)
mga
Ok, here's yet another version that uses the device model for the
suspend/resume, rather than pci hooks.
Greg, DRM desperately needs review of its device model usage, can you
take a look at this patch and the current drm_sysfs.c code? Right now,
we're mixing class_devices and regular devices
On Friday, October 26, 2007 1:02 am Michel Dänzer wrote:
On Thu, 2007-10-25 at 11:18 -0700, Jesse Barnes wrote:
The vblank-rework tree has been sitting around with ported radeon
and i915 drivers for some time now,
... except i915 still doesn't increment the counters at the beginning
On Friday, October 26, 2007 1:14 am Michel Dänzer wrote:
On Thu, 2007-10-25 at 10:25 -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote:
It still has some bugs. When moving windows between screens,
Mesa seems to lose track of the right vblank count
On Thursday, October 25, 2007 9:59 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
Ok, here's yet another version that uses the device model for the
suspend/resume, rather than pci hooks.
Greg, DRM desperately needs review of its device model usage, can
On Friday, October 26, 2007 10:10 am Kay Sievers wrote:
The conversion is already queued in Greg's tree, and in -mm:
http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob;f
=driver/drm-convert-from-class_device-to-device-in-drivers-char-drm.pa
On Friday, October 26, 2007 10:10 am Kay Sievers wrote:
On 10/26/07, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, October 25, 2007 9:59 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
Ok, here's yet another version that uses the device model
On Friday, October 26, 2007 12:08 pm Kay Sievers wrote:
How does this conversion look?
Seems fine, at a first look. You moved the device structure into the
object where it belongs, instead of allocating one, and saving the
pointer. You should really considering changing the core to do the
)
(EE) [drm] drmOpen failed.
(EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.
Dmesg messages: i915: Unknown symbol __you_cannot_kmalloc_that_much
If reverted this commit, above error disappeared:
commit 1e2a2bababf3fbaa0a665983856761c2284dba30
Author: Jesse Barnes [EMAIL PROTECTED
On Monday, October 29, 2007 1:15 am Dave Airlie wrote:
Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack
of coherency..
The attached patches add a new AGP interface for this purpose and
implements
On Monday, October 29, 2007 12:52 pm Dave Airlie wrote:
In this case, we're performing basically a
dma_sync*(...DMA_TO_DEVICE) right? Can we be sure that a single
flush is sufficient? Is there any window between when we flush and
when we start accessing memory with the device that we
On Monday, October 29, 2007 1:12 pm Keith Packard wrote:
On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
In this case, we're performing basically a
dma_sync*(...DMA_TO_DEVICE) right?
But this is just for the GPU; every other DMA device in the system is
cache-coherent.
Right
Arg, eventually I'll send this mail correctly (last one was rejected
since my @intel.com address isn't a subscriber).
How does this one look?
Thanks,
Jesse
On Monday, October 29, 2007 2:17 pm Chris Rankin wrote:
Hi,
A NULL pointer is killing OpenGL for my Radeon 9200; here's a quick
fix.
On Wednesday, October 31, 2007 3:12 Mathieu Bérard wrote:
+void mach64_disable_vblank(struct drm_device * dev, int crtc)
+{
+ drm_mach64_private_t *dev_priv = dev-dev_private;
u32 status = MACH64_READ(MACH64_CRTC_INT_CNTL);
- DRM_DEBUG(before install CRTC_INT_CTNL:
On Thursday, November 01, 2007 11:24 Mathieu Bérard wrote:
Jesse Barnes a écrit :
I think this bit might cause problems. Since it doesn't look like
you're using a hardware provided vblank count register, you'll want
to keep vblank interrupts on after the first enable call so that
it'll
On Thursday, November 01, 2007 12:06 Mathieu Bérard wrote:
Jesse Barnes a écrit :
Forgive my lack of global understanding of the whole issue but my
conclusion is that we just can't disable vbl interrupt on hardware
which lack vbl count in hardware, right ?
That's one option, yes
On Sunday, November 04, 2007 11:28 Zhenyu Wang wrote:
[PATCH] i915: fix missing G33 detect in IS_I9XX
G33 detect seems missing with Jesse's suspend/resume patch.
---
shared-core/i915_drv.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/shared-core/i915_drv.h
Since the driver unload will probably want to use the register map we
shouldn't unmap it until after the unload callback returns. This allows
load/unload to work again with i915.
Does this look ok? If so, I'll push it into modesetting-101.
Jesse
diff --git a/linux-core/drm_drv.c
On Tuesday, November 13, 2007 10:25 pm Dave Airlie wrote:
NAK...
I already fixed this, we have a driver mapping.. otherwise we leak
mappings if userspace dies..
I don't see the fix, the latest tree gives an oops on unload with something
like this...
I guess somehow the i915_load isn't using
On Wednesday, November 14, 2007 8:11 am Jesse Barnes wrote:
On Tuesday, November 13, 2007 10:25 pm Dave Airlie wrote:
NAK...
I already fixed this, we have a driver mapping.. otherwise we leak
mappings if userspace dies..
I don't see the fix, the latest tree gives an oops on unload
On Saturday, December 01, 2007 1:02 am Robert Noland wrote:
This is a patch against HEAD of my latest efforts porting the i915
suspend code over to bsd. I would really like some feedback from
folks with hardware that sucks less than mine.
Hi Robert, the patch looks great to me (though one
On Saturday, December 01, 2007 9:59 am Robert Noland wrote:
On Sat, 2007-12-01 at 08:40 -0800, Jesse Barnes wrote:
Hi Robert, the patch looks great to me (though one little nit,
don't we
have a DRM PCI config space wrapper? that would let us get rid of
a couple of #ifdefs). Sorry I've
The map removal code was blithely freeing the lock structure, even if it was
part of a _DRM_DRIVER mapping. This caused X to crash at startup if you used
a DRI aware driver.
Look good? There may be a nicer way to do it...
Jesse
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index
Since the _DRM_DRIVER mapping stuff went in, i915 has been panicing at
unload time. However, the driver appears to be correctly using the new
_DRM_DRIVER flag, so it's not immediately obvious what's going wrong.
This hacky workaround prevents the crash.
Jesse
diff --git
If drmMinor = 6, the intel DDX driver will enable vblank events on both
pipes. If drmMinor = 10 on pre-965 chipsets, the intel DDX driver
will swap the pipe-plane mapping to allow for framebuffer compression
on laptop screens. This means the secondary vblank counter
(corresponding to pipe B)
next suspend/resume try:
BLE drm_addmap_core a: map 81007c2d9b00, handle
BLE drm_addmap_core c: map 81007c2d9b00, handle c20010092000
BLE drm_rmmap_locked b: map 81007c2d9b00, handle c20010092000
BLE drm_addmap_core a: map 81007c2d9b00, handle
Until last night, it had been over a month since a vblank problem was
reported, so I figure now is a good time to try to break things again.
The vblank-rework tree has been soaking for quite awhile now, and I don't
think it'll get anymore exposure as a branch of the main drm tree. Since it
On Tuesday, January 22, 2008 9:55 am Jesse Barnes wrote:
Until last night, it had been over a month since a vblank problem was
reported, so I figure now is a good time to try to break things again.
The vblank-rework tree has been soaking for quite awhile now, and I don't
think it'll get
On Wednesday, January 23, 2008 4:29 am Michel Dänzer wrote:
On Tue, 2008-01-22 at 15:17 -0800, Jesse Barnes wrote:
@@ -378,6 +380,15 @@ u32 i915_get_vblank_counter(struct drm_device *dev,
int plane)
count = (high1 8) | low;
+ /*
+* If we're in the middle of the vblank
On Wednesday, January 23, 2008 8:28 am Jesse Barnes wrote:
On Wednesday, January 23, 2008 4:29 am Michel Dänzer wrote:
On Tue, 2008-01-22 at 15:17 -0800, Jesse Barnes wrote:
@@ -378,6 +380,15 @@ u32 i915_get_vblank_counter(struct drm_device
*dev, int plane)
count = (high1 8
On Wednesday, February 06, 2008 9:37 pm Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
Sorry this is so late, after much talking at LCA we decided to pull TTM
from this round and I had
On Wednesday, February 13, 2008 1:28 am Dave Airlie wrote:
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching, GPGPU apps,
different users on a per head one a single card..
http://dri.freedesktop.org/wiki/DRMRedesign
has
On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote:
On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote:
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching, GPGPU apps,
different users on a per head one a single
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
You don't want any application to be able to change CRTC-output
mappings, or bind BOs to CRTCs. Ideally you'd just have one app that
could do that on a given system, and it would contain the distribution's
policy regarding
On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote:
Dave there is one things that is needed to be redone: frame buffer
creation handling. And i would like we not freeze the API until
we had some time to play with it a bit. So i guess my question is
does this means modesetting API get
On Thursday, February 28, 2008 11:33 am Dave Airlie wrote:
the current API abstracts connectors from outputs, so in reality it
is encoders with connector properties at the moment.
you define a connector type and a connector id for each output and
can gang them together..
so wrt to the
On Sunday, March 02, 2008 10:17 pm Nan hai Zou wrote:
shared-core/i915_irq.c |7 +++
1 file changed, 7 insertions(+)
New commits:
commit 63fd6f284ddd1096d34b39941683ae244c1e01fc
Author: Zou Nan hai [EMAIL PROTECTED]
Date: Mon Mar 3 14:49:49 2008 +0800
[i915] 2D driver may
On Monday, March 03, 2008 10:34 am Thomas Hellström wrote:
1) Allocating all pages at once:
Yes, I think this might improve performance in some cases. The reason
it hasn't been done already is the added complexity needed to keep track
of the different allocation sizes. One optimization
On Friday, March 07, 2008 1:21 am Tom Cooksey wrote:
I'm a developer working on getting OpenGL ES working with QWS - the window
system built into Qt/Embedded. That is, Trolltech's own windowing system,
completely independent of X. The typical hardware we're working with is
PowerVR MBX, an
I found myself pointing people at krh's blog post on building the stack a lot
recently, so I figured it should be made into an x.org wiki page. We already
had a git development guide started, so I updated it based on krh's guide and
a couple of the replies in his blog.
Please give it a try
On Monday, March 10, 2008 2:02 am Thomas Fritzsche wrote:
Hi Jesse,
thanks for the x.org wiki-page.
The other day I also tried to follow-up on the krh's blog, but as you
mentioned, all this proto libs really send me in a dependency hell.
I like to build git x-server (intel), but with latest
On Tuesday, March 18, 2008 9:54 am Tom Cooksey wrote:
I've had some time to play with the modesetting branch. I am using a laptop
with an Intel 965GM, is this likely to work? At the moment, when I run
tests/modedemo I get a hard lock. :-/
Yeah, that should be a good platform...
I have a few
On Wednesday, March 19, 2008 3:14 pm Thomas Hellström wrote:
IIRC Eric had the relocation costs down in the negligible range, but
with the latest Mesa DRM bits, applying relocations seems to be a big
part of openarena profiles at least:
samples %app name symbol
On Friday, April 04, 2008 11:14 am Thomas Hellström wrote:
Dave Airlie wrote:
I'm just wondering if rather than specify all the CACHED and MAPPABLE and
SHAREABLE flags we make the BO interface in terms of CPU and GPU
operations..
So we define
CPU_READ - cpu needs to read from this
I just pushed a few changes updating the DRM modesetting sysfs support, both
for debugging and eventual HAL friendliness.
So far, the support is limited to describing outputs and generating hotplug
events. A typical card0 directory now looks like this:
.
|-- card0-DAC-1
| |-- device -
[Sorry for the DUP, forgot to cc lkml]
I just pushed a few changes updating the DRM modesetting sysfs support, both
for debugging and eventual HAL friendliness.
So far, the support is limited to describing outputs and generating hotplug
events. A typical card0 directory now looks like this:
On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote:
I was going to suggest that you plug it into the hotplug_stage_two
function but it looks like you have already done that. Things might be
routed differently now then since the last time I looked at the code,
are you sure that
On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote:
On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote:
On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote:
I was going to suggest that you plug it into the hotplug_stage_two
function but it looks like you have already
On Wednesday, April 09, 2008 10:23 am Alan Hourihane wrote:
On Wed, 2008-04-09 at 09:34 -0700, Jesse Barnes wrote:
On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote:
On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote:
On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz
On Sunday, April 27, 2008 3:25 am Michel Dänzer wrote:
On Sat, 2008-04-26 at 17:14 -0700, Jesse Barnes wrote:
New commits:
commit b45fe49bcd989be4e1327c13dd734410b395761c
Author: Jesse Barnes [EMAIL PROTECTED](none)
Date: Sat Apr 26 17:11:18 2008 -0700
Enum-ectomy of vblank
On Monday, May 05, 2008 11:22 am Miles Lane wrote:
On Mon, May 5, 2008 at 4:15 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Sun, 2008-05-04 at 21:12 -0400, Miles Lane wrote:
When I boot this kernel, everything seems okay, but after I leave the
machine for 30 minutes or so, I come
The attached patches, which depend on kernel mode setting, will allow us to
see some kernel messages even if a panic occurs while X is running.
I think the approach is fairly sound (using a notifier to let mode setting
drivers switch the front buffer), but there are some details to be worked
On Friday, May 16, 2008 2:26 pm Stephen Hemminger wrote:
After the screensaver does it's idle shut off of the monitor, it never
comes back. This is a new problem and only shows up post 2.6.25.
Console log messages:
Note: this message should be WARN_ON_ONCE() since it fills the disk!
May 16
On Thursday, May 29, 2008 11:26 pm Dave Airlie wrote:
On Thu, May 29, 2008 at 9:02 PM, David Woodhouse [EMAIL PROTECTED]
wrote:
On Thu, 2008-05-29 at 10:46 +1000, Dave Airlie wrote:
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it
On Tuesday, June 03, 2008 2:54 am Michel Dänzer wrote:
Nan hai (I hope I got that right), Jesse,
I think your drm commits 63fd6f284ddd1096d34b39941683ae244c1e01fc
([i915] 2D driver may reset Frame count value, this may lead driver)
and c7ee6cc269c26d8e7ed98a16a272eca63daab201 (Remove broken
On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
Michel, can you take a look at this? vblank wait is working really well
for me with the latest bits, but I found what I think is a page flip
related bug on 965. I've been testing with the attached pre-
post-modeset ioctl patch to the 2D
Michel, can you take a look at this? vblank wait is working really well for
me with the latest bits, but I found what I think is a page flip related bug
on 965. I've been testing with the attached pre- post-modeset ioctl patch
to the 2D driver. Changing modes, adding removing outputs and
On Sunday, June 22, 2008 6:55 am Pekka Paalanen wrote:
On Thu, 19 Jun 2008 15:13:51 -0700
Jesse Barnes [EMAIL PROTECTED] wrote:
In a shameless attempt to capitalize on the recent enthusiasm for
documenting things, I've put together a skeletal DRM developer guide.
Yay! \o/
The attached
On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
Michel, can you take a look at this? vblank wait is working really
well for me with the latest bits, but I found what I think
On Monday, June 23, 2008 11:02 am Jesse Barnes wrote:
On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
Michel, can you take a look at this? vblank wait is working really
On Wednesday, June 25, 2008 10:28 am Steven J Newbury wrote:
On Wed, 2008-06-25 at 16:29 +0100, Johannes Engel wrote:
Steven J Newbury wrote:
When building with a separate objdir -I$(top_srcdir)/libdrm needs to be
added to the intel Makefile.am otherwise only $(top_builddir)/libdrm is
On Monday, June 23, 2008 11:50 pm Michel Dänzer wrote:
On Mon, 2008-06-23 at 11:02 -0700, Jesse Barnes wrote:
On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
Michel
On Sunday, July 06, 2008 12:29 am vehemens wrote:
Would anyone object to using a struct for the vblank crtc data to eliminate
the multiple allocs / frees?
For example:
struct drm_vblank {
wait_queue_head_t vbl_queue;
atomic_t _vblank_count;
struct drm_vbl_sig_list
On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote:
Simon Thum escreveu:
But all this in the kernel is an impedance mismatch to me. What could it
buy us we don't have today?
Improve heavy-load behavior -- no jumping pointer.
(BTW, your mouse acceleration proposal [0] doesn't do it at
On Thursday, July 10, 2008 9:14:20 pm Dave Airlie wrote:
Right, and it's actually fairly common in other OSes. It sounds like the
biggest chunk of additional code will be dealing with acceleration; I'm
not sure how complex the latest algorithms are... Also input
transformation is an
Here's a patch that implements what we've been talking about:
- uses the atomic counter while interrupts are on, which means the
get_vblank_counter callback is only used when going from off-on to
account for missed events
- won't disable interrupts until the modeset ioctl is called, to
On Wednesday, July 16, 2008 11:51 pm Michel Dänzer wrote:
On Wed, 2008-07-16 at 16:01 -0700, Jesse Barnes wrote:
Here's a patch that implements what we've been talking about:
- uses the atomic counter while interrupts are on, which means the
get_vblank_counter callback is only used
On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
On Friday, July 18, 2008 1:12 am Michel Dänzer wrote:
On Thu, 2008-07-17 at 09:32 -0700, Jesse Barnes wrote:
On Wednesday, July 16, 2008 11:51 pm Michel Dänzer wrote:
On Wed
On Friday, July 18, 2008 10:24 am Jesse Barnes wrote:
On Friday, July 18, 2008 10:15 am Jesse Barnes wrote:
On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
On Friday, July 18, 2008 1:12 am Michel Dänzer wrote:
On Thu
On Friday, July 18, 2008 10:36 am Jesse Barnes wrote:
On Friday, July 18, 2008 10:24 am Jesse Barnes wrote:
On Friday, July 18, 2008 10:15 am Jesse Barnes wrote:
On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
On Friday
On Saturday, July 19, 2008 5:01 am Michel Dänzer wrote:
On Fri, 2008-07-18 at 14:41 -0700, Jesse Barnes wrote:
I failed to get the old update_vblank approach working, messing with the
counter is different under the new interrupt counter scheme.
Okay, I don't really understand why it's so
On Sunday, July 20, 2008 3:10 am Maarten Maathuis wrote:
Has it been considered to put this up somewhere for autogeneration?
I'm not very familiar with these documentation schemes, but i imagine
it's a matter of putting appropriately styled comments in code and
they'll appear?
It would be a
On Sunday, July 20, 2008 3:46 am Michel Dänzer wrote:
On Sat, 2008-07-19 at 12:54 -0400, Robert Noland wrote:
One other issue that I spotted while testing is that we initialize
vblank_disable_allowed to 0. The only place that it ever becomes true
is in post modeset. So, for me... vblanks
On Friday, July 25, 2008 1:09 pm Robert Noland wrote:
The changes that we discussed on irc are turning out to be slightly more
difficult than I expected... In the meantime, I'd like to push this to
master to get things more or less working again.
One thing I discovered was that, at least on
101 - 200 of 693 matches
Mail list logo
