On Sunday 03 July 2005 12:31, Jon Smirl wrote: > On 7/3/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > > Shouldn't this just be a string you pull right out of a drm ioctl? I > > know the name currently lives in the server, but as with many things the > > server does I think that's a mistake. > > > > Binding EGL driver load to sysfs is not portable. > > The code is only in my Linux drivers. In your EGL app you specify > something like ":0". The generic code is wired to always load > dri_egl.so for the :? syntax. dri_egl then figures out which screen > corresponds to :0 and looks for the DRM sysfs entry. It then uses that > to load the right DRI driver and passes control over.
Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I
was anticipating:
- eglChooseDisplayMESA("display/0")
- EGL translates to /dev/dri/card0, opens it
- ioctl: what's the DRI driver name for this device?
- kernel: i915
- EGL loads i915_dri.so, calls its egl setup
- eglCreateContext notices the attached dri driver, does device setup
I guess I don't see the point of loading one module to have it load another,
particularly if that first module is always getting loaded.
> On Linux sysfs attributes and ioctls are very similar. It is now
> preferred on Linux to get simple things like this from a sysfs
> attribute instead of an ioctl since the sysfs attributes avoid 32/64
> and endian issues. It is also easy for a human to see which driver the
> DRM module needs.
The human should never have to care. There's going to need to be an ioctl for
this _anyway_ if anyone ever implements this on non-Linux. We should really
be avoiding OS-specific code paths in the driver as much as possible. That's
why we have the abstract DRM interface to begin with.
- ajax
pgpTWRV79UQ9l.pgp
Description: PGP signature
