Direct Rendering Infrastructure

I might move stuff like AGP support into the core. The core is the most
OS specific piece of code. So anything that is very specific to the
kernel API should be in it.

I would split like this:
drm_core - OS specific code, all global things
drm_library - shared code, not OS specific
driver

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?

Stuff like this should probably be an inline...
#if LINUX_VERSION_CODE <= 0x020402
                        up( &current->mm->mmap_sem );
#else
                        up_write( &current->mm->mmap_sem );
#endif

What about the VM page fault routines with 2.4 vs 2.6 differences?
How about HAS_WORKQUEUE?


=====
Jon Smirl
jonsmirl@...


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

>
> 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, this
interface is minimal, so AGP won't go in it... *ALL* the core does is deal
with the addition/removal of modules, the idea being that the interface is
very minor and new features won't change it...

The library/driver interface then becomes a source interface as the
library isn't a separate module, it is linked into the modules, so we have
no binary interface issues with it, so the library/driver interface is
what we have at the moment minus the uglyness of DRM() and templated
header files... so if a vendor wants to ship a binary DRM, they only worry
about the drm core interface, and we avoid moving that interface as all it
does is keep track of all installed drms and the major device number..

> What about the VM page fault routines with 2.4 vs 2.6 differences?
> How about HAS_WORKQUEUE?

These are things to worry about later, as I said the code was just
experimental hackery to get my head around the issues. I'm not proposing
it for inclusion at any point, it also doesn't follow the design I
proposed, it makes the library as a separate module at the moment, and
uses an EXPORT_SYMBOL table, which isn't what I want to do...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

On Sat, 4 Sep 2004 01:12:16 +0100 (IST), Dave Airlie <airlied@...> wrote:
> 
> Okay I've had some thoughts about the DRM interfaces and did some code
> hacking (drmlib-0-0-1 branch on DRM CVS , very incomplete)
> 
> Below is my proposal for an interface that does introduce a major new
> binary interface (the biggest issue with a straight core/personality split
> for DRI developers, we have enough binary interfaces in our lives)...
> 
> Any comments are appreciated, the document is also available at:
> http://dri.sourceforge.net/cgi-bin/moin.cgi/DRMRedesign
> 
> Dave.
> 
> This documents a proposed new design for the DRM internal kernel interfaces.
> 
> The current DRM suffers from a number of issues with multiple drivers in
> the same kernel (the mess that is the drm_stub.h and parts of drm_drv.h)
> along with the DRM() macros show this up. This design tries to address
> this issue without introducing any major new binary interface.
> 
> I propose a 3 way code split-
>         DRM core
>         DRM library
>         DRM driver
> 
> This is slightly along the lines of the fb where the core is fbmem + co,
> the library is the cfb* object and the driver is the graphics chipset
> specific.
> 
> What I would like to do for the DRM is not as extreme as the fb approach.
> I propose the following type split:
> 
>         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 minimal as can be, (Jon Smirls dyn-minor patch will help a fair
> bit also). All the core does is allow DRMs to register and de-register in
> a nice easy fashion and not interfere with each other. This drmcore.o can
> either be linked into the kernel (ala the fb core) or a module, but in
> theory it should only really be shipped with the kernel - (for compat
> reasons the DRM tree will ship it for older systems).
> 
>         DRM library - this contains all the non-card specific code, AGP
> interface, buffers interface, memory allocation, context handling etc.
> This is mostly stuff that is in templated header files now moved into C
> files along the lines of what I've done in the drmlib-0-0-1-branch. This
> file gets linked into each drm module, if you build two drivers into the
> kernel it gets shared automatically as far as I can see, if you build as
> modules they both end up with the code, for the DRM the single card is the
> primary case so I don't mind losing some resources for having different
> cards in a machine.
> 
>         DRM driver - the current driver files converted to the new
> interfaces, I don't mind retaining some of the templating work, I like the
> fact that we don't have 20 implementations of the drm probe or PCI tables
> or anything like that, so I think some small uses of DRM() may still be
> acceptable from a maintenance point of view.
> 

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 have HW accel on :0 and :1.  If not, I think
it's something we should consider.

Alex

>
> 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 have HW accel on :0 and :1.  If not, I think
> it's something we should consider.

should be no problem at all, this is what I consider a DRM requirement so
any design that doesn't fulfill it isn't acceptable...

of course implemented code may need a bit of testing :-)

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

--- Dave Airlie <airlied@...> wrote:
> Yes we only have one binary interface, between the core and module,
> this interface is minimal, so AGP won't go in it... *ALL* the core
> does is deal with the addition/removal of modules, the idea being 
> that the interface is very minor and new features won't change it...

If you're Nvidia you ship the library source (since it is GPL) and a
binary driver. You compile the library on your kernel so that kernel
API IFDEF's get executed and then link to the binary driver. This model
won't work with IFDEF'd inline functions that are used in a binary
driver. They will have to be real functions in the library.

Things like this from the i830 driver will need to be library functions
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,2)
#define down_write down
#define up_write up
#endif

With the right set of library functions it should be possible to write
a video driver that is OS independent.

How big is the library that is going to get duplicated? Note that it
only gets duplicated for different cards not multiple instances of the
same card family. 

Are you going to hide the exported symbols so that we don't need the
DRM() macros?

=====
Jon Smirl
jonsmirl@...


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

--- Dave Airlie <airlied@...> 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 have HW accel on :0 and :1.  If not, I
> think
> > it's something we should consider.
> 
> should be no problem at all, this is what I consider a DRM
> requirement so
> any design that doesn't fulfill it isn't acceptable...
> 
> of course implemented code may need a bit of testing :-)

I've been reworking the DRM code to better support two dissimilar video
card. I pratice on a PCI Rage128 and AGP Radeon. 

I would also like to start making infastructure changes to allow two
independently logged in users, one on each head. Multihead DRM cards
will show one device per head. If you set a merged fb mode the other
head will get disabled. 

This is the general plan I am working towards...
http://lkml.org/lkml/2004/8/2/111


=====
Jon Smirl
jonsmirl@...


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

As we work towards the merged DRM/fbdev goal the fbdev libraries are
going to become part of DRM. The libraries will be used pretty much
unchanged as it is the driver code that needs to be adjusted. How does
this play with the new DRM model?

I think we have to remember licensing at all stages of this, the DRM is
X licensed, so I don't think we can just merge the fb code, I'm not sure
what peoples views on this, the main reason I see for using X licensing
is that we can share this stuff with FreeBSD and have an open source
graphics interface standard that the chipset designers can use, against it
is the fact that it allows for properitary drivers, - I personally don't
think we'll ever win that war.. will the prop drivers be derived works of
the DRM rather than the kernel anyone got a spare lawyer?

Dave.

On Fri, 3 Sep 2004, Jon Smirl wrote:

> As we work towards the merged DRM/fbdev goal the fbdev libraries are
> going to become part of DRM. The libraries will be used pretty much
> unchanged as it is the driver code that needs to be adjusted. How does
> this play with the new DRM model?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

>
> If you're Nvidia you ship the library source (since it is GPL) and a

is it GPL though.. we are X licensed at the moment and all my changes are
under the original license...

> binary driver. You compile the library on your kernel so that kernel
> API IFDEF's get executed and then link to the binary driver. This model
> won't work with IFDEF'd inline functions that are used in a binary
> driver. They will have to be real functions in the library.

there shouldn't be many ifdefs left, AGP and MTRR, if you re building a
binary driver for x86 you can assume the platform has AGP and MTRR and the
kernel should sort it all out, the remaining macros are mainly for
building on Alpha and Sparc...

 >
> How big is the library that is going to get duplicated? Note that it
> only gets duplicated for different cards not multiple instances of the
> same card family.

it'll be big but that's the same as we have now as I said, I believe the
balance between having a common library with an extensive new binary
interface, vs the un-common use case of using two different graphics card
in one PC is worth having the library in eeach driver, the binary
interface needs to be avoided at all costs, and I believe Keith's opinion
is worth listening to on binary interfaces :-)

> Are you going to hide the exported symbols so that we don't need the
> DRM() macros?
>

Again that is a bit of a separate project, my thinking on all these
projects is that I can feed them into the kernel is small obvious changes
this change will probably just fall out at the end as obvious it isn't so
for me yet...

I'm willing to spend the time doing an initial implementation (as we all
know, code talks, I'm not sure what talking does :-)

Dave.


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 are ok. They don't have to use the GPL
DRM/fbdev code; nothing stops them from writing their own version. I
also don't see how a binary driver that links with drm_core and the
kernel is any different than one that just links to the kernel. GPL
will stop a vendor from taking the source for drm_core/lib and making
a private version. But we want to stop that.

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 run into three that
I know of. I'm sure there are more but is it 1,000 people or 100,000?
I don't think DRM CVS will even compile currently on FreeBSD. I think
I broke it a week ago and no one has said anything.

Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed. Any fbdev code I add will go into
drm/linux. Then we patch up drm/bsd so that is continues to work given
the changes in drm/linux. The other alternative is simply forking the
tree. The licenses also allow chunks of DRM to be pulled into the
fbdev directory but that's effectively a fork.

The code is starting to drift further from BSD anyway. BSD is missing
major OS features like hotplug and resource control that Linux DRM is
starting to use.

The only rational way we can fix the multiple drivers for the same
video card is to merge fbdev and DRM functions. The other solution is
device driver multi-tasking with a 256MB state to be saved on task
swap.

On Sat, 4 Sep 2004 05:52:37 +0100 (IST), Dave Airlie <airlied@...> wrote:
> I think we have to remember licensing at all stages of this, the DRM is
> X licensed, so I don't think we can just merge the fb code, I'm not sure
> what peoples views on this, the main reason I see for using X licensing
> is that we can share this stuff with FreeBSD and have an open source
> graphics interface standard that the chipset designers can use, against it
> is the fact that it allows for properitary drivers, - I personally don't
> think we'll ever win that war.. will the prop drivers be derived works of
> the DRM rather than the kernel anyone got a spare lawyer?
> 
> Dave.
> 
> On Fri, 3 Sep 2004, Jon Smirl wrote:
> > As we work towards the merged DRM/fbdev goal the fbdev libraries are
> > going to become part of DRM. The libraries will be used pretty much
> > unchanged as it is the driver code that needs to be adjusted. How does
> > this play with the new DRM model?

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.

