rc/i830_memory.c
> index ca15964..132642f 100644
> --- a/src/i830_memory.c
> +++ b/src/i830_memory.c
> @@ -918,10 +918,13 @@ i830_allocate_memory_tiled(ScrnInfoPtr pScrn, const
> char *name,
> mem = i830_all
sole mode (which has a small active area, and we don't set
scaling because we assume that that's the real 1:1 native mode).
Xorg.0.log between success and failure would be the way to tell.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Descri
this limit imposed by the hardware or the driver? Can the hardware do
> RGBA16?
The public specs list r10g10b10a2, r16g16b16a16, and many others as
available formats.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digit
}
> + }
>
> + /* Pin and relocate */
> + for (i = 0; i < args->buffer_count; i++) {
> object_list[i]->pending_read_domains = 0;
> object_list[i]->pending_write_domain = 0;
> ret = i915_gem_object_pin_and
uld quietly return to userland.
> - pinned = i + 1;
> +
> + /* unpin all of our buffers */
> + for (i = 0; i < pinned; i++)
> + i915_gem_object_unpin(object_list[i]);
> +
>
ll require intrusive changes targeted
at the next kernel release, not this one.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_gem_tiling.c |7 ---
drivers/gpu/drm/i915/i915_reg.h|1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --g
compositor wakes up to do a
vblank-synced composite, not wait for the compositor to grab the stale
frame before continuing.
In the world I imagine, the app's running nearly flat-out (waiting only
for getting its n-1 frame completed), getting damage posted as it
"swaps" (flips f
d)
> + q = NULL;
> + }
> + if (tail)
> + tail->next = e;
> + else
> +
ig.fb_base = pci_resource_start(dev->pdev, 0);
> +
> + if (IS_MOBILE(dev) || IS_I9XX(dev))
> + num_pipe = 2;
> + else
> + num_pipe = 1;
> + DRM_DEBUG("%d display pipe%s available.\n",
> + num_pipe, num_pipe >
>dma_status_page);
> + I915_READ(HWS_PGA); /* posting read */
> + }
> return 0;
> + }
>
> obj = drm_gem_object_alloc(dev, 4096);
> if (obj == NULL) {
>
>
> ___
> Intel-gfx mailing l
functions->ClearColor = intelClearColor;
> }
>
>
> _______
> Intel-gfx mailing list
> [EMAIL PROTECTED]
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Eric
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:
> > > >
left flags in (had it removed but not committed). It's not actually
> necessary. I'll post an updated set with the libdrm stuff and this fixed.
addr_ptr should probably be called "offset" since it's not actually a
pointer, right?
--
Eric Anholt
[EMAIL PROTECTED]
would never see an interrupt again.
This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract
out the steps needed to change the reported interrupts.
Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/d
This is the patch series I've pushed to for-airlied for 2.6.28. It's similar
to the previous IRQ patch series, but with the IMR -> IER change that had
snuck in reverted. On non-MSI chipsets, twiddling IER apparently sometimes
gets the interrupt wedged despite IIR=0, and the interrupt gets disable
ay to zero.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_irq.c | 40 +++---
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ca3ed18..047b
On Fri, 2008-11-07 at 14:01 +, Steven J Newbury wrote:
> On Tue, 2008-11-04 at 16:04 -0800, Eric Anholt wrote:
> > On Tue, 2008-11-04 at 02:03 -0800, Keith Packard wrote:
> > > The pipestat fields affect reporting of all vblank-related interrupts, so
> > > we
>
This fixes hangs on 855-class hardware by avoiding double attachment of the
driver due to the stub second head device having the same pci id as the real
device.
Other DRM drivers probably want this treatment as well, but I'm applying it
just to this one for safety.
Signed-off-by: Eric A
000) << 32;
+ val = (uint64_t)((obj_priv->gtt_offset + obj->size - 4096) &
+ 0xf000) << 32;
val |= obj_priv->gtt_offset & 0xf000;
val |= ((obj_priv->stride / 128) - 1) << I965_FENCE_PITCH_SHIFT;
if (obj_p
et 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 is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> --
>
It's not used in any other drivers, and doesn't look like it will be from
drm.git master.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_irq.c | 80
drivers/gpu/drm/drm_lock.c |9 -
drivers/gpu/drm/d
emitting wait-for-vblank-before-rendering
in the command stream. That path also falls back correctly, at the performance
cost of not being able to queue up rendering before the flip occurs.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h | 15 --
drivers/g
t; + dev_priv->irq_enable_reg = I915_INTERRUPT_ENABLE_FIX;
> +
> + dev_priv->pipestat[0] = 0;
> + dev_priv->pipestat[1] = 0;
> +
> + /* Disable pipe interrupt enables, clear pending pipe status */
> + I915_WRITE(PIPEASTAT, I915_READ(PIPEASTAT) & 0x8000);
> +
ay to zero.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_irq.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3b8c78b..5c2c3bf 100644
--- a
emitting wait-for-vblank-before-rendering
in the command stream. That path also falls back correctly, at the performance
cost of not being able to queue up rendering before the flip occurs.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h |4 -
drivers/g
Ack as long as things keep building.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the
G_ON(!list_empty(&dev_priv->mm.flushing_list));
> + if (!list_empty(&dev_priv->mm.flushing_list)) {
> + struct drm_i915_gem_object *obj_priv;
> + DRM_ERROR("flushing list not empty, still has:\n");
#x27;t
support MSI. That's a mistake, I'll get it cleaned up.
(MSI didn't actually get supported for integrated graphics until the
G965 for the desktop and GM45 for mobile, though it got supported for
ethernet and PEG earlier than that)
--
Eric Anholt
[EMAIL PROTECTED]
access to
the main ring, solving problem 1. And with DRI2 the kernel's the only
one in charge of the locking, so #2 should be OK as well (and if it
isn't, then we finally have a reason to go finer-grained with our
locking).
> > commit 35ad68c18148a18938ff4f40e945c9734e7d2265
> >
e BARs were expensive for some reason and they stuffed both the
framebuffer and registers into one PCI BAR, where you want the FB to be
WC and the registers to be UC. Not sure if they would be supportable
with this API or not. And if it's not, I'm not sure how much we care to
design for
On Fri, 2008-10-17 at 19:47 -0700, Linus Torvalds wrote:
>
> On Fri, 17 Oct 2008, Eric Anholt wrote:
> >
> > Yeah, none of us are on x86-64, so we missed those warnings in testing.
>
> Really? None of you use any modern CPU's, or you're _all_ running 32-bit
W, write cleaner code, and the warning just goes away on its own.
> Something like the appended. UNTESTED!
Yeah, none of us are on x86-64, so we missed those warnings in testing.
The change looks pretty good except for s/return 1/return 0/. We wanted
to pull the i_wish_it_was_ior
On Fri, 2008-10-17 at 02:04 -0700, Keith Packard wrote:
> On Fri, 2008-10-17 at 15:48 +0800, Zhenyu Wang wrote:
> > On 2008.10.16 23:27:12 -0700, Eric Anholt wrote:
> > > On Fri, 2008-10-17 at 13:16 +0800, Zhenyu Wang wrote:
> > > > From 4aab96c10fca2d5a3f89e56a4d6a96
drm: Set cliprects to NULL when changing drawable to having 0 cliprects.
This avoids setting the cliprects pointer to a zero-sized allocation.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
Signed-off-by: Eric Anholt <[
drm_free(info->rects, info->num_rects * sizeof(struct drm_clip_rect),
> + DRM_MEM_BUFS);
> + drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
>
> idr_remove(&dev->drw_idr, draw->handle);
That get_drawable_info should be under
riginally went with. It got messy when we wanted a
different mmap path, so that we had to do one of 1) or 2) anyway.
Also, I'm looking at a bunch of spu*.c code, and I'm having a hard time
finding something relevant for us, but maybe I'm not looking in the
right place. Can you
ioctl instead of .unlocked_ioctl as I understand.
Removing the volatile from both of these should be safe.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
ou're not VT switching (sometimes Linux systems I've
seen fail at this), in which case you might have a pile of junk in the
ring at resume time.
Overall, while my 3 regular-use machines have been suspend/resuming fine
as far as graphics go, we probably want tighter integration of
suspend/r
or more data.
For GEM I don't need tiling or swizzling information. I just ask the
kernel what the answer is, since the DDX hadn't been telling me the
information I needed in the past.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Descripti
ver mess they've got.
This gets us better merge process ("here's my short patch series on top
of linus"), something believable for our project's stable release (full
kernel, not a pile of kernel code that might work as long as you've
added our kernel subsystem patches a
On Fri, 2008-06-13 at 13:18 +0300, Timo Jyrinki wrote:
> 2008/6/12 Eric Anholt <[EMAIL PROTECTED]>:
> > I'm really having a hard time caring until someone comes up with
> > something other than a microbenchmark that has issues with teximage
> > performance.
>
&g
On Thu, 2008-06-12 at 17:44 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > We're getting close to ready to mark GEM on Intel as done. We've got
> > one failing testcase that we isolated this week with interrupt handling,
> > and we've got a fix in test
On Thu, 2008-06-12 at 17:17 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > We're getting close to ready to mark GEM on Intel as done. We've got
> > one failing testcase that we isolated this week with interrupt handling,
> > and we've got a fix in test
ibdrm with memory management that
is released and ready.
After I get at least 1-3 sorted out, I'll be working on 2d 2.4 release
process and putting together the kernel patch for submission to lkml.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED]
set_domain, to device-specific.
We've talked with krh, and there are a couple of different viable ways
to deal with the dri2 requirement for shared memory. That was basically
the only reason for it to be generic originally, and including use of
graphics memory objects for non-graphics pu
915_*.[ch] -> ../../linux/i915/i915_*.[ch]
drm/bsd/r128/Makefile
drm/bsd/r128/r128_drv.c
drm/bsd/r128/r128_*.[ch] -> ../../linux/r128/r128_*.[ch]
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROT
cation
> around a lot.
Sorry for the long delay! I committed most of your work, with a couple
of tweaks. I moved the lock grab in drm_addbufs_* to when it was
required to avoid the need for more error path code. Also, free(9) and
thus drm_free() should be just fine with being passed NULL. If it
isn
that
> problem.
>
> As for speed, the TTM-based i915tex driver is still substantially more
> CPU-efficient (which translates to faster for CPU-bound apps), than
> _any_ of the intel-modified drivers.
> Among other things, the texsubimage throughput is about 5x tha
On Wed, 2008-05-14 at 21:51 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> >
> > If the implementation of those ioctls in generic code doesn't work for
> > some drivers (say, early shmfs object creation turns out to be a bad
> > idea for VRAM drivers), I'
be supportable for everyone got moved to generic.
If the implementation of those ioctls in generic code doesn't work for
some drivers (say, early shmfs object creation turns out to be a bad
idea for VRAM drivers), I'll happily push it out to the driver.
--
Eric Anholt
t;
> No. Gem can't coop with it. Let's say you have a 512M system with two 1G
> video cards, 4G swap space, and you want to fill both card's videoram
> with render-and-forget textures for whatever purpose.
Who's selling that system? Who's building that system at
ostly well with every
> > use case.
>
> It's always been a big win to go to single-copy texturing. Textures
> tend to be large and nobody has so much memory that doubling up on
> textures has ever been appealing... And there are obvious use-cases
> like
pace.
> I think that it is a good way.
> What do you think about it?
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
s to a large extent. I'm not
> sure what the current i915 driver does. Anyway, we need a more
> fine-grained approach.
In master we hold the lock around execbuffer. Is getting multiple cpus
in the validate path a bottleneck, really, where a finer-grained
approach is needed?
--
l is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> --
> ___
> Dri-pa
On Wed, 2008-03-05 at 01:25 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> >
> >> c) User-space bo-caching and reuse.
> >> d) User-space buffer pools.
> >>
> >> TG is heading down the d) path since it also fixes the texture
> >> gra
de for the 3d driver,
to avoid the mapping and kernel page allocation overhead by using the
plain old libc allocator that already happily hangs on to mapped pages
for me. It might obsolete my buffer-reuse branch. However, the DRM
needs some fixes to allow this to happen.
--
Eric Anholt
On Fri, 2008-02-29 at 11:08 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Thu, 2008-02-28 at 10:08 +0100, Thomas Hellström wrote:
> >
> >> Eric Anholt wrote:
> >>
> >>> On Thu, 2008-02-28 at 06:08 +1000, Dave Airlie wrote
> >
ary buffer idling.
What are the performance results of using this? We've thought about
doing this before, but cworth's experiments with it in the 2d driver
were supposedly not too impressive. (but then, applying relocations to
currently in-flight buffers is
On Thu, 2008-02-28 at 10:08 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Thu, 2008-02-28 at 06:08 +1000, Dave Airlie wrote:
> >
> >>> I wasn't planning on a Mesa 7.1 (trunk code) release for a while, but I
> >>> could finish up
On Wed, 2008-02-27 at 21:55 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote:
> >
> >> Eric Anholt wrote:
> >>
> >>> On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wr
On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote:
> >
> >> shared-core/i915_dma.c | 13 +
> >> 1 file changed, 9 insertions(+), 4 deletions(-)
&
;mutex);
> - ret = drm_bo_wait (relocatee.buf, 0, 0, FALSE);
> - if (ret)
> - goto out_err1;
> -
> while (reloc_user_ptr) {
> ret = i915_process_relocs(file_priv, buf_handle,
> &reloc_user_ptr, &relocatee, buffers, buf_count);
&
AIL PROTECTED]>
>
> Committed. Is this chipset a variation on the i915 architechture?
965-ish.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
t's unreliable, along with not being an obvious performance
win in tests done in the 2d driver as I recall.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed
ho the hell have such hw ? :)) a scanout
>buffer which use 4Mo and user resizing to buffer which need 5Mo
>obviously we can't allocate it until we free the previous one... Maybe
>we can accept some kind of allocate over style or simply a resize
>function.
N
On Thu, 2007-10-18 at 07:55 +0800, Keith Packard wrote:
> On Wed, 2007-10-17 at 16:40 -0700, Eric Anholt wrote:
>
> > Turn off CRTCs
> > Unpin old framebuffer
> > Allocate new framebuffer
> > Copy from old to new
>
> We needn't copy on resize, leaving u
your repeated sampling. If we only allow memory
location hinting* for mapping at object create, we can't fix this case,
while if we move location hinting to map, we can do both this and your
VRAM case. I believe GL also has some hints that applications can pass
at
> #include "intel_tex_layout.h"
> #include "macros.h"
> +#include "intel_context.h"
>
> GLuint intel_compressed_alignment(GLenum internalFormat)
> {
>
> Thanks,
Committed. Apparently I failed to check again after my first nm and fix
on
On Sat, 2007-09-29 at 00:24 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
>
> >On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote:
> >
> >
> >>Eric Anholt wrote:
> >>
> >>
> >>> libdrm/xf86drm.c |
On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > libdrm/xf86drm.c | 26
> > libdrm/xf86mm.h |1
> > linux-core/Makefile |1
> > linux-core/drm_bo.c | 249
> > +
-
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download y
red code, and flip sign on return
from
shared code to *BSD code.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed
; > functions.
> >
> > :04 04 9f70804d38a62512f185453df294c7e1df8e44e0
> > 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src
> >
> >
>
> Brian,
>
> Can you shed some light onto what this commit did to blender? :-)
I was ju
ect 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 TransitionTo2/3D hooks. Or possibly
> even bett
and map blocks on (write-flushed if necessary)
fence completion. It is up to threads performing submit_buffers and
maps on shared objects to arrange external synchronization to avoid
deadlock." This has the advantage that those threads likely have some
sort of protocol requirements for renderin
es in
the process. My concern is that this pageflipping work is significantly
destabilizing, while we're in the midst of release candidates. Would
you be willing to relocate it to a branch until it's release-ready, or
we're at least not actively rolling releases?
--
Eric Anholt
g and the output of scanpci from
libpciaccess, and we can blacklist the LVDS on your board hopefully.
> If there are no objections, I'd like to merge these branches to the
> respective master branches by the end of this week. Of course, if the
> issues above can
On Thu, 2006-11-23 at 11:34 +0100, Tino Keitel wrote:
> On Wed, Nov 22, 2006 at 10:58:01 -0800, Eric Anholt wrote:
> > On Fri, 2006-11-17 at 22:12 +0100, Tino Keitel wrote:
> > > Hi folks,
> > >
> > > I use the TV application MythTV that uses OpenGL to dra
would need to figure out what MythTV is doing with OpenGL that's
causing the hang initially. This will probably mean getting down to the
simplest OpenGL program that does what MythTV does to cause the hang.
That is, unless I'm misunderstanding what you mean as to when the hang
happens.
pply the full error message, but this could be the usual
issue when you load two major versions of libpthread.so. ldd will tell
you if you are.
2) This is a known issue with AIGLX on Intel on FreeBSD, with no known
solution other than disabling AIGLX.
--
Eric Anholt
I updated my 965 driver today, and found that glxgears and Xgl were both
crashing on my C2 system. I checked out back to my last commit, and
bisected forward, and found that the commit yesterday for doom3 lockups
was what broke my system. Could it get backed out?
--
Eric Anholt
bits on FreeBSD, too. Sounds good to me.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
--
s no pdev defined at drm_device structure
> I think.
Yes, the code is currently broken on FreeBSD. However, given that
FreeBSD (so far) lacks GART support for the G965 support added in
current DRM code compared to the last merge to FreeBSD, that's probably
a priority to add before fixing t
nel yet, but I posted to lkml. Hopefully on Monday I should have
them cleaned up and suitable for integration.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED
$1 = (struct gl_framebuffer *) 0x0
Anyone else seeing this?
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
--
___
nctions, but essentially the same errors.
>
> Yet I know that somehow I did manage to get 1.20.0 installed on this
> machine because I had it working before :-(
>
> Any ideas what I'm doing wrong? Thanks!
Nothing. I need to commit jhb's DRM patch from the vga master device
changes.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
On Fri, 2005-12-02 at 15:11 -0500, Adam K Kirchhoff wrote:
> FYI, I'm attaching two very small patches that get the r300 driver
> working with my AGP X700 card.
>
> Adam
Committed, thanks. Note that for the future, unified diffs (diff -u)
are much preferred.
On Tue, 2005-11-08 at 12:25 -0800, Eric Anholt wrote:
> CVSROOT: /cvs/dri
> Module name: drm
> Repository: drm/shared-core/
> Changes by: [EMAIL PROTECTED] 05/11/08 12:25:00
>
> Log message:
> Initial port of savage to FreeBSD for the AGP and !Sha
may not have used the best app (ipers) for the test -- it
was dominated by fillrate, so there might not have been many
opportunities for pingponging state. Or maybe not, since it was the
best app I found for reproducing that race in state updating that we
were dealing with.
--
Eric Anholt
While it
should be doable to use numbers 0x80 and up, there may be cases such as
inside the kernel where we're comparing an ioctl against 0x40 and
looking at the driver's set if it's >=. We'll have to poke around
before deciding, I think.
--
Eric Anholt
ents for the
> via / unichrome driver.
>
> sf user: unichrome
I've (re)added you to the mesa group. But yeah, submitting a bug to the
freedesktop.org product, new account (or whatever) component of the fd.o
bugzilla is the best way to get these things done.
--
Eric Anholt
Package libdrm was not found in the pkg-config search path.
^^^ Just install libdrm from DRM CVS. It's a requirement now.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
his should be fixed in CVS, though I couldn't test due to libGL
issues. Could you test and see if it works now?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
; > possible with an eye toward future extensions.
> >
> >
> > I think it would be worthwhile to start a specification document for
> > this project (or perhaps a wiki page) where the requirements, issues and
> > proposed interface could be recorded. Any volu
the OP: I've been using r300 (Radeon 9600, specifically)
on FreeBSD-current since I merged the bits to Mesa CVS. Not sure what's
going on there.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
Thomas Hellström wrote:
Hi!
Eric Anholt wrote:
[EMAIL PROTECTED] sent me a port of the VIA DRM to FreeBSD. However, it
left a couple of rough edges (most of them preexisting), which I tried
to clean up. Attached is the diff against DRM CVS HEAD. I've
compile-tested on Linux and Fr
e test the diff so I can commit?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: bsd-core/Makefile
===
RCS file: /cvs/dri/drm/bsd-core/
able, 3 would be even more
confusing.
Oh, and also this is as long as those root checks in the shared code get
wrapped in an appropriate macro/function (taking no arguments).
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [
to vulnerabilities. I pointed out two cases, but I didn't
review all the ioctls. Before a patch based on this goes in, I would
like a review of every previously root-requiring ioctl to explain why
it's okay to not require root on it now.
Alternatively, you could do what Michel sugges
201 - 300 of 561 matches
Mail list logo
