All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonyoung Shim <jy0922.shim@samsung.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Daniel Kurtz <djkurtz@google.com>,
	cpgs@samsung.com, dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] xf86drm: remove to open the DRM device unnecessarily
Date: Mon, 01 Jun 2015 11:53:09 +0900	[thread overview]
Message-ID: <556BC915.1080603@samsung.com> (raw)
In-Reply-To: <CACvgo50b4vKS+vQgy-nTxEv+fJibJH+Um=Pdwv9Fqx5vf+EmiQ@mail.gmail.com>

On 05/30/2015 10:20 PM, Emil Velikov wrote:
> On 29 May 2015 at 07:50, Joonyoung Shim <jy0922.shim@samsung.com> wrote:
>> On 05/29/2015 12:51 AM, Emil Velikov wrote:
>>> Seems like I'm either too subtle and/or too stingy earlier.
>>>
>>> If drmAvailable() returns false, we have two options:
>>>  - opt for the old-schoold (dri1) and ask drm_server_info to load the
>>> module for us, or
>>>  - bail out, as neither drmOpenByBusid() or drmOpenByName() will be
>>> able to open the device considering that a DRM module is not loaded.
>>>
>>> So what I was hinting earlier was to make the above more obvious,
>>> rather than reordering the arguments in the if clause. How does that
>>> sound ?
>>>
>>
>> I'm unhappy about to open DRM device always via drmAvailable(). IMHO
>> it's enough to check DRM device can be open by drmOpenByBusid() or
>> drmOpenByName() if don't load module and actually i expect DRM device
>> is open only once when call drmOpenWithType().
>>
> Seems that checking via drmAvailable() is quicker than going through
> the whole drmOpen*. On the other side the former does not cater for
> render only devices... fun.
> 

If want to check via drmAvailable(), we can call it regardless of
drmOpen*.

> Seems like this is the price to pay, considering that our current
> libdrm caters after both UMS(DRI1) and KMS(DRI2+) drivers. In the
> kernel we did have some nice cleanup (props to Daniel V and others)
> although in the userspace side things are less polished.
> 
> Perhaps we can get libdrm 3 soon or start annotating the old functions
> as depreciated ? Curious if one should add libdrm_ancient.so (or
> similar) to ensure that things don't break when building old apps
> against new libdrm ?
> 
> TLDR: No objections against the patch, but we should consider
> cleaning/splitting the ancient APIs.
> 

Agree but what i wanted to say is just to remove unnecessary to open DRM
device in drmOpen*.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2015-06-01  2:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28  0:57 [PATCH] xf86drm: remove to open the DRM device unnecessarily Joonyoung Shim
2015-05-28  9:00 ` Zhou, Jammy
2015-05-28 13:13 ` Emil Velikov
2015-05-28 14:15   ` Daniel Kurtz
2015-05-28 15:51     ` Emil Velikov
2015-05-29  6:50       ` Joonyoung Shim
2015-05-30 13:20         ` Emil Velikov
2015-06-01  2:53           ` Joonyoung Shim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556BC915.1080603@samsung.com \
    --to=jy0922.shim@samsung.com \
    --cc=cpgs@samsung.com \
    --cc=djkurtz@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.