Keith

> 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 thinking we'll need to rob a lot of code from X11, a fair
bit of code in fbdev is taken from X anyways.. I'm not so sure it
wouldn't be that hard to move the rest...

From what I can see we make the core in-kernel and library sections under
BSD and then the driver can probably choose their license... I just think
this work is pretty ugly work and I would hate for another OS to have to
go do it again from scratch just because we decided to use GPL, I would
also like to make the interface as standard as possible.. (maybe ReactOS
could port it to Windows :-)

> Would this work? drm/shared and drm/bsd directories are BSD licensed.
> drm/linux is GPL licensed. Any fbdev code I add will go into
> drm/linux. Then we patch up drm/bsd so that is continues to work given

All the current code is X licensed, I think we should try and get code
from X where we can and if not maybe ask fb people about it ..

> The code is starting to drift further from BSD anyway. BSD is missing
> major OS features like hotplug and resource control that Linux DRM is
> starting to use.

But the future isn't set in stone, if BSD gets these features this
statement is insigificant...

> The only rational way we can fix the multiple drivers for the same
> video card is to merge fbdev and DRM functions. The other solution is
> device driver multi-tasking with a 256MB state to be saved on task
> swap.

For the cards the DRM supports, we could just reimplement the fb
functionality, the only card I'm aware of that really matters is the
radeon, there is no fbdev for i830/915 (I'm going to do one under the BSD
license when time permits, Dave Dawes did one half in half, part GPL part
BS but it was for 2.4 and he's abandoned it now .. the mach64 fb doesn't
work very well (my mobility chip craps it out..).. maybe the matrox is
another useful one, we probably should work on a dmacon interface rather
than fbcon, again this isn't obvious yet what we do...

Dave.
>
> On Sat, 4 Sep 2004 05:52:37 +0100 (IST), Dave Airlie <airlied@...> wrote:
> > I think we have to remember licensing at all stages of this, the DRM is
> > X licensed, so I don't think we can just merge the fb code, I'm not sure
> > what peoples views on this, the main reason I see for using X licensing
> > is that we can share this stuff with FreeBSD and have an open source
> > graphics interface standard that the chipset designers can use, against it
> > is the fact that it allows for properitary drivers, - I personally don't
> > think we'll ever win that war.. will the prop drivers be derived works of
> > the DRM rather than the kernel anyone got a spare lawyer?
> >
> > Dave.
> >
> > On Fri, 3 Sep 2004, Jon Smirl wrote:
> > > As we work towards the merged DRM/fbdev goal the fbdev libraries are
> > > going to become part of DRM. The libraries will be used pretty much
> > > unchanged as it is the driver code that needs to be adjusted. How does
> > > this play with the new DRM model?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

> > 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. I'm as I said against the GPL'ing of any of this at this stage,
we have all the info we need in X DDXes they are all usually X licensed so
I don't for see issues with ripping the code from them..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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
> that form. I'm as I said against the GPL'ing of any of this at this stage,
> we have all the info we need in X DDXes they are all usually X licensed so
> I don't for see issues with ripping the code from them..

OK, it's a proposal rather than a statement.  Apologies in that case.

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.

Maybe it's time to consider a fork of the DRM to allow a major experimentation 
of the form Jon envisages to proceed without worrying about boring constraints 
like keeping BSD working, backwards compatibility, etc.  And the current DRM 
architecture, which is pretty much stabilized, can continue to do those boring 
tasks, and accumulate new drivers, until GNULonghorn is finished...

Keith

>
> 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 worrying about boring constraints
> like keeping BSD working, backwards compatibility, etc.  And the current DRM
> architecture, which is pretty much stabilized, can continue to do those boring
> tasks, and accumulate new drivers, until GNULonghorn is finished...

I think it might be an idea myself, but not at this stage, I think a month
or two from now it might be a better time, if we get an agreeable
re-design done, then I'd be willing to let a fork proceed from that point,
so that at least the DRMs are all coming from the same point,

I think we should hold off on putting 2d stuff into the 3d drivers until
the DRM is rearchitected into a nice clean stable system that is actually
liked by kernel developers :-), I'm pushing the second set of macros
removals to Linus over the next week, along with experimenting on a
core/library tree...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 without worrying about boring constraints
>>like keeping BSD working, backwards compatibility, etc.  And the current DRM
>>architecture, which is pretty much stabilized, can continue to do those boring
>>tasks, and accumulate new drivers, until GNULonghorn is finished...
> 
> 
> I think it might be an idea myself, but not at this stage, I think a month
> or two from now it might be a better time, if we get an agreeable
> re-design done, then I'd be willing to let a fork proceed from that point,
> so that at least the DRMs are all coming from the same point,

This seems a good plan.

> I think we should hold off on putting 2d stuff into the 3d drivers until
> the DRM is rearchitected into a nice clean stable system that is actually
> liked by kernel developers :-), I'm pushing the second set of macros
> removals to Linus over the next week, along with experimenting on a
> core/library tree...

Thanks for the great work you're putting into this, it's very much 
appreciated.  Apologies for my pre-morning-coffee grumpiness...

Keith

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 minimal as can be, (Jon Smirls dyn-minor patch will help a fair
> bit also). All the core does is allow DRMs to register and de-register in
> a nice easy fashion and not interfere with each other. This drmcore.o can
> either be linked into the kernel (ala the fb core) or a module, but in
> theory it should only really be shipped with the kernel - (for compat
> reasons the DRM tree will ship it for older systems).

Ok.

> 	DRM library - this contains all the non-card specific code, AGP
> interface, buffers interface, memory allocation, context handling etc.
> This is mostly stuff that is in templated header files now moved into C
> files along the lines of what I've done in the drmlib-0-0-1-branch. This
> file gets linked into each drm module, if you build two drivers into the
> kernel it gets shared automatically as far as I can see, if you build as
> modules they both end up with the code, for the DRM the single card is the
> primary case so I don't mind losing some resources for having different
> cards in a machine.

Ok except you should build this only once.

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, this
> interface is minimal, so AGP won't go in it... *ALL* the core does is deal
> with the addition/removal of modules, the idea being that the interface is
> very minor and new features won't change it...

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.

>
> 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 to reside in
the kernel,

While I agree the perfcet solution is to introduce another binary
interface, but no-one on the dri-devel list is willing to dedicate most of
their time for the next age answering questions like "well I upgraded my
r200 driver, and my mga stopped working, and the ATI binary driver killed
my dog when I changed something else", Ian has pointed this out on the
dri-devel list as a major issue and to be honest he is not alone in his
worries, if make the kernel responsible for the registration/de-reg only
then build everything else in the drivers, we don't have to worry about
someone adding a line to the middle of a structure and breaking the
modules from somewhere else.. not many people have two different graphics
cards and I'd rather inconvience them than increase support burden..

We go through this with the DRI/DRM/DDX interfaces on a number of
occasions.. also the debacle of the i810 interface changes way back when..
I'd rather avoid it all at this stage.. again we are trying to find an
agreeable balancing point...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 and module, this
>>interface is minimal, so AGP won't go in it... *ALL* the core does is deal
>>with the addition/removal of modules, the idea being that the interface is
>>very minor and new features won't change it...
> 
> 
> 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 in the same 
way that they do graphics drivers.  Hence the concern of many drm developers 
to avoid introducing new failure modes in this process.

People who'd never dream of upgrading their kernel have acquired the habit of 
pulling down up-to-date video drivers on a weekly or monthly basis.  So, for 
sanity's sake, the DRI/DRM has been in the business of minimizing exposed 
interfaces, and for my money, should continue to be in that business.

Keith

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 lowlevel
> component of a much larger system, of which the DRM just has to reside in
> the kernel,

And what makes this different?

> While I agree the perfcet solution is to introduce another binary
> interface, but no-one on the dri-devel list is willing to dedicate most of
> their time for the next age answering questions like "well I upgraded my
> r200 driver, and my mga stopped working, and the ATI binary driver killed
> my dog when I changed something else",

Just upgrade all of drm.  You don't uopgrade a single drm driver either.
Or introduce a DRM_VERSION macro ala KERNEL_VERSION.    But best thing is
really to keep the mast copy of drm in the latest kernel and let vendors
backport if nessecary.

> Ian has pointed this out on the
> dri-devel list as a major issue and to be honest he is not alone in his
> worries, if make the kernel responsible for the registration/de-reg only
> then build everything else in the drivers, we don't have to worry about
> someone adding a line to the middle of a structure and breaking the
> modules from somewhere else.. not many people have two different graphics
> cards and I'd rather inconvience them than increase support burden..

I think you need to start to play the kernel game if you want your code
in the kernel.  I know X has this strange idea of beeing useful mostly to
make propritary vendors their life easier, but in kernel lands we thing
differently.

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 in the same 
> way that they do graphics drivers.  Hence the concern of many drm developers 
> to avoid introducing new failure modes in this process.

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.

> People who'd never dream of upgrading their kernel have acquired the habit of 
> pulling down up-to-date video drivers on a weekly or monthly basis.  So, for 
> sanity's sake, the DRI/DRM has been in the business of minimizing exposed 
> interfaces, and for my money, should continue to be in that business.

And DRM is the most crappy code in the kernel.  See any corelations?

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.
>=20
> 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 interface is supposed to be stable, and it should
be so that you can basically decouple X and kernel versions.

Within the kernel you should go for the best interface (where "best" is
a notion that is flexible over time) because 1) you can and 2) you are
suboptimal in both performance and maintenance if you don't

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 interface is supposed to be stable, and it should
> be so that you can basically decouple X and kernel versions.
> 
> Within the kernel you should go for the best interface (where "best" is
> a notion that is flexible over time) because 1) you can and 2) you are
> suboptimal in both performance and maintenance if you don't

