Re: [RFC PATCH 0/2] libdrm: Add master <> render node helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13/02/15 11:18, Frank Binns wrote:
> Hi Emil,
> 
> On 13/02/15 09:18, Emil Velikov wrote:
>> 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 ?
> Can you you not just use use readdir on /dev/dri and stat on each
> entry's d_name comparing the result to an fstat on the fd?
Unless I've misunderstood something, a primary device will have
226:{0-63}, while render device 226:{128-191}.

One cannot just mask out the 7th bit, as this is the (wrong) solution
what I've mentioned above. Or maybe I'm missing something ?
Afaict the information/"link" between the two is present at the drm
module level - thus the ugly sysfs dance.

> Once you find a match you just strdup the d_name.
> 
>>
>> 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);
> I personally prefer this as it fits in better with what we already have.
> 
The recent inspiration came from the prime helpers. I don't feel
strongly either way.

Cheers,
Emil
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux