Created attachment 136475 [details] logcat showing hwc errors Hi, while testing drm_hwcomposer (hwc v1), having enabled atomic ioctl for drm/nouveau a series of properties can be enquired, but rotation property returns an error in drmplane.cpp:123 01-02 00:05:42.626 2300 2300 E hwc-drm-plane: Could not get rotation property 01-02 00:05:42.626 2300 2300 I hwc-drm-plane: Could not get alpha property Since ALOGE() is used, an error is signalled, could you please check why rotation property not available and why drm_hwcomposer is not working with drm/nouveau? 01-02 00:05:42.628 2300 2300 E hwc-drm-resources: Could not find a suitable encoder/crtc for display 2 01-02 00:05:42.628 2300 2300 E hwc-drm-resources: Failed CreateDisplayPipe 49 with -19 01-02 00:05:42.628 2300 2300 E hwcomposer-drm: Can't initialize Drm object -19 01-02 00:05:42.629 2300 2300 E SurfaceFlinger: composer device failed to initialize (No such device) 01-02 00:05:42.629 2300 2300 E SurfaceFlinger: ERROR: failed to open framebuffer (Invalid argument), aborting --------- beginning of crash 01-02 00:05:42.629 2300 2300 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 2300 (surfaceflinger), pid 2300 (surfaceflinger) Another question is about alpha property, is it correct/safe to assume that being only logged as info, with ALOGI() it is not preventing drm_hwcomposer from working properly? Full logcat attached Mauro
Created attachment 136476 [details] dmesg for same session
Those properties are not available for the very simple reason that they're not implemented. What would the 'alpha' property do? I don't think there's any support for rotation in the hardware. (That's like you want to set a 1280x720 mode but use a 720x1280 fb?)
(As an aside, you filed this bug against nouveau, but perhaps you meant to file it against drm_hwcomposer? Not sure where that project is hosted though.) Is there anything in there that leads you to believe that nouveau is doing something wrong?
Hi Ilia, thanks for your responses. Also in my understanding, which is not professional but more of an hobbyist, the drm planes model considered in drm_hwcomposer may have considered rotation property as available in its first implementations/test cases. IMHO since having no rotation is equivalent to having 0 rotation only, I don't see the reason for drm_hwcomposer to throw the error in drmplane.cpp:123, unless being born as an hwcomposer HAL and having a strong requirement for it (or to "fake it"). Also I wanted to get your feedback, which is in line with KMS documentation, that rotation property can be optional. Thanks for your hint, drm_hwcomposer is now part of freedesktop.org https://cgit.freedesktop.org/drm_hwcomposer but I could not find how to submit a bug for drm_hwcomposer in bugzilla. I think it should not be in 'DRI' section and it should not be in 'Mesa' Mauro
Hi Ilia, Thanks for your feedbacks, rotation property is unessential, so drm_hwcomposer error is "informative" I could boot oreo-x86 with GT610 with some changes in drm_hwcomposer, i.e. adding some drm mode connector types which were missing (DVID, DVII and VGA) and considering only connected ones I'll write an email to Robert Foss and Rob Herring in Cc: Please close as Not-Your-Bug Cheers Mauro
FYI you can also change bug status yourself. Glad you got things going.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.