from:"Chih\-Wei Huang"

Re: [PATCH] xf86drm: add drmOpenByFB

2020-05-28 Thread Chih-Wei Huang

Simon Ser  於 2020年5月25日 週一 上午3:25寫道：
> On Sunday, May 24, 2020 8:53 PM, Daniel Vetter  wrote:
> > On Sat, May 23, 2020 at 5:44 PM Mauro Rossi issor.or...@gmail.com wrote:
> >
> > > OpenByFB is introduced to overcome GPU driver loading order issue
> > > on a device with multiple GPUs, e.g. Intel iGPU and Nvidia dGPU
> > > where the first drmfb kernel module loaded will become device file
> > > /dev/dri/card0 and the second will become /dev/dri/card1
> > > The use case is to prefer Intel iGPU over dGPU, or viceversa,
> > > in a deterministic and reliable manner.
> > > OpenByFB function opens the DRM device with specified fb and node type,
> > > thus enabling gralloc to open the correct device node of the primary fb,
> > > regardless of the GPU driver loading order.
> >
> > The fbdev load ordering is as inconsistent/random as the dri node
> > loading. Well more so, because you might have random firmware fbdev
> > drivers hanging out there. Hence I'm not following how this solves
> > anything for your problem.
> >
> > I think usually what userspace does it look at the boot_vga property
> > of the underlying device in sysfs, and prefer that one.

Thank you for the reply.
I'm not the expert so
I can't fully understand what you mean.
What does 'boot_vga' mean and how could it help our problem?

The main problem we're trying to solve is to
find the DRM device of the primary framebuffer (fb0).
I believe /sys/class/graphics/fb0/device/drm
is the correct one we could use.
At least it works on all devices I've tested
including nvidia optimus notebooks.
If there is a simpler way to get the DRM device of fb0
I'm happy to learn.

> Yes. See [1] for an example of how to do this.
>
> [1]: 
> https://github.com/swaywm/wlroots/blob/5c942bd5972afee9a68cb15c14aa83b4b0aaf82d/backend/session/session.c#L331

Thank you for the example.
However, our target platform is Android and
Android doesn't have udev. So I'm afraid we can't use it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

2019-06-23 Thread Chih-Wei Huang

Sorry for the late reply since I didn't notice it.
(I rarely read the ML)

The patch of Jiyong Park is the one he submitted to the ML before.
https://patchwork.kernel.org/patch/9864539/
https://patchwork.kernel.org/patch/10109599/

I'm not sure why it's not merged. Maybe just forgotten.

The 2nd and 3rd patch (mine and Mauro's) could be combined
into one before submission, I think.


Mauro Rossi  於 2019年4月27日 週六 上午6:06寫道：
>
> Here is patch using include 
> which should suffice for the purpose.
> Cheers
>
> Mauro
>
> On Mon, Apr 22, 2019 at 11:46 AM Mauro Rossi  wrote:
> >
> > Hi Emil, Chih-Wei,
> >
> > what about the series of latest three patches we have in oreo-x86 branch?
> >
> > [oreo-x86 branch]
> > http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=history;f=Android.mk;h=f832b24e99007c75ce3a8d9a3ece34d4e475e957;hb=refs/heads/oreo-x86
> >
> > My doubt is about the one "android: make libdrm*.so available to the
> > vendor partition",
> > should we keep it (and send to mesa/drm) so that we will simply have
> > our x86 branches aligned to mesa/drm,
> > or should we skip it in both cases?
> >
> > Once this is assessed I will either send the series of 3 or just the
> > android logging one.
> > Mauro
> >
> > Mauro
> >
> > On Wed, Apr 17, 2019 at 7:50 PM Emil Velikov  
> > wrote:
> > >
> > > On Mon, 18 Mar 2019 at 13:32, Tapani Pälli  wrote:
> > > > On 3/18/19 3:25 PM, Robert Foss wrote:
> > > > > Hey,
> > > > >
> > > > > On 3/18/19 2:11 PM, Mauro Rossi wrote:
> > > > >> Hi,
> > > > >>
> > > > >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
> > > > >>  wrote:
> > > > >>>
> > > > >>> Hey Mauro,
> > > > >>>
> > > > >>> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> > > > >>>> Hi Robert,
> > > > >>>>
> > > > >>>> On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
> > > > >>>>  wrote:
> > > > >>>>>
> > > > >>>>> On a second note, this does not apply on libdrm/master due
> > > > >>>>> to:
> > > > >>>>>
> > > > >>>>> LOCAL_SHARED_LIBRARIES := \
> > > > >>>>>   libcutils
> > > > >>>>
> > > > >>>> Sorry, we have an additional Google patch, not present in 
> > > > >>>> libdrm/master
> > > > >>>> that adds libdrm_platform module, but it is for a specific Google
> > > > >>>> issue. [1]
> > > > >>>>
> > > > >>>> However with libdrm module we have both liblog and libcutils shared
> > > > >>>> dependencies
> > > > >>>>
> > > > >>>> [1]
> > > > >>>> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e
> > > > >>>>
> > > > >>>
> > > > >>> Do you know if [1] causes incompatibility issues with earlier 
> > > > >>> android
> > > > >>> verions?
> > > > >>> If not I would suggest upstreaming it too.
> > > > >>
> > > > >> I used those patches to build with nougat-x86 and there was no issue.
> > > > >>
> > > > >> To be precise I did a double rookie mistake, because 
> > > > >> __android_log_vprint
> > > > >> not used in upstream libdrm and libdrm_platform not used either.
> > > > >>
> > > > >> Now starting from my mistakes, let's see if there is anything useful
> > > > >> to libdrm project
> > > > >>
> > > > >> In our builds Chih-Wei Huang said that libdrm_platform is not used,
> > > > >> meaning not added to packages list,
> > > > >> however with oreo-x86 the build error appeared and the liblog 
> > > > >> dependency.
> > > > >>
> > > > >>   __android_log_vprint is used with __ANDROID__ braces
> > > > >> in a special patch [2] by Chih-Wei Huang which adds capability to
> > > > >> print logs
> > > > >> in logcat
> > > > >>
> > > > >> If it's not too invasive in libdrm, it could be useful.
> > > > >> Cheers
> > > > >> Mauro
> > > > >>
> > > > >> [2]
> > > > >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9
> > > > >>
> > > > >
> > > > > [2] Seems like a good idea to me.
> > > > > Logcat really is the only intended path for logging on Android, and
> > > > > redirecting our logs there does make sense to me.
> > > > >
> > > > > But, I'm not sure about I like the way [2] disregards log-levels in
> > > > > drmMsg().
> > > > >
> > > >
> > > > Yeah, I think it's a good idea. I see that in mesa we include
> > > > "android/log.h", not "log/log.h", will need to make sure we get that
> > > > correctly, maybe older versions did "log/log.h"?
> > > >
> > > I would also be in favour of adding logcat support to libdrm.
> > >
> > > Mauro, please respin when you have the time.



--
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] intel: annotate the intel genx helpers as private

2018-09-21 Thread Chih-Wei Huang

2018-09-20 7:18 GMT+08:00 Lucas De Marchi :
> On Wed, Sep 19, 2018 at 03:47:48PM +0800, Chih-Wei Huang wrote:
>> 2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
>> > +Chris
>> >>
>> >> That's because drm_gralloc use the IS_GEN9 macro
>> >> (and other IS_GEN{n} macros) directly.
>> >>
>> >> Since IS_GEN{n} are public APIs, I don't see
>> >
>> >
>> > IS_GEN() is *not* public API and should not be. It's an internal macro.
>> >
>> > DESTDIR=/tmp/inst ninja -C build install
>> > grep -r IS_GEN /tmp/inst/
>> > Binary file /tmp/inst/usr/local/lib64/libdrm_intel.so.1.0.0 matches
>> >
>> >   [  same thing when using autotools ]
>> >
>> > Grepping https://android.googlesource.com/platform/external/drm_gralloc/ I
>> > see IS_GEN* is being used, but I don't see where it's getting it from,
>> > unless it's using private headers... Let's see by grepping it:
>> >
>> > $ git grep intel_chipset
>> > gralloc_drm_intel.c:#include "intel_chipset.h" /* for platform detection
>> > macros */
>> >
>> > oh. You're a using a private header :(. How many places and libraries will
>> > we need to update to support different platforms? This is crazy.
>> > AFAICS it only uses that to get the max_stride for each platform... this
>> > info should be coming from somewhere else. Chris, any idea here?
>>
>> Hmm... There is no private declaration in this header.
>
> ???
>
>> Why is it private?
>
> All headers are private unless they are exported/installed. Android does
> things a little differently by incorporating libdrm inside this drm_gralloc.
>
>> If so, what is the correct way to get the gen of Intel's GPU?
>> Or the userspace should not know it?
>
> libdrm *is* userspace.

Sorry.
I meant an app which uses libdrm.
Shouldn't the app know the gen?

One interesting I just found.
I noticed Mesa has its own intel_chipset.h
which defines the IS_GEN3 macro.
(~src/mesa/drivers/dri/i915/intel_chipset.h)

So... to get the gen, I need to write my own header?
Or just copy libdrm's header?

