From: Jon Smirl <hidden> Date: 2003-09-22 05:28:39
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
From: Ian Romanick <hidden> Date: 2003-09-22 06:13:49
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
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
From: Michel Dänzer <hidden> Date: 2003-09-22 10:23:34
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
I'd like to add three new IOCTLs to the FB API to help support standalone
Mesa.
quoted
The idea is to eliminate the need for config files. Xfree might even use
these
quoted
in the future.
For 2.4.x or 2.6.0?
For 2.6
quoted
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
quoted
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
From: Ian Romanick <hidden> Date: 2003-09-22 23:18:51
Geert Uytterhoeven wrote:
On Sun, 21 Sep 2003, Jon Smirl wrote:
quoted
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. :)
quoted
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
From: Michel Dänzer <hidden> Date: 2003-09-23 00:28:04
On Mon, 2003-09-22 at 22:25, Jon Smirl wrote:
quoted
quoted
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
quoted
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
Il Mon, Sep 22, 2003 at 04:18:15PM -0700, Ian Romanick ha scritto:
quoted
quoted
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