Add three new IOCTLs to FB API

Add three new IOCTLs to FB API

[Jon Smirl]

I'd like to add three new IOCTLs to the FB API to help support standalone Mesa.
The idea is to eliminate the need for config files. Xfree might even use these
in the future.

In order to load DRM 3D support I need two pieces of information. The name of
the 3D DRM driver and the bus:dev:func of the hardware. DRM does not implement
PCI ID probing, instead you need to it what hardware to use. 

By adding these to the FB API you can start standalone Mesa just by specifying
the name of the FB device to use. I can pick up mode and resolution from the
existing FB API.

1) Get location of card that is associated with this fb device. It would return
bus,dev,func of hardware. There may be more than one piece of the same hardware
installed.

3) Get vendor and card PCI ID

2) Get 3D driver name. Return the name of the DRM driver that is associated
with this fb device. For example aty128fb would return r128, radeonfb would
return radeon. Empty string if there is none. There are eight DRM drivers and
15 fb ones.

The functions are trivial to implement but implementing them will require
touching all of the fbdev files.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Ian Romanick]

Jon Smirl wrote:

> 1) Get location of card that is associated with this fb device. It would return
> bus,dev,func of hardware. There may be more than one piece of the same hardware
> installed.
> 
> 3) Get vendor and card PCI ID

This should also return the Subsystem vendor and ID.

> 2) Get 3D driver name. Return the name of the DRM driver that is associated
> with this fb device. For example aty128fb would return r128, radeonfb would
> return radeon. Empty string if there is none. There are eight DRM drivers and
> 15 fb ones.

Would that be just the DRM name or the client-side DRI driver name as 
well?  Don't you need both?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Geert Uytterhoeven]

On Sun, 21 Sep 2003, Jon Smirl wrote:
> I'd like to add three new IOCTLs to the FB API to help support standalone Mesa.
> The idea is to eliminate the need for config files. Xfree might even use these
> in the future.

For 2.4.x or 2.6.0?

> In order to load DRM 3D support I need two pieces of information. The name of
> the 3D DRM driver and the bus:dev:func of the hardware. DRM does not implement
> PCI ID probing, instead you need to it what hardware to use. 
> 
> By adding these to the FB API you can start standalone Mesa just by specifying
> the name of the FB device to use. I can pick up mode and resolution from the
> existing FB API.
> 
> 1) Get location of card that is associated with this fb device. It would return
> bus,dev,func of hardware. There may be more than one piece of the same hardware
> installed.
> 
> 3) Get vendor and card PCI ID

In 2.6.0, you should be able to get them from sysfs, once fbdev does full
sysfs.

Note that both are PCI-specific, for whatever that matters (no DRM for non-PCI
chips anyway, right?).

> 2) Get 3D driver name. Return the name of the DRM driver that is associated
> with this fb device. For example aty128fb would return r128, radeonfb would
> return radeon. Empty string if there is none. There are eight DRM drivers and
> 15 fb ones.

I think this should be done using sysfs, too. I.e. symbolic links between the
fbdev and drm drivers in /sys.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Michel Dänzer]

On Mon, 2003-09-22 at 07:28, Jon Smirl wrote:
> 
> In order to load DRM 3D support I need two pieces of information. The name of
> the 3D DRM driver and the bus:dev:func of the hardware. DRM does not implement
> PCI ID probing, instead you need to it what hardware to use. 
> 
> By adding these to the FB API you can start standalone Mesa just by specifying
> the name of the FB device to use. I can pick up mode and resolution from the
> existing FB API.
> 
> 1) Get location of card that is associated with this fb device. It would return
> bus,dev,func of hardware. There may be more than one piece of the same hardware
> installed.
> 
> 3) Get vendor and card PCI ID
> 
> 2) Get 3D driver name. Return the name of the DRM driver that is associated
> with this fb device. For example aty128fb would return r128, radeonfb would
> return radeon. Empty string if there is none. There are eight DRM drivers and
> 15 fb ones.

For radeon, you also need to know whether it's an R100 or R200 core (for
the 3D driver, as Ian pointed out, but also for the CP init ioctl).

Maybe these could be handled via sysfs instead of adding ioctls?

Also, at least with radeonfb, the fix.id field contains the chip ID.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Jon Smirl]

--- Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, 21 Sep 2003, Jon Smirl wrote:
> > I'd like to add three new IOCTLs to the FB API to help support standalone 
Mesa.
> > The idea is to eliminate the need for config files. Xfree might even use
these
> > in the future.
> 
> For 2.4.x or 2.6.0?
For 2.6

> > 2) Get 3D driver name. Return the name of the DRM driver that is associated
> > with this fb device. For example aty128fb would return r128, radeonfb would
> > return radeon. Empty string if there is none. There are eight DRM drivers
> and
> > 15 fb ones.
> 
> I think this should be done using sysfs, too. I.e. symbolic links between the
> fbdev and drm drivers in /sys.

Initially the fb device will need to provide strings for the name of the 3D
driver. A user app is going to read these strings and load the DRM driver.
After the DRM driver is loaded it can make links.

Another solution would be for the fb driver to reference a symbol in the
appropriate DRM driver. This would make modprobe load them both.

What should the /sys entries look like for fb devices?



=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Ian Romanick]