> Better question: why do you need to know the gen? Can
> this be decided in another way by using a properly exported function from
> libdrm?

OK. That's another question.
The simple answer is I don't know.
That code is not written by me.
The code was written by some Google and Intel engineers.
So Intel engineer didn't think that header is private,
at least at that time he wrote the code...

> If you only want to hack it to work again, just link with the static library
> since you are already incorporating the library, as Chris suggested. If you
> want to do it right you may need to look into your library to see why it
> is doing that.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] intel: annotate the intel genx helpers as private

2018-09-19 Thread Chih-Wei Huang

2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
> +Chris
>>
>> That's because drm_gralloc use the IS_GEN9 macro
>> (and other IS_GEN{n} macros) directly.
>>
>> Since IS_GEN{n} are public APIs, I don't see
>
>
> IS_GEN() is *not* public API and should not be. It's an internal macro.
>
> DESTDIR=/tmp/inst ninja -C build install
> grep -r IS_GEN /tmp/inst/
> Binary file /tmp/inst/usr/local/lib64/libdrm_intel.so.1.0.0 matches
>
>   [  same thing when using autotools ]
>
> Grepping https://android.googlesource.com/platform/external/drm_gralloc/ I
> see IS_GEN* is being used, but I don't see where it's getting it from,
> unless it's using private headers... Let's see by grepping it:
>
> $ git grep intel_chipset
> gralloc_drm_intel.c:#include "intel_chipset.h" /* for platform detection
> macros */
>
> oh. You're a using a private header :(. How many places and libraries will
> we need to update to support different platforms? This is crazy.
> AFAICS it only uses that to get the max_stride for each platform... this
> info should be coming from somewhere else. Chris, any idea here?

Hmm... There is no private declaration in this header.
Why is it private?

If so, what is the correct way to get the gen of Intel's GPU?
Or the userspace should not know it?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] intel: annotate the intel genx helpers as private

2018-09-13 Thread Chih-Wei Huang

Note this patch breaks drm_gralloc:

FAILED: 
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
/bin/bash -c "prebuilts/clang/host/linux-x86/clang-4053586/bin/clang++
-nostdlib -Wl,-soname,libgralloc_drm.so -Wl,--gc-sections -shared
out/target/product/x86_64/obj_x86/lib/crtbegin_so.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_kms.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_intel.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_radeon.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_nouveau.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_pipe.o
-Wl,--whole-archive  -Wl,--no-whole-archive
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a
  
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
-Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--gc-sections
-Wl,--hash-style=gnu -Wl,--no-undefined-version -m32  -target
i686-linux-android
-Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
-Wl,--no-undefined out/target/product/x86_64/obj_x86/lib/libdrm.so
out/target/product/x86_64/obj_x86/lib/liblog.so
out/target/product/x86_64/obj_x86/lib/libcutils.so
out/target/product/x86_64/obj_x86/lib/libhardware_legacy.so
out/target/product/x86_64/obj_x86/lib/libdrm_intel.so
out/target/product/x86_64/obj_x86/lib/libdrm_radeon.so
out/target/product/x86_64/obj_x86/lib/libdrm_nouveau.so
out/target/product/x86_64/obj_x86/lib/libc++.so
out/target/product/x86_64/obj_x86/lib/libc.so
out/target/product/x86_64/obj_x86/lib/libm.so
out/target/product/x86_64/obj_x86/lib/libdl.so -o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
out/target/product/x86_64/obj_x86/lib/crtend_so.o"
external/drm_gralloc/gralloc_drm_intel.c:631: error: undefined
reference to 'intel_is_genx'
external/drm_gralloc/gralloc_drm_intel.c:630: error: undefined
reference to 'intel_get_genx'
clang.real: error: linker command failed with exit code 1 (use -v to
see invocation)


That's because drm_gralloc use the IS_GEN9 macro
(and other IS_GEN{n} macros) directly.

Since IS_GEN{n} are public APIs, I don't see
the rationale of this change.
Unless you are going to privatize all IS_GEN{n} macros.
(are you?)