seconded.

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 or ata drivers in the same 
>>way that they do graphics drivers.  Hence the concern of many drm developers 
>>to avoid introducing new failure modes in this process.
> 
> 
> 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 on my new i915?

I'm not a big fan of the DRM code either, it's ironic that I'm in a position 
where I'm defending it.  Thanks to the cleanup work Dave is doing though it is 
improving after a long period of neglect.

However, introducing a new binary interface isn't going to magically transform 
a fairly neglected codebase into a sparkly new one.  All I can really see it 
doing is saving a few K of memory in the hetrogenous dual head case.  Oh, and 
introducing a new failure mode to be debugged at a distance.

Keith

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 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 security
and data integrity issues anyway, so you'd be a fool to keep running it.

> However, introducing a new binary interface isn't going to magically transform 
> a fairly neglected codebase into a sparkly new one.  All I can really see it 
> doing is saving a few K of memory in the hetrogenous dual head case.  Oh, and 
> introducing a new failure mode to be debugged at a distance.

huh?  it you change the ABI your modules simply won't load.  that's not
exactly what I'd call debugging.

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 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 security
> and data integrity issues anyway, so you'd be a fool to keep running it.

OK, I've found http://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?

Keith

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 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 security
>> and data integrity issues anyway, so you'd be a fool to keep running it.
> 
> 
> OK, I've found http://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?
> 

Just out of interest, what would the scenario be if you do if you could
get a compatible driver?

>
> 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 different version, you
are screwed, snapshot process breaks..

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), same goes
for i915 as Keith points out..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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, 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 security
>>> and data integrity issues anyway, so you'd be a fool to keep running it.
>>
>>
>>
>> OK, I've found http://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?
>>
> 
> Just out of interest, what would the scenario be if you do if you could
> get a compatible driver?

Nick, I'm sorry I couldn't quite parse your question.

Ideally, everybody would have all the drivers they need right there on the 
media they got their distribution on, and if not, they'd be able to pull them 
over quick smart from their vendor online.

The biggest problem the DRI had in the early years was believing that you 
could get a new driver released to the public though the DRI tree, then an 
XFree86 CVS merge and XFree86 release, a Linux kernel release, maybe making it 
into vendor updates for X and kernel, but more likely the next full RedHat 
release,  and ultimately into users hands in a reasonable amount of time. 
Typically it was 6 months to a year for this process to roll through.

Given that we seldom had access to pre-release hardware, that meant that users 
were getting drivers about the time that cards became obsolete.

A couple of things have changed since then - DRI drivers for the i915 were 
available at launch of the hardware, not 6 months later.  But the rest of the 
process is still pretty slow, which is why the DRI snapshots and downloadable 
binaries were a significant step forward - if nvidia in particular can get 
uptodate drivers quickly into the hands of unsophisticated users, you have to 
ask yourself why users of DRI hardware should be forced to wait 6 months and 
then jump through hoops just to get their video cards working.

Keith

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 http://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.

> > OK, I've found http://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 a user with no clue, and why
should a user who can't get his graphics card working worry about kernel
upgrades, along with X upgrades, the DRI has a workable snapshot process
now that allows users to use their DRI supported graphics card now, not in
6 months time when the X release happens, and the distro picks up the X
release, they run a script it builds a module against their kernel,
breaking this for a small decrease in memory usage in an uncommon use
case and as far as I can see no better maintainability (or worse) is a bit
of an ask... we aren't coming up with these problems just to annoy kernel
developers they are real world issues.. that the DRI team deal with not
the kernel team....

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
> > > OK, I've found http://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 a user with no clue, and why
> should a user who can't get his graphics card working worry about kernel
> upgrades, along with X upgrades, the DRI has a workable snapshot process
> now that allows users to use their DRI supported graphics card now, not in

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.

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 kernel, now if your
 > current kernel has a DRM module built-in which is a different version, you
 > are screwed, snapshot process breaks..

You're also screwed if your vendor has AGPGART compiled into its kernel[1]
and your new card needs an AGPGART update.
Which is a valid thing to do if they want things like i810fb to work.
Or AMD64's IOMMU code. (Which is dependant on the agpgart having a view
on what its up to, otherwise loading the agpgart module later would cause
data corruption as it stomps all over the first half of the aperture where
the IOMMU put its mappings).

For the simple cases of just a PCI ID update, you could just echo the id
into agpgart's relevant sysfs file. But chipsets that need new/altered
code are going to cause a problem.

This is already causing havoc with ATI/NVIDIA/Matrox binary drivers that
ship their own agpgarts. I've seen all manner of oopses, crash reports
that are from two sets of agpgart code fighting it out. Now do you see
why I'm beating on these binary folks to give it up already and use
the in-kernel gart driver ? Without sounding all high and mighty,
they cannot win this game. The rest of the driver can stay binary only
for the rest of time for all I care, but running a modular agpgart
and a built-in agpgart is the fast road to a dead box.

 > 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), same goes
 > for i915 as Keith points out..

It's something I ranted about yesterday on dri-devel in regards to ATI,
I really expected more of opensource developers.  Encouraging end-users
to run ancient kernels is a *BAD* idea. Both from a security/stability
standpoint, and a code maintainability standpoint.

		Dave

[1] Of which Fedora/RHEL is one of these.

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 http://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.
> 

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 2.6.8.1 - it's implausible 
I know, but let's make it easier for you.  Now, why isn't my i915 working?

Keith

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 2.6.8.1 - it's implausible 
> I know, but let's make it easier for you.  Now, why isn't my i915 working?

Because the drm developer took a long time to submit the driver after
is was finished as they develop in a separate CVS tree instead of the kernel
tree.

>
> 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 me...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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? they would have a 2.4 kernel.. is Debian not supported,
> no-one told me...

Due to the policies of the release manager Debian stable is a totalally lost
cause.  It's missing all other support bits for i915 plattforms aswell.

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 security
 > >and data integrity issues anyway, so you'd be a fool to keep running it.
 > 
 > OK, I've found http://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?

Tungsten might like to think your end users are morons, but we like to
believe our end-users (ie, ANYONE building their own kernel) have
a small amount of common sense.  For those that find themselves lacking
in this area, they can usually buy some by using a vendor kernel.

If you believe that end-users aren't smart enough to figure out where to
get a kernel with all the bits they need, what makes you think they're
smart enough to figure out they need to grab the dri bits from the dri
sourceforge site (or wherever the hell they are) ?

For the record, the dri part is all thats missing in 2.6.8.1
Had it been merged sooner[1], it would work out of the box today with
that file that you downloaded. The AGPGART support for i915 has been
there for ages.

		Dave

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 & 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?
> 
> 
> Because the drm developer took a long time to submit the driver after
> is was finished as they develop in a separate CVS tree instead of the kernel
> tree.

OK, fair enough.  We've been spoilt in the past with "automatic" merges 
courtesy of some nice LKML types.

But, now I've compiled 2.6.9 or whatever, it's still not working.  My brother 
says he won't come in and do any more work on my computer, so you'll have to 
help me out from here...

Keith

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?
> > 
> > 
> > Because the drm developer took a long time to submit the driver after
> > is was finished as they develop in a separate CVS tree instead of the kernel
> > tree.
> 
> OK, fair enough.  We've been spoilt in the past with "automatic" merges 
> courtesy of some nice LKML types.
> 
> But, now I've compiled 2.6.9 or whatever, it's still not working.  My brother 
> says he won't come in and do any more work on my computer, so you'll have to 
> help me out from here...

Here's a nickel, buy yourself some supported distribution and talk to their
support people.

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 has various security
>  > >and data integrity issues anyway, so you'd be a fool to keep running it.
>  > 
>  > OK, I've found http://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?
> 
> Tungsten might like to think your end users are morons, but we like to
> believe our end-users (ie, ANYONE building their own kernel) have
> a small amount of common sense. 

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. 
Apologies if the use of a TG mailing address is confusing, but I will have to 
continue using it for the meantime as it is the one subscribed to this list.

Likewise, are you making a RedHat statement that you believe that your 
endusers need to be able to compile a kernel to use your products, or is that 
a statement of a regular LK developer?  I'm sure you appreciate the parallel.

But in general, yes, I'd like to think that you don't have to have even heard 
of a compiler in order to be able to install a video driver...

I don't see why installing a DRI driver should be more difficult than 
installing an NV, ATI or even a windows driver...

I don't see why it should be necessary to reboot a machine just to update it's 
video driver...

Keith

On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
 > > > OK, I've found http://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 a user with no clue, and why
 > should a user who can't get his graphics card working worry about kernel
 > upgrades, along with X upgrades, the DRI has a workable snapshot process
 > now

So, how in reality is our pepsi swigging spotty quake player, going to know
he needs to run off to download the latest dri snapshot if he is so clueless ?

If our imaginary hero is so clueless he won't even know what a 'dri' is,
and nor should he. Let alone know that he needs to go grab a patch for
some subsystem.

Regardless of what the folks at Tungsten would like you to believe,
end-users *do not* like changing bits of the distro from random sources.
"a 3d driver from here, a scsi driver from there". Next time they update
their system with their update tool of choice, it pulls down a security
errata for their kernel, and whoops, their 3d has gone, their scsi controller
disappears etc etc.
The next time they see a kernel security errata available they remember the
incident, and what happens? They blame the distro for breaking their setup,
and live with a potentially insecure system.

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.

		Dave

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 my i915 working?
>>>
>>>
>>>Because the drm developer took a long time to submit the driver after
>>>is was finished as they develop in a separate CVS tree instead of the kernel
>>>tree.
>>
>>OK, fair enough.  We've been spoilt in the past with "automatic" merges 
>>courtesy of some nice LKML types.
>>
>>But, now I've compiled 2.6.9 or whatever, it's still not working.  My brother 
>>says he won't come in and do any more work on my computer, so you'll have to 
>>help me out from here...
> 
> 
> Here's a nickel, buy yourself some supported distribution and talk to their
> support people.

Or I could just buy an closed-source card instead.

Keith

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. 
> Apologies if the use of a TG mailing address is confusing, but I will have to 
> continue using it for the meantime as it is the one subscribed to this list.

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.

This should be a v ery big warnings sign for potentitial Thungsten Customers
to look for a better supplier or at least give very strong directions.

> Likewise, are you making a RedHat statement that you believe that your 
> endusers need to be able to compile a kernel to use your products, or is that 
> a statement of a regular LK developer?  I'm sure you appreciate the parallel.

That's not what he said.  But sees Dave's next mail.

> But in general, yes, I'd like to think that you don't have to have even heard 
> of a compiler in order to be able to install a video driver...

And how does taking random dri snapshots help you there?  The only sane way
to make that happen is to make sure it's in the various distro kernels ASAP.

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 mechanism to reduce that 
lag.

Keith

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 
 > > it.
 > > > 
 > > > OK, I've found http://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?
 > >
 > >Tungsten might like to think your end users are morons, but we like to
 > >believe our end-users (ie, ANYONE building their own kernel) have
 > >a small amount of common sense. 
 > 
 > 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. Apologies if the use of a TG mailing address is confusing, but I will 
 > have to continue using it for the meantime as it is the one subscribed to 
 > this list.
 > 
 > Likewise, are you making a RedHat statement that you believe that your 
 > endusers need to be able to compile a kernel to use your products, or is 
 > that a statement of a regular LK developer?  I'm sure you appreciate the 
 > parallel.

If you follow the thread back, YOU were the one who decided to choose
compiling a new kernel. Christoph presented the options.
- do it yourself
- ask the fedora legacy folks to do an upgrade kernel with a new drm.
There's also a third option
- Upgrade your distro to something more recent.

And yes, I stand by these points with my Red Hat on.

 > But in general, yes, I'd like to think that you don't have to have even 
 > heard of a compiler in order to be able to install a video driver...
 > 
 > I don't see why installing a DRI driver should be more difficult than 
 > installing an NV, ATI or even a windows driver...

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 off to fetch
bits from websites and replace random bits of their system.

Who do you think gets the support calls and blame when the X server breaks
because the user bodged it ?

 > I don't see why it should be necessary to reboot a machine just to update 
 > it's video driver...

Thats a different kettle of fish. One day we might have an answer for
that (look up kexec if you're interested).

		Dave

> 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 worth it, then it becomes the kernel way as far
as I'm concerned... what you mean is the way things are usually done,
which may not always be applicable in every case,

> This should be a v ery big warnings sign for potentitial Thungsten Customers
> to look for a better supplier or at least give very strong directions.

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, lots of people I know dont.. it supports DRI
on IGP and i915 in Fedora 3 Test only, a DRI snapshot works on FC1 and
FC2 as well..

>
> And how does taking random dri snapshots help you there?  The only sane way
> to make that happen is to make sure it's in the various distro kernels ASAP.

Again what about distros that only do security upgrades in stable
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 with i915 install Debian go to Intels website and download their
drivers, it all works, now why do I have to compile a kernel again?

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 off to fetch
> bits from websites and replace random bits of their system.
> 
> Who do you think gets the support calls and blame when the X server breaks
> because the user bodged it ?

I think they get shared out pretty evenly between dri-users and your lot.  We 
all agree there's a problem, I'm happy to do what it takes to move towards a 
solution.

In the past, redhat & other vendors have only tracked XFree86 release cycles, 
which weren't exactly timely, and in the most recent instance, didn't even 
include an up-to-date DRI.  Although we've mainly been bitching about the 
kernel, the real drag has been userspace updates.

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 properly. 
Maybe things will improve now.

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.

Keith

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 with i915 install Debian go to Intels website and download their
 > drivers, it all works, now why do I have to compile a kernel again?

Then a month later, Debian issues a kernel security errata.
You download and install it, and your 3d stops working.
(worse case, maybe even your 2d breaks).
The 'download third party drivers' thing is not a silver bullet.
It will screw end users over, just as equally as it claims to help them.

		Dave

>
> 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 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 new card, like a driver for ANotherOS. Now I just want to give
them an XFree DDX, DRI driver and a drm module (in source form, that they
can use no matter what kernel), now at the moment no matter what kernel
they have, the DRM is a completly separate entity - the DRM code deals
with it,

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
properly with the core...

Dave.


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 properly. Maybe things will improve now.
 > 
 > 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.

I don't speak for X packaging (which is why I Cc'd Mike), but Fedora
(Sorry Dave theres that word again) as a whole is tracking upstream
very aggressively in most of its packages.
(In the case of the kernel right now, we're tracking the daily -bk trees.
 Though due to the number of architectures we support, it obviously takes
 a while for it to all trickle out of our build system).
Cherry picking updates from upstream happens for some packages, but typically,
we'll just grab a new upstream as a whole as soon as it comes out.

Daves point was true that only FC3test currently supports i915, but as we
now use FC3test stabilisation points as update kernels for FC2 too, the
kernel bits end up going back periodically.
The Xorg side of the fence doesn't get as many updates.
(And FC1 will never get Xorg, its still XFree86 4.4 iirc)
One possible reason for this is sheer size of an X update, which annoys users.
Hopefully this will be fixed with the modularisation work thats somewhere
down the road.

		Dave

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 new card, like a driver for ANotherOS. Now I just want to give
> them an XFree DDX, DRI driver and a drm module (in source form, that they
> can use no matter what kernel), now at the moment no matter what kernel
> they have, the DRM is a completly separate entity - the DRM code deals
> with it,
> 
> 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
> properly with the core...

And with each distro kernel update they have to reinstall the damn thing.
If you absolutely want people to use your driver on older kernels add the
right KERNEL_VERSION (or DRI_VERSION if you want to abstract this out some
way) for older ones.

Again, how is drm different from scsi or net or whatever drivers except
that you need a big userlevel component aswell?

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 happen to use it, lots of people I know dont.. it supports DRI
> on IGP and i915 in Fedora 3 Test only, a DRI snapshot works on FC1 and
> FC2 as well..

Fedota is only mentioned as an example because the development is so open
and I happen to see what's going on (I'm not using it myself at all).  I'm
pretty sure SuSE has/will have soon an update for i915, but it would requite
more work for me to find out.

> >
> > And how does taking random dri snapshots help you there?  The only sane way
> > to make that happen is to make sure it's in the various distro kernels ASAP.
> 
> Again what about distros that only do security upgrades in stable
> 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 with i915 install Debian go to Intels website and download their
> drivers, it all works, now why do I have to compile a kernel again?

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?

You really want the whole software stack to support new hardware.  And for
that you best go to a kernel that's not from stoneage, either a new upstream
release or a maintained vendor kernel.

> 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
> 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.

>
> 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 install FC1 or upgrade my kernel to a non-RH
kernel, same with X on the i845, it was crap on RH9 by the time FC1 came
out the i865 was out, the distros play catchup the whole time with new
hardware, why not allow people to download external drivers and use em?

I do take your point that a vendor supplied kernel update will break
everything anyways, but we do have a lot of proprietary driver users that
deal with this and get support for their hardware why should people
supplying open source drivers be worse off.. and that is my view with the
drm at the moment, companies wanting to do the right things are in a worse
position than companies just releasing binary drivers, and that is just
wrong :-), telling your users to get a new kernel isn't a nice way of
doing things, and maybe Fedora is doing things right, but not many other
distros are...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 get a
>  > machine with i915 install Debian go to Intels website and download their
>  > drivers, it all works, now why do I have to compile a kernel again?
> 
> Then a month later, Debian issues a kernel security errata.
> You download and install it, and your 3d stops working.
> (worse case, maybe even your 2d breaks).
> The 'download third party drivers' thing is not a silver bullet.
> It will screw end users over, just as equally as it claims to help them.

Dave,

There's no real disagreement that the best way to do things would be have 
everything come down nicely packaged from the distro vendor.  (Certainly with 
my TG hat on, that is how we'd like to see things work - it's obviously easier 
for us.)  Historically it just didn't work though, and even into the future, 
no matter what changes, I can still see a requirement for binary snapshots or 
downloadable drivers.

With the new LK "always stable" development model, one barrier to this ideal 
of fast distribution of drivers seems to have fallen.   This is perhaps the 
biggest change, and I admit the implications have only just started to sink in.

Dave Airlie taking a pro-active role as DRM maintainer is also a recent change 
- for a long time that code was a neglected corner of the XFree86 tree, now 
it's starting to look like a first-class project in its own right and is 
getting more of the attention it needs to beat it into shape.

The remaining question mark is the process of pushing the userspace drivers 
out.  I floated a proposal recently to loosely synchronize Xorg and Mesa 
release schedules which might help a little, but there is still a potentially 
long delay affecting the userspace parts of a driver in their progress to 
vendors & ultimately users.  Ultimately you're right that splitting that tree 
up & letting the parts evolve independently might address the problems there, 
though that's at least two X releases away.

In the meantime, though, downloadable binary drivers continue to be a useful 
testing aid for the DRI project (their original intent), and a convenient 
bandaid for working around a distribution channel which I think will probably 
be pretty slow for a year or more to come.

Keith

> > 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 drivers as a library rather
than the kernel, and the actual "core" is just a major number sharing
scheme, again the only advantage of building the library functions into
the kernel or as a separate module are a small memory saving on a rare use
case, hardly an astounding reason,

New functions added to the library can be made available to new drivers,
and vendors can ship their own set of library sources and not use
the kernels ones..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 kernel, now if your
> current kernel has a DRM module built-in which is a different version, you
> are screwed, snapshot process breaks..

So they are just building an external driver for the kernel.
No binary compatibility - and maybe a thin compat layer.
Not a big deal to maintain - only a small diff to latest kernel tree.

	Sam

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 them 
>  > working properly. Maybe things will improve now.
>  > 
>  > 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.
> 
> I don't speak for X packaging (which is why I Cc'd Mike), 

In fact this drags back to my mind the last time a similar conversation came 
up.  That conversation lead in part to the descision to pull the userspace DRI 
drivers out of the DRI tree into Mesa, and to likewise spin the DRM off into a 
project of its own.  At that point Mike did indicate that he might consider 
pulling drivers directly from our releases (if I remember correctly).  Shortly 
after this the XFree86 slow-motion trainwreck started, and history overtook 
that idea.