Geert Uytterhoeven wrote:
> On Sun, 21 Sep 2003, Jon Smirl wrote:
> 
>>3) Get vendor and card PCI ID
> 
> In 2.6.0, you should be able to get them from sysfs, once fbdev does full
> sysfs.
> 
> Note that both are PCI-specific, for whatever that matters (no DRM for non-PCI
> chips anyway, right?).

Right.  Just PCI and AGP (which looks like PCI).  Presumably PCI Express 
will look the same.  I can't imagine ISA or VLB cards being supported. 
Ever.  At some point someone *may* support Sun's UPA or some other 
proprietary graphics interface, but I wouldn't lose too much sleep over 
it. :)

>>2) Get 3D driver name. Return the name of the DRM driver that is associated
>>with this fb device. For example aty128fb would return r128, radeonfb would
>>return radeon. Empty string if there is none. There are eight DRM drivers and
>>15 fb ones.
> 
> I think this should be done using sysfs, too. I.e. symbolic links between the
> fbdev and drm drivers in /sys.

I'm not that familiar with how sysfs works.  How would this look? 
There'd be a tree like:

     /sys/
         card0/
             dri.so (link to client-side driver)
             DRM_device (link to DRM device that will load kernel module)
             PCI_INFO (file containing PCI device information)

Or something roughly similar?  If so, I think this would be a 
*wonderful* way to handle it. :)




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Michel Dänzer]

On Mon, 2003-09-22 at 22:25, Jon Smirl wrote:
> 
> > > 2) Get 3D driver name. Return the name of the DRM driver that is associated
> > > with this fb device. For example aty128fb would return r128, radeonfb would
> > > return radeon. Empty string if there is none. There are eight DRM drivers
> > and
> > > 15 fb ones.
> > 
> > I think this should be done using sysfs, too. I.e. symbolic links between the
> > fbdev and drm drivers in /sys.
> 
> Initially the fb device will need to provide strings for the name of the 3D
> driver. A user app is going to read these strings and load the DRM driver.

So the app will map from 3D driver to DRM?

> After the DRM driver is loaded it can make links.

The framebuffer device could do it just as well, the link target doesn't
have to exist.

> Another solution would be for the fb driver to reference a symbol in the
> appropriate DRM driver. This would make modprobe load them both.

This doesn't work because the framebuffer device is needed for console
on boot and hence built into the kernel. :)


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Ville Syrjälä]

On Sun, Sep 21, 2003 at 10:28:38PM -0700, Jon Smirl wrote:
> I'd like to add three new IOCTLs to the FB API to help support standalone Mesa.
> The idea is to eliminate the need for config files. Xfree might even use these
> in the future.
> 
> 1) Get location of card that is associated with this fb device. It would return
> bus,dev,func of hardware. There may be more than one piece of the same hardware
> installed.
> 
> 3) Get vendor and card PCI ID

I'd like to have these too. DirectFB needs to know if the chip is G400 or
G450/G550. Currently we just pick the first entry found in /proc/bus/pci
and hope it has the same chip type as the /dev/fb we're using.

> 2) Get 3D driver name. Return the name of the DRM driver that is associated
> with this fb device. For example aty128fb would return r128, radeonfb would
> return radeon. Empty string if there is none. There are eight DRM drivers and
> 15 fb ones.

Why does this have to be in the kernel? You already have the PCI IDs so
you should be able to handle this in user space.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Add three new IOCTLs to FB API

[Kronos]

Il Mon, Sep 22, 2003 at 04:18:15PM -0700, Ian Romanick ha scritto: 
> >>2) Get 3D driver name. Return the name of the DRM driver that is 
> >>associated
> >>with this fb device. For example aty128fb would return r128, radeonfb 
> >>would
> >>return radeon. Empty string if there is none. There are eight DRM drivers 
> >>and
> >>15 fb ones.
> >
> >I think this should be done using sysfs, too. I.e. symbolic links between 
> >the
> >fbdev and drm drivers in /sys.
> 
> I'm not that familiar with how sysfs works.  How would this look? 
> There'd be a tree like:
> 
>     /sys/
>         card0/
Actually it will be /sys/graphics/fb0

>             dri.so (link to client-side driver)

Userspace  library? We  can  put  the   name  here,  not  a  symlink  to
the  library. sysfs  deals  only  with kobjects  (ie.  things that  live
somewhere in the  kernel). We can create link between  two kobjects (see
sysfs_create_link) but not between a kobject and something else.

>             DRM_device (link to DRM device that will load kernel module)

Do you mean device under /dev? Can't do that, see above. We can put
module name, so a user can do:
modprobe `cat /sys/graphics/fb0/drm_module`

>             PCI_INFO (file containing PCI device information)

Under /sys/graphics/fb0 there will be a "device" symlink. This will take
you to the device dir:
root@dreamland:/sys/bus/pci/devices/0000:01:00.0# ls
class  config  detach_state  device  irq  power/  resource subsystem_device  subsystem_vendor  vendor
root@dreamland:/sys/bus/pci/devices/0000:01:00.0# cat vendor device subsystem_vendor subsystem_device
0x1002
0x4e45
0x1681
0x0002

You can get everything from here without the need to add another
attribute.

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Ci sono due cose che l'uomo non puo` nascondere:
essere ubriaco ed essere innamorato.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf