>
> When you start merging DRM and fbdev you will be able to use relative
> paths that are closer together. For example #include
> "../char/drm/drmP.h" versus "#include "drm/drmP.h" for internal
> headers.
No. Using relative include paths is not good. I will most probarly
not work with make O=.
On 7/14/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > I'm thinking include/linux/drm/
> > > but include/linux would also be possible.
> > >
> > > Any suggestions or ideas?
> >
> > If you're in a mood to move things, how about moving drivers/char/drm
> > to drivers/video/drm.
>
> But that has li
On Thu, 2005-07-14 at 14:04 +1000, Dave Airlie wrote:
> Hi,
> I'd like to move the interface DRM header files (drm.h and *_drm.h)
> somewhere more useful and also more "user-space" visible, (i.e. so
> kernel-headers could start picking them up.)
I would suggest making ONE userspace visible header,
> > I'm thinking include/linux/drm/
> > but include/linux would also be possible.
> >
> > Any suggestions or ideas?
>
> If you're in a mood to move things, how about moving drivers/char/drm
> to drivers/video/drm.
But that has little point beyond aesthetics... moving the header files
is for a rea
On 7/14/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> Hi,
> I'd like to move the interface DRM header files (drm.h and *_drm.h)
> somewhere more useful and also more "user-space" visible, (i.e. so
> kernel-headers could start picking them up.)
>
> I'm thinking include/linux/drm/
> but include/linux
On 7/14/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> Hi,
> I'd like to move the interface DRM header files (drm.h and *_drm.h)
> somewhere more useful and also more "user-space" visible, (i.e. so
> kernel-headers could start picking them up.)
>
> I'm thinking include/linux/drm/
> but include/linux
6 matches
Mail list logo