What does all this mean?  Not much except that we've been hoping to speed up 
this process for a long time, and have been working to improve how we do 
things for about as long.

It's still a difficult problem though.  We've got three distinct, major 
projects that have to coordinate to get a release to users - Linux kernel 
(DRM), X.org (DDX) and Mesa (DRI 3D client).  These are all big, stable trees 
that have their own and changing release strategies.

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 Mesa 3D --> X.org
	Release stable X.org  --> Picked up by vendor

Now that there's no development/stable kernel divide, the kernel releases 
should be the quickest part of this, though I'm not as optimistic as some 
about users pulling them down (but please, let's not go back to that, I'm 
prepared to believe...).

The fact is that X is already very modular, although not in terms of it's 
build process.  (If you believe the hype, a DDX compiled on i386 Linux should 
run on i386 Solaris, SCO, BSD, wherever, without modification.)

In any case, X isn't a monolithic binary, there is scope to pull in 
incremental updates if the will is there to do the validation.  If vendors are 
serious about making ad-hoc binary driver updates unnecessary, there has to be 
a willingness to address the whole problem.

Keith

On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
<keith@...> 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 Mesa 3D --> X.org
>         Release stable X.org  --> Picked up by vendor
> 

X on GL will make this process faster

         Merge DRM CVS --> LK
         Release stable kernel  --> Picked up by vendor
         Release stable Mesa 3D --> Picked up by vendor
         Release stable X.org  --> Picked up by vendor

If DRM went into a kernel development model....

         Release stable kernel  --> Picked up by vendor
         Release stable Mesa 3D --> Picked up by vendor
         Release stable X.org  --> Picked up by vendor

This is the fastest model. Merges have been eliminated.

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.

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 run into three that
> I know of. I'm sure there are more but is it 1,000 people or 100,000?
> I don't think DRM CVS will even compile currently on FreeBSD. I think
> I broke it a week ago and no one has said anything.

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 
- fix it!". Actually I hoped that the linux specific parts would be 
abstracted again so that it wouldn't break on BSD. As I'm not following 
cvs mailings I hoped Erik Anholt would fix the broken parts, but he's 
busy I think.

But as it seems that you want to hear people scream when something 
broke, okay. I will happily post breakes and - if I'm able to do so - 
also fixes to this.

I personally don't care *that* much about licenses as long as at least 
an OS agnostic API is retained.

> The code is starting to drift further from BSD anyway. BSD is missing
> major OS features like hotplug and resource control that Linux DRM is
> starting to use.

Don't worry about BSD's features. Again, as long as there is an OS 
agnostic API, there will be a way for any OS to implement the needed 
features *the way the OS structure demands*.

Oh, I don't even want to think about an ABI like X has...

cheers
   simon

-- 
/"\
\ /
  \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

On Sat, 4 Sep 2004 08:52:00 +0100 (IST), Dave Airlie <airlied@...> 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 locate all of the
> > coders.
> 
> Well I've been thinking we'll need to rob a lot of code from X11, a fair
> bit of code in fbdev is taken from X anyways.. I'm not so sure it
> wouldn't be that hard to move the rest...

I have tried twice now to extract code from X and merge it into DRM.
It is a pointless endeavor. The driver code is so intertwined into the
X type system and other pieces of X it is hopeless to extract it.
You're better off just using it as a reference and writing the code
again. On the other hand code fron fbdev can be used with almost zero
change in DRM.

The radeon fbdev I2C driver code is based on the X version. But if you
compare the code it is a complete rewrite.

The big piece of fbdev code I need implements text drawing in graphics
mode. This is needed to print OOPs when they happen in a graphics
mode. I also need the fbdev drivers for which there is no
corresponding DRM equivalent. These drivers need to be converted to
use drm_core so that we have a unified driver model.

One end goal of all this is to end up with a single video mode setting
API for the kernel.

Am Samstag, 4. September 2004 17:36 schrieb Jon Smirl:
> On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
>
> <keith@...> 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 stable kernel  --> Picked up by vendor
>          Release stable Mesa 3D --> Picked up by vendor
>          Release stable X.org  --> Picked up by vendor
>
> This is the fastest model. Merges have been eliminated.
>
> 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.

And I think people want _working_ DRI (graphics) on Linux _and_ *BSD etc. 
sooner than later.

Please do not slowdown DRI development than it even is today.
We have so much _bugs_ even without 6 months cycles...

Every test(er) is welcome.

-Dieter

On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
<corecode@...> 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
> - fix it!". Actually I hoped that the linux specific parts would be
> abstracted again so that it wouldn't break on BSD. As I'm not following
> cvs mailings I hoped Erik Anholt would fix the broken parts, but he's
> busy I think.
> 
> But as it seems that you want to hear people scream when something
> broke, okay. I will happily post breakes and - if I'm able to do so -
> also fixes to this.

BSD developers need to keep an eye on DRM and make sure it doesn't get
totally broken for them. There are DRM developers (like me) that have
never even booted a BSD system and haven't got a clue about it's
kernel API.

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'm also not proposing to shut BSD out of the DRM code base. I'm
trying to merge fbdev and DRM into a single, unified video
architecture on Linux.  Linux is GPL so half of this merge code base
(fbdev) is GPL code. Mixing the GPL code into the DRM code base will
convert it's license from BSD to GPL. No one is proposing removing BSD
support from DRM.

So from a BSD perspective which is worse, converting DRM to a GPL
license or forking DRM into Linux and BSD versions?

On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
<keith@...> 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 these sorts of comments, you dweeb.  There shouldn't be any
> GPL code in there at all.
> 

Dave was right, this is a proposed changed. I know the current license is BSD.

> Keith
> 



-- 

Jon Smirl
jonsmirl@...

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 lines of working driver code.
> >
> > How many DRM users are there on FreeBSD? I've only run into three that
> > I know of. I'm sure there are more but is it 1,000 people or 100,000?
> > I don't think DRM CVS will even compile currently on FreeBSD. I think
> > I broke it a week ago and no one has said anything.
>
> 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
> - fix it!". Actually I hoped that the linux specific parts would be
> abstracted again so that it wouldn't break on BSD. As I'm not following
> cvs mailings I hoped Erik Anholt would fix the broken parts, but he's
> busy I think.
Ditto for FreeBSD.  There are also quite a few people that rely on DRM on=20
=46reeBSD since NVidia are currently the only ones that provide FreeBSD=20
drivers, it's either DRM or NVidia.
The reason for the few complaints is probably because everyone is gearing u=
p=20
for 5.3 since it's a major release and time is being consumed by that.
>
> But as it seems that you want to hear people scream when something
> broke, okay. I will happily post breakes and - if I'm able to do so -
> also fixes to this.
>
> I personally don't care *that* much about licenses as long as at least
> an OS agnostic API is retained.
>
> > The code is starting to drift further from BSD anyway. BSD is missing
> > major OS features like hotplug and resource control that Linux DRM is
> > starting to use.
IIRC some of stuff should be coming after 5.3.
>
> Don't worry about BSD's features. Again, as long as there is an OS
> agnostic API, there will be a way for any OS to implement the needed
> features *the way the OS structure demands*.
>
> Oh, I don't even want to think about an ABI like X has...
>
> cheers
>    simon

=2D-=20
Anish Mistry

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, lots of people I know dont.. it supports DRI
> on IGP and i915 in Fedora 3 Test only, a DRI snapshot works on FC1 and
> FC2 as well..

Fedora essentially solves the problem with regularly release cycles and
policy. So once we know 2.6.10 or whatever is stable we can push that
for FC2 and FC3. We can push Xorg for FC2 because its in the
distribution description. Same for Gentoo except they'll probably ship
it before Fedora does.

> Again what about distros that only do security upgrades in stable
> releases, I would like to give those people a chance to use their graphics
> cards, and the snapshots are not the only way, 

For these setups the snapshots work well because you can package up an
extra driver in the knowledge that the vendor isnt going to do something
"Neat". If you want i915 in RHEL3 then that would certainly be the path
to take for example.

Distribution policies in part dictate the method. It doesn't imply any
one distribution policy is somehow "right".

Alan

Jon Smirl wrote:
> On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
> <keith@...> 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 these sorts of comments, you dweeb.  There shouldn't be any
>>GPL code in there at all.
>>
> 
> 
> Dave was right, this is a proposed changed. I know the current license is BSD.

Yes, apologies for flying off the handle and in particular for being rude 
enough to resort to name-calling.  It was just plain stupid of me.

Keith

Jon Smirl wrote:
> On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
> <keith@...> 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 Mesa 3D --> X.org
>>        Release stable X.org  --> Picked up by vendor
>>
> 
> 
> X on GL will make this process faster
> 
>          Merge DRM CVS --> LK
>          Release stable kernel  --> Picked up by vendor
>          Release stable Mesa 3D --> Picked up by vendor
>          Release stable X.org  --> Picked up by vendor
> 
> If DRM went into a kernel development model....
> 
>          Release stable kernel  --> Picked up by vendor
>          Release stable Mesa 3D --> Picked up by vendor
>          Release stable X.org  --> Picked up by vendor
> 
> This is the fastest model. Merges have been eliminated.

Yep.  Right now, I think it's really the Mesa/Xorg side that needs work and is 
the "critical path".  If we can convince/educate the distros to take 3D 
drivers from Mesa, that will be a good step in the right direction.

> 
> 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 like the name.  But a fork could help relieve 
the tension between trying to maintain a stable DRM and the sorts of stuff 
that you need to do to move to the next level.  And I recognize that I get 
grumpy when it sounds like existing functionality is threatened by your desire 
to push off in a certain technical direction.  If gnuLonghorn/DRM makes a 
friendly/development fork off the existing DRM, things might go a little smoother.

Keith

