[1/2] loader: add loader_open_name(..)
Emil Velikov
emil.l.velikov at gmail.com
Fri Aug 17 09:20:12 UTC 2018
On 14 August 2018 at 11:16, Christian Gmeiner
<christian.gmeiner at gmail.com> wrote:
> Am Fr., 10. Aug. 2018 um 19:52 Uhr schrieb Emil Velikov
> <emil.l.velikov at gmail.com>:
>>
>> On 10 August 2018 at 13:25, Martin Fuzzey <martin.fuzzey at flowbird.group> wrote:
>> > Hi Christian,
>> >
>> > On 01/08/18 23:07, Christian Gmeiner wrote:
>> >>
>> >> Add an improved drmOpenWithType(..) clone which fixes some serious
>> >> flaws. Some highlights:
>> >> - using busid works only with PCI devices
>> >> - open() w/o O_CLOEXEC
>> >> - when build w/o udev - it creates a node: mkdir, chown(root), chmod,
>> >> mknod
>> >> - calls back into Xserver/DDX module
>> >> - last but no least - borderline hacks with massive documentation [1]
>> >> to keep this running.
>> >>
>> >> Signed-off-by: Christian Gmeiner <christian.gmeiner at gmail.com>
>> >
>> >
>> > Why do this in mesa rather than fixing (or adding a new version if necessary
>> > for backwards compatibility) to the libdrm code?
>> >
>> By fixing the libdrm code, we'll break old users - something that is a
>> no-go for open-source projects.
>
> If we add a complete new api function to libdrm and it gets accepted I am okay
> to put my effort into this direction.
>
Normally, yes. Sadly there is far too much historical baggage so new
stuff gets lost/missed/unused :-\
>> I've been slowly chipping on libdrm3 for far too long. Sadly it's not
>> the most enjoyable thing to hack on in one's spare time.
>>
>
> libdrm3 sounds interesting... do you have some more information about
> this beast?
>
Have to fish out/push the branch somewhere. Ideally this weekend, but
no guarantee.
>> FWIW, Christian's second take on the topic is here [1].
>>
>
> Which I have planed to push by the end of the week.
>
Sure thing.
Thanks
Emil
More information about the etnaviv
mailing list