2018-09-13 0:03 GMT+08:00 Rodrigo Vivi :
> On Wed, Sep 12, 2018 at 08:50:54AM -0700, Rodrigo Vivi wrote:
>> From: Emil Velikov 
>>
>> They're used internally and never meant to be part of the API.
>> Add the drm_private notation, which should resolve that.
>>
>> v2: (Rodrigo) Add missing include.
>> v3: (Rodrigo) Keep includes grouped per Eric suggestion.
>>
>> Cc: Eric Engestrom 
>> Cc: Lucas De Marchi 
>> Cc: Chris Wilson 
>> Cc: Rodrigo Vivi 
>> Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
>> Signed-off-by: Emil Velikov 
>> Acked-by: Lucas De Marchi 
>> Signed-off-by: Rodrigo Vivi 
>> Reviewed-by: Eric Engestrom 
>
> And pushed...
> thanks for patch, ack and review ;)
>
>> ---
>>  intel/intel_chipset.c | 4 ++--
>>  intel/intel_chipset.h | 5 +++--
>>  2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
>> index d5c33cc5..5aa4a2f2 100644
>> --- a/intel/intel_chipset.c
>> +++ b/intel/intel_chipset.c
>> @@ -44,7 +44,7 @@ static const struct pci_device {
>>   INTEL_SKL_IDS(9),
>>  };
>>
>> -bool intel_is_genx(unsigned int devid, int gen)
>> +drm_private bool intel_is_genx(unsigned int devid, int gen)
>>  {
>>   const struct pci_device *p,
>> *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
>> @@ -66,7 +66,7 @@ bool intel_is_genx(unsigned int devid, int gen)
>>   return false;
>>  }
>>
>> -bool intel_get_genx(unsigned int devid, int *gen)
>> +drm_private bool intel_get_genx(unsigned int devid, int *gen)
>>  {
>>   const struct pci_device *p,
>> *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
>> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
>> index 9b1e64f1..5db207cc 100644
>> --- a/intel/intel_chipset.h
>> +++ b/intel/intel_chipset.h
>> @@ -329,9 +329,10 @@
>>
>>  /* New platforms use kernel pci ids */
>>  #include 
>> +#include 
>>
>> -bool intel_is_genx(unsigned int devid, int gen);
>> -bool intel_get_genx(unsigned int devid, int *gen);
>> +drm_private bool intel_is_genx(unsigned int devid, int gen);
>> +drm_private bool intel_get_genx(unsigned int devid, int *gen);
>>
>>  #define IS_GEN9(devid) intel_is_genx(devid,

Re: [RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android

2018-04-02 Thread Chih-Wei Huang

2018-03-28 23:22 GMT+08:00 Rob Herring :
> On Wed, Mar 28, 2018 at 10:19 AM, Rob Herring  wrote:
>> On Sat, Mar 17, 2018 at 2:33 PM, Stefan Schake  wrote:
>>> Hey John,
>>>
>>> On Fri, Mar 16, 2018 at 10:48 PM, John Stultz  
>>> wrote:
 In trying to integrate the new gralloc_handle.h with the
 drm_hwcomposer, I started seeing the following compilation
 errors:

 In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
 external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize 
 return object of type 'native_handle_t *' (aka 'native_handle *') with an 
 lvalue of type 'struct gralloc_handle_t *'
 return handle;
^~
 1 error generated.
>>
>> Somehow this is not throwing an error for me...
>
> NM. I have it fixed in a subsequent change in my tree...

Hi,
I saw the same error after updated to libdrm master branch.
Could John's fix be merged?
Or maybe Rob has a better fix?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] android: make libdrm*.so available to the vendor partition

2017-12-10 Thread Chih-Wei Huang

It seems the patch is necessary in Android 8.1,
otherwise we got the errors:

bootable/recovery/minui/Android.mk: error: libminui (STATIC_LIBRARIES
android-x86_64) missing libdrm_platform (STATIC_LIBRARIES
android-x86_64)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if
this is intentional, but that may defer real problems until later in
the build.
bootable/recovery/minui/Android.mk: error: libminui (STATIC_LIBRARIES
android-x86) missing libdrm_platform (STATIC_LIBRARIES android-x86)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if
this is intentional, but that may defer real problems until later in
the build.
build/core/main.mk:728: error: exiting from previous errors.

Please rebase to the latest master and re-submit the patch.
In particular, please consider the master already has
a Rob Herring's patch which moved libdrm* to /vendor.



2017-07-26 18:08 GMT+08:00 Jiyong Park :
> libdrm_.so are moved to the vendor partition (/vendor/lib or
> /system/vendor/lib if there is no dedicated vendor partition), since
> they are vendor-specific extension that must not be in the system
> partition which should be generic.
>
> libdrm.so (which is generic) is built/installed twice: once to
> /vendor/lib to satisfy the dependency for the libdrm_.so libs
> and once to /system/lib for platform clients such as the recovery
> executable.
>
> The platform variant of libdrm is named as libdrm_platform.so since
> in Android.mk we can't have two different shared libs having
> same soname. In the near future, this will be fixed by converting these
> Android.mk files to Android.bp and mark the module libdrm as
> 'vendor_available: true'. (See
> https://android-review.googlesource.com/c/368372/ for further detail on
> the property)
>
> Signed-off-by: Jiyong Park 
> ---
>  Android.mk| 39 +++
>  amdgpu/Android.mk |  2 +-
>  etnaviv/Android.mk|  1 +
>  freedreno/Android.mk  |  2 +-
>  intel/Android.mk  |  1 +
>  libkms/Android.mk |  1 +
>  nouveau/Android.mk|  1 +
>  radeon/Android.mk |  1 +
>  tests/modetest/Android.mk |  2 +-
>  tests/proptest/Android.mk |  2 +-
>  tests/util/Android.mk |  2 +-
>  11 files changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/Android.mk b/Android.mk
> index 292be236..a5986b4e 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -21,6 +21,10 @@
>  # IN THE SOFTWARE.
>  #
>
> +# Two identical libs are defined here.
> +# libdrm: for vendors. installed to /vendor/lib. libdrm_ uses this.
> +# libdrm_platform: for platform modules (such as libminui). installed to 
> /system/lib
> +
>  LIBDRM_COMMON_MK := $(call my-dir)/Android.common.mk
>
>  LOCAL_PATH := $(call my-dir)
> @@ -33,7 +37,41 @@ include $(LOCAL_PATH)/Makefile.sources
>
>  #static library for the device (recovery)
>  include $(CLEAR_VARS)
> +
> +LOCAL_MODULE := libdrm_platform
> +
> +LOCAL_SRC_FILES := $(LIBDRM_FILES)
> +LOCAL_EXPORT_C_INCLUDE_DIRS := \
> +   $(LOCAL_PATH) \
> +   $(LOCAL_PATH)/include/drm
> +
> +LOCAL_C_INCLUDES := \
> +   $(LOCAL_PATH)/include/drm
> +
> +include $(LIBDRM_COMMON_MK)
> +include $(BUILD_STATIC_LIBRARY)
> +
> +# Dynamic library for the device
> +include $(CLEAR_VARS)
> +
> +LOCAL_MODULE := libdrm_platform
> +
> +LOCAL_SRC_FILES := $(LIBDRM_FILES)
> +LOCAL_EXPORT_C_INCLUDE_DIRS := \
> +   $(LOCAL_PATH) \
> +   $(LOCAL_PATH)/include/drm
> +
> +LOCAL_C_INCLUDES := \
> +   $(LOCAL_PATH)/include/drm
> +
> +include $(LIBDRM_COMMON_MK)
> +include $(BUILD_SHARED_LIBRARY)
> +
> +# Static library for the device (recovery)
> +include $(CLEAR_VARS)
> +
>  LOCAL_MODULE := libdrm
> +LOCAL_VENDOR_MODULE := true
>
>  LOCAL_SRC_FILES := $(LIBDRM_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := \
> @@ -49,6 +87,7 @@ include $(BUILD_STATIC_LIBRARY)
>  # Shared library for the device
>  include $(CLEAR_VARS)
>  LOCAL_MODULE := libdrm
> +LOCAL_VENDOR_MODULE := true
>
>  LOCAL_SRC_FILES := $(LIBDRM_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := \
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611ba..1df84b3e 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -5,7 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>
>  LOCAL_MODULE := libdrm_amdgpu
> -
> +LOCAL_VENDOR_MODULE := true
>  LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
> diff --git a/etnaviv/Android.mk b/etnaviv/Android.mk
> index 390f9a98..1143eac5 100644
> --- a/etnaviv/Android.mk
> +++ b/etnaviv/Android.mk
> @@ -5,6 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>
>  LOCAL_MODULE := libdrm_etnaviv
> +LOCAL_VENDOR_MODULE := true
>
>  LOCAL_SHARED_LIBRARIES := libdrm
>
> diff --git a/freedreno/Android.mk b/freedreno/Android.mk
> index 2b582aed..c1289145 100644
> --- a/freedreno/Android.mk
> +++ b/freedreno/Android.mk
> @@ -5,7 +5,7 @@ include $(CLEAR_VARS)
>  include

Re: [PATCH hwc] Android: add CleanSpec.mk

2017-11-05 Thread Chih-Wei Huang

2017-11-03 20:35 GMT+08:00 Rob Herring <r...@kernel.org>:
> On Thu, Nov 2, 2017 at 11:45 PM, Chih-Wei Huang <cwhu...@android-x86.org> 
> wrote:
>> The file contains rules that are executed on incremental builds.
>> Since commit 4f7dc9b6 the library was moved to /vendor so
>> the old file must be removed.
>>
>> Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
>> ---
>>  CleanSpec.mk | 1 +
>>  1 file changed, 1 insertion(+)
>>  create mode 100644 CleanSpec.mk
>>
>> diff --git a/CleanSpec.mk b/CleanSpec.mk
>> new file mode 100644
>> index 000..99dcecd
>> --- /dev/null
>> +++ b/CleanSpec.mk
>> @@ -0,0 +1 @@
>> +$(call add-clean-step, rm -rf $(TARGET_OUT)/lib*/hw/hwcomposer.drm.so)
>
> Seems a bit silly to add forever an explicit file to clean for a
> transient problem.

The problem is people usually won't notice
the libraries have been moved to /vendor.
In an incremental build the old files still
exist in /system that may cause issues.

It's necessary unless you have a better idea
to tell people "hey, you need to do a clean build".


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hwc] Android: add CleanSpec.mk

2017-11-02 Thread Chih-Wei Huang

The file contains rules that are executed on incremental builds.
Since commit 4f7dc9b6 the library was moved to /vendor so
the old file must be removed.

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 CleanSpec.mk | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 CleanSpec.mk

diff --git a/CleanSpec.mk b/CleanSpec.mk
new file mode 100644
index 000..99dcecd
--- /dev/null
+++ b/CleanSpec.mk
@@ -0,0 +1 @@
+$(call add-clean-step, rm -rf $(TARGET_OUT)/lib*/hw/hwcomposer.drm.so)
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] Android: update CleanSpec.mk

2017-11-02 Thread Chih-Wei Huang

The libraries are moved to /vendor since commit 011fd913.
Clean all old files for incremental builds.

Fixes: 011fd913 (Android: move libraries to /vendor)

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 CleanSpec.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CleanSpec.mk b/CleanSpec.mk
index 28a11db4..29d3f671 100644
--- a/CleanSpec.mk
+++ b/CleanSpec.mk
@@ -2,3 +2,5 @@ $(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/include/libdrm)
 $(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/include/freedreno)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/obj/SHARED_LIBRARIES/libdrm_*intermediates)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/obj/STATIC_LIBRARIES/libdrm_*intermediates)
+$(call add-clean-step, rm -rf $(TARGET_OUT)/lib*/libdrm[._]*)
+$(call add-clean-step, rm -rf $(TARGET_OUT_ETC)/hwdata/amdgpu.ids)
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH hwc] drm_hwcomposer: provide a common gralloc handle definition

2017-10-24 Thread Chih-Wei Huang