On Sat, 04 Sep 2004 18:43:16 +0100, Keith Whitwell
<keith@...> 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 like the name.  But a fork could help relieve
> the tension between trying to maintain a stable DRM and the sorts of stuff
> that you need to do to move to the next level.  And I recognize that I get
> grumpy when it sounds like existing functionality is threatened by your desire
> to push off in a certain technical direction.  If gnuLonghorn/DRM makes a
> friendly/development fork off the existing DRM, things might go a little smoother.

I'm sure we'll get a cease and desist letter from Microsoft if we call
it gnuLonghorn.

Here's a completely different tack on the same problem. As I
understand things it would be better for DRM if DRM merged into the
Linux kernel tree/development process. Given that this is true for
Linux it is probably true for BSD too.

Developers hold the copyrights on their patches. We could mark each
patch going into Linux DRM as being BSD or GPL licensed. For example I
could add a bunch of existing fbdev code in a patch marked GPL. I
could then add the code for integrating it and making it work and mark
it as BSD. This scheme lets the BSD people extract driver changes out
of the Linux code base without licensing problems. The BSD marked
patches don't bother Linux since the BSD license is upwardly
compatible to GPL.

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 fbdev code.

On Fri, 3 Sep 2004 18:25:10 -0700 (PDT), Jon Smirl <jonsmirl@...> wrote:
> --- Dave Airlie <airlied@...> 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 have HW accel on :0 and :1.  If not, I
> > think
> > > it's something we should consider.
> >
> > should be no problem at all, this is what I consider a DRM
> > requirement so
> > any design that doesn't fulfill it isn't acceptable...
> >
> > of course implemented code may need a bit of testing :-)
> 
> I've been reworking the DRM code to better support two dissimilar video
> card. I pratice on a PCI Rage128 and AGP Radeon.
> 
> I would also like to start making infastructure changes to allow two
> independently logged in users, one on each head. Multihead DRM cards
> will show one device per head. If you set a merged fb mode the other
> head will get disabled.

I'm not sure mergedfb is really "the way" to go long term.  It has
certain limitations (drawing engine limits, scrolling viewport when
using dissimilar modes on each head, etc.).  We might be better off
sharing access to the 3d engine like we do for 2D with "regular"
multihead.  xinerama could then be handled by indirect rendering mixed
with DMX and GLproxy.  some sort of fast path could be designed for
dualhead cards if a 3D window strattled both heads.  Just a thought.

Alex

> 
> This is the general plan I am working towards...
> http://lkml.org/lkml/2004/8/2/111
> 
> 
> 
> 
> =====
> Jon Smirl
> jonsmirl@...
>

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 before now (they still can't get it any current distro), same goes
> for i915 as Keith points out..
> 

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

How do you expect users to 'just grab the new release' if *your own user
documentation* is incorrect (from the above page):

  NOTE that these instructions may be out of date. According to 
  http://sourceforge.net/mailarchive/message.php?msg_id=9295537 
  parts of DRI have moved to a new repository. 
        
        "Mesa and DRM are still in the same repositories on
        freedesktop.org. But the DRI enabled DDX drivers are now
        developped in Xorg CVS instead of DRI CVS. See
        http://xorg.freedesktop.org for details." 
        
Wow, thanks, that explains everything!

This should not be hard.  I have built and installed Xorg from CVS.  I
know what I am doing.  What the heck is a non-coder supposed to do?

All I need is to figure out how to build unichrome_dri.so.  There seems
to be a unichrome directory in the Xorg, Mesa, and DRI CVS trees.  I
should just be able to cd to this directory and type make or make
unichrome_dri.so or something, just like I do to install the via DRI
kernel module, or ALSA modules, or any other kernel module with a
reasonable build process.  Does not work.

If someone tells me how to do this I promise to post a HOWTO.

Lee

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 locate all of the
> coders.
> 
> The proprietary drivers are ok. They don't have to use the GPL
> DRM/fbdev code; nothing stops them from writing their own version. I
> also don't see how a binary driver that links with drm_core and the
> kernel is any different than one that just links to the kernel. GPL
> will stop a vendor from taking the source for drm_core/lib and making
> a private version. But we want to stop that.
> 
> 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 run into three that
> I know of. I'm sure there are more but is it 1,000 people or 100,000?
> I don't think DRM CVS will even compile currently on FreeBSD. I think
> I broke it a week ago and no one has said anything.
> 
> Would this work? drm/shared and drm/bsd directories are BSD licensed.
> drm/linux is GPL licensed. Any fbdev code I add will go into
> drm/linux. Then we patch up drm/bsd so that is continues to work given
> the changes in drm/linux. The other alternative is simply forking the
> tree. The licenses also allow chunks of DRM to be pulled into the
> fbdev directory but that's effectively a fork.
> 
> The code is starting to drift further from BSD anyway. BSD is missing
> major OS features like hotplug and resource control that Linux DRM is
> starting to use.

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 want to make more diffs compared to Linux.

As far as hotplug, well, I've never used that feature on Linux and
haven't looked in to it.  When I think of "hotplug" I don't see anything
that couldn't be implemented using FreeBSD's current driver model with
only minor changes.

I personally think that these major architectural changes you're looking
at doing would be best done outside of our stable DRM (head) branch in
DRI CVS.  I'm not expecting FreeBSD to adopt them, because our
requirements are different (debugging of panics is supposed to be done
over serial console or through dumps.  We don't generally have an fbdev
equivalent, and though some individuals have produced mostly-complete fb
devices, nobody has really been interested).  If it gets to the point
that Linux wants to move to the fb-ified DRM and it's going to become
the stable version, I would say let's deal with those issues then.  Or
just stick your GPL code in drm/linux and not worry about BSD, if it can
be developed in head without disrupting (Linux) users.

-- 
Eric Anholt                                eta@...          
http://people.freebsd.org/~anholt/         anholt@...

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 kernel with i915 support on his disk.
> > 
> > What about Debian? they would have a 2.4 kernel.. is Debian not supported,
> > no-one told me...
> 
> Due to the policies of the release manager Debian stable is a totalally lost
> cause.  It's missing all other support bits for i915 plattforms aswell.
> 

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 policies are you referring to?  That Debian won't ship with
showstopper, data-destroying bugs due to pressure to make a release
date?

Lee

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 08:59, Jon Smirl wrote:
> On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
> <corecode@...> 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
> > - fix it!". Actually I hoped that the linux specific parts would be
> > abstracted again so that it wouldn't break on BSD. As I'm not following
> > cvs mailings I hoped Erik Anholt would fix the broken parts, but he's
> > busy I think.
> > 
> > But as it seems that you want to hear people scream when something
> > broke, okay. I will happily post breakes and - if I'm able to do so -
> > also fixes to this.
> 
> BSD developers need to keep an eye on DRM and make sure it doesn't get
> totally broken for them. There are DRM developers (like me) that have
> never even booted a BSD system and haven't got a clue about it's
> kernel API.
> 
> 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.

FreeBSD and DFBSD have the DRM integrated into the kernel tree, and it
works just great (i.e. no configuration except for Section "DRI") for
our users.  I only get complaints when someone has some new PCI ID, or
when there's some issue in an AGP driver.  Nobody actively uses DRI
CVS's DRM, because I fix DRI CVS and merge to -current whenever there
are major differences, and people on 4-stable generally just grab the
DRM code from -current since I maintain source-level compatibility.

So this is why you don't really hear complaints from BSD users on
dri-devel.  But there are quite a number from them.  I've certainly
heard from over a hundred, and of course that's a tiny fraction of the
total number.

-- 
Eric Anholt                                eta@...          
http://people.freebsd.org/~anholt/         anholt@...

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 to them.  Or do you expect them to
take your word for it?

Stability can only be proven in the field which takes time.  Debian
stable is for a box that you will install and stick in a closet and
forget about for a year or two, and be basically guaranteed that the
hardware will fail long before the software does.

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 shipped, so we can't develop them in-kernel....
(another reason for the CVS tree)...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

On Sat, 04 Sep 2004 14:31:16 -0700, Eric Anholt <eta@...> 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 want to make more diffs compared to Linux.
> 
> As far as hotplug, well, I've never used that feature on Linux and
> haven't looked in to it.  When I think of "hotplug" I don't see anything
> that couldn't be implemented using FreeBSD's current driver model with
> only minor changes.
> 
> I personally think that these major architectural changes you're looking
> at doing would be best done outside of our stable DRM (head) branch in
> DRI CVS.  I'm not expecting FreeBSD to adopt them, because our
> requirements are different (debugging of panics is supposed to be done
> over serial console or through dumps.  We don't generally have an fbdev
> equivalent, and though some individuals have produced mostly-complete fb
> devices, nobody has really been interested).  If it gets to the point
> that Linux wants to move to the fb-ified DRM and it's going to become
> the stable version, I would say let's deal with those issues then.  Or
> just stick your GPL code in drm/linux and not worry about BSD, if it can
> be developed in head without disrupting (Linux) users.

The major DRM changes are all stemming from problems on Linux. 
1) DRM attaching directly to device
2) hotplug
3) stopping device driver multi-tasking
4) no universal video mode setting API

The only reasonable solution to #3/4 is to merge DRM/fbdev.

I have been burnt several times doing major changes on branches. What
inevitably happens is a) lots of code drift between the trunk and the
branch and b) refusal to take the big patch when it shows up. I have
learned instead to get general acceptance of the proposed
architecture. This architecture has been posted everywhere and
discussed in detail at OLS: http://lkml.org/lkml/2004/8/2/111 After
getting acceptance write the pieces one at a time and get them
accepted into the kernel. DRM is already getting considerable kickback
from kernel developers for the size of the patches coming in, doing
this work on a branch would make it even worse. If there are flaws or
better ways to achieve the proposed architecture please let me know.

With X on GL the 2D XAA driver disappears. Since the 2D XAA driver was
supplying the mode setting code we need another solution. Attached is
the mode setting scheme discussed at OLS. It supplies a universal API
for handling devices that do mode setting in all different ways: user
space, vm86, in kernel.

