Re: DRM development process wiki page..

2008-08-28 Thread Tomas Carnecky
Keith Whitwell wrote: >> Major bumps once stuff went into the kernel weren't allowed at all. >> You'd need to fork the driver in any case. So we did this once or >> twice on drivers in devel trees like mach64. >> However upstream first policy should avoid this need. I'd also prefer >> to see getpar

Re: DRM development process wiki page..

2008-08-28 Thread Kristian Høgsberg
On Thu, Aug 28, 2008 at 8:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: >> Major bumps once stuff went into the kernel weren't allowed at all. >> You'd need to fork the driver in any case. So we did this once or >> twice on drivers in devel trees like mach64. >> However upstream first policy sho

Re: DRM development process wiki page..

2008-08-28 Thread Keith Whitwell
> Major bumps once stuff went into the kernel weren't allowed at all. > You'd need to fork the driver in any case. So we did this once or > twice on drivers in devel trees like mach64. > However upstream first policy should avoid this need. I'd also prefer > to see getparam for new features instead

Re: DRM development process wiki page..

2008-08-28 Thread Dave Airlie
he regression rate >>>> gets too high. So upstreaming is great for features like GEM, however >>>> it would suck for something like vblank-rework. This appears to point >>>> at, upstream is great if you touch one driver and exist in your own >>>> world, however if yo

Re: DRM development process wiki page..

2008-08-28 Thread Thomas Hellström
tually ignore us if the regression rate >>> gets too high. So upstreaming is great for features like GEM, however >>> it would suck for something like vblank-rework. This appears to point >>> at, upstream is great if you touch one driver and exist in your own >>>

Re: DRM development process wiki page..

2008-08-28 Thread Dave Airlie
ork. This appears to point >> at, upstream is great if you touch one driver and exist in your own >> world, however if you want interfaces that all drivers can use like >> vbl-rework you need to work somewhere else or carry two interfaces >> until everyone is ported. >&g

Re: DRM development process wiki page..

2008-08-28 Thread Thomas Hellström
ures like GEM, however > it would suck for something like vblank-rework. This appears to point > at, upstream is great if you touch one driver and exist in your own > world, however if you want interfaces that all drivers can use like > vbl-rework you need to work somewhere else or ca

Re: DRM development process wiki page..

2008-08-27 Thread Robert Noland
On Wed, 2008-08-27 at 13:35 +1000, Dave Airlie wrote: > On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote: > >> Okay I've put some thoughts up at: > >> http://dri.freedesktop.org/wiki/DRMProcess > >> > >> and I've past

Re: DRM development process wiki page..

2008-08-26 Thread Dave Airlie
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <[EMAIL PROTECTED]> wrote: > On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote: >> Okay I've put some thoughts up at: >> http://dri.freedesktop.org/wiki/DRMProcess >> >> and I've pasted it in below this for discussion. >> >> some other points: >> >>

Re: DRM development process wiki page..

2008-08-26 Thread Robert Noland
t > at, upstream is great if you touch one driver and exist in your own > world, however if you want interfaces that all drivers can use like > vbl-rework you need to work somewhere else or carry two interfaces > until everyone is ported. > > So lets see if we can improve thi

Re: DRM development process wiki page..

2008-08-26 Thread Jesse Barnes
On Tuesday, August 26, 2008 5:15 pm Dave Airlie wrote: > DRM Development Process (Proposed) > > 1. Master branch in Linux tree style with links for BSD etc. > > 2. Always compatible with current release Linux kernel + with > backwards compat *where* practical for older

DRM development process wiki page..

2008-08-26 Thread Dave Airlie
l-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) 1. Master branch in Linux tree style with links for BSD etc. 2. Always compatible with current release Lin

Re: DRM development process

2008-08-26 Thread Robert Noland
On Tue, 2008-08-26 at 14:17 -0700, Jesse Barnes wrote: > On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: > > On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <[EMAIL PROTECTED]> > wrote: > > > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote: > > >> > As for the "new develo

Re: DRM development process

2008-08-26 Thread Stephane Marchesin
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: >> >> I am outlining the fact that you confuse a problem and its solution. >> >> Problem: merging stuff upstream takes time to Dave >> Your solution: have lots o

Re: DRM development process

2008-08-26 Thread Jesse Barnes
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: > On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote: > >> > As for the "new development model"... Things are actually worse than I > >> > thought.