2017-10-25 7:40 GMT+08:00 Rob Herring :
> EGL, gralloc, and HWC must all have a common definition of fd's and int's
> in native_handle_t to share the fd and width, height, format, etc.
> of a dmabuf.
>
> Move the definition into HWC so we aren't dependent on a specific gralloc
> implementation and so we don't have to create an importer just for
> different native_handle_t layouts. This will allow supporting multiple
> gralloc implementations that conform to this layout.
>
> Perhaps we should allow for multiple levels of subclassing by only defining
> the fields we care about here and not validating magic and the size.
>
> Signed-off-by: Rob Herring 
> ---
> I'm not sure if there's a better way, but I can't find a way to remove
> the gralloc dependency. At least for EGL, only the fd is needed as it
> has the ANativeWindow and can get all the info from that.
>
>
>  Android.mk   |  1 -
>  gralloc_drm_handle.h | 85 
> 
>  2 files changed, 85 insertions(+), 1 deletion(-)
>  create mode 100644 gralloc_drm_handle.h
>
> diff --git a/Android.mk b/Android.mk
> index 611fcb75190b..ee5b8bfb44d0 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -47,7 +47,6 @@ LOCAL_SHARED_LIBRARIES := \
>  LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
>
>  LOCAL_C_INCLUDES := \
> -   external/gbm_gralloc \
> system/core/libsync
>
>  LOCAL_SRC_FILES := \
> diff --git a/gralloc_drm_handle.h b/gralloc_drm_handle.h
> new file mode 100644
> index ..aa89e46db619
> --- /dev/null
> +++ b/gralloc_drm_handle.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2010-2011 Chia-I Wu 
> + * Copyright (C) 2010-2011 LunarG Inc.
> + * Copyright (C) 2016 Linaro, Ltd., Rob Herring 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included
> + * in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _GRALLOC_DRM_HANDLE_H_
> +#define _GRALLOC_DRM_HANDLE_H_
> +
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +struct gralloc_drm_handle_t {
> +   native_handle_t base;
> +
> +   /* file descriptors */
> +   int prime_fd;
> +
> +   /* integers */
> +   int magic;
> +
> +   int width;
> +   int height;
> +   int format;
> +   int usage;
> +   int stride; /* the stride in bytes */
> +   uint64_t modifier; /* buffer modifiers */

As a fix [1] I sent to you before,
it's better to force align the 64-bit int to 8.

[1]: 
https://github.com/robherring/gbm_gralloc/commit/d8b95e3ed2f0b38949c9339b6f5c9ffb32ca1089

> +   int data_owner; /* owner of data (for validation) */
> +   union {
> +   void *data; /* private pointer for gralloc */
> +   uint64_t reserved;
> +   } __attribute__((aligned(8)));
> +};
> +#define GRALLOC_HANDLE_MAGIC 0x5f47424d
> +#define GRALLOC_HANDLE_NUM_FDS 1
> +#define GRALLOC_HANDLE_NUM_INTS (
>   \
> +   ((sizeof(struct gralloc_drm_handle_t) - 
> sizeof(native_handle_t))/sizeof(int))   \
> +- GRALLOC_HANDLE_NUM_FDS)
> +
> +static inline struct gralloc_drm_handle_t 
> *gralloc_drm_handle(buffer_handle_t _handle)
> +{
> +   struct gralloc_drm_handle_t *handle =
> +   (struct gralloc_drm_handle_t *) _handle;
> +
> +   if (handle && (handle->base.version != sizeof(handle->base) ||
> +  handle->base.numInts != GRALLOC_HANDLE_NUM_INTS ||
> +  handle->base.numFds != GRALLOC_HANDLE_NUM_FDS ||
> +  handle->magic != GRALLOC_HANDLE_MAGIC))
> +   return NULL;
> +
> +   return handle;
> +}
> +
> +static inline int gralloc_drm_get_prime_fd(buffer_handle_t _handle)
> +{
> +   struct gralloc_drm_handle_t *handle = gralloc_drm_handle(_handle);
> +   return (handle) ? handle->prime_fd : -1;
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +#endif /*

Re: [PATCH] drm_hwcomposer: remove unnecessary external includes

2017-10-24 Thread Chih-Wei Huang

2017-10-25 8:06 GMT+08:00 Rob Herring <r...@kernel.org>:
> Linking to libraries will add necessary include paths, so we don't need to
> list them explicitly.
>
> Still need libsync for sw_sync.h until this dependency is removed.
>
> Signed-off-by: Rob Herring <r...@kernel.org>
> ---
>  Android.mk | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/Android.mk b/Android.mk
> index 109e352f2a0e..8b11e375adde 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -48,11 +48,7 @@ LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
>
>  LOCAL_C_INCLUDES := \
> external/drm_gralloc \
> -   external/libdrm \
> -   external/libdrm/include/drm \
> -   system/core/include/utils \
> -   system/core/libsync \
> -   system/core/libsync/include \
> +   system/core/libsync
>
>  LOCAL_SRC_FILES := \
> autolock.cpp \
> --

Looks good to me
Reviewed-and-tested-by: Chih-Wei Huang <cwhu...@linux.org.tw>

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

2017-09-29 Thread Chih-Wei Huang

2017-09-29 16:44 GMT+08:00 Robert Foss <robert.f...@collabora.com>:
> On Fri, 2017-09-29 at 13:49 +0800, Chih-Wei Huang wrote:
>> 2017-09-29 5:29 GMT+08:00 Rob Herring <r...@kernel.org>:
>> > Perhaps just leave the current state as a separate branch.
>>
>> Did you mean we maintain the branch in our repo?
>> (that's what we do now, but I hope to avoid that)
>>
>> Or fd.o could help to maintain the two branches (HWC1 and HWC2)?
>
> Android later than O will not support HWC1 (as far as I understand it),
> so HWC2 is the way forward.

If all x86 GPUs we want to support
can work with drm_hwcomposer,
I'm happy to switch to HWC2.
However it seems impossible at this moment. :(

> Furthermore I think targeting aosp/master at all time is the right
> thing to do for drm_hwcomposer.
>
> I for one am less than keen on maintaining branch that is incompatible
> with aosp/master upstream.
>
> Ideally we wouldn't maintain a compile time switch either, not on
> principle but because of the development overhead it causes.
> We have very finite resources contributing to drm_hwcomposer.
> If it was cheap& to support old Android versions we should, but I
> don't think it is.

My point is not to support old Android versions,
but to support old(?) GPUs that can't work with drm_hwcomposer.


> I would suggest maintaining a HWC1 fork downstream as the way forward.
> But any input is welcome.



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

2017-09-28 Thread Chih-Wei Huang

2017-09-29 5:29 GMT+08:00 Rob Herring <r...@kernel.org>:
> On Thu, Sep 28, 2017 at 11:43 AM, Chih-Wei Huang
> <cwhu...@android-x86.org> wrote:
>> 2017-09-27 19:58 GMT+08:00 Robert Foss <robert.f...@collabora.com>:
>>> From: Sean Paul <seanp...@chromium.org>
>>>
>>> Since HWC2 doesn't require the use of threads to implement correct
>>> synchronization, remove some of these threads.
>>
>> May I ask to avoid HWC2 only implementation?
>> The main reason is not all GPUs support
>> drm_hwcompser (as discussed in another thread).
>
> Which thread? Is that because they don't support explicit fences? Or
> something else?

The "drm_hwcomposer moving to fd.o" thread.
For example, see
https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html

>> To continue supporting these GPUs we need to
>> keep using HWC1 version of SurfaceFlinger.
>
> I think that is a lot of complexity to keep which will impact future
> changes as well. For example, is keeping it going to make removing
> sw_sync dependency (A non-stable debugfs interface) more difficult?
> drm_hwcomposer is already complex enough IMO with the GL compositing
> that removing some complexity would be a good thing.
>
>> So it's better to keep the code compatible with
>> HWC1. At least make it be a compile-time option.
>>
>> Personally I have a patch to make
>> HWC1 vs HWC2 a compile-time choice
>> of drm_hwcomposer.

FYI, the patch is
https://osdn.net/projects/android-x86/scm/git/external-drm_hwcomposer/commits/7acc332019d211cb2747fd4068cf41aaa62753fb

> Perhaps just leave the current state as a separate branch.

Did you mean we maintain the branch in our repo?
(that's what we do now, but I hope to avoid that)

Or fd.o could help to maintain the two branches (HWC1 and HWC2)?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

2017-09-28 Thread Chih-Wei Huang

2017-09-28 15:08 GMT+08:00 Daniel Vetter <dan...@ffwll.ch>:
> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhu...@android-x86.org> 
> wrote:
>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <dan...@ffwll.ch>:
>>> On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:
>>>> On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:
>>>> > Hey Robert, thank you for the reply.
>>>> >
>>>> > 2017-09-22 23:43 GMT+08:00 Robert Foss <robert.f...@collabora.com>:
>>>> >> Hey Chih-Wei,
>>>> >> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>>>> >
>>>> >> The android-ia project has supported using drm_hwcomposer and an
>>>> >> alternative hwcomposer, so it would think there should be no issues.
>>>> >
>>>> > By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
>>>> > Among these only virgl works with the current drm_hwcomposer.
>>>> > All the others don't have a ready atomic mode-setting API to use it.
>>>> > That's the problem which should be addressed I meant.
>>>>
>>>> Most if not all of those drivers support the atomic updates API in
>>>> mainline (and have for a few releases by now).
>>>
>>> amdgpu does not (but will once DC has landed, at least when you enable
>>> DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
>>> nv50+.
>>
>> Thank you for the clarification.
>>
>> I have made test with kernel 4.13 +
>> gbm_grallc + drm_hwcomposer + mesa 17.1
>> on Android-x86 7.1.
>> Except virgl all others just failed as expected.
>>
>> i915 (i965) was tested in Intel Broxton.
>> It's the best result. SurfaceFlinger runs and
>> bootanimation is shown. However, after boot
>> complete it only shown systemui + navbar with
>> black background. No app icons or mouse cursor
>> in the desktop. I guess the composition of 3+
>> layers has some problems.
>
> Could be a bug in either drm_hwcomposer making assumptions that don't
> hold, or i915 for implementing stuff wrongly. Would need someone to
> debug. Given that we have products shipping on bxt using atomic (CrOS)
> I'm leaining towards drm_hwcomposer making bad assumptions.
>
>> nouveau is tested on GTX 1060.
>> drm_hwcomposer init failed so SurfaceFlinger crashed.
>> Seems the driver is not atomic:
>>
>> 09-28 13:21:39.719  3096  3096 E hwc-drm-resources: Failed to set atomic cap 
>> -1
>>
>> which comes from this line of drmresources.cpp:
>>
>>  ret = drmSetClientCap(fd(), DRM_CLIENT_CAP_ATOMIC, 1);
>
> nouveau.atomic=1 or you won't get the atomic ioctl. Not sure why it's
> not enabled by default for nv50+. If it works, perhaps submit a patch
> to change the default?

Ah! Thank you for the hint.
By setting atomic=1 for nouveau it works.
But similar to i965 case, after boot complete
it only shows systemui + navbar + black background
Besides, it's quite unstable.
I tried to do something (move mouse, press some keys)
then system_server crashes.

Log: https://drive.google.com/open?id=0B3GICgSwrKXcVTJfblY1NGllUXM

>> vmwgfx also has issues on drm_hwcomposer
>> initialization. SurfaceFlinger didn't crashes but
>> no bootanimation. It seems just blocked.
>>
>> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set active
>> config d=1 ret=-19
>> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set initial
>> config for d=1 ret=-19
>> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to initialize 
>> display 1
>> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to enumerate
>> displays: Unknown error -19
>
> Sounds like the vmwgfx implementation of atomic is a big buggy. Bug
> filing for this would be good I think.

Will do. Thank you!


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

2017-09-28 Thread Chih-Wei Huang

2017-09-27 19:58 GMT+08:00 Robert Foss :
> From: Sean Paul 
>
> Since HWC2 doesn't require the use of threads to implement correct
> synchronization, remove some of these threads.

May I ask to avoid HWC2 only implementation?
The main reason is not all GPUs support
drm_hwcompser (as discussed in another thread).
To continue supporting these GPUs we need to
keep using HWC1 version of SurfaceFlinger.
So it's better to keep the code compatible with
HWC1. At least make it be a compile-time option.

Personally I have a patch to make
HWC1 vs HWC2 a compile-time choice
of drm_hwcomposer.
I can submit it if it's acceptable.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

2017-09-28 Thread Chih-Wei Huang

2017-09-26 13:26 GMT+08:00 Daniel Vetter <dan...@ffwll.ch>:
> On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:
>> On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:
>> > Hey Robert, thank you for the reply.
>> >
>> > 2017-09-22 23:43 GMT+08:00 Robert Foss <robert.f...@collabora.com>:
>> >> Hey Chih-Wei,
>> >> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>> >
>> >> The android-ia project has supported using drm_hwcomposer and an
>> >> alternative hwcomposer, so it would think there should be no issues.
>> >
>> > By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
>> > Among these only virgl works with the current drm_hwcomposer.
>> > All the others don't have a ready atomic mode-setting API to use it.
>> > That's the problem which should be addressed I meant.
>>
>> Most if not all of those drivers support the atomic updates API in
>> mainline (and have for a few releases by now).
>
> amdgpu does not (but will once DC has landed, at least when you enable
> DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
> nv50+.

Thank you for the clarification.

I have made test with kernel 4.13 +
gbm_grallc + drm_hwcomposer + mesa 17.1
on Android-x86 7.1.
Except virgl all others just failed as expected.

i915 (i965) was tested in Intel Broxton.
It's the best result. SurfaceFlinger runs and
bootanimation is shown. However, after boot
complete it only shown systemui + navbar with
black background. No app icons or mouse cursor
in the desktop. I guess the composition of 3+
layers has some problems.

nouveau is tested on GTX 1060.
drm_hwcomposer init failed so SurfaceFlinger crashed.
Seems the driver is not atomic:

09-28 13:21:39.719  3096  3096 E hwc-drm-resources: Failed to set atomic cap -1

which comes from this line of drmresources.cpp:

 ret = drmSetClientCap(fd(), DRM_CLIENT_CAP_ATOMIC, 1);

vmwgfx also has issues on drm_hwcomposer
initialization. SurfaceFlinger didn't crashes but
no bootanimation. It seems just blocked.

09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set active
config d=1 ret=-19
09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set initial
config for d=1 ret=-19
09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to initialize display 1
09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to enumerate
displays: Unknown error -19

Full log:
https://drive.google.com/open?id=0B3GICgSwrKXcci1lbDdaSlJBRE0

Shall I create bugs in the Bugzilla?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

2017-09-24 Thread Chih-Wei Huang

Hey Robert, thank you for the reply.

2017-09-22 23:43 GMT+08:00 Robert Foss <robert.f...@collabora.com>:
> Hey Chih-Wei,
> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>> Great news!
>> Thanks a lot to make it happen.
>>
>> I hope I am wrong.
>> From my understanding most x86 GPUs still
>> cannot work with drm_hwcomposer since
>> they lack of atomic mode-setting API support
>> required by drm_hwcomposer.
>> Hope this could be addressed soon since
>> drm_hwcomposer becomes a standard project of fd.o.
>
> I haven't personally run drm_hwc ontop of any x86 hardware, but there
> are people who do it.

Indeed we (android-x86 project) are the people who try to use it
but without lucky. Rob Herring also uses (a slightly modified)
drm_hwcomposer with his aosp virgl porting.
Except these I don't know any others use it on x86 hardware.
Though drm_hwcomposer is developed from Chromium
but I've heard Chrome actually use an alternative proprietary
hwcomposer in their Android Runtime for Chrome (ARC).

> The android-ia project has supported using drm_hwcomposer and an
> alternative hwcomposer, so it would think there should be no issues.

By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
Among these only virgl works with the current drm_hwcomposer.
All the others don't have a ready atomic mode-setting API to use it.
That's the problem which should be addressed I meant.

The android-ia doesn't support using fdo's drm_hwcomposer I think.
They use an alternative hwcomposer [1] as you said.
It looks very different than drm_hwcomposer though
both rely on the similar (or same?) atomic API.
Android-ia's kernel has also been patched to work with it.
The vanilla kernel (at least LTS 4.9) can't work with [1]
or drm_hwcomposer.
Actually [1] only works with i915(i965) but we want
a more generic hwcomposer like drm_hwcomposer.

Please correct me if I am wrong.

[1]: git://github.com/01org/IA-Hardware-Composer

>> How about the gralloc?
>> There are also several implementations
>> scattered somewhere.
>> I think it's also important to standardize it to fd.o
>> and make it work with fd.o's drm_hwcomposer.
>
> Gralloc is a different story, and the right person to ask about it is
> not me, but maybe Rob Herring.

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

2017-09-21 Thread Chih-Wei Huang

Great news!
Thanks a lot to make it happen.

I hope I am wrong.
From my understanding most x86 GPUs still
cannot work with drm_hwcomposer since
they lack of atomic mode-setting API support
required by drm_hwcomposer.
Hope this could be addressed soon since
drm_hwcomposer becomes a standard project of fd.o.

How about the gralloc?
There are also several implementations
scattered somewhere.
I think it's also important to standardize it to fd.o
and make it work with fd.o's drm_hwcomposer.

2017-09-22 7:52 GMT+08:00 Robert Foss :
> Hey,
>
> After talking to Liviu Dudau at LPC and Sean Paul & Kaveh Nasri at XDC
> it seems that we all could benefit from community maintainership of
> drm_hwcomposer.
>
> I'm happy to announce that drm_hwcomposer now officially is hosted on
> freedesktop.org:
> https://cgit.freedesktop.org/drm_hwcomposer/
>
> The chromiumos wiki entries have also been moved to f.do:
> https://www.x.org/wiki/Projects/drm_hwcomposer/
> https://www.x.org/wiki/Projects/drm_hwcomposer/Overview/

Seems I can't connect to it now...

> With this I'm hoping we'll be able to merge the changes done by intel
> in [1], but more importantly remove the need for an alternative
> implementation.
>
> Regarding contributions, they are accepted on the dri-devel list, using
> the patch prefix "hwc".
>
> Currently Sean Paul, Zach Reizner, Rob Clark, Rob Herring and Robert
> Foss have commit access. This is just the initial set, any contributor
> with a few commits under their belt is welcome to request commit
> access.
>
> A fd.o account is needed for to grant commit rights, one can be
> requested here:
> https://www.freedesktop.org/wiki/AccountRequests/
>
> I would also like to thank Sean Paul for taking the initiative and
> helping out with the move.
>
>
> [1] https://github.com/android-ia/external-drm_hwcomposer/

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 2/2] android: amdgpu: fix build break

2017-08-23 Thread Chih-Wei Huang

2017-08-21 20:18 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>:
> On 17 August 2017 at 04:31, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>> Ping. Is there any other concern to merge the fix?
>>
> My earlier suggestion was to use the respective Android build system
> variable, instead of hardcoding the actual path.

Oh. Sorry I didn't really get your point.
But IMO that's not possible.
TARGET_OUT_ETC is not a valid path in the target device.
Unless you want to see a more complex rule like
/($notdir $(TARGET_OUT_ETC))/hwdata/amdgpu.ids ...

> Merged v2 of the series, although I reserve my right of "I told you
> so" as this comes to bite :-)


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 2/2] android: amdgpu: fix build break

2017-08-16 Thread Chih-Wei Huang

Ping. Is there any other concern to merge the fix?

2017-07-27 16:20 GMT+08:00 Chih-Wei Huang <cwhu...@android-x86.org>:
> Define two macros to avoid building errors.
>
> Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)
>
> Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
> ---
>  amdgpu/Android.mk | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611b..88d3765 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -10,5 +10,11 @@ LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>
> +LOCAL_CFLAGS := \
> +   -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
> '^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
> +
> +LOCAL_REQUIRED_MODULES := amdgpu.ids
> +
>  include $(LIBDRM_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-27 Thread Chih-Wei Huang

> 2017-07-26 17:27 GMT+02:00 Emil Velikov <emil.l.veli...@gmail.com>:
>> On 25 July 2017 at 08:28, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>>> Hi Mauro,
>>> Please note AMDGPU_ASIC_ID_TABLE
>>> should be a path in the target device (i.e., Android).
>>> So using $(LIBDRM_TOP) is incorrect.
>>>
>>> Actually I've sent a fix for it about one week ago.
>>>
>> Did you sent v2 of the patch? I cannot see any in my inbox.

OK. I re-submitted v2 patch to replace
/etc with /system/etc.

2017-07-27 1:36 GMT+08:00 Mauro Rossi <issor.or...@gmail.com>:
> This one has conceptual error and is to be dropped.
>
> The ones submitted by Chih-Wei are here:
>
> https://github.com/maurossi/drm/commits/2.4.82_android-x86
>
> where in the (v2) of the second I just replaced /etc path with 
> $(TARGET_OUT_ETC)

No. TARGET_OUT_ETC is still the host path.
(which is out/target/product/$target/system/etc )

> Chih-Wei if you like the (v2) could you please resubmit to dri-devel
> using [PATCH libdrm] in the title?

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm v2 2/2] android: amdgpu: fix build break

2017-07-27 Thread Chih-Wei Huang

Define two macros to avoid building errors.

Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 amdgpu/Android.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index bf0611b..88d3765 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -10,5 +10,11 @@ LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
 
+LOCAL_CFLAGS := \
+   -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
+   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
'^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
+
+LOCAL_REQUIRED_MODULES := amdgpu.ids
+
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm v2 1/2] android: add rules to build amdgpu.ids

2017-07-27 Thread Chih-Wei Huang

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 data/Android.mk | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 data/Android.mk

diff --git a/data/Android.mk b/data/Android.mk
new file mode 100644
index 000..3c1fd7c
--- /dev/null
+++ b/data/Android.mk
@@ -0,0 +1,9 @@
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+LOCAL_MODULE := amdgpu.ids
+LOCAL_MODULE_TAGS := optional
+LOCAL_MODULE_CLASS := ETC
+LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/hwdata
+LOCAL_SRC_FILES := $(LOCAL_MODULE)
+include $(BUILD_PREBUILT)
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-25 Thread Chih-Wei Huang

2017-07-22 17:01 GMT+08:00 Mauro Rossi :
> Changes in Android.mk makefile to avoid building errors in mesa
> due to missing LOCAL_CFLAGS variable definition for
> AMDGPU_ASIC_ID_TABLE and ASIC_ID_TABLE_NUM_ENTRIES
>
> Fixes: 7e6bf88cac ("amdgpu: move asic id table to a separate file")
> ---
>  amdgpu/Android.mk | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611ba..270680bb 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -10,5 +10,13 @@ LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> +   $(LIBDRM_TOP)/data/amdgpu.ids)
> +
> +LOCAL_CFLAGS += -DAMDGPU_ASIC_ID_TABLE=\"$(LIBDRM_TOP)/data/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)

Hi Mauro,
Please note AMDGPU_ASIC_ID_TABLE
should be a path in the target device (i.e., Android).
So using $(LIBDRM_TOP) is incorrect.

Actually I've sent a fix for it about one week ago.

> +$(intermediates)/amdgpu_asic_id.o: $(LIBDRM_TOP)/data/amdgpu.ids
> +
>  include $(LIBDRM_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] android: add rules to build amdgpu.ids

2017-07-19 Thread Chih-Wei Huang

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 data/Android.mk | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 data/Android.mk

diff --git a/data/Android.mk b/data/Android.mk
new file mode 100644
index 000..3c1fd7c
--- /dev/null
+++ b/data/Android.mk
@@ -0,0 +1,9 @@
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+LOCAL_MODULE := amdgpu.ids
+LOCAL_MODULE_TAGS := optional
+LOCAL_MODULE_CLASS := ETC
+LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/hwdata
+LOCAL_SRC_FILES := $(LOCAL_MODULE)
+include $(BUILD_PREBUILT)
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] android: amdgpu: fix build break

