On 12/02/15 18:21, David Herrmann wrote: > Hi > > On Tue, Feb 10, 2015 at 11:37 PM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> On 02/02/15 00:14, Emil Velikov wrote: >>> Hi all, >>> >>> As mentioned a couple of days ago at #dri-devel some(most) users of >>> render nodes tend to rely on strict mapping between the primary and >>> render node. I.e. something along the lines of >>> >>> fstat(render_fd, &sbuf); >>> sprintf(primary_node, "/dev/dri/card%d", >>> ((sbuf.st_rdev & 0x3f) | 0x80)); >>> >>> Currently the following are (ab)using the above code: >>> - xf86-video-nouveau >>> - xf86-video-intel >>> - libva (vaapi) >>> >>> As reminded by David Herrman, this is not the correct solution - thus >>> I've added a couple of helpers which walk through sysfs of the >>> respecitive device and return the correct device name. >>> >>> I'm not 100% happy with the function names, so suggestions are greatly >>> appreciated. Any other comments are also welcome :) >>> >>> Note: BSD guys - you'll likely need your own version of these functions. >>> >> David, Daniel >> >> Can you please take a look at these two patches. Would be great if we >> can minimize the above assumptions before they get too wide spread. > > The patches look ok. I really dislike the direct file-probing, though. > I'd recommend using libudev or readdir_r() on /dev/dri/, but I'm not > the one to ask about coding-style for libdrm, so fine with me. > Thanks for having a look. libudev is no used in libdrm so I will stay away for now. I would prefer to use readdir on /dev/dri/ but AFAICT there is no way to get the mapping from those alone. Am I missing something ? I'm also thinking that changing the prototypes, as below, might be useful - i.e. return 0 on success, -ENODEV when the corresponding device lacks render/primary device, and other negative value on error ? char *drmGetRenderNameFromDeviceFD(int fd); char *drmGetDeviceNameFromRenderFD(int fd); int drmGetRenderNameFromDeviceFD(int fd, char **render); int drmGetDeviceNameFromRenderFD(int fd, char **device); Cheers, Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
