[Dri-devel] libdrm.a Bugs

[Sottek, M. J <mat...@in...>]

All,
 I'm doing a direct rendered HWMC (XvMC protocol) driver for the i81x, I am
compiling the drm Libs outside of the X server and have run into a problem.
The
current Linux kernel is allocating minor numbers for the device dynamically,
but
the drm Libs don't seem to have caught up with this idea. Here is the broken
scenario:

* X starts up and creates a /dev/dri/card0 at major minor 10,63. (actually
as
I write this I'm curious as to how X knows where to find it)

* My client library (when running as root) does a drmAvailable() call.
drmAvailable()
calls drmOpenMinor() with minor number 0. drmOpenMinor calls drmOpenDevice
which opens up card0 finds that card0 does not have minor number 0 and
_removes_ it! At the end of the process I'm left without a device file at
all!

* drmOpen("i810", NULL) has the same issue. It uses drmOpenByName()
which then calls drmOpenMinor for each minor number in the range (the
incorrect range) looking for a device, but it never finds it.

  I'm unsure of how to solve this properly. Obviously X is using the same
library
and it gets the device correct... I need to find out how.

  Clearly drmAvailable() should not be removing device files. It should
probably open
any available files first to see if they work, then only if none of them are
working
should it attempt to create it's own files. It shouldn't care that the path
name
does not end in the device number.
  drmOpen() should probably do the same... open existing files first, if
none
match the name or busid _then_ go about creating new devices.
   The while thing seems a little odd to me. If the kernel module is getting
a
dynamically allocated device number then it should be responsible for
creating
the device file itself using devfs or some other means. X can come along an
chmod/chomod it to the correct permissions if need be.

  I can get around the problems by just turning off the "create" parameter
passed
to drmOpenMinor() knowing that X has already created my device, however the
problem still needs to be looked into for a more complete solution.

-Matt