------------------------------------------------
At OLS we talked about a system like this:
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode sets
4) common code takes this string and does a hotplug event with it.
5) hotplug event runs in root context in user space 
6) mode is decoded and verified, this may involve a little process that
maintains the DDC database and reads a file of legal modes. Other
schemes are possible.
7a) mode is set using VBIOS and vm86, signal driver mode is set
7b) the register values needed to set the mode are passed into a root
priv ioctl.
8) driver is unlocked.

In this model all of the verification happens in user space. If you
want to set modes other than the ones from DDC you have to add them to
the config file. There is no need for DDC support and mode verification
in the kernel.

To give credit this is Alan Cox's design.

-- 
Jon Smirl
jonsmirl@...

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 can proceed with moving stuff into libraries and the
likes without making the final decision until later, we will probably
start with having the library type code in the driver (where it is now)
and make it possible to change later, as it evolves..

I'll do some more research...

Dave.

 >
> It's still useful, it just is built into the drivers as a library rather
> than the kernel, and the actual "core" is just a major number sharing
> scheme, again the only advantage of building the library functions into
> the kernel or as a separate module are a small memory saving on a rare use
> case, hardly an astounding reason,
>
> New functions added to the library can be made available to new drivers,
> and vendors can ship their own set of library sources and not use
> the kernels ones..
>
> Dave.
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

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 principles of a)least surprise, b) kernel must remain
> stable, I think I can proceed with moving stuff into libraries and the
> likes without making the final decision until later, we will probably
> start with having the library type code in the driver (where it is now)
> and make it possible to change later, as it evolves..

Fine with me.  ad keep up your good work.

El S=C3=A1bado, 4 de Septiembre del 2004 11:06 PM, Lee Revell escribi=C3=B3:
> 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, please.  You (developers) are always asking for testers, but we=20
(end-users) don't know how to test the drivers properly if you don't make=20
comprehensive and updated docs.
I want to test the latest Savage driver directly from the XOrg CVS but I do=
n't=20
know how to compile it. I am running XFree86 4.4.0 RC2. I have XOrg CVS &=20
Mesa CVS. I applied the savage-dri-to-xorg.diff patch. Now what. There seem=
s=20
to be some obscure points, i.e. XOrg already *has* Mesa (altough some files=
=20
differ) and there is no 'host.def' file to edit, etc.
Please somebody update the docs, or explain briefly here, so anybody else=20
could make a HOWTO.

Thank you.
David.

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 system. It would be no problem to update all of them at
the same time. The snapshots include all the DRM sources anyway, they
just build the DRM for a single type of card right now.

The snapshots have been split into a common and a hardware-specific part
some time ago. Just move the DRM into the common part of the snapshots
and make it build and upgrade all DRM drivers at the same time. This way
a change in the binary interface won't break any other drivers (provided
that DRM CVS is the authoritative source for *all* DRM drivers that rely
on that library module).

Regards,
  Felix

On Sat, 4 Sep 2004 23:17:40 +0100 (IST)
Dave Airlie <airlied@...> wrote:

>=20
> 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 can proceed with moving stuff into libraries and the
> likes without making the final decision until later, we will probably
> start with having the library type code in the driver (where it is now)
> and make it possible to change later, as it evolves..
>=20
> I'll do some more research...
>=20
> Dave.
>=20

| Felix K=FChling <fxkuehl@...>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |

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 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 them in
kernel providing you put

	if(!capable(CAP_SYS_RAWIO))
		return -EPERM

in the client side open for these devices. At that point root can use it
happily but nobody else can. You can test it, you can share it upstream
and you can motivate people to fix it.

Alan

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 fbdev code.

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 Sun, 05 Sep 2004 13:07:37 +0100, Alan Cox <alan@...> 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 write as being BSD licensed, I just
> > don't want to rewrite 80,000 lines of fbdev code.
> 
> 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 license and turn it into GPL.



-- 
Jon Smirl
jonsmirl@...

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 license and turn it into GPL.

There is no reason to do that. The fb layer of Linux and BSD is very
different and both provide fb drawing functionality.

On Sun, 05 Sep 2004 15:15:25 +0100, Alan Cox <alan@...> 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)
> > >
> > If I copy GPL pieces of fbdev in to the DRM drivers it will pollute
> > the BSD license and turn it into GPL.
> 
> There is no reason to do that. The fb layer of Linux and BSD is very
> different and both provide fb drawing functionality.

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 silly for me to rewrite 10,000 lines of code
just to make it BSD licensed when BSD isn't even going to use the
code.

What is wrong with marking each CVS commit with BSD/GPL license? Then
having the BSD people pick off the relevant code.



-- 
Jon Smirl
jonsmirl@...

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 other
opinions.

If you are merging them then something is wrong in the design. The only
things they fundamentally share are knowledge of the current display
layout, and state management for rendering. 

As you say "if BSD isn't even going to use the code". So why are you
trying to make it hard for the BSD side ? They've got a perfectly good
frame buffer layer too and not suprisingly it has the same requirements
for knowledge.

Alan

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 keep going back to that plan and ignoring the other
> opinions.

Umm something ate half that paragraph or it got lost between brain and
keyboard ;)

Everyone else in the discussions didnt think it was neccessary to merge
them, yet you keep going back to that plan and ignoring the other
opinions.

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 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
in 3D mode. The chip needs to stay in 3D mode with the CP running.

We're not going to get OOPS display while running X without merging.
Something I would really like to have since I just had some and was
force to hook up a serial console.

It is just plain stupid having multiple device drivers fighting over
control of a single piece of hardware.  I thought we went over this
multiple times at OLS. There have been email discussions about this
since March.


On Sun, 05 Sep 2004 15:44:34 +0100, Alan Cox <alan@...> 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 keep going back to that plan and ignoring the other
> opinions.
> 
> If you are merging them then something is wrong in the design. The only
> things they fundamentally share are knowledge of the current display
> layout, and state management for rendering.
> 
> As you say "if BSD isn't even going to use the code". So why are you
> trying to make it hard for the BSD side ? They've got a perfectly good
> frame buffer layer too and not suprisingly it has the same requirements
> for knowledge.
> 
> Alan
> 
> 



-- 
Jon Smirl
jonsmirl@...

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 is complex and is a big
> chunk of the driver.

I see the entire time at OLS trying to sort this out was a complete
waste.

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 *private
};

Right now the drvdata for most PCI/AGP frame buffers is set to the
fb_info. If that is set to the shared object then you can attach DRI and
or FB first and they can find and call each others methods.

It might also need a single lock just to avoid DRI deciding to go away
while fb is calling dri and the reverse although I think the refcnt is
easier and cheaper.

With that in place if X tells DRI "640x480 starting here" then DRI can
tell fb "640x480 starting here". Similarly fb and dri can find each
other for acceleration and the kernel can become a DRI client for
console acceleration.

Once you have this object you can start attaching memory managers and
mode setup pointers to the shared structure so that they live
independantly.

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 *private
> };
>
> Right now the drvdata for most PCI/AGP frame buffers is set to the
> fb_info. If that is set to the shared object then you can attach DRI and
> or FB first and they can find and call each others methods.
>
> It might also need a single lock just to avoid DRI deciding to go away
> while fb is calling dri and the reverse although I think the refcnt is
> easier and cheaper.
>
> With that in place if X tells DRI "640x480 starting here" then DRI can
> tell fb "640x480 starting here". Similarly fb and dri can find each
> other for acceleration and the kernel can become a DRI client for
> console acceleration.
>
> Once you have this object you can start attaching memory managers and
> mode setup pointers to the shared structure so that they live
> independantly.

So then this structure would represent a merged driver?  That is, you'd have a 
driver that attaches to display devices and creates this structure to manage 
fb and dri?

Jesse

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 one fbdev. On every process swap I am going to
have to save graphics state, stop the coprocessor, flush the drawing
queue, etc because fbdev runs the chip in 2D mode and DRM runs it in
3D. It may take longer than a timeslice to flush the graphics queue. 
In a coordinated driver world I can leave the chip in 3D mode and
processes swap without overhead. The coordinated driver can also
manage allocating the VRAM between users.

How is multihead mode setting going to work with separate drivers? Set
head #1 using fbdev and head #2 using DRM? I can't imagine how merged
fb will work in that model. Or am I supposed to teach existing fbdev
how to do merged fb?

Some of the fbdev drivers are starting to attempt acceleration using
3D mode. This is going to be a complete mess when swapping to DRM.

What is so awful about merging the code? I'm the one doing the all of
the work. I intend to use 95% of the code extracted from fbdev without
change. I'm not getting rid of fbdev capability in the merged code,
I'm just coordinating use of the hardware.

On Sun, 05 Sep 2004 16:31:15 +0100, Alan Cox <alan@...> 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 *private
> };
> 
> Right now the drvdata for most PCI/AGP frame buffers is set to the
> fb_info. If that is set to the shared object then you can attach DRI and
> or FB first and they can find and call each others methods.
> 
> It might also need a single lock just to avoid DRI deciding to go away
> while fb is calling dri and the reverse although I think the refcnt is
> easier and cheaper.
> 
> With that in place if X tells DRI "640x480 starting here" then DRI can
> tell fb "640x480 starting here". Similarly fb and dri can find each
> other for acceleration and the kernel can become a DRI client for
> console acceleration.
> 
> Once you have this object you can start attaching memory managers and
> mode setup pointers to the shared structure so that they live
> independantly.
> 
> 



-- 
Jon Smirl
jonsmirl@...

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 of the problems go away
rather nicely over time.

> What is so awful about merging the code? I'm the one doing the all of
> the work. I intend to use 95% of the code extracted from fbdev without
> change. I'm not getting rid of fbdev capability in the merged code,
> I'm just coordinating use of the hardware.

It doesn't solve the problem. That is the fundamental part of it. I can
put the code in the same place or in different places, the problem you
have to fix is co-ordination, and when you fix that not suprisingly you
still don't care where the code lives.

Create a top level video device object to hold dri and fb info pointers.
End of problem #1. Make that top level video object the one which is
handling the pci device irrespective of DRI/fb loading first. You've now
solved the load order problem. Make DRI tell fb about display layout in
X and provide sync functions. You've now solved the Oops problem.

