Re: libdrm

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The default code in drmGetDeviceFromDevId() calls readdir(3) on the
> "/dev/dri" directory to get a list of the devices then prunes this
> down to one on each bus.

This will break on multiheaded systems with multiple framebuffers on
the same bus.

Furthermore, except for diagnostic tools, userland has no business
whatever caring about what bus, nor even what _kind_ of bus, a device
is on.  (This is one of my major beefs with X.org.)

> We want the retained device node to be the one for the framebuffer,

"The" framebuffer?  Again, broken from the start on multiheaded
systems.

> The unsorted order of the nodes in the directory will depend on when
> they were created though, [...]

This is filesystem-specific; nothing promises that the order seen by
readdir() matches the order in which the entries were created.  Even
for FFS that may not be true (it _usually_ will be, but removals, or
creating a shorter name after a longer name, can make it false).

Indeed, as far as I know nothing specifies that the order seen by one
readdir() traversal will match the order seen by another readdir(),
even if the directory isn't changed in between (for FFS, in the absence
of changes to the directory I think this one _is_ true).

> We need something more robust though,

Agreed.

> any ideas?

The only one I see is to provide a kernel interface of some sort that
has the kernel do the pruning and sorting.  (Well, there's also "fix
Mesa", but even if that's technically feasible it likely runs into
political headaches getting the result upstreamed.  "Replace Mesa",
while arguably better in that it avoids the political headaches, runs
into a different set of - probably bigger - headaches.)

There are multiple possible ways this could be done; the first two that
come to mind are (1) a drifs, mounted on /dev/dri, which presents
things in the desired order and (2) a pseudo-device which takes a list
of device <major,minor> numbers in some form and returns it pruned and
sorted.  This could be a cloner that uses read and write, it could be
via ioctl, whatever.  There are doubtless other alternatives.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B