On Mer, 2004-09-08 at 14:40, Ville SyrjÃlà 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 curre
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
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 going to work if one them uses
fbdev and keeps swithing the chip to 2D mode wh
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 don
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 an
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
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 t
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 nativ
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
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
Alan Cox wrote:
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.
OK. (Even) I follow that... :)
Unless you can have fb sitting on top of DRM of course... (I discount
DRM on-top of fb, bec
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 con
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 :)...
>
>
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 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 see
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 sou
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 of problems. Why can't
we fix the development mode
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
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
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;
> voi
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 *p
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 co
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 the driver.
I wou
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,
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 oth
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 int
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
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
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
On Sad, 2004-09-04 at 23:06, Dave Airlie wrote:
> we also have out of kernel DRM drivers for mach64 and savage that would
> pose security issues if shipped, so we can't develop them in-kernel
> (another reason for the CVS tree)...
I still think this is actually a bad decision. You can develop
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
---
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 s
El SÃbado, 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,
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
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 I
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 di
>
> 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 shipp
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
--
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 alread
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 bac
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
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
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 accelerati
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
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,
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
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 m
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
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
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
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 brea
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
>
> R
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
> > reli
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, 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
>
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, 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 curren
> > 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 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 i
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
> 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
>
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 h
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: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
>
> Are you suggesting for instance, that RedHat might pick up individual drivers
> out of Xorg or better still Mesa, rather than waiting for a full stable
> release? That would probably be the biggest help - by comparison kernel
> releases are very frequent.
Lets take an example, I'm DA graphics
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
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 of
> 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
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 kee
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 mec
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.
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
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?
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 R
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 wo
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 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 va
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 D
>
> 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 tol
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 runnin
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 cur
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 stable
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?
> >
> > 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
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 I
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' lin
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,
>
> 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
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 s
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
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 o
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<->
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 lowleve
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 dr
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
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 an
>
> 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 h
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 an
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 min
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
1 - 100 of 116 matches
Mail list logo
