On Wed, Sep 08, 2004 at 01:09:11PM +0200, Helge Hafting wrote:
Jon Smirl wrote:
On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting [EMAIL PROTECTED]
wrote:
Jon Smirl wrote:
I would also like to fix things so that we can have two logged in
users, one on each head. This isn't
On Mer, 2004-09-08 at 14:40, Ville Syrjl wrote:
Like Jon said the hardware can do it but the XFree86 driver doesn't allow
it. AFAIK it doesn't even allow XAA acceleration on the secondary head.
I can run multiple 3D apps simultaneosly on both heads of my G400 with
DirectFB. But currently
Patrick McFarland wrote:
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote:
In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.
Thats actually a pretty cool idea. For us that need to use the vesa
fbcon driver because
there is no native
Jon Smirl wrote:
They have to be merged. Cards with two heads need the mode set on each
head. fbdev only sets the mode on one head. If I teach fbdev how to
set the mode of the other head fbdev needs to learn about memory
management. The DRM memory management code is complex and is a big
chunk of
On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
I would also like to fix things so that we can have two logged in
users, one on each head. This isn't going to work if one them uses
fbdev and keeps swithing the chip to 2D mode while the other user is
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core
Jon Smirl wrote:
I'm a little concerned that we are doing a lot of work to support a
few people (100) using DRM on BSD. I suspicious that it is a very
small number since we get close to zero complaints about BSD even
though we break it continuously.
I think the difference may be that BSD users
On Sun, Sep 05, 2004 at 11:33:53AM -0400, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware? I was planning on adding
pieces of the existing fbdev code to DRM in order to implement printk
from the kernel. It seems
Lee Revell [EMAIL PROTECTED] said:
[...]
Wrong and wrong. If you run Debian unstable (which is WAY more stable
than, say, FC2) then you can apt-get upgrade to the latest kernel.
What makes you say this? I've seen no stability problems with FC2.
--
Dr. Horst H. von Brand
On Llu, 2004-09-06 at 21:58, Hamie wrote:
The fs - SCSI interface is a logical one.
We just have to make the fb and DRI to hardware one logical.
Unless you can have fb sitting on top of DRM of course... (I discount
DRM on-top of fb, because of the D == Direct... No other reason :)...
Does
Alan Cox wrote:
On Sul, 2004-09-05 at 23:11, Jon Smirl wrote:
What is the advantage to continuing a development model where two
groups of programmers work independently, with little coordination on
two separate code bases trying to simultaneously control the same
piece of hardware? This is a
Some examples of merging are turning two independent radeon
personality modules into a single one. Another thing I need to do is
to extract the printk support from the core fb module and put it
somewhere I can get to it from DRM. We can't have two cores trying to
attach to the same device and then
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote:
In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.
Thats actually a pretty cool idea. For us that need to use the vesa
fbcon driver because
there is no native driver, it would probably be
Dave Airlie wrote:
It's one of the major successes I feel of the DRI project, those
snapshots allowed people with Radeon IGP chipsets to get 3d acceleration
long before now (they still can't get it any current distro)
Not quite right -- Gentoo has xorg 6.7.99.x snapshots.
Donnie
On Sad, 2004-09-04 at 19:03, Jon Smirl wrote:
This does add some work to the BSD developers but it would make all of
the new code that doesn't copy preexisting GPL code fair game. I have
no problem marking any new code I write as being BSD licensed, I just
don't want to rewrite 80,000 lines of
On Sun, 05 Sep 2004 13:07:37 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Sad, 2004-09-04 at 19:03, Jon Smirl wrote:
This does add some work to the BSD developers but it would make all of
the new code that doesn't copy preexisting GPL code fair game. I have
no problem marking any new code I
On Sul, 2004-09-05 at 16:05, Jon Smirl wrote:
If DRI stays the way it is currently licensed no problems arise anyway
(beyond proprietary people reusing DRI code, which given the license is
presumably the intent)
If I copy GPL pieces of fbdev in to the DRM drivers it will pollute
the BSD
On Sun, 05 Sep 2004 15:15:25 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Sul, 2004-09-05 at 16:05, Jon Smirl wrote:
If DRI stays the way it is currently licensed no problems arise anyway
(beyond proprietary people reusing DRI code, which given the license is
presumably the intent)
On Sul, 2004-09-05 at 16:33, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware?
Everyone else in the discussions but you seemed to have no plans to
merge them, yet you keep going back to that plan and ignoring the
On Sul, 2004-09-05 at 15:44, Alan Cox wrote:
On Sul, 2004-09-05 at 16:33, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware?
Everyone else in the discussions but you seemed to have no plans to
merge them, yet you
On Sul, 2004-09-05 at 17:05, Jon Smirl wrote:
They have to be merged. Cards with two heads need the mode set on each
head. fbdev only sets the mode on one head. If I teach fbdev how to
set the mode of the other head fbdev needs to learn about memory
management. The DRM memory management code
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 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
Sure you can use this to get around both fbdev and DRM trying to claim
the resource. But it doesn't help at all to fix the problem that fbdev
and DRM are programming the radeon chip in conflicting ways.
Look at the case of two independent users, one logged into each head.
One is running DRI and
On Sul, 2004-09-05 at 22:12, Jon Smirl wrote:
Sure you can use this to get around both fbdev and DRM trying to claim
the resource. But it doesn't help at all to fix the problem that fbdev
and DRM are programming the radeon chip in conflicting ways.
Once you have the common structure the rest
On Sul, 2004-09-05 at 23:11, Jon Smirl wrote:
What is the advantage to continuing a development model where two
groups of programmers work independently, with little coordination on
two separate code bases trying to simultaneously control the same
piece of hardware? This is a continuous source
We're going to have to work out a GPL/BSD solution for the fbdev
merge. There are 80,000 lines of code in the fbdev directory. It is
impractical to rewrite them. It's probably also impractical to
relicense the fbdev code BSD since we would have to locate all of the
coders.
The proprietary drivers
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
We're going to have to work out a GPL/BSD solution for the fbdev
merge. There are 80,000 lines of code in the fbdev directory. It is
impractical to rewrite them. It's probably also impractical to
relicense the fbdev code BSD since we would have to locate all of the
coders.
Well I've been
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
I think you mis-read Keith, he said about converting it in the future to
that form.
Dave Airlie wrote:
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
I think you mis-read Keith, he said about converting it in the future to
Let me be clear that I am unwilling to support changes to the DRM that break
it's usability on other operating systems on principle.
I'm in agreement on that, ...
Maybe it's time to consider a fork of the DRM to allow a major experimentation
of the form Jon envisages to proceed without
Dave Airlie wrote:
Let me be clear that I am unwilling to support changes to the DRM that break
it's usability on other operating systems on principle.
I'm in agreement on that, ...
Maybe it's time to consider a fork of the DRM to allow a major experimentation
of the form Jon envisages to proceed
On Sat, Sep 04, 2004 at 01:12:16AM +0100, Dave Airlie wrote:
DRM core - just the stub registration procedure and handling any
shared resources like the device major number, and perhaps parts of sysfs
and class code. This interface gets set in stone as quickly as possible
and is as
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core and module,
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
component of a much larger system, of which the DRM just has
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core
On Sat, Sep 04, 2004 at 10:43:39AM +0100, Dave Airlie wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
true but the DRM isn't only about the Linux kernel, the DRM is a
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
But regular users don't tend to pull down new scsi or ata drivers
On Sat, 2004-09-04 at 11:43, Dave Airlie wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
On Sat, Sep 04, 2004 at 11:48:47AM +0200, Arjan van de Ven wrote:
true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
component of a much larger system, of which the DRM just has to reside in
the kernel,
you seem to be confusing 2 things.
The kernel-userspace
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
But regular users don't tend to pull down new scsi
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate kernel or
using a vendor kernel with backports. This model would work for video drivers
aswell.
Sure, explain to me how I should upgrade my RH-9 system to work
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate kernel or
using a vendor kernel with backports. This model would work for video drivers
aswell.
Sure, explain to me how I should upgrade my RH-9
Just out of interest, what would the scenario be if you do if you could
get a compatible driver?
you just grab a DRI snapshot which contains new userspace and DRM, and
install it... it builds the DRM against your current kernel, now if your
current kernel has a DRM module built-in which is a
Nick Piggin wrote:
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure,
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
include a drm update. The last release RH-9 kernel has various security
and data integrity issues anyway, so you'd be a fool to keep running it.
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure, explain to me how
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
I got a file called patch-2.6.8.1.bz2. I tried to install this but
nothing happened. My i915 still doesn't work. What do I do now?
You could start getting a clue.
Which is the problem, Keith was acting as
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
I got a file called patch-2.6.8.1.bz2. I tried to install this but
nothing happened. My i915 still doesn't work. What do I do now?
You could
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
include a drm update. The last release RH-9 kernel has various security
and data integrity issues anyway, so you'd be a fool to keep running it.
OK, I've found www.kernel.org, and clicked on the 'latest
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote:
Just out of interest, what would the scenario be if you do if you could
get a compatible driver?
you just grab a DRI snapshot which contains new userspace and DRM, and
install it... it builds the DRM against your current
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
You didn't stick with that long Christoph. We're not even past first base
yet. Let's try again?
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me I'm now running
A user without a clue should better be using a supported distribution.
If he used Fedora Core2 instead of the totally outdated and unsupported
RH9 he'd already have a kernel with i915 support on his disk.
What about Debian? they would have a 2.4 kernel.. is Debian not supported,
no-one told
On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote:
A user without a clue should better be using a supported distribution.
If he used Fedora Core2 instead of the totally outdated and unsupported
RH9 he'd already have a kernel with i915 support on his disk.
What about Debian?
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
Sure, explain to me how I should upgrade my RH-9 system to work on my new
i915?
Download a new kernel.org kernel or petition the fedora legacy folks to
include a drm update. The last release RH-9 kernel has various
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
You didn't stick with that long Christoph. We're not even past first base
yet. Let's try again?
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote:
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me I'm now running 2.6.8.1 - it's implausible
I know, but let's make it easier for you. Now, why isn't my i915 working?
Dave Jones wrote:
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
Sure, explain to me how I should upgrade my RH-9 system to work on my new
i915?
Download a new kernel.org kernel or petition the fedora legacy folks to
include a drm update. The last release RH-9 kernel
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
I got a file called patch-2.6.8.1.bz2. I tried to install this but
nothing happened. My i915 still doesn't work. What do I do now?
You
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote:
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me I'm now running 2.6.8.1 - it's implausible
I know, but let's make it easier for you. Now, why isn't
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote:
Please don't think that I'm talking for Tungsten at this or any other time on
the DRI list. I'm talking for myself and have never attempted to convey here
or elsewhere a company view without explictly flagging it up as such.
Dave Jones wrote:
If dri stuff isn't getting into distros fast enough, take it up with the
distros. For Fedora at least, we have a very quick turnaround right now.
Indeed. Maybe it's time to try again. There will always be a lag, though,
and the binary snapshots were only ever intended as a
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote:
Download a new kernel.org kernel or petition the fedora legacy folks to
include a drm update. The last release RH-9 kernel has various
security
and data integrity issues anyway, so you'd be a fool to keep running
Even if you are not speaking for Thungesten you pretty much show that
Thungsten has developers that in an area that overlaps with their works are
not willing to get things done the kernel way.
I don't know if you anyone can claim the kernel way except Linus, if he
decideds our argument is
Dave Jones wrote:
There's already a per-distro mechanism to make all this all nice and
transparent to end-users. In Fedora, we even have 3 (apt-get/yum/up2date).
The problem is when 3rd parties like the DRI project expect users not to
use the tools they are familiar with, and expect them to run
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
releases, I would like to give those people a chance to use their graphics
cards, and the snapshots are not the only way, Intel have i915 Linux
drivers on their site from TG, they work on most kernels/distros, I get a
machine
On Sat, Sep 04, 2004 at 01:08:26PM +0100, Keith Whitwell wrote:
So, we are coming out of a period of history where it was extremely
difficult to get our drivers to users through the 'official' channels - to
the extent that many people have given up on the possibility of them
working
On Sat, Sep 04, 2004 at 01:17:54PM +0100, Dave Airlie wrote:
Lets take an example, I'm DA graphics card vendor, I write a DRI driver
for my brand new 3d graphics cards (they rock btw :-), people buy loads of
them, I want to give them something on my website that they can deploy to
use their
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
I've got nothing to do with Tungsten whatsoever, I've never met any of the
other major DRI developers, my worries here is this is turning into a
company issue, people keep mentioning Fedora this and that, Fedora is one
distro, I
If we make a library split that sits inside the kernel, their DRM can
stop working if someone busts the interface, hence the idea of having the
core reg/dereg in the kernel, and locking it down, then they can ship a
complete DRM source tree, and do as they wish as long as they interface
Dave Jones wrote:
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
releases, I would like to give those people a chance to use their graphics
cards, and the snapshots are not the only way, Intel have i915 Linux
drivers on their site from TG, they work on most kernels/distros, I
Again, how is drm different from scsi or net or whatever drivers except
that you need a big userlevel component aswell?
Well I've always wondered why I couldn't download drivers for my i845 on
board soundcard for Redhat 9 (back when it was a supported distro), why
the hell did I need to go
properly with the core...
or they just ship their own matching core .c file as well
Lets face it, for the core there are 2 things that are entirely at
conflicts: small interface and core being useful.
I rather go for the useful side myself.
It's still useful, it just is built into the
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote:
Just out of interest, what would the scenario be if you do if you could
get a compatible driver?
you just grab a DRI snapshot which contains new userspace and DRM, and
install it... it builds the DRM against your current
Dave Jones wrote:
On Sat, Sep 04, 2004 at 01:08:26PM +0100, Keith Whitwell wrote:
So, we are coming out of a period of history where it was extremely
difficult to get our drivers to users through the 'official' channels - to
the extent that many people have given up on the possibility of
On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Currently we have to perform two merges and three releases to get a driver to
a users:
Merge DRM CVS -- LK
Release stable kernel -- Picked up by vendor
Release stable Mesa 3D
Merge
On 04.09.2004, at 08:04, Jon Smirl wrote:
So what do we do about FreeBSD? For example I need to bring in the I2C
and mode setting code from the GPL fbdev radeon driver into the DRM
one. I don't want to rewrite a 1,000 lines of working driver code.
How many DRM users are there on FreeBSD? I've only
On Sat, 4 Sep 2004 08:52:00 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote:
We're going to have to work out a GPL/BSD solution for the fbdev
merge. There are 80,000 lines of code in the fbdev directory. It is
impractical to rewrite them. It's probably also impractical to
relicense the
Am Samstag, 4. September 2004 17:36 schrieb Jon Smirl:
On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Currently we have to perform two merges and three releases to get a
driver to a users:
If DRM went into a kernel development model
Release
On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
[EMAIL PROTECTED] wrote:
I think David Airlie broke it already before. Yes I am using DRM on
DragonFlyBSD and yes there are lots of people who'd like to use it on
*BSD too. I just didn't want to stomp right in and scream you break it
On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make
On Saturday 04 September 2004 11:43 am, Simon 'corecode' Schubert wrote:
On 04.09.2004, at 08:04, Jon Smirl wrote:
So what do we do about FreeBSD? For example I need to bring in the I2C
and mode setting code from the GPL fbdev radeon driver into the DRM
one. I don't want to rewrite a 1,000
On Sad, 2004-09-04 at 13:04, Dave Airlie wrote:
I've got nothing to do with Tungsten whatsoever, I've never met any of the
other major DRI developers, my worries here is this is turning into a
company issue, people keep mentioning Fedora this and that, Fedora is one
distro, I happen to use it,
Jon Smirl wrote:
On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you
Jon Smirl wrote:
On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Currently we have to perform two merges and three releases to get a driver to
a users:
Merge DRM CVS -- LK
Release stable kernel -- Picked up by vendor
Release stable Mesa 3D
On Sat, 04 Sep 2004 18:43:16 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
You may think that X on GL (gnuLonghorn) is a crazy idea. But
comptetive pressures from the Mac and Longhhorn will force us into
doing it so or later. I'd rather do it sooner.
Not a crazy idea at all, plus I
On Fri, 3 Sep 2004 18:25:10 -0700 (PDT), Jon Smirl [EMAIL PROTECTED] wrote:
--- Dave Airlie [EMAIL PROTECTED] wrote:
Will this redesign allow for multiple 3d accelerated cards in the
same
machine? could I have say an AGP radeon and a PCI radeon or a AGP
matrox and a PCI sis and
On Sat, 2004-09-04 at 06:54, Dave Airlie wrote:
Just out of interest, what would the scenario be if you do if you could
get a compatible driver?
It's one of the major successes I feel of the DRI project, those
snapshots allowed people with Radeon IGP chipsets to get 3d acceleration
long
On Fri, 2004-09-03 at 23:04, Jon Smirl wrote:
We're going to have to work out a GPL/BSD solution for the fbdev
merge. There are 80,000 lines of code in the fbdev directory. It is
impractical to rewrite them. It's probably also impractical to
relicense the fbdev code BSD since we would have to
On Sat, 2004-09-04 at 08:59, Jon Smirl wrote:
On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
[EMAIL PROTECTED] wrote:
I think David Airlie broke it already before. Yes I am using DRM on
DragonFlyBSD and yes there are lots of people who'd like to use it on
*BSD too. I just
On Sat, 2004-09-04 at 08:25, Christoph Hellwig wrote:
Okay, let's take Debian stable as an example. How do you get an agpgart
that deals with the i915 into the 2.4.18 kernel woody ships?
The same way you demonstrate that the driver you just wrote is stable.
Run it for a few years and get back
On Sat, 2004-09-04 at 07:26, Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote:
A user without a clue should better be using a supported distribution.
If he used Fedora Core2 instead of the totally outdated and unsupported
RH9 he'd already have a
On Sat, 2004-09-04 at 07:42, Dave Jones wrote:
If dri stuff isn't getting into distros fast enough, take it up with the
distros. For Fedora at least, we have a very quick turnaround right now.
How about getting the VIA DRI module into the kernel?
Lee
How about getting the VIA DRI module into the kernel?
As soon as it is secure it goes in, the VIA DRI developers are working on
it at the moment, and it should be suitable for merging soon...
we also have out of kernel DRM drivers for mach64 and savage that would
pose security issues if
On Sat, 04 Sep 2004 14:31:16 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
You mean all the rearchitecting you've been doing to make the driver
behave like it actually attaches to specific device? Yeah, BSD has
wanted that since the very beginning. I just never implemented it
because I didn't
Actually after sleeping on this, I've just realised technically whether
the code is in a core separate module or driver module is only going to
affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
following the principles of a)least surprise, b) kernel must remain
stable, I think
On Sat, Sep 04, 2004 at 11:17:40PM +0100, Dave Airlie wrote:
Actually after sleeping on this, I've just realised technically whether
the code is in a core separate module or driver module is only going to
affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
following the
El Sbado, 4 de Septiembre del 2004 11:06 PM, Lee Revell escribi:
OK, please explain how I install the latest Unichrome DRI driver. The
docs at the unichrome site are correct except they refer to this guide
which is out of date:
http://dri.sourceforge.net/cgi-bin/moin.cgi/Building
Yes,
I realized, that from a snapshot point of view, it would be easy to cope
with a separate library module + additional binary interface. As far as
I gathered the main argument against another binary interface is that
upgrading one driver would break the other ones that may still be
installed on the
1 - 100 of 109 matches
Mail list logo