2017-07-19 Thread Chih-Wei Huang

Define two macros to avoid building errors.

Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)

Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw>
---
 amdgpu/Android.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index bf0611b..955bd53 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -10,5 +10,11 @@ LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
 
+LOCAL_CFLAGS := \
+   -DAMDGPU_ASIC_ID_TABLE=\"/etc/hwdata/amdgpu.ids\" \
+   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
'^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
+
+LOCAL_REQUIRED_MODULES := amdgpu.ids
+
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

2017-07-19 Thread Chih-Wei Huang

Sorry for reply late.

2017-07-05 19:05 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>:
> On 5 July 2017 at 11:44, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>>
>> Yep. The first problem to prepare the patch is,
>> where to install amdgpu.ids on Android?
>> Is /system/etc/amdgpu.ids OK?
>>
> Personally I'd stick it alongside the pci.ids/usb.ids, but it's up-to
> you really.

Thanks!
There files are usually in /usr/share/hwdata/
but Android has no such a directory.
So I'm going to use /etc/hwdata/.

> The library does not care about the filename/path - it's passed as a define.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

2017-07-05 Thread Chih-Wei Huang

2017-07-05 17:35 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>:
> On 4 July 2017 at 07:40, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>>
>> Unfortunately this patch breaks Android build
>> since the two macros are not defined.
>>
>> Anyone is working on a fix?
>> If not, I'll try to provide one.
>>
> Please send a patch. I doubt many of the AMD devs have an Android setup.
> Do ensure that the amdgpu.ids file is installed and accessible.

