On Sunday, September 5, 2004 8:31 am, Alan Cox wrote:
The only glue structure you need for most of this is
struct fb_device
{
struct fb_info *fb; /* NULL or frame buffer device */
struct dri_whatever *dri; /* As yet not nicely extracted DRI
object */
atomic_t refcnt;
void
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
The IA64 people want a file/ioctl interface on the /dev/vga0 devices
so that they can issue control calls to the active device in each VGA
space
I think ppc and sparc want this too, we'll use it for issuing legacy in/out.
Thanks,
Jesse
On Sunday, January 16, 2005 2:24 pm, Stephane Marchesin wrote:
Jesse Barnes wrote:
I figured other projects might have similar problems, thanks for checking
dri.
Please note that I didn't actually check the dri. I just happened to get
an MCA from time to time at mesa solo startup and your
On Saturday, January 29, 2005 4:38 pm, [EMAIL PROTECTED] wrote:
When I use solo on ia64, it sometimes causes an MCA upon startup. That's
because a memset is done on the framebuffer memory during init.
Please refer to this message from Jesse Barnes to know why this is bad :
http
On Monday, January 31, 2005 12:00 pm, Stephane Marchesin wrote:
Yes, other drivers suffer from that too (at least r128, i810 and mga as
far as I can see). However, as I said previously I don't understand them
enough to touch them.
Oh, I must have missed that message, sorry. It sure looks like
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote:
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no
Some ia64 platforms may not support write combining on all type of memory, so
we need to consult the EFI memory map before we try to set the write combine
attribute of a page. This patch will try to map a page write combined if
it's not an AGP page and the EFI memory map says it's ok,
On Friday, March 4, 2005 10:31 am, Jesse Barnes wrote:
Seems like we need something like this instead?
Index: linux-core/drm_dma.c
===
RCS file: /cvs/dri/drm/linux-core/drm_dma.c,v
retrieving revision 1.39
diff -u -r1.39
This simple patch makes it a little easier to build against arbitrary drm
trees. It'll pull in DRM_SOURCE_PATH from the environment if set, otherwise
it'll default to it's current value.
Jesse
Index: configs/default
===
RCS file:
I got this error when I tried to build linux-solo-ia64:
gcc -c -I. -I../../../include -I../../../src/mesa -I../../../src/mesa/main
-I../../../src/mesa/glapi -I../../../src/mesa/math
-I../../../src/mesa/transform -I../../../src/mesa/swrast
-I../../../src/mesa/swrast_setup
On Friday, March 04, 2005 6:01 pm, Roland Scheidegger wrote:
Paul Mackerras wrote:
Note that that check is also wrong for ppc64. I think it is going to
be wrong for most 64-bit platforms, since it is assuming that you can
never have ram at a higher physical address than any I/O devices.
Ok, so I've applied Stephane's fixes and sample_server comes up and
miniglxtest no longer segfaults. However, after setting the mode,
sample_server seems to die and wedge my display. miniglxtest just fails
right away with this message:
[EMAIL PROTECTED] miniglx]$ ./miniglxtest
[miniglx]
On Tuesday, March 8, 2005 12:01 am, Vladimir Dergachev wrote:
Hi Jesse !
On Mon, 7 Mar 2005, Jesse Barnes wrote:
Ok, so I've applied Stephane's fixes and sample_server comes up and
miniglxtest no longer segfaults. However, after setting the mode,
sample_server seems to die and wedge my
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid mixing code declarations warnings and
adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for
pointing out the resource size mismatch. The patch just fixes that (PCI
resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and
adds the checking for write combining regions I posted earlier
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds
On Tuesday, March 8, 2005 10:43 am, Jesse Barnes wrote:
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid mixing code declarations warnings
and adds vmalloc.h
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux
On Tuesday, March 8, 2005 12:24 pm, Jesse Barnes wrote:
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to
Stephane for pointing out the resource size mismatch
On Tuesday, March 08, 2005 4:24 pm, Paul Mackerras wrote:
Jesse Barnes writes:
Anyone have a preference on this stuff? Should we remove the checks
altogether or just the ones against the highmem variable? If we did the
latter, we could remove the #ifdefs altogether, though I'm not sure
On Tuesday, March 15, 2005 6:36 am, Dave Jones wrote:
I saw one report where the recent drm security hole fix broke dri
for one user. Whilst it seems an isolated incident, could this have
more impact than we first realised ?
Worse case scenario we can drop out the multi-bridge support for
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
Jesse Barnes [EMAIL PROTECTED] wrote:
I'd be happy to test and fix things, but the page table walker patches
broke ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed
On Thursday, March 24, 2005 2:33 am, Dave Airlie wrote:
Hi Andrew, Dave,
I've put a couple of patches into my drm-2.6 tree that hopefully fix up
the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop
the two patches in your tree.. the one from Brice and the one I attached
On Thursday, March 24, 2005 10:18 am, Dave Jones wrote:
I'm trying to get ahold of one--so hopefully I'll be able to test and
fix this stuff up when I do.
Aparently backing out the changes to via's tlb_flush routine fixed it
for one VIA user. I've not had a chance to look into it just
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in use.
I chose this method because Xegl wants radeonfb loaded and this
scheme has minimal code impact.
Seems
On Friday, June 10, 2005 8:39 am, Jon Smirl wrote:
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in
use. I
On Friday, June 10, 2005 8:52 am, Jon Smirl wrote:
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in
use. I chose this method because Xegl wants radeonfb loaded
On Friday, June 10, 2005 9:07 am, Jon Smirl wrote:
The Xegl model lets you pick where you get your drivers from. It just
runs on top of a driver stack providing the OpenGL/ES+EGL API. The
embedded systems I am aware of are ignoring mesa, drm, fbdev and and
building their own optimized
On Friday, June 10, 2005 10:46 am, Jon Smirl wrote:
We don't have enough people to finish one set of drivers and cetainly
not enough to finish two. What we are going to end up with is two
half finished systems. People working on KAA are capable of making
valuable contributions to DRI/DRM if
On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't
touch the hardware per-se (thus won't break your VGA
On Thursday, November 24, 2005 4:50 am, Thomas Hellström wrote:
There is some info in the old precision insight documentation about
the DRI infrastructure, (can't seem to find a link right now) But
generally there is only one global lock and something called the
drawable spinlock that is
to
accomplish this (using get_user_pages() etc.) or is there some existing
code I could leverage?
Thanks,
Jesse
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/char/drm/Makefile b/drivers/char/drm/Makefile
index 9d180c4..a212175 100644
--- a/drivers/char/drm/Makefile
+++ b/drivers
On Monday, March 6, 2006 12:28 pm, Thomas Hellström wrote:
The via driver has code that does this (via_dmablit.c) as a
device-specific IOCTL.
It maintains a queue of blit operations and fire them off when the
previous one is completed. The user calls a sync IOCTL to verify that
the operation
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_crtc.h 1969-12-31 16:00:00.0 -0800
+++ linux-2.6.21-rc4-modesetting/drivers/char/drm/drm_crtc.h 2007-03-21 08:41:51.0 -0700
@@ -0,0 +1,350 @@
+/*
+ * Copyright © 2006 Keith Packard
+ * Copyright © 2007 Intel Corporation
+ * Jesse Barnes [EMAIL PROTECTED]
+ */
+#ifndef
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 of the sorts of structures and layout
I've been
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 along nicely. Much
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 be
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 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 driver
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
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 debugging new console
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 describes and controls
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 userspace via ioctls
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 unregistration via the VT layer,
and updates
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:
new file mode 100644
index
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 are
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 and
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 have now where
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 concerned with the actual mode
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
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 interrupts when a client is actually
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 resets on mode switch, we need to rebase
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 from
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(diff, dev-vblank_count[crtc]);
Ok, I
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?
Oh, hm yeah. I guess it'll have to go in drm_device
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-detection in the core code by reporting
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 there some
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 like
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 just requested one for, so maybe
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
@@ -77,6 +77,70 @@ int
+ 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]);
I think atomic_add is
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:
+typedef struct drm_modeset_ctl
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
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 bit, second 64 bit) is exactly
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
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
97dcd7fd25c18d5148619254229f8d94efb55b44 Author
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 97dcd7fd25c18d5148619254229f8d94efb55b44 (from
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 11:13 -0700, Jesse Barnes wrote:
diff
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 11:13 -0700, Jesse Barnes wrote:
diff
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 uses the
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 apply the 3 Patches from Jesse Barnes
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 drm
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 Sergio
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 false
for that
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 of your xorg.conf?
no , seems that not obey to Option tiling false
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
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.
I
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 tiling and
framebuffer
compression right
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
will
work for you.
Let me
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. Graphics
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
information how to set up
Forgot to cc dri-devel, but you can follow this discussion on lkml.
Jesse
---BeginMessage---
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
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
judder.
This should
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 radeon): a client trying to sync
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't think of
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 the
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 correctly
One idea (with some handwaving
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 correctly
One idea (with some handwaving
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 Friday, September 21, 2007 2:51 am Michel Dänzer
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 moves the new fields over to the drawable
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 to the
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
1 - 100 of 693 matches
Mail list logo
