* drm_hwcomposer moving to fd.o @ 2017-09-21 23:52 Robert Foss 2017-09-22 2:40 ` Chih-Wei Huang 2017-09-22 11:21 ` Jani Nikula 0 siblings, 2 replies; 15+ messages in thread From: Robert Foss @ 2017-09-21 23:52 UTC (permalink / raw) To: Kalyan Kondapally, Kaveh Nasri, Liviu Dudau Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, dri-devel@lists.freedesktop.org, Marissa Wall, Stephane Marchesin 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/ 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/ Rob. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-21 23:52 drm_hwcomposer moving to fd.o Robert Foss @ 2017-09-22 2:40 ` Chih-Wei Huang 2017-09-22 15:43 ` Robert Foss 2017-09-22 11:21 ` Jani Nikula 1 sibling, 1 reply; 15+ messages in thread From: Chih-Wei Huang @ 2017-09-22 2:40 UTC (permalink / raw) To: Robert Foss Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally 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 <robert.foss@collabora.com>: > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-22 2:40 ` Chih-Wei Huang @ 2017-09-22 15:43 ` Robert Foss 2017-09-25 2:44 ` Chih-Wei Huang 0 siblings, 1 reply; 15+ messages in thread From: Robert Foss @ 2017-09-22 15:43 UTC (permalink / raw) To: Chih-Wei Huang Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Kalyan Kondapally, Stephane Marchesin 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. The android-ia project has supported using drm_hwcomposer and an alternative hwcomposer, so it would think there should be no issues. > > 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. Rob. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-22 15:43 ` Robert Foss @ 2017-09-25 2:44 ` Chih-Wei Huang 2017-09-25 3:25 ` Kondapally, Kalyan 2017-09-25 7:06 ` Tomeu Vizoso 0 siblings, 2 replies; 15+ messages in thread From: Chih-Wei Huang @ 2017-09-25 2:44 UTC (permalink / raw) To: Robert Foss Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Kalyan Kondapally, Stephane Marchesin Hey Robert, thank you for the reply. 2017-09-22 23:43 GMT+08:00 Robert Foss <robert.foss@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: drm_hwcomposer moving to fd.o 2017-09-25 2:44 ` Chih-Wei Huang @ 2017-09-25 3:25 ` Kondapally, Kalyan 2017-09-25 7:06 ` Tomeu Vizoso 1 sibling, 0 replies; 15+ messages in thread From: Kondapally, Kalyan @ 2017-09-25 3:25 UTC (permalink / raw) To: Chih-Wei Huang, Robert Foss Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Nasri, Kaveh, Stephane Marchesin Hi Chih-Wei, 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. Not sure why you have that impression. We don't carry any custom Kernel patches in our side. Br, Kalyan -----Original Message----- From: Chih-Wei Huang [mailto:cwhuang@android-x86.org] Sent: Sunday, September 24, 2017 7:44 PM To: Robert Foss <robert.foss@collabora.com> Cc: Zach Reizner <zachr@chromium.org>; Daniel Stone <daniels@collabora.com>; Tomeu Vizoso <tomeu.vizoso@collabora.com>; Liviu Dudau <Liviu.Dudau@arm.com>; dri-devel@lists.freedesktop.org; Marissa Wall <marissaw@google.com>; Nasri, Kaveh <kaveh.nasri@intel.com>; Stephane Marchesin <marcheu@chromium.org>; Kondapally, Kalyan <kalyan.kondapally@intel.com> Subject: Re: drm_hwcomposer moving to fd.o Hey Robert, thank you for the reply. 2017-09-22 23:43 GMT+08:00 Robert Foss <robert.foss@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-25 2:44 ` Chih-Wei Huang 2017-09-25 3:25 ` Kondapally, Kalyan @ 2017-09-25 7:06 ` Tomeu Vizoso 2017-09-26 5:26 ` Daniel Vetter 1 sibling, 1 reply; 15+ messages in thread From: Tomeu Vizoso @ 2017-09-25 7:06 UTC (permalink / raw) To: Chih-Wei Huang, Robert Foss Cc: Zach Reizner, Daniel Stone, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Kalyan Kondapally, Stephane Marchesin 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.foss@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). Regards, Tomeu > 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. > > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-25 7:06 ` Tomeu Vizoso @ 2017-09-26 5:26 ` Daniel Vetter 2017-09-28 6:49 ` Chih-Wei Huang 0 siblings, 1 reply; 15+ messages in thread From: Daniel Vetter @ 2017-09-26 5:26 UTC (permalink / raw) To: Tomeu Vizoso Cc: Zach Reizner, Daniel Stone, Robert Foss, Liviu Dudau, Marissa Wall, dri-devel@lists.freedesktop.org, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally 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.foss@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+. Cheers, Daniel > Regards, > > Tomeu > > > 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. > > > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-26 5:26 ` Daniel Vetter @ 2017-09-28 6:49 ` Chih-Wei Huang 2017-09-28 7:08 ` Daniel Vetter 0 siblings, 1 reply; 15+ messages in thread From: Chih-Wei Huang @ 2017-09-28 6:49 UTC (permalink / raw) To: Daniel Vetter Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Robert Foss, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-28 6:49 ` Chih-Wei Huang @ 2017-09-28 7:08 ` Daniel Vetter 2017-09-28 7:35 ` Tomeu Vizoso 2017-09-29 5:31 ` Chih-Wei Huang 0 siblings, 2 replies; 15+ messages in thread From: Daniel Vetter @ 2017-09-28 7:08 UTC (permalink / raw) To: Chih-Wei Huang Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Robert Foss, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote: > 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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? > 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. Cheers, Daniel > Full log: > https://drive.google.com/open?id=0B3GICgSwrKXcci1lbDdaSlJBRE0 > > > Shall I create bugs in the Bugzilla? -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-28 7:08 ` Daniel Vetter @ 2017-09-28 7:35 ` Tomeu Vizoso 2017-09-28 7:43 ` Tapani Pälli 2017-09-29 5:31 ` Chih-Wei Huang 1 sibling, 1 reply; 15+ messages in thread From: Tomeu Vizoso @ 2017-09-28 7:35 UTC (permalink / raw) To: Daniel Vetter, Chih-Wei Huang Cc: Zach Reizner, Daniel Stone, Robert Foss, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally On 09/28/2017 09:08 AM, Daniel Vetter wrote: > On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote: >> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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. An easy way of making sure that the problem is with compositing with overlays is applying this hack: https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba It should also allow you to move on and test more stuff. >> vmwgfx also has issues on drm_hwcomposer >> initialization. SurfaceFlinger didn't crashes but >> no bootanimation. It seems just blocked. If you want to test another driver in qemu, you can test Varad's patches in https://patchwork.freedesktop.org/series/29006/ for atomic updates in the Cirrus driver. Regards, Tomeu _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-28 7:35 ` Tomeu Vizoso @ 2017-09-28 7:43 ` Tapani Pälli 2017-09-28 7:59 ` Daniel Vetter 0 siblings, 1 reply; 15+ messages in thread From: Tapani Pälli @ 2017-09-28 7:43 UTC (permalink / raw) To: Tomeu Vizoso, Daniel Vetter, Chih-Wei Huang Cc: Zach Reizner, Daniel Stone, Robert Foss, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Kalyan Kondapally, Stephane Marchesin On 09/28/2017 10:35 AM, Tomeu Vizoso wrote: > On 09/28/2017 09:08 AM, Daniel Vetter wrote: >> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote: >>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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. > > An easy way of making sure that the problem is with compositing with > overlays is applying this hack: > > https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba > > It should also allow you to move on and test more stuff. back when Android-IA used drm_hwcomposer there were some fixes made before things started to work, this is a shot in the dark but following commits might fix something (disclaimer, this is based on some old snapshot of drm_hwcomposer but one might be able to port relevant changes ...) handle cursor separately: https://github.com/android-ia/external-drm_hwcomposer/commit/f9029ff42f7f925a2e34aad1caa1481f72f347ac introduce own planner for IA: https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352c631b379d9721795c783fc4e7 >>> vmwgfx also has issues on drm_hwcomposer >>> initialization. SurfaceFlinger didn't crashes but >>> no bootanimation. It seems just blocked. > > If you want to test another driver in qemu, you can test Varad's patches > in https://patchwork.freedesktop.org/series/29006/ for atomic updates in > the Cirrus driver. > > Regards, > > Tomeu > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-28 7:43 ` Tapani Pälli @ 2017-09-28 7:59 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2017-09-28 7:59 UTC (permalink / raw) To: Tapani Pälli Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Robert Foss, Liviu Dudau, Marissa Wall, dri-devel@lists.freedesktop.org, Kaveh Nasri, Kalyan Kondapally, Stephane Marchesin On Thu, Sep 28, 2017 at 9:43 AM, Tapani Pälli <tapani.palli@intel.com> wrote: > > > On 09/28/2017 10:35 AM, Tomeu Vizoso wrote: >> >> On 09/28/2017 09:08 AM, Daniel Vetter wrote: >>> >>> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> >>> wrote: >>>> >>>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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. >> >> >> An easy way of making sure that the problem is with compositing with >> overlays is applying this hack: >> >> >> https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba >> >> It should also allow you to move on and test more stuff. > > > back when Android-IA used drm_hwcomposer there were some fixes made before > things started to work, this is a shot in the dark but following commits > might fix something (disclaimer, this is based on some old snapshot of > drm_hwcomposer but one might be able to port relevant changes ...) > > handle cursor separately: > > https://github.com/android-ia/external-drm_hwcomposer/commit/f9029ff42f7f925a2e34aad1caa1481f72f347ac > > introduce own planner for IA: > > https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352c631b379d9721795c783fc4e7 Both of these should be fixed in the generic code I'd say. Cursor is a perfect case of random special cases that might make some planes unsuable in certain conditions (but there's really nothing special with it being the cursor plane). And the 2nd patch shows how we probably want to expose the can_scale and can_position stuff from the plane's atomic_check functions as hints to the compositor. Plus ofc the compositor should try to only use the supported drm_fourcc codes (if it indeed gets that wrong). So yeah I'd say that's bugs in drm_hwcomposer, if this helps with fixing it. -Daniel >>>> vmwgfx also has issues on drm_hwcomposer >>>> initialization. SurfaceFlinger didn't crashes but >>>> no bootanimation. It seems just blocked. >> >> >> If you want to test another driver in qemu, you can test Varad's patches >> in https://patchwork.freedesktop.org/series/29006/ for atomic updates in >> the Cirrus driver. >> >> Regards, >> >> Tomeu >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-28 7:08 ` Daniel Vetter 2017-09-28 7:35 ` Tomeu Vizoso @ 2017-09-29 5:31 ` Chih-Wei Huang 1 sibling, 0 replies; 15+ messages in thread From: Chih-Wei Huang @ 2017-09-29 5:31 UTC (permalink / raw) To: Daniel Vetter Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, Robert Foss, Liviu Dudau, dri-devel@lists.freedesktop.org, Marissa Wall, Kaveh Nasri, Stephane Marchesin, Kalyan Kondapally 2017-09-28 15:08 GMT+08:00 Daniel Vetter <daniel@ffwll.ch>: > On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote: >> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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.foss@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-21 23:52 drm_hwcomposer moving to fd.o Robert Foss 2017-09-22 2:40 ` Chih-Wei Huang @ 2017-09-22 11:21 ` Jani Nikula 2017-09-22 15:23 ` Robert Foss 1 sibling, 1 reply; 15+ messages in thread From: Jani Nikula @ 2017-09-22 11:21 UTC (permalink / raw) To: Robert Foss, Kalyan Kondapally, Kaveh Nasri, Liviu Dudau Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, dri-devel@lists.freedesktop.org, Marissa Wall, Stephane Marchesin On Fri, 22 Sep 2017, Robert Foss <robert.foss@collabora.com> wrote: > 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. Sounds good! > Regarding contributions, they are accepted on the dri-devel list, using > the patch prefix "hwc". dri-devel averages around 2400-2500 messages per month AFAICT. If hwc community development picks up any kind of momentum, please consider starting a new list. Or would a joint userspace list with e.g. libdrm be beneficial? Daniel Stone will help you here. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: drm_hwcomposer moving to fd.o 2017-09-22 11:21 ` Jani Nikula @ 2017-09-22 15:23 ` Robert Foss 0 siblings, 0 replies; 15+ messages in thread From: Robert Foss @ 2017-09-22 15:23 UTC (permalink / raw) To: Jani Nikula, Kalyan Kondapally, Kaveh Nasri, Liviu Dudau Cc: Zach Reizner, Daniel Stone, Tomeu Vizoso, dri-devel@lists.freedesktop.org, Marissa Wall, Stephane Marchesin Hey Jani, On Fri, 2017-09-22 at 14:21 +0300, Jani Nikula wrote: > On Fri, 22 Sep 2017, Robert Foss <robert.foss@collabora.com> wrote: > > 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. > > Sounds good! > > > Regarding contributions, they are accepted on the dri-devel list, > > using > > the patch prefix "hwc". > > dri-devel averages around 2400-2500 messages per month AFAICT. If hwc > community development picks up any kind of momentum, please consider > starting a new list. Or would a joint userspace list with e.g. libdrm > be > beneficial? Daniel Stone will help you here. A separate ML if there ends up being a significant volume of traffic sounds like a good idea. I guess we're following the IGT model here, and will move if/when sustained development is occurring. > > BR, > Jani. > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-09-29 5:31 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-21 23:52 drm_hwcomposer moving to fd.o Robert Foss 2017-09-22 2:40 ` Chih-Wei Huang 2017-09-22 15:43 ` Robert Foss 2017-09-25 2:44 ` Chih-Wei Huang 2017-09-25 3:25 ` Kondapally, Kalyan 2017-09-25 7:06 ` Tomeu Vizoso 2017-09-26 5:26 ` Daniel Vetter 2017-09-28 6:49 ` Chih-Wei Huang 2017-09-28 7:08 ` Daniel Vetter 2017-09-28 7:35 ` Tomeu Vizoso 2017-09-28 7:43 ` Tapani Pälli 2017-09-28 7:59 ` Daniel Vetter 2017-09-29 5:31 ` Chih-Wei Huang 2017-09-22 11:21 ` Jani Nikula 2017-09-22 15:23 ` Robert Foss
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.