On Mon, 2004-08-02 at 11:57, Dave Jones wrote:
> I don't maintain upstream DRM, but I have a fair amount of responsibility
> regarding the Fedora kernel, and I'll state publically that looking at
> bugs in drivers/char/drm is right up there on my list of
> "things I'd rather not do after lunch". Ma
On Maw, 2004-08-03 at 00:48, Dave Airlie wrote:
> I'm going to agree with Ian here, making a generic library layer is going
> to make maintaining the DRM a full time job as opposed to the 5-6 hrs a
Disagree. If the factoring is done right its probably easier to maintain
and you'll have more peopl
On Llu, 2004-08-02 at 22:09, Dave Jones wrote:
> Whip me, beat me, make me clean up drivers/char/drm
>
> 8-)
Im sure that can be arranged by someone.
> Another possibility of course is that the BSD & Linux kernel side bits
> go their seperate ways. How active is the kernel side of the BSD world
>
> How does this differ from any other subsystem that supports
> cards with features that may not be present in another model ?
> Other subsystems have dealt with this problem without the need
> to introduce horrors like the abstractions in DRM.
The biggest issue I have with all the other subsyst
Dave Jones wrote:
On Mon, Aug 02, 2004 at 01:11:26PM -0700, Ian Romanick wrote:
> > > This would be *very* non-trivial to do. Doing the DRM like this has
> > > come up probably a dozen times (or more) over the last 3 years.
> >Which should ring alarm bells that something might not be quite rig
>
> If this is something that we really want to pursue, someone needs to dig in
> and figure out:
>
> 1. How much / which code can be "trivially" shared?
> 2. How much / which code can be shared with very little work?
> 3. How much / which code would we rather get a root-canal than try to make
> sh
--- Dave Jones <[EMAIL PROTECTED]> wrote:
> Another possibility of course is that the BSD & Linux kernel side
> bits go their separate ways. How active is the kernel side of the
> BSD world ?
I'll probably get flamed to death for suggesting this, but why not?
What about leaving BSD working with
On Mon, 2004-08-02 at 22:09 +0100, Dave Jones wrote:
>
> If subsequent DRI tree -> kernel merges back out any cleanup work, it's
> definitly going to be a waste of time even trying.
That can easily be avoided by doing the cleanup the right way in the
first place, i.e. in the DRI tree...
--
Ea
On Mon, Aug 02, 2004 at 01:42:04PM -0700, Jon Smirl wrote:
> We are really short handed for kernel level DRM developers; most 3D
> developers work in user space. The main person that wrote it, Gareth
> Hughes, doesn't seem to work on it any more. Right now there are three
> to four, non-paid pe
On Mon, Aug 02, 2004 at 01:11:26PM -0700, Ian Romanick wrote:
> > > This would be *very* non-trivial to do. Doing the DRM like this has
> > > come up probably a dozen times (or more) over the last 3 years.
> >Which should ring alarm bells that something might not be quite right.
> And that i
We are really short handed for kernel level DRM developers; most 3D
developers work in user space. The main person that wrote it, Gareth
Hughes, doesn't seem to work on it any more. Right now there are three
to four, non-paid people working part-time on DRM.
How about you kernel developers workin
Dave Jones wrote:
On Mon, Aug 02, 2004 at 11:02:43AM -0700, Ian Romanick wrote:
> This would be *very* non-trivial to do. Doing the DRM like this has
> come up probably a dozen times (or more) over the last 3 years.
Which should ring alarm bells that something might not be quite right.
And tha
On Llu, 2004-08-02 at 19:57, Dave Jones wrote:
> > The problem is that each driver has different needs based on hardware
> > functionality.
>
> How does this differ from any other subsystem that supports
> cards with features that may not be present in another model ?
> Other subsystems have de
On Mon, Aug 02, 2004 at 11:02:43AM -0700, Ian Romanick wrote:
> This would be *very* non-trivial to do. Doing the DRM like this has
> come up probably a dozen times (or more) over the last 3 years.
Which should ring alarm bells that something might not be quite right.
> The problem is that
ian: what about splitting the current memory management code into a
module that can be swapped for your new version?
AFAIK, the only drivers that have any sort of in-kernel memory manager
are the radeon (only used by the R200 driver) and i830. That memory
manager only exists to support an NV_v
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IR
Jon Smirl wrote:
4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.
What should be the model for reorganizing DRM? An obvious change is
eliminate the naming mac
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=969
Summary: DRM Kernel Modules Fail to compile
Product: DRI
Ver
Hi!
At least compile well , I am not in home to test on my savage twister k!
but after apply your patch we only need uncomment one line on
xc/config/cf/xorgsite.def to compile our savage dri from current xorg cvs
like this :
--- xc/config/cf/xorgsite.def 2004-08-02 14:38:47.0 +0
Hi!
I think this might be caused by the via drm module only reports vsync
irqs as handled, even if the
unichrome device issues other interrupts, such as 2d engine completions
etc. I'll try come up with a patch that makes the via drm irq handler
respond "handled" to all interrupts coming from the
Philipp Klaus Krause wrote:
Since the drivers have to use software fallback instead of
hardware tcl in some cases anyways, why don't they expose
GL_ARB_vertex_blend and GL_ARB_vertex_program?
No reason not to. Bear in mind that our current implementations of these are
less optimized than the hard
Since the drivers have to use software fallback instead of
hardware tcl in some cases anyways, why don't they expose
GL_ARB_vertex_blend and GL_ARB_vertex_program?
Philipp Klaus Krause
---
This SF.Net email is sponsored by OSTG. Have you noticed t
22 matches
Mail list logo