Yep. The first problem to prepare the patch is,
where to install amdgpu.ids on Android?
Is /system/etc/amdgpu.ids OK?

> JFYI: a similar work is coming on the radeon side, so keep an eye open.




-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] amdgpu: move asic id table to a separate file

2017-07-04 Thread Chih-Wei Huang

2017-06-12 17:50 GMT+08:00 Michel Dänzer :
> From: Xiaojie Yuan 
>
> v2: fix an off by one error and leading white spaces
> v3: use thread safe strtok_r(); initialize len before calling getline();
> change printf() to drmMsg(); add initial amdgpu.ids
> v4: integrate some recent internal changes, including format changes
> v5: fix line number for empty/commented lines; realloc to save memory;
> indentation changes
> v6: remove a line error
> v7: [Michel Dänzer]
> * Move amdgpu.ids to new data directory
> * Remove placeholder entries from amdgpu.ids
> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
>   [Emil Velikov]
> * Use isblank() instead of open-coding it [Emil Velikov]
> * Don't leak asic_id_table memory if realloc fails [Emil Velikov]
> * Check and bump table_max_size at the beginning of the while loop [Emil
>   Velikov]
> * Initialize table_max_size to the number of entries in data/amdgpu.ids
>
> Reviewed-by: Junwei Zhang 
> Signed-off-by: Samuel Li 
> Signed-off-by: Michel Dänzer 
> ---
>  Makefile.am  |   1 +
>  amdgpu/Makefile.am   |   6 ++
>  amdgpu/Makefile.sources  |   2 +-
>  amdgpu/amdgpu_asic_id.c  | 219 
> +++
>  amdgpu/amdgpu_asic_id.h  | 165 ---
>  amdgpu/amdgpu_device.c   |  28 --
>  amdgpu/amdgpu_internal.h |  10 +++
>  configure.ac |   4 +
>  data/Makefile.am |  23 +
>  data/amdgpu.ids  | 159 ++
>  10 files changed, 444 insertions(+), 173 deletions(-)
>  create mode 100644 amdgpu/amdgpu_asic_id.c
>  delete mode 100644 amdgpu/amdgpu_asic_id.h
>  create mode 100644 data/Makefile.am
>  create mode 100644 data/amdgpu.ids
>
> diff --git a/Makefile.am b/Makefile.am
> index dfb8fcdb..7b86214e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -109,6 +109,7 @@ SUBDIRS = \
> $(TEGRA_SUBDIR) \
> $(VC4_SUBDIR) \
> $(ETNAVIV_SUBDIR) \
> +   data \
> tests \
> $(MAN_SUBDIR)
>
> diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
> index cf7bc1ba..3444883f 100644
> --- a/amdgpu/Makefile.am
> +++ b/amdgpu/Makefile.am
> @@ -30,6 +30,12 @@ AM_CFLAGS = \
> $(PTHREADSTUBS_CFLAGS) \
> -I$(top_srcdir)/include/drm
>
> +libdrmdatadir = @libdrmdatadir@
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> +   $(top_srcdir)/data/amdgpu.ids)
> +AM_CPPFLAGS = -DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)

Unfortunately this patch breaks Android build
since the two macros are not defined.

Anyone is working on a fix?
If not, I'll try to provide one.

>  libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
>  libdrm_amdgpu_ladir = $(libdir)
>  libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
> index 487b9e0a..bc3abaa6 100644
> --- a/amdgpu/Makefile.sources
> +++ b/amdgpu/Makefile.sources
> @@ -1,5 +1,5 @@
>  LIBDRM_AMDGPU_FILES := \
> -   amdgpu_asic_id.h \
> +   amdgpu_asic_id.c \
> amdgpu_bo.c \
> amdgpu_cs.c \
> amdgpu_device.c \
> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
> new file mode 100644
> index ..3a88896b
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright © 2017 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xf86drm.h"
> +#include "amdgpu_drm.h"
> +#include

Re: [PATCH libdrm] xf86drm: fix compile error for declare i in for loop

2017-05-17 Thread Chih-Wei Huang

2017-05-18 0:10 GMT+08:00 Emil Velikov :
> On 17 May 2017 at 14:58, Yu, Qiang  wrote:
>> Hi Emil,
>>
>> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure 
>> pass but
>> fail when compile.
>>
>> I think my gcc support c99 but needs adding "-std=c99" to enable it, and the 
>> configure
>> script add it into CC variable. When just use "make", it's OK, but my build 
>> script uses
>> "make CC=gcc".
>>
>> If you think current state is OK, I can change my build script for that.
>>
> Overrides shouldn't be used normally. If needed, one has to be very
> careful what they set them to.
>
> So the question is: why do you set CC - is there something broken on our end?
> Add "-std=c99" is fine, but I'd suggest dropping the override all together.

Indeed it also causes building error on Android
before and include 6.0.
Adding "-std=c99" will result in more strange errors
that I can't understand.
So I have to make a similar change to avoid it.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] intel: fix a conversion format mismatch

2017-03-08 Thread Chih-Wei Huang

To avoid the warning:

external/libdrm/intel/intel_bufmgr.c:362:20: warning: more '%' conversions than 
data arguments [-Wformat]
fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n");
 ~^

Change-Id: I6c1b0a9e3004aacde0d64662de1144cadff30132
---
 intel/intel_bufmgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 42f5f62..5bad93f 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -359,7 +359,7 @@ static size_t
 drm_intel_probe_agp_aperture_size(int fd)
 {
/* Nothing seems to rely on this value on Android anyway... */
-   fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n");
+   fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n", 
__func__);
return 64 * 1024 * 1024;
 }
 #endif
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs

2016-03-24 Thread Chih-Wei Huang

2016-02-15 10:34 GMT+08:00 Saket Sinha :
>
> It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
> virtualized support for 3D/OpenGL hardware acceleration in VMs,
> allowing using the GPU of the host in VMs.
>
> As per my understanding the following components are needed -
>
> - Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D
> acceleration (needed in the VM).
> - Qemu 2.5  includes the VirtIO-GPU 3D mode support.
> - Gallium3D VirGL driver is included in Mesa git (needed in the VM,
> supports up to OpenGL 3.3 atm).
> - On the host *any* OpenGL driver (for the host GPU obviously), no
> special requirements there.
>
> In order to do test this, if I can be guided as to what are the right
> applications to test the entire Graphic stack on a QEMU-KVM Virtual
> machine, I shall be grateful.

If you are interested to test Android on QEMU
with 3D hardware acceleration (via virgl, of course),
here is an ISO you can test:

http://www.fosshub.com/Android-x86.html/android-x86-6.0-20160318.iso

The command to run QEMU

qemu-kvm -smp 2 -m 2048 \
-device virtio-gpu-pci,virgl -display gtk,gl=on \
-d guest_errors \
-serial mon:stdio \
-cdrom android-x86-6.0-20160318.iso


It's built with kernel 4.4.4 and Mesa 11.2.0-rc3.
If you'd like to build the ISO yourself, please read
https://sourceforge.net/p/android-x86/wiki/Downloading%20and%20Building/

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

Atomic mode-setting drivers

2016-03-07 Thread Chih-Wei Huang

2016-03-05 0:32 GMT+08:00 Daniel Vetter :
> Adding relevant mailing lists and people. Please don't send private
> mails to maintainers ;-)

Thank you for the reply and pointing it.

> On Fri, Mar 4, 2016 at 1:47 PM, Chih-Wei Huang  
> wrote:
>> Hi Daniel,
>> This is the Android-x86 project.
>> I'm looking for info about atomic mode-setting drivers
>> and then found your presentation at
>> http://www.x.org/wiki/Events/XDC2015/Program/xdc-2015.pdf
>>
>> Especially page 16 talks about the Android support,
>> exactly what I want.
>>
>> It said "no one has an open-source atomic hwc".
>> Actually there is one in the AOSP 6.0 release:
>>
>> https://android.googlesource.com/platform/external/drm_hwcomposer
>>
>> It's developed by the Chromium team.
>> An update repo is here:
>> https://chromium.googlesource.com/chromiumos/drm_hwcomposer
>
> Yup, my presentation is already outdated - the latest one for LCA2016
> mentions that hwc exists.

Thanks! Do you have a link for it?

>> Contributing instructions are here:
>> https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer
>>
>> We are trying to enable the drm_hwcomposer for Android-x86.
>> However, it requires atomic mode-setting drivers
>> which seems are not ready in the vanilla kernel 4.4,
>> the kernel we are using now.
>>
>> Unfortunately none of us is an expert of kernel drm drivres.
>> Could you give me a brief status of the
>> current atomic mode-setting drivers in vanilla kernel?
>> What are still missing? fences? deadlock?
>> More important, how much effort do we need
>> to make them work with AOSP's drm_hwcomposer?
>
> There's a pile of drivers, but for classic x86 desktop only i915.ko,
> and that is still not yet enabled by default. i915.nuclear_pageflip=1
> will give you experimental atomic support but not sure whether that's
> good enough for hwcomposer.

Yes. I've tried i915.nuclear_pageflip=1
(before sent you the email)
The atomic call pass, but I got further errors:

02-25 17:37:28.320  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.320  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.323  1641  1641 E hwc-drm-resources: Could not find a
suitable encoder/crtc for display 3
02-25 17:37:28.323  1641  1641 E hwc-drm-resources: Failed
CreateDisplayPipe 47 with -19
02-25 17:37:28.323  1641  1641 E hwcomposer-drm: Can't initialize Drm object -19

Still black screen.

The other x86 drivers I've tried are radeon and vmwgfx.
Both seems don't support atomic mode-setting yet.

The only x86 GPU works with drm_hwcomposer
is virgl (with patches by Rob Herring).

> Fences are being worked on in upstream kernel, but nothing to show
> yet.. Otherwise I don't know what's all needed to make it, I haven't
> had a chance to play around with it yet.
>
>> More discussion about it can be found in
>> our devel group:
>> https://groups.google.com/d/msg/android-x86-devel/RErWaXk3b7g/g_OSPGf4AwAJ
>
> Please include that mailing list too, to make sure everyone is on board.

Included. Thanks!

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[PATCH] android: add virgl to be a valid driver

2016-02-26 Thread Chih-Wei Huang

To avoid the warning:

external/libdrm/libkms/Android.mk:17: invalid GPU drivers: virgl

Signed-off-by: Chih-Wei Huang 
---
 libkms/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libkms/Android.mk b/libkms/Android.mk
index 4f5e3d2..a406782 100644
--- a/libkms/Android.mk
+++ b/libkms/Android.mk
@@ -3,12 +3,14 @@ DRM_GPU_DRIVERS := $(strip $(filter-out swrast, 
$(BOARD_GPU_DRIVERS)))
 intel_drivers := i915 i965 i915g ilo
 radeon_drivers := r300g r600g radeonsi
 nouveau_drivers := nouveau
+virgl_drivers := virgl
 vmwgfx_drivers := vmwgfx

 valid_drivers := \
$(intel_drivers) \
$(radeon_drivers) \
$(nouveau_drivers) \
+   $(virgl_drivers) \
$(vmwgfx_drivers)

 # warn about invalid drivers
-- 
1.9.1

DRM support in Android

2016-01-15 Thread Chih-Wei Huang

2016-01-09 16:37 GMT+08:00 vijay kumar :
> Thanks Greg .You Helped me a lot.
>
> On Thu, Jan 7, 2016 at 10:52 PM, Greg Hackmann  
> wrote:
>>
>> On Tue, Jan 5, 2016 at 12:06 AM, vijay kumar  wrote:
>>>
>>> Hii all,
>>>   I want to know some information regarding DRI and DRM
>>> support in android.Does Android uses DRI drivers in MESA for Direct
>>> rendering.
>>
>> The vendor needs to supply an EGL implementation at a well-known path
>> (https://android.googlesource.com/platform/frameworks/native/+/android-6.0.1_r5/opengl/libs/EGL/Loader.cpp#41).
>> This can be Mesa or a proprietary library.

Android-x86 is the first open source project
that brought Mesa/DRM to the Android platform.
Refer to:

http://sourceforge.net/p/android-x86/external_libdrm/
http://sourceforge.net/p/android-x86/external_mesa/
http://sourceforge.net/p/android-x86/external_drm_gralloc/ (Drm based
gralloc HAL)

It's glad to see drm_gralloc is now a part of
AOSP marshmallow release.
Google Pixel C is probably the first (and only?) one
android product that uses it.

We have a devel group working on that.
If you are interesting, I can invite you to join.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[PATCH libdrm] intel: add the missing header

2015-12-01 Thread Chih-Wei Huang

Any concern to merge such a simple fix??

2015-10-30 11:49 GMT+08:00 Chih-Wei Huang :
> It defines the prototype of ffs that fixes the building error
> on Android 6.0 64-bit image.
>
> Signed-off-by: Chih-Wei Huang 
> ---
>  intel/intel_bufmgr_fake.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/intel/intel_bufmgr_fake.c b/intel/intel_bufmgr_fake.c
> index 551e05d..7f4c7b9 100644
> --- a/intel/intel_bufmgr_fake.c
> +++ b/intel/intel_bufmgr_fake.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "intel_bufmgr.h"
> --
> 1.9.1
>



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[PATCH libdrm] intel: add the missing header

2015-10-30 Thread Chih-Wei Huang

It defines the prototype of ffs that fixes the building error
on Android 6.0 64-bit image.

Signed-off-by: Chih-Wei Huang 
---
 intel/intel_bufmgr_fake.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/intel/intel_bufmgr_fake.c b/intel/intel_bufmgr_fake.c
index 551e05d..7f4c7b9 100644
--- a/intel/intel_bufmgr_fake.c
+++ b/intel/intel_bufmgr_fake.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "intel_bufmgr.h"
-- 
1.9.1

[PATCH libdrm] Add missing includes

2015-04-27 Thread Chih-Wei Huang

2015-04-24 0:56 GMT+08:00 Emil Velikov :
> On 22/04/15 16:19, Greg Hackmann wrote:
>> On Tue, Apr 21, 2015 at 11:31 AM, Emil Velikov  
>> wrote:
>>>
>>> I'm not sure why I haven't hit this while building with Android-x86's
>>> bionic, although it's the right thing to do.
>>
>> Maybe a difference in bionic versions?  I know the bionic team made
>> some recent (post-5.1) changes that unintentionally exposed a handful
>> of other missing #includes in our tree.
>>
> Could be. I've never really bothered checking the bionic (both
> downstream patches and version) that Android-x86 uses.

Each Android-x86 branch is based on the respective
AOSP stable release.
That means bionic of kitkat-x86 is based on
ASOSP kitkat-mr2.2, while lollipop-x86 is based on
the lollipop-mr1 release.
It may be different than the AOSP master branch.

[PATCH] android: remove unnecessary TARGET_OUT_HEADERS variable

2015-03-31 Thread Chih-Wei Huang

Signed-off-by: Chih-Wei Huang 
---
 tests/modetest/Android.mk | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index aee3564..0fdfe68 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -7,8 +7,6 @@ LOCAL_SRC_FILES := $(MODETEST_FILES)

 LOCAL_MODULE := modetest

-LOCAL_C_INCLUDES += $(TARGET_OUT_HEADERS)/libdrm
-
 LOCAL_SHARED_LIBRARIES := libdrm

 include $(BUILD_EXECUTABLE)
-- 
1.9.3

[PATCH libdrm 0/5] Yet another round of Android build cleanups

2015-03-20 Thread Chih-Wei Huang

Is there any gating item to prevent
these patches (5+2) from being merged?

2015-03-19 10:56 GMT+08:00 Chih-Wei Huang :
> 2015-03-19 10:06 GMT+08:00 Emil Velikov :
>> On 18/03/15 16:38, Chih-Wei Huang wrote:
>>> 2015-03-18 9:37 GMT+08:00 Emil Velikov :
>>>> > On 18 March 2015 at 01:19, Chih-Wei Huang  
>>>> > wrote:
>>>>> >>
>>>>> >> I would suggest to remove all the use of LIBDRM_TOP.
>>>>> >> Do you want me to submit a patch?
>>>> > Hmm I'm not sure that things will work correctly if we directly
>>>> > substitute LIBDRM_TOP with LOCAL_PATH within the following.
>>>> >
>>>> > mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))
>>> Sure. It works.
>>> But I prefer to simplify it by android build system
>>> built-in functions. See the attached 0001-* patch.
>>>
>>> 0002-* removes LIBDRM_TOP entirely.
>>>
>> I realise that most people aren't too exited about Android, but for the
>> future please try to use git send-email when sending patches to
>> dri-devel or mesa-dev. I've included them below for posterity.
>>
>> Patches look good imho. Just one question - when was the
>> all-makefiles-under macro introduced ? I haven't seen it used too often.
>
> It's introduced since very early day of android.
> (git blame shows it's in commit 88b60799)
>
> Personally I use it often.



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[PATCH libdrm 0/5] Yet another round of Android build cleanups

2015-03-19 Thread Chih-Wei Huang

2015-03-19 10:06 GMT+08:00 Emil Velikov :
> On 18/03/15 16:38, Chih-Wei Huang wrote:
>> 2015-03-18 9:37 GMT+08:00 Emil Velikov :
>>> > On 18 March 2015 at 01:19, Chih-Wei Huang  
>>> > wrote:
>>>> >>
>>>> >> I would suggest to remove all the use of LIBDRM_TOP.
>>>> >> Do you want me to submit a patch?
>>> > Hmm I'm not sure that things will work correctly if we directly
>>> > substitute LIBDRM_TOP with LOCAL_PATH within the following.
>>> >
>>> > mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))
>> Sure. It works.
>> But I prefer to simplify it by android build system
>> built-in functions. See the attached 0001-* patch.
>>
>> 0002-* removes LIBDRM_TOP entirely.
>>
> I realise that most people aren't too exited about Android, but for the
> future please try to use git send-email when sending patches to
> dri-devel or mesa-dev. I've included them below for posterity.
>
> Patches look good imho. Just one question - when was the
> all-makefiles-under macro introduced ? I haven't seen it used too often.

It's introduced since very early day of android.
(git blame shows it's in commit 88b60799)

Personally I use it often.

[PATCH libdrm 0/5] Yet another round of Android build cleanups

2015-03-19 Thread Chih-Wei Huang

2015-03-18 9:37 GMT+08:00 Emil Velikov :
> On 18 March 2015 at 01:19, Chih-Wei Huang  wrote:
>>
>> I would suggest to remove all the use of LIBDRM_TOP.
>> Do you want me to submit a patch?
> Hmm I'm not sure that things will work correctly if we directly
> substitute LIBDRM_TOP with LOCAL_PATH within the following.
>
> mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))

Sure. It works.
But I prefer to simplify it by android build system
built-in functions. See the attached 0001-* patch.

0002-* removes LIBDRM_TOP entirely.

> Can you send a patch over ?

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
-- next part --
A non-text attachment was scrubbed...
Name: 0001-android-simplify-the-including-rule-of-subdirs.patch
Type: text/x-patch
Size: 1093 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150319/c6f1fe6d/attachment-0002.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-android-get-rid-of-LIBDRM_TOP.patch
Type: text/x-patch
Size: 875 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150319/c6f1fe6d/attachment-0003.bin>

[PATCH libdrm 3/5] android: remove ${srcdir} from the includes

2015-03-18 Thread Chih-Wei Huang

2015å¹´3æ18æ¥ ä¸å7:30 æ¼ "Emil Velikov"  
å¯«éï¼
>
> Already implicitly handled by the compiler.

Actually it's not handled by the compiler, but by the Android build system.
It automatically adds  $(LOCAL_PATH), $(intermediate), ... to the include
paths.

> Signed-off-by: Emil Velikov 
> ---
>  freedreno/Android.mk | 3 ---
>  intel/Android.mk | 1 -
>  nouveau/Android.mk   | 3 ---
>  radeon/Android.mk| 3 ---
>  4 files changed, 10 deletions(-)
>
> diff --git a/freedreno/Android.mk b/freedreno/Android.mk
> index d6c19fe..9031d61 100644
> --- a/freedreno/Android.mk
> +++ b/freedreno/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_FREEDRENO_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/freedreno
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> diff --git a/intel/Android.mk b/intel/Android.mk
> index 8a30fb5..7397110 100644
> --- a/intel/Android.mk
> +++ b/intel/Android.mk
> @@ -34,7 +34,6 @@ LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
>  LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/intel \
> external/libpciaccess/include
>
>  LOCAL_CFLAGS := \
> diff --git a/nouveau/Android.mk b/nouveau/Android.mk
> index 6c46f6c..5bc325c 100644
> --- a/nouveau/Android.mk
> +++ b/nouveau/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_NOUVEAU_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/nouveau
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> diff --git a/radeon/Android.mk b/radeon/Android.mk
> index d9192b6..f12e631 100644
> --- a/radeon/Android.mk
> +++ b/radeon/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_RADEON_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/radeon
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> --
> 2.1.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:

[PATCH libdrm 0/5] Yet another round of Android build cleanups

2015-03-18 Thread Chih-Wei Huang

2015-03-18 7:30 GMT+08:00 Emil Velikov :
>
> As pointed out by Chih-Wei, Android's LOCAL_COPY_HEADERS{,_TO} has been
> depreciated for quite some time.
>
> Although it was a convenient way of getting things done (no more
> hard-coding the location of drm) it seems that there is another more
> appropriate (and cleaner) solution. Namely:
> Annotate the includes as "exported" and as the user selects the library
> for linking, the build will automatically add the includes.
>
> Big thanks to Chih-Wei for the patience and persistence explaining the
> whole shebang. This series is mostly based on his patch in the
> Android-x86 tree, with some extra bits from your truly :-)
>
> Chih-Wei,
>
> I've tested this a few times already, although having someone with
> experience in the whole thing will be appreciated.

Thank you for the effort to clean it up.
The patches looks good to me.

I would suggest to remove all the use of LIBDRM_TOP.
Do you want me to submit a patch?

45 matches

Mail list logo