On 6/18/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > Everyone except for you that I have heard so far has been assuming the
> > kernel has some very limited capability to change modes in case things
> > go horribly wrong, which OOM killing this hypothetical small daemon
> > certainl
On Fri, 2005-06-17 at 22:38 +0100, Dave Airlie wrote:
> >
> > I was going to delete the code that looks for fbdev and conditionally
> > takes control since it had been rejected. Should I leave it in?
>
> I'd leave it in, no-one says DRM CVS has to be exactly what is in the
> kernel, it is nice to
> Can you provide more detail here ?
>
> The current situation is that when fbdev is loaded the DRM falls back
> to using the sysdev approach. If fbdev isn't loaded it takes direct
> control as the DRM becomes a real PCI driver and accesses the PCI functions
> for suspend/resume directly.
>
> Wh
> Everyone except for you that I have heard so far has been assuming the
> kernel has some very limited capability to change modes in case things
> go horribly wrong, which OOM killing this hypothetical small daemon
> certainly should qualify as.
I think all the kernel needs is the capability to
>
> I was going to delete the code that looks for fbdev and conditionally
> takes control since it had been rejected. Should I leave it in?
I'd leave it in, no-one says DRM CVS has to be exactly what is in the
kernel, it is nice to know what happens when we own the PCI device vs
currently,
Dave.
On 6/17/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> > > The current situation is that when fbdev is loaded the DRM falls back
> > > to using the sysdev approach. If fbdev isn't loaded it takes direct
> > > control as the DRM becomes a real PCI driver and accesses the PCI
> > > functions
> > >
On Fri, Jun 17, 2005 at 03:02:09PM -0400, Jon Smirl wrote:
> On 6/17/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> > Ben,
> >
> > Can you provide more detail here ?
> >
> > The current situation is that when fbdev is loaded the DRM falls back
> > to using the sysdev approach. If fbdev isn't loa
On 6/17/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> Ben,
>
> Can you provide more detail here ?
>
> The current situation is that when fbdev is loaded the DRM falls back
> to using the sysdev approach. If fbdev isn't loaded it takes direct
> control as the DRM becomes a real PCI driver and ac
On Fri, Jun 17, 2005 at 09:35:31AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote:
> > > The DRM drivers know what is important but they don't know when
> > > suspend/VT swap is happening because there is only one set of kernel
> > > hooks and the fbdev
On Fri, 2005-06-17 at 08:51 -0400, Jon Smirl wrote:
> On 6/17/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > On Thursday 16 June 2005 22:11, Jon Smirl wrote:
> > > On 6/16/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > > I would strongly suggest that we use usermode helpers as much as
> > > >
On 6/17/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Thursday 16 June 2005 22:11, Jon Smirl wrote:
> > On 6/16/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > I would strongly suggest that we use usermode helpers as much as possible
> > > even on linux, since we have the code already written
On Thursday 16 June 2005 22:11, Jon Smirl wrote:
> On 6/16/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > I would strongly suggest that we use usermode helpers as much as possible
> > even on linux, since we have the code already written in X and it'll
> > increase the similarity with other platfo
On Thu, 2005-06-16 at 22:01 -0400, Adam Jackson wrote:
> On Thursday 16 June 2005 20:06, Jon Smirl wrote:
> > On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > > In fact, the framebuffer support/mode setting doesn't have to be in the
> > > kernel stricto-sensus.
> >
> > In the model
On 6/16/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> I would strongly suggest that we use usermode helpers as much as possible even
> on linux, since we have the code already written in X and it'll increase the
> similarity with other platforms. Write it once. Other platforms without an
> fbdev
On Thursday 16 June 2005 20:06, Jon Smirl wrote:
> On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > In fact, the framebuffer support/mode setting doesn't have to be in the
> > kernel stricto-sensus.
>
> In the model I'm working with, things like mode setting always have to
> go thr
On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> > Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the
> > mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will
> > likely provide OpenGL/EGL's that don't use fbdev.
>
> One thing that bothers me about this
On Fri, 17 Jun 2005, Benjamin Herrenschmidt wrote:
Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the
mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will
likely provide OpenGL/EGL's that don't use fbdev.
One thing that bothers me about this whole discussi
> > Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the
> > mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will
> > likely provide OpenGL/EGL's that don't use fbdev.
>
> One thing that bothers me about this whole discussion is the mounting
> level of interface c
On Thu, 16 Jun 2005, Jon Smirl wrote:
On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote:
On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
Out of curiosity - who are the people that *need* intelfb ? (as opposed to
*want*
On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> In fact, the framebuffer support/mode setting doesn't have to be in the
> kernel stricto-sensus.
In the model I'm working with, things like mode setting always have to
go through a kernel call gate to provide the user to root privileg
On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote:
> > On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> > > Out of curiosity - who are the people that *need* intelfb ? (as opposed to
> > > *want*).
> >
> > To use Xegl it wi
On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote:
> On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> > Out of curiosity - who are the people that *need* intelfb ? (as opposed to
> > *want*).
>
> To use Xegl it will require you to load both fbdev and DRM drivers for
> your hardware. Xe
On Thu, 2005-06-16 at 22:28 +0100, Dave Airlie wrote:
> >
> > Out of curiosity - who are the people that *need* intelfb ? (as opposed to
> > *want*).
>
>
> Xegl people will need a kernel framebuffer driver (not necessarily running
> the console) but something loaded to take care of X when it star
On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote:
> > The DRM drivers know what is important but they don't know when
> > suspend/VT swap is happening because there is only one set of kernel
> > hooks and the fbdev driver is attached to them. The scheme where a
> > texture copy is kept in syste
On 6/16/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> Why would layering the DRM on top of the fbdev driver break DirectFB? I
> (think I) understand the issues with actually merging the drivers, but
> the more I dig into, for example, MGA DRM, the more convenient it seems
> to have DRM on top of f
>
> Why would layering the DRM on top of the fbdev driver break DirectFB? I
> (think I) understand the issues with actually merging the drivers, but
> the more I dig into, for example, MGA DRM, the more convenient it seems
> to have DRM on top of fbdev.
It won't if you do it properly.. Jons was d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
> And to be honest this is "bollocks" I don't want to quote private mails
> here, but neither myself or benh said anything of the sort from my
> reading, we just a) didn't like your Xegl is the *ONLY* way forward
> approach and b) y
On 6/16/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> You haven't seen intelfb then, it is a train wreck of code and I've no
> idea if it works on most chipsets, it certainly will blow up with wierd
> BIOS configs and funny screen, I won't load it on any platform as-is..
>
> it mainly gives us
> a)
On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> Out of curiosity - who are the people that *need* intelfb ? (as opposed to
> *want*).
To use Xegl it will require you to load both fbdev and DRM drivers for
your hardware. Xegl uses fbdev for things like mode setting. In X.org
mode setti
>
> Out of curiosity - who are the people that *need* intelfb ? (as opposed to
> *want*).
Xegl people will need a kernel framebuffer driver (not necessarily running
the console) but something loaded to take care of X when it starts ...
also this memory manager has to go somewhere, and part of it
there is insufficient info about the specific laptop model to know
what is failing. It's not like the 12 fbdev drivers are chock full of
bugs, they are used routinely on other platforms.
You haven't seen intelfb then, it is a train wreck of code and I've no
idea if it works on most chipsets, it
> I just think this is a giant amount of work to save 70K of memory (by
> allowing a setup which avoids loading fbdev) on desktop x86 machines.
> It is much simpler to just treat fbdev as the bottom layer and have
> two tiers instead of three.
> Wouldn't it be easier to just debug the 12 fbdev dr
On 6/16/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > Three tiers is fine with me and I've never been against it. But we've
> > only been talking about this for two years now and no one has stepped
> > up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to
> > wait another two
>
> Three tiers is fine with me and I've never been against it. But we've
> only been talking about this for two years now and no one has stepped
> up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to
> wait another two years to build Xegl so I'm trying to come up with
> some way
On 6/16/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> And to be honest this is "bollocks" I don't want to quote private mails
> here, but neither myself or benh said anything of the sort from my
> reading, we just a) didn't like your Xegl is the *ONLY* way forward
> approach and b) your approach sto
> The DRM drivers know what is important but they don't know when
> suspend/VT swap is happening because there is only one set of kernel
> hooks and the fbdev driver is attached to them. The scheme where a
> texture copy is kept in system RAM doesn't depend on the DRM driver
> having suspend/VT sw
On 6/16/05, Philip Armstrong <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 11:49:41AM -0400, Jon Smirl wrote:
> > Another proposal is to write a third stub driver. This driver would
> > hook to the ints, suspend, etc. Then DRM and fbdev would register with
> > it. This would work but nobody
On Thu, Jun 16, 2005 at 11:49:41AM -0400, Jon Smirl wrote:
> Another proposal is to write a third stub driver. This driver would
> hook to the ints, suspend, etc. Then DRM and fbdev would register with
> it. This would work but nobody wants to fix 67 fbdev drivers to use
> it.
If a new architectur
On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 16 Jun 2005, Jon Smirl wrote:
>
> > On 6/16/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> >> But, if you implement your scheme, by the same logic you need another
> >> 512mb of system ram just to make things work. If you'
On Thu, 16 Jun 2005, Jon Smirl wrote:
On 6/16/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
But, if you implement your scheme, by the same logic you need another
512mb of system ram just to make things work. If you've got all that
extra ram hanging around, you could implement the single copy
On 6/16/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> But, if you implement your scheme, by the same logic you need another
> 512mb of system ram just to make things work. If you've got all that
> extra ram hanging around, you could implement the single copy scheme and
> when a suspend occurs, p
41 matches
Mail list logo
