ave any ideas how to fix/track/debug that please let me know,
> same if you need more information.
I was seeing something similar on my 945, can you try this patchset?
It seems to make things much more stable for me.
http://lists.freedesktop.org/archives/intel-g
that reverts the quirk by Clemens (to replace it with
> disabling MSI entirely when the AMD NB doesn't accept them) seems to be a
> good idea regardless, since it's apparently not just about gfx. Jesse?
Yeah, that sounds fine. I can inc
On Tue, 30 Mar 2010 22:57:06 +0900
Norbert Preining wrote:
> On Mo, 29 Mär 2010, Jesse Barnes wrote:
> > I was seeing something similar on my 945, can you try this patchset?
>
> Tried it with git kernel commit b72c409 and your patches, but
> didn't change anything. Start
.
Francisco Jerez (4):
nouveau: Update nouveau_class.h.
nouveau: Small lighting related addition to nouveau_class.h.
nouveau: Fix up the stride of NV20TCL_LIGHT_BACK_*.
nouveau: Regenerate nouveau_class.h.
Jerome Glisse (1):
drm/radeon: tab/whitespace cleanup
Jesse Barnes
On Fri, 26 Mar 2010 13:41:08 -0700
Jesse Barnes wrote:
> On Fri, 26 Mar 2010 11:07:20 -0700
> Jesse Barnes wrote:
>
> > - if (iir & I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT)
> > + if ((iir & I915_DISPLAY_P
switching to the VT with all the good stuff on it.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c | 42 +-
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
ind
Yeah, I'm just getting the info for that now. But I don't think we
have subscriber lists, so everyone will have to re-subscribe to the new
list.
I'll send out a note to dri-devel when it's all set.
--
Jesse Barnes, Intel Open Source Technology Center
---
sting subscription options related to delivery and
digests.
Have fun using the new list!
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself.
On Fri, 26 Mar 2010 11:07:19 -0700
Jesse Barnes wrote:
> On 945, vblank delivery alone seems unreliable. The PIPE*STAT bits get
> set correctly, but interrupts occur at a low frequency relative to
> refresh. If we enable VSYNC interrupts as well however (even though we
> only chec
On Wed, 5 May 2010 11:12:13 +1000
Dave Airlie wrote:
> So at startup X drivers genearlly seem to ask for a list of
> connectors and status for them, and if it can't find any connected,
> it goes to unknown, and if none of those they fall over and X exits.
> Idea 1 was to just pick a connector and
On Wed, 23 Jun 2010 13:12:59 +1000
Dave Airlie wrote:
> From: Jesse Barnes
>
> Jesse's initial patch commit said:
>
> "At panic time (i.e. when oops_in_progress is set) we should try a bit
> harder to update the screen and make sure output gets to the VT, since
&
arly the case when it's the DRI
> stuff which oopsed, which is not exactly an uncommon occurrence lately ;)
>
> Oh well, the best way to tell is to ship-it-and-see.
To avoid the oops part (which as I said should still be safe) we could
add a new panic_in_progress flag, that would ma
On Wed, 23 Jun 2010 13:36:37 -0700
Andrew Morton wrote:
> On Wed, 23 Jun 2010 13:05:47 -0700
> Jesse Barnes wrote:
>
> > On Wed, 23 Jun 2010 12:56:05 -0700
> > Andrew Morton wrote:
> >
> > > On Wed, 23 Jun 2010 13:12:59 +1000
> > > Dave Airlie
cking for IS_PINEVIEW()
> in i915_backlight_init().
>
> Review URL: http://codereview.chromium.org/2830015
> Signed-off-by: Bryan Freed
How does this compare to Matthew's native backlight support? AFAIK
that patch is still outstanding due to the need for some changes to the
backl
vt.c bug coupled with another problem, which in
> turn got opened as a separate bugzilla entry:
>
>http://bugzilla.kernel.org/show_bug.cgi?id=16252
>
> which in turn then got closed. I dunno.
Yeah, this is weird. Norbert, do you still see this? Have you tried
to bisect it?
pci_domain_nr(dev->pdev->bus);
> >
> > error: implicit declaration of function ‘pci_domain_nr’
> > on m68k without PCI.
>
> I don't think I want to add an ifdef CONFIG_PCI into the drm layer for
> this, since we seem to be okay everywhere else,
>
> l
> > Hm, so pci_domain_nr should just return 0 on platforms where
> > CONFIG_PCI_DOMAINS isn't set. I'd expect that to be the case when
> > CONFIG_PCI=n... Maybe we just need to shuffle the definition
> > around?
>
> I suspect something like the attached would suffice.
>
> Or maybe moving the CO
(probably a "task hung" message?).
Does this happen reliably? Does a previous kernel work ok?
--
Jesse Barnes, Intel Open Source Technology Center
--
Create and publish websites with WebMatrix
Use the most popular FR
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a ueve
On Saturday, March 17, 2007, Sergio Monteiro Basto wrote:
> Hi ,
> I need your help , I am trying compile intel video drive and give me
> this:
>
> checking for xf86Modes.h... no
> symlink mode code
> configure: error: Must have X server >= 1.3 source tree for mode setting
> code. Please specify --
(drm_device_t *dev, bool can_grow)
+{
+ return 0;
+}
diff -Napur -X /home/jbarnes/dontdiff linux-2.6.21-rc4/drivers/char/drm/drm_crtc.h linux-2.6.21-rc4-modesetting/drivers/char/drm/drm_crtc.h
--- linux-2.6.21-rc4/drivers/char/drm/drm_crtc.h 1969-12-31 16:00:00.0 -0800
+++ linux-2.6.21-rc4-modese
On Thursday, March 22, 2007 6:54 am Alex Deucher wrote:
> On 3/22/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Tuesday, March 20, 2007, Jakob Bornecrantz wrote:
> > > Added structs and ioctls for modesetting in kernel
> >
> > And just to give you an idea o
Some people were asking about modeseting on #dri-devel this morning so I
thought I'd post an update (airlied is asleep so we can blame him for all
the problems :).
The modesetting-101 branch of the DRM tree is coming along nicely. Much of
X.Org's modesetting code has been pulled in (will look
On Wednesday, April 11, 2007, Jesse Barnes wrote:
> Some people were asking about modeseting on #dri-devel this morning so I
> thought I'd post an update (airlied is asleep so we can blame him for
> all the problems :).
>
> The modesetting-101 branch of the DRM tree is coming
On Wednesday, April 11, 2007, Keith Packard wrote:
> > o what should the initial config be? cloned? multihead? single,
> > primary head with other heads initialized to a blank screen?
>
> The X server has some built-in policy for what the starting mode should
> look like. I think we should
In playing around yesterday, we found that some drivers will
unnecessarily enable interrupts for vblank events. Since these tend to
happen frequently (60+ Hz), they'll cause your CPU to wake up a lot,
which will waste power if they're not really in use.
This patch hacks the radeon driver to on
On Wednesday, May 9, 2007 8:56 am Eric Anholt wrote:
> > I suspect doing it like this might break userspace expectations
> > about the behaviour of the vblank counter. It would be better to do
> > it similarly to how Eric Anholt did it for i915, i.e. by toggling
> > the vblank interrupt in the 2D d
Patches at http://www.kernel.org/pub/linux/kernel/people/jbarnes/patches
drm-modesetting-core.patch
drm-modesetting-i915.patch
console-unregister.patch
(Sorry the first two are slightly too big for lkml; they're against the
DRM tree at git://git.freedesktop.org/git/mesa/drm.)
In collaborati
Randy just informed me that the patch limits are bigger now, so here are the
actual patches.
This patch allows for proper console unregistration via the VT layer, and
updates the FB layer to use it. This makes debugging new console drivers
much easier, since you can properly clean them up before
On Thursday, May 17, 2007 3:32 pm Jesse Barnes wrote:
> Randy just informed me that the patch limits are bigger now, so here
> are the actual patches.
>
> This patch allows for proper console unregistration via the VT layer,
> and updates the FB layer to use it. This makes debugg
On Thursday, May 17, 2007 3:37 pm Jesse Barnes wrote:
> This patch adds the core of the new DRM based modesetting system. It
> creates several new structures in the DRM, the primary ones being the
> CRTC, which controls all aspects of your device's CRTC(s), output,
> which descr
On Thursday, May 17, 2007 3:40 pm Jesse Barnes wrote:
> This patch adds support for DRM modesetting to the Intel DRM driver
> and stubs out a simple FB driver to sit underneath. The code had to
> be refactored a bit, since current DRM drivers tend to be fully
> initialized by userspac
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> > Randy just informed me that the patch limits are bigger now, so here
> > are the actual patches.
> >
> > This patch allows for proper console unregistratio
On Thursday, May 17, 2007, Luca Tettamanti wrote:
> Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> > This patch adds the core of the new DRM based modesetting system.
>
> A couple of comments on drm_fb since I'm somewhat familiar with fb code:
>
On Friday, May 18, 2007 12:33 pm Luca Tettamanti wrote:
> > Yeah, there's more sharing that could be done... though I don't
> > think the fb layer has the bits to actually grab EDIDs.
>
> There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I
> wrote them for the radeon driver, but now
On Monday, May 21, 2007, Benjamin Herrenschmidt wrote:
> > In collaboration with the FB guys, we've been working on enhancing
> > the
> > kernel's graphics subsystem in an attempt to bring some sanity to the
> > Linux graphics world and avoid the situation we have now where
> > several
> > kernel a
On Tuesday, May 22, 2007, Philipp Klaus Krause wrote:
> Benjamin Herrenschmidt schrieb:
> >> In collaboration with the FB guys, we've been working on enhancing
> >> the
> >> kernel's graphics subsystem in an attempt to bring some sanity to the
> >> Linux graphics world and avoid the situation we ha
On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote:
> > The current code does its best to figure out what modes are available
> > and tries to pick a good one for each display. It sounds like you're
> > mainly
We've had some IRC and off-list discussions about how to improve the
DRM's vblank code to be a bit more power friendly. The core requirement
is that we only enable vblank interrupts when a client is actually waiting
for a vblank event (be it a signal or a wakeup).
This patch updates the DRM core,
On Monday, June 11, 2007 11:14:45 Ian Romanick wrote:
> Jesse Barnes wrote:
> > We've had some IRC and off-list discussions about how to improve the
> > DRM's vblank code to be a bit more power friendly. The core requirement
> > is that we only enable vblank inter
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> On Mon, 2007-06-11 at 10:59 -0700, Jesse Barnes wrote:
> > The patch doesn't yet deal with two obvious cases (and probably more
> > that I'm missing, it's untested yet):
> > - the hardware counter rese
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> ick. just read the registers and return the value here. We should place
> wrap-detection in the core code by reporting the range of the register
> values; with the offset suggested above, that would result in a single
> addition to convert fr
On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > +static u32 last_vblank; /* protected by dev->vbl_lock */
>
> uh. per crtc?
Oh, hm yeah. I guess it'll have to go in drm_device.
> > + atomic_add(
On Monday, June 11, 2007 7:13:04 Jesse Barnes wrote:
> On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > +static u32 last_vblank; /* protected by dev->vbl_lock */
> >
> > uh. per crtc?
>
>
On Monday, June 11, 2007 7:32:34 Jesse Barnes wrote:
> On Monday, June 11, 2007 7:13:04 Jesse Barnes wrote:
> > On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> > > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > > +static u32 last_vblank;
On Monday, June 11, 2007 11:59:23 Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > > ick. just read the registers and return the value here. We should
> > > place wrap-de
On Tuesday, June 12, 2007 7:53:13 Ian Romanick wrote:
> If an app is running with swap buffers synchronized to vblank, won't
> it go through the following:
>
> - Render scene.
> - Start to wait for vblank.
> - Enable vblank int.
> - Wait.
> - Disable vblank int.
> - Do swap.
> - Repeat.
>
> Isn't t
On Tuesday, June 12, 2007 10:58:24 Keith Packard wrote:
> On Tue, 2007-06-12 at 19:23 +0200, Michel Dänzer wrote:
> > That would mean one register read sequence per waiter per interrupt
> > whereas otherwise it's one read sequence per CRTC (which is enabled
> > and has waiters) per interrupt. Looks
On Tuesday, June 12, 2007 10:05:46 Keith Packard wrote:
> On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote:
> > Hm, we might get nonsensical values or a non-incrementing vblank
> > count, but otoh userspace didn't bother to enable vblank events for
> > the pipe it
On Wednesday, June 13, 2007 12:24:05 Michel Dänzer wrote:
> On Tue, 2007-06-12 at 13:37 -0700, Jesse Barnes wrote:
> > diff --git a/linux-core/drm_irq.c b/linux-core/drm_irq.c
> > index f229f77..8125b75 100644
> > --- a/linux-core/drm_irq.c
> > +++ b/linux-core/drm_irq.c
> > > + if (temp & VSYNC_PIPEA_FLAG)
> > > + atomic_add(i915_get_vblank_counter(dev, 0),
> > > +&dev->vblank_count[0]);
> > > + if (temp & VSYNC_PIPEB_FLAG)
> > > + atomic_add(i915_get_vblank_counter(dev, 1),
> > > +&dev->vblank_count[1]);
> >
On Thursday, June 14, 2007 12:40:46 Michel Dänzer wrote:
> On Wed, 2007-06-13 at 14:26 -0700, Jesse Barnes wrote:
> > On Wednesday, June 13, 2007 12:24:05 Michel Dänzer wrote:
> > > On Tue, 2007-06-12 at 13:37 -0700, Jesse Barnes wrote:
> > > > +
Ok, I updated the branch with most of your suggestions. I think the
ioctl still needs work (just made it a u64 for now), since at the very
least we'll need to add the new one Keith suggested to handle CRTC
reconfiguration.
Please take a look and I'll test some more. I also added some comments
On Friday, June 15, 2007 4:15:57 Michel Dänzer wrote:
> On Thu, 2007-06-14 at 11:37 -0700, Jesse Barnes wrote:
> > Ok, I updated the branch with most of your suggestions. I think
> > the ioctl still needs work (just made it a u64 for now),
>
> Yeah, that (first member 32 b
For reference, here's a patch converting radeon to the new vblank
infrastructure. The basics are pretty easy:
- add a get_vblank_counter hook to return the current vblank event
count
- add enable/disable_vblank hooks to enable/disable the vblank
interrupt
- init the vblank core (drm_
On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
> On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote:
> > New commits:
> > diff-tree 7f2a1cf2753c0c97b1290469a15322f7549f78ae (from parents)
> > Merge: d2d53024fb4003a6b86a3ea1ea33c76ac20bebc9
> > 97dcd7fd25c18
On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
> On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
> > On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
> > > On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote:
> > > > diff-tree 97dcd7fd25c18d51
On Monday, June 25, 2007 12:44:16 Jesse Barnes wrote:
> On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
> > On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
> > > On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
> > > > On Fri, 2007-06-22 at 1
On Monday, June 25, 2007 12:44:16 pm Jesse Barnes wrote:
> On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
> > On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
> > > On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
> > > > On Fri, 2007-06-22 at 1
On Wednesday, June 27, 2007 2:55:39 am Michel Dänzer wrote:
> > Ok, I retested without the if (!IS_965) ... code in place, which was
> > working for you. On my box, I get a hard hang when I run the attached
> > test program, or any other gl program.
>
> I tried the clutter examples (clutter also u
On Wednesday, June 27, 2007 6:30:14 am Philippe Gaultier wrote:
> Anyway, I would like to remove Xorg and only use the framebuffer because
> - I don't need X
> - I would like to reduce the whole application footprint
>
> So, I did the following :
>
> 1- I tried to appl
On Tuesday, July 3, 2007 5:26:07 Philippe Gaultier wrote:
> Anyway, I tried the last release of the modsetting-101 branch
> yesterday night and I wasn't able to make it work :
> - I compiled the code (everything was fine)
> - I inserted the drm module
>
> Jul 2 21:10:56 coreduo [drm] Initialized
What hardware do you have? Does Xv based video work again if you add
Option "tiling" "false"
to the Intel device section of your xorg.conf?
I thought Wang's fix would have taken care of this problem, but it
sounds like we still have a bug here...
Jesse
On Sunday, July 29, 2007 11:29 am Sergi
> > Does Xv based video work again if you add
> > Option "tiling" "false"
> > to the Intel device section of your xorg.conf?
>
> no , seems that not obey to Option "tiling" "false"
> I try latest git and here is the xorg diff in attach
Oh, you should also add
Option "FramebufferCompression" "f
On Monday, July 30, 2007 2:01 pm Sergio Monteiro Basto wrote:
> On Mon, 2007-07-30 at 13:37 -0700, Jesse Barnes wrote:
> > > > Does Xv based video work again if you add
> > > > Option "tiling" "false"
> > > > to the Intel device section
I finally found some time to create a new wiki page for all the
modesetting/configuration related DRM enhancements we've been talking about:
http://dri.freedesktop.org/wiki/DrmModesetting
Please take a look and let me know what you think. I still have to go through
all the feedback I received f
On Wednesday, August 8, 2007 10:33 am Sergio Monteiro Basto wrote:
> On Wed, 2007-08-08 at 10:21 +0800, Zhenyu Wang wrote:
> > Pls raise any Xorg video driver issue to
> > [EMAIL PROTECTED], not dri-devel.
>
> xorg ML have many traffic
>
> > It's good if you can pull latest fixes to test it, thanks
On Wednesday, August 8, 2007 1:11 pm Sergio Monteiro Basto wrote:
> On Wed, 2007-08-08 at 11:12 -0700, Jesse Barnes wrote:
> > Sergio, to reiterate (sorry I lost the earlier messages in this
> > thread),
> > you're having trouble with Xv unless you disable
On Thursday, August 9, 2007 5:33:20 am Sergio Monteiro Basto wrote:
> On Wed, 2007-08-08 at 16:13 -0700, Jesse Barnes wrote:
> > I just tested again on my 915 machine. Xv seems to work well, the
> > display is ok and the speed is right, so hopefully the latest bits
> >
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
> Hi,
>
> On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > There should be master (possibly one for each card) which be the only
> > one being able to do this call:
> > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
>
>
On Wednesday, August 22, 2007 6:47:31 am Matthias Hopf wrote:
> On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
> > On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
> > > Because we won't get an ix86 emulator in kernel space, Linus and others
> > > have been pretty clear about that. Graph
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote:
> I am *not* opposed to a scheme where userspace has to provide
> information how to set up a desired mode. (Although I'm not conviced
> it's really necessary -- both Keith Packard and Dave Airlie argued that
> mode setting is simple
On Thursday, August 23, 2007 8:38:46 pm Tiago Vignatti wrote:
> I hope you guys are not forgetting who wants to start two (or more)
> instances of the Xorg server (for multiseat purposes or what ever).
Oh definitely not. This work should make muliseat much easier.
> In this case, the daemon - in
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
> Hi,
>
> On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote:
> > On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED]
wrote:
> > > I am *not* opposed to a scheme where userspace has to provide
Forgot to cc dri-devel, but you can follow this discussion on lkml.
Jesse
--- Begin Message ---
I just narrowed down a weird problem where I was losing more than 50% of
my vblank interrupts to what seems to be the hires timers patch. Stock
2.6.23-rc5 works fine, but the latest (171) kernel from
Both the generic DRM vblank-rework and Intel specific pipe/plane
swapping have uncovered some vblank related problems which we discussed
at XDS last week. Unfortunately, no matter what we do (including
the "do nothing" option), some applications will break some of the time
in the new world ord
On Tuesday, September 18, 2007 3:10 pm Torgeir Veimo wrote:
> On 18 Sep 2007, at 22:54, Jesse Barnes wrote:
> > Any other thoughts?
>
> Please do add the option of retrieving a serial number of the vsync
> irq. It is very handy when debugging video playback that suffers from
>
On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote:
> On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
> > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new
> > world of dyanmically controlled outputs and CRTCs (at least for
> > i915 and rade
On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote:
> > So:
> > - use the vblank-rework tree to make per-CRTC vblank counters (as
> > you
> > say, this breaks some setups but will fix others)
>
> Out of curiosity, what setups are you thinking of that this will fix on
> its own? Can'
On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
> > correctly
>
> One idea (with some handwaving :) would be the common code keeping
> around a pointer to the driver's vblank_flags variable or keeping
> track of t
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > > - add code to Mesa so GetMSC/WaitForMSC set
> > > > DRM_VBLANK_SECONDARY cor
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > > - add code to Mesa so GetMSC/WaitForMSC set
> > > > DRM_VBLANK_SECONDARY cor
On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> > On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> > > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > > > On Frid
On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote:
> On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote:
> > On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> > > On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> > > > that mo
On Wednesday, September 26, 2007 9:39 am Michel Dänzer wrote:
> > Err yeah I was describing it backwards. The __DRIscreen hooks for
> > the MSC stuff all point to dri_util.c wrapper functions that end up
> > calling the driver hooks. However, drivers always set their hooks
> > to either NULL or t
Per the discussion in the other vblank thread, this patch does several
things:
- adds a new getMSC hook to __DRIdrawableRec
- updates glXGetVideoSyncSGI to use the new hook if present
- adds new vblank fields to __DRIdrawablePrivateRec
- adds a new driDrawableGetMSC32 vblank.c routine
t
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 o
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, i
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 du
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_
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 fro
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 windo
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
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 sema
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 0
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? Mu
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
601 - 700 of 741 matches
Mail list logo