After that you can begin to worry about dual head and memory management
which is a *lot* harder than you seem to realise and much of which
cannot be done user space side for performance reasons.

Alan

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 model to stop this?

On Sun, 05 Sep 2004 21:53:41 +0100, Alan Cox <alan@...> wrote:
> 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 of the problems go away
> rather nicely over time.
> 
> > What is so awful about merging the code? I'm the one doing the all of
> > the work. I intend to use 95% of the code extracted from fbdev without
> > change. I'm not getting rid of fbdev capability in the merged code,
> > I'm just coordinating use of the hardware.
> 
> It doesn't solve the problem. That is the fundamental part of it. I can
> put the code in the same place or in different places, the problem you
> have to fix is co-ordination, and when you fix that not suprisingly you
> still don't care where the code lives.
> 
> Create a top level video device object to hold dri and fb info pointers.
> End of problem #1. Make that top level video object the one which is
> handling the pci device irrespective of DRI/fb loading first. You've now
> solved the load order problem. Make DRI tell fb about display layout in
> X and provide sync functions. You've now solved the Oops problem.
> 
> After that you can begin to worry about dual head and memory management
> which is a *lot* harder than you seem to realise and much of which
> cannot be done user space side for performance reasons.
> 
> Alan
> 
> 



-- 
Jon Smirl
jonsmirl@...

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 of problems. Why can't
> we fix the development model to stop this?

I don't see that as much of a problem. The mess arises from some simple
lacks in the objects in kernel and the methods required to co-ordinate.
Lots of drivers are written by a lot of people in the kernel and they
work just fine. The ext3 authors don't spend their lives co-ordinating
with SCSI driver authors, they just get the API right.

On Sun, Sep 05, 2004 at 11:33:53AM -0400, Jon Smirl wrote:
>=20
> 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 silly for me to rewrite 10,000 lines of code
> just to make it BSD licensed when BSD isn't even going to use the
> code.

Is the code in question attributed to a single developer or to a horde?
I only have a 2.4 kernel handy, so I can't check.

If it's a single developer or just a few, you could ask them for
permission to put it under a less restrictive license.  Petr Vandrovec
gave that permission for his components of the matroxfb code.

A lot of times the FB people don't really care about the license and
slap GPL on it just because that's the default thing to do for code
going into the Linux kernel.  It doesn't necessarily mean that they
would only grant permission for the code to be used in GPL scenarios.

--=20
Ryan Underwood, <nemesis@...>

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 continuous source of problems. Why can't
>>we fix the development model to stop this?
>>    
>>
>
>I don't see that as much of a problem. The mess arises from some simple
>lacks in the objects in kernel and the methods required to co-ordinate.
>Lots of drivers are written by a lot of people in the kernel and they
>work just fine. The ext3 authors don't spend their lives co-ordinating
>with SCSI driver authors, they just get the API right.
>
>  
>

Sorry, but I think that's (Possibly?) a really really bad & misleading 
example... Apples & Apples vs Chocolate & Milkshakes... The dual screen 
problem with DRM & fb is two drivers accessing (Sometimes) the same 
hardware. The ext3 vs SCSI is a filesystem, that sits on-top of a disk 
device that may just be SCSI.. Or IDE..

The fs -> SCSI interface is a logical one.

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 it make sens to have fb ontop of DRM at all? Anyone?


regards
  Hamish.

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 it make sens to have fb ontop of DRM at all? Anyone?

In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.

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, because of the D == Direct... No other reason :)...
>>
>>Does it make sens to have fb ontop of DRM at all? Anyone?
>>    
>>
>
>In some cases yes. The DRM is happy with the idea of the kernel being a
>DRM client too.
>
>  
>

Alright... So you have drm at the lower level, and the fb sits ontop of 
that... The fb just becomes a user of the DRM... No merge necessary 
then, because all the actual hardware access, memory allocation etc 
would live in drm? Is that right? And all the 2D code would also move 
into the DRM? (IIRC the DRM just has 3D stuff in it yes? IMO It would 
made sense to have all the acceleration & hardware access in the DRM 
together rather than in a separate place... Correct?)

H

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 doing takeover_console().

Mode setting will be a lot of new code since Alan's proposed design
doesn't match any of the existing solutions. I will try to reuse
snippets where I can.


On Mon, 06 Sep 2004 22:38:05 +0100, Hamie <hamish@...> wrote:
> Alright... So you have drm at the lower level, and the fb sits ontop of
> that... The fb just becomes a user of the DRM... No merge necessary
> then, because all the actual hardware access, memory allocation etc
> would live in drm? Is that right? And all the 2D code would also move
> into the DRM? (IIRC the DRM just has 3D stuff in it yes? IMO It would
> made sense to have all the acceleration & hardware access in the DRM
> together rather than in a separate place... Correct?)
> 

-- 
Jon Smirl
jonsmirl@...

On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox <alan@...> 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 faster and saner, and
no more problems with
dri drivers that don't play nice with fbcon drivers (is that even an
issue anymore?)

-- 
Patrick "Diablo-D3" McFarland || diablod3@...
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Patrick McFarland wrote:

>On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox <alan@...> 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 faster and saner, and
>no more problems with
>dri drivers that don't play nice with fbcon drivers (is that even an
>issue anymore?)
>
>  
>
Yeah it is... Especially with (Dare I say it) closed source drivers such 
as ATI's firegl.

H

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 the driver.
>
>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
>in 3D mode. The chip needs to stay in 3D mode with the CP running.
>
>  
>
Yes!  I use the ruby patch and have two users logged in on the
two heads of a G550.  It works fine - as long as no mode
change is attempted.  And only one user can use 3D (or even 2D),
the other is stuck with a unaccelerated framebuffer.

>We're not going to get OOPS display while running X without merging.
>Something I would really like to have since I just had some and was
>force to hook up a serial console.
>  
>
Also nice to have.

Helge Hafting

On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting <helge.hafting@...> 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
> >in 3D mode. The chip needs to stay in 3D mode with the CP running.
> >
> Yes!  I use the ruby patch and have two users logged in on the
> two heads of a G550.  It works fine - as long as no mode
> change is attempted.  And only one user can use 3D (or even 2D),
> the other is stuck with a unaccelerated framebuffer.

There is nothing in the hardware preventing both users from having 3D
displays. This is a problem in the way fbdev and DRM are designed. I
would like to work towards fixing this.

-- 
Jon Smirl
jonsmirl@...

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 and module, this
>>interface is minimal, so AGP won't go in it... *ALL* the core does is deal
>>with the addition/removal of modules, the idea being that the interface is
>>very minor and new features won't change it...
> 
> 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.

Oh for crying out loud!  I have posted a clear, concise explaination of 
why THIS WILL NEVER HAPPEN at least 10 times.  Unless you are willing to 
take over all user support issues that this *WILL* create from now until 
the end of time on all DRI supported platforms, GO AWAY!  Your endless 
squaking is doing nothing be waste developer time.  For the DRI project, 
that is a very valuable commodity.

P.S.: Welcome to my spam filter.

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't update out-of-tree 
kernel modules like Linux users do.  Because of that, they never see the 
breakage.

Jon Smirl wrote:

>On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting <helge.hafting@...> 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
>>>in 3D mode. The chip needs to stay in 3D mode with the CP running.
>>>
>>>      
>>>
>>Yes!  I use the ruby patch and have two users logged in on the
>>two heads of a G550.  It works fine - as long as no mode
>>change is attempted.  And only one user can use 3D (or even 2D),
>>the other is stuck with a unaccelerated framebuffer.
>>    
>>
>
>There is nothing in the hardware preventing both users from having 3D
>displays. This is a problem in the way fbdev and DRM are designed. I
>would like to work towards fixing this.
>  
>
I have heard of someone using two 3D displays, but he
used separate cards.  Can you get this on a single G550, which
supports two monitors but don't duplicate all hardware?

I have tried running two 2D-drivers, that works. But running
even one 3D app then froze 2D on the other display until
the 3D action ended. Simultaneous 3D was impossible, the
second user got segfaults when 3D was "busy" on the first display.

Helge Hafting

On Wed, Sep 08, 2004 at 01:09:11PM +0200, Helge Hafting wrote:
> Jon Smirl wrote:
>=20
> >On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting <helge.hafting@....=
no>=20
> >wrote:
> >=20
> >
> >>Jon Smirl wrote:
> >>  =20
> >>
> >>>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
> >>>in 3D mode. The chip needs to stay in 3D mode with the CP running.
> >>>
> >>>    =20
> >>>
> >>Yes!  I use the ruby patch and have two users logged in on the
> >>two heads of a G550.  It works fine - as long as no mode
> >>change is attempted.  And only one user can use 3D (or even 2D),
> >>the other is stuck with a unaccelerated framebuffer.
> >>  =20
> >>
> >
> >There is nothing in the hardware preventing both users from having 3D
> >displays. This is a problem in the way fbdev and DRM are designed. I
> >would like to work towards fixing this.
> >=20
> >
> I have heard of someone using two 3D displays, but he
> used separate cards.  Can you get this on a single G550, which
> supports two monitors but don't duplicate all hardware?

Like Jon said the hardware can do it but the XFree86 driver doesn't allow=
=20
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=20
DirectFB. But currently DirectFB's multihead capabilities are limited so=20
it only works with a TV as the secondary display.

--=20
Ville Syrj=E4l=E4
syrjala@...
http://www.sci.fi/~syrjala/

On Mer, 2004-09-08 at 14:40, Ville Syrj=C3=A4l=C3=A4 wrote:
> Like Jon said the hardware can do it but the XFree86 driver doesn't allow=
=20
> it. AFAIK it doesn't even allow XAA acceleration on the secondary head.
>=20
> I can run multiple 3D apps simultaneosly on both heads of my G400 with=20
> DirectFB. But currently DirectFB's multihead capabilities are limited so=20
> it only works with a TV as the secondary display.

Its a DRI issue not an X one. X has no problem with this but the DRI
layer can't deal with the "this cliprect this driver, that cliprect=20
a different driver" cases.