> > Do you see any other solution to this then?
>
> You could build this inside of the DRM framework which already
> supports DMA and memory management. DRM doesn't really know anything
> about 3D, it just knows how to send commands to the graphics hardware.
> It's the mesa layer in user space that knows about 3D.
>
> There is a lot of code inside DRM to stop a DRM user from using the
> DMA hardware to play with kernel memory and gain root priv. fbdev will
> need the same protection if it starts using DMA.
I have CC the dri list to discuss the issues. I have looked at the DRI
code. I know merging dri and fbdev infrastructres has been discussed
before. There are a few issues that have always prevented this. Now
I'm going to go over the issues.
1. Lots of work that would take lots of time. To my knowledge all fbdev
developers work in there spare free time. No one does this for a
living.
2. Sharing of headers. The dri headers are isolated in the drm directory.
I totally understand why :-) It makes merging easier for them. The
disadvantage is no one in the fbdev can use them easily :-(
3. DRM has way to much functionality for most embedded devices. I have
talked to embedded guys before and they want a simple api to work with.
By default DRM builds in everything. A simple api mean alot to those
guys. Plus the extra built in code bloat takes up to much space which
is precious on embedded devices. If a devices doesn't support dma then
the dma code doesn't need to be built in.
4. Which comes to the next point. The code is not modular enough. Take
drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
One is the fbdev layer couldn't just link into it so fbcon could use
it. The second is it's not easy to take advantage of things like sysfs.
If you could untangle the code somewhat it would make life so much
easier. That would include making life easier for OS ports.
5. The license issue. The DRI code is GPL and additional rights. What is that?
For the fbdev layer we would need a layer on top of the drm data
structures because we need to know things in the kernel to draw images
for font characters i.e how much byte padding is need for images.
>
> 1. Lots of work that would take lots of time. To my knowledge all fbdev
> developers work in there spare free time. No one does this for a
> living.
So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
contributers apart from new driver submissions...
> 2. Sharing of headers. The dri headers are isolated in the drm directory.
> I totally understand why :-) It makes merging easier for them. The
> disadvantage is no one in the fbdev can use them easily :-(
I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time
I get around to it, just some minor issues.. Arjan asked me for this
ages ago as well...
> 3. DRM has way to much functionality for most embedded devices. I have
> talked to embedded guys before and they want a simple api to work with.
> By default DRM builds in everything. A simple api mean alot to those
> guys. Plus the extra built in code bloat takes up to much space which
> is precious on embedded devices. If a devices doesn't support dma then
> the dma code doesn't need to be built in.
Well crap on that, the old DRM didn't build everything in people
complained aw this code is too messy, build everything in, now you
want to revert? damn you all!!! :-), I understand I'm just saying we
can't have it both ways.. and too be honest I'm an embedded person and
I just want it to work, with a Linux kernel you rarely get to an every
byte counts embedded env, of if you are you aren't using the stock
Linus kernel....
>
> 4. Which comes to the next point. The code is not modular enough. Take
> drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
> One is the fbdev layer couldn't just link into it so fbcon could use
> it. The second is it's not easy to take advantage of things like sysfs.
> If you could untangle the code somewhat it would make life so much
> easier. That would include making life easier for OS ports.
the reason we can't take advantage of sysfs or anything like it is
that we can't bind to the PCI device as we break things.. this is the
root of a lot of our problems...
>
> 5. The license issue. The DRI code is GPL and additional rights. What is that?
Nope the drm code is BSD... there should be no GPL anywhere near it...
it is GPL in the kernel as of course it is imported into a GPL work..
but the code is available for BSD uses....
Jon's last plan - was like to have a radeon basic module, with fb and
drm personalities and in fact any number of personalities..taking
radeon as example:
base module : hotplug, reset, monitor probing, memory management, CP
programming and locking.
fb: adds accelerated fb functions using CP locking.
drm: adds drm functionality on top of base module, drm ioctl interfaces etc..
I've looked at Alans ideas on a vga_class driver and have decided they
are unworkable due to the massive initial changes they involve in
*every* fb/drm driver in the kernel, I cannot undertake a work of that
magnitude without fb people being involved and the chances of breaking
a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a
2.7 for this stuff...
What I do think though is that ideas of a the vga class driver could
be made into a helper module that the base graphics driver uses to do
some standard things, like reset and stuff..
I'm hoping to get a better handle on these ideas and write something
up.. but they are mostly Jons ideas better presented :-)
Dave.
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> > developers work in there spare free time. No one does this for a
> > living.
>
> So do most of the drm developers, I know I do and Jon Smirl does, and
> Eric Anholt does and I think us three have been the largest
> contributers apart from new driver submissions...
Ug :-( That is sad!!!
> > 2. Sharing of headers. The dri headers are isolated in the drm directory.
> > I totally understand why :-) It makes merging easier for them. The
> > disadvantage is no one in the fbdev can use them easily :-(
>
> I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time
> I get around to it, just some minor issues.. Arjan asked me for this
> ages ago as well...
Okay. Where will they go? include/video ?
> > 3. DRM has way to much functionality for most embedded devices. I have
> > talked to embedded guys before and they want a simple api to work with.
> > By default DRM builds in everything. A simple api mean alot to those
> > guys. Plus the extra built in code bloat takes up to much space which
> > is precious on embedded devices. If a devices doesn't support dma then
> > the dma code doesn't need to be built in.
>
> Well crap on that, the old DRM didn't build everything in people
> complained aw this code is too messy, build everything in, now you
> want to revert? damn you all!!! :-),
Ha Ha. I didn't know the history.
> I understand I'm just saying we
> can't have it both ways.. and too be honest I'm an embedded person and
> I just want it to work, with a Linux kernel you rarely get to an every
> byte counts embedded env, of if you are you aren't using the stock
> Linus kernel....
I can live with this issue as long it would not increase the complexity of
framebuffer only devices. Simple api is very important to me. The current
fbdev api is designed to be very simple for the most common cases. It can
get complex tho with exotic hardware.
> > 4. Which comes to the next point. The code is not modular enough. Take
> > drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
> > One is the fbdev layer couldn't just link into it so fbcon could use
> > it. The second is it's not easy to take advantage of things like sysfs.
> > If you could untangle the code somewhat it would make life so much
> > easier. That would include making life easier for OS ports.
>
> the reason we can't take advantage of sysfs or anything like it is
> that we can't bind to the PCI device as we break things.. this is the
> root of a lot of our problems...
Is this because you want to be OS portable? This makes things very very
hard to merge. Fbdev attempts to take advantage the most powerful linux
kernel features.
> > 5. The license issue. The DRI code is GPL and additional rights. What is that?
> Nope the drm code is BSD... there should be no GPL anywhere near it...
> it is GPL in the kernel as of course it is imported into a GPL work..
> but the code is available for BSD uses....
If it is GPL in the kernel then that is fine. We can work with that. I
don't care about userland code.
> Jon's last plan - was like to have a radeon basic module, with fb and
> drm personalities and in fact any number of personalities..taking
> radeon as example:
> base module : hotplug, reset, monitor probing, memory management, CP
> programming and locking.
> fb: adds accelerated fb functions using CP locking.
> drm: adds drm functionality on top of base module, drm ioctl interfaces etc..
That will be a huge amount of work! BTW what does CP stand for?
> I've looked at Alans ideas on a vga_class driver and have decided they
> are unworkable due to the massive initial changes they involve in
> *every* fb/drm driver in the kernel, I cannot undertake a work of that
> magnitude without fb people being involved and the chances of breaking
> a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a
> 2.7 for this stuff...
>
> What I do think though is that ideas of a the vga class driver could
> be made into a helper module that the base graphics driver uses to do
> some standard things, like reset and stuff..
>
> I'm hoping to get a better handle on these ideas and write something
> up.. but they are mostly Jons ideas better presented :-)
As for the VGA class driver. We already have something like that for the
fbdev layer. Take a look at vgastate.c. It was written originally so you
could go from vgacon to fbdev without fbcon and back to vgacon state
again. It also has common functions for all the drivers to work with. I
already asked Jon to merge his work with that code. That code could also
be very useful for vgacon in the future. We need vga core management in
the kernel.
On Tue, 22 Feb 2005 15:46:03 +1100, Dave Airlie <[email protected]> wrote:
> >
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> > developers work in there spare free time. No one does this for a
> > living.
>
> So do most of the drm developers, I know I do and Jon Smirl does, and
> Eric Anholt does and I think us three have been the largest
> contributers apart from new driver submissions...
As far as I know none of the significant contributors on either fbdev
or DRM are being paid to work on the project.
> > 2. Sharing of headers. The dri headers are isolated in the drm directory.
> > I totally understand why :-) It makes merging easier for them. The
> > disadvantage is no one in the fbdev can use them easily :-(
>
> I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time
> I get around to it, just some minor issues.. Arjan asked me for this
> ages ago as well...
I'd like to take this further and move the stuff in drivers/video to
drivers/video/fb and then
move drm from drivers/char/drm to drivers/video/drm. I'd also like to
consolidate drm and fbdev Kconfig menus.
> > 3. DRM has way to much functionality for most embedded devices. I have
> > talked to embedded guys before and they want a simple api to work with.
> > By default DRM builds in everything. A simple api mean alot to those
> > guys. Plus the extra built in code bloat takes up to much space which
> > is precious on embedded devices. If a devices doesn't support dma then
> > the dma code doesn't need to be built in.
>
> Well crap on that, the old DRM didn't build everything in people
> complained aw this code is too messy, build everything in, now you
> want to revert? damn you all!!! :-), I understand I'm just saying we
> can't have it both ways.. and too be honest I'm an embedded person and
> I just want it to work, with a Linux kernel you rarely get to an every
> byte counts embedded env, of if you are you aren't using the stock
> Linus kernel....
If you removed the EXPORT_SYMBOLs and compiled everything in, won't
the compiler just eliminate the dead code for you?
PCI Express is a big reason for the new core/personality split. There
are Nforce4 motherboards now with 16 16x sockets. That means you can
plug 16 different video cards in if you want. The days of a single AGP
slot are over. If someone will send me one (with the four Opteron
chips) I'll write drivers for it.
> > 4. Which comes to the next point. The code is not modular enough. Take
> > drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
> > One is the fbdev layer couldn't just link into it so fbcon could use
> > it. The second is it's not easy to take advantage of things like sysfs.
> > If you could untangle the code somewhat it would make life so much
> > easier. That would include making life easier for OS ports.
>
> the reason we can't take advantage of sysfs or anything like it is
> that we can't bind to the PCI device as we break things.. this is the
> root of a lot of our problems...
This not binding to the PCI device has to be fixed. DRM can not
support hotplug or suspend/resume without a device to bind to.
> Jon's last plan - was like to have a radeon basic module, with fb and
> drm personalities and in fact any number of personalities..taking
> radeon as example:
> base module : hotplug, reset, monitor probing, memory management, CP
> programming and locking.
> fb: adds accelerated fb functions using CP locking.
> drm: adds drm functionality on top of base module, drm ioctl interfaces etc..
I have already coded most of this up and it works for me.
Unfortunately I derived it from the DRM codebase instead of the fbdev
one. fbdev has changed too much in the last six months to allow a
simple merge. Now I'm regenerating patches against fbdev using my
prior code.
A smaller step is to just treat radeonfb as the base module. This will
eat up extra memory for x86 users and they will complain, but we can
split it into three pieces later.
I think good first step would simply be to get DRM and fbdev both into
drivers/video and get the DRM h files into include/linux.
> I've looked at Alans ideas on a vga_class driver and have decided they
> are unworkable due to the massive initial changes they involve in
> *every* fb/drm driver in the kernel, I cannot undertake a work of that
> magnitude without fb people being involved and the chances of breaking
> a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a
> 2.7 for this stuff...
My head hurts thinking about how much editing this would involve.
> What I do think though is that ideas of a the vga class driver could
> be made into a helper module that the base graphics driver uses to do
> some standard things, like reset and stuff..
>
> I'm hoping to get a better handle on these ideas and write something
> up.. but they are mostly Jons ideas better presented :-)
>
> Dave.
>
--
Jon Smirl
[email protected]
On Tue, 22 Feb 2005 05:13:07 +0000 (GMT), James Simmons
<jsimmons@http://www.infradead.org> wrote:
> > > 4. Which comes to the next point. The code is not modular enough. Take
> > > drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
> > > One is the fbdev layer couldn't just link into it so fbcon could use
> > > it. The second is it's not easy to take advantage of things like sysfs.
> > > If you could untangle the code somewhat it would make life so much
> > > easier. That would include making life easier for OS ports.
> >
> > the reason we can't take advantage of sysfs or anything like it is
> > that we can't bind to the PCI device as we break things.. this is the
> > root of a lot of our problems...
>
> Is this because you want to be OS portable? This makes things very very
> hard to merge. Fbdev attempts to take advantage the most powerful linux
> kernel features.
My turn to laugh! It's because Linux only allow one driver to bind to
the device and fbdev has already bound to it. We have done
siginificant work to DRM to try and work around this (stealth mode)
but the right solution is to have a common base driver.
--
Jon Smirl
[email protected]
> As far as I know none of the significant contributors on either fbdev
> or DRM are being paid to work on the project.
So I have noticed. There is much to do but no real man power. We are
talking about this merging but at our rate it will take 5 years to happen.
We don't have the man power to do this. So I'm not going to bother
merging. Its all pipe dreams here.
On Tue, 22 Feb 2005 17:23:03 +0000 (GMT), James Simmons
<jsimmons@http://www.infradead.org> wrote:
>
> > As far as I know none of the significant contributors on either fbdev
> > or DRM are being paid to work on the project.
>
> So I have noticed. There is much to do but no real man power. We are
> talking about this merging but at our rate it will take 5 years to happen.
> We don't have the man power to do this. So I'm not going to bother
> merging. Its all pipe dreams here.
>
>
with that attitude it's never gonna happen. I work almost exclusively
on X, but once we get at least one sample driver done (probably
radeon, I would be more than happy to devote my limited development
resources to the new drm/fb super driver. Right now the kernel FB
drivers have no benefit for me so I don't use/develop them. The drm
just works and I'm more interested in the crtc/modes/outputs handling
than the command processor control stuff. I think a lot of X
developers (and porobably IHVs) will get on board when this happens.
X is undermanned as well, but we've managed to do a pretty good job of
supported a lot of features on a fair number of cards.
Alex