New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
regression found by drm: remove VA_DRM_IsRenderNodeFd() helper #692
Comments
suppose I will revert this patch to release 2.17.1 if no other concern. |
The function has been used by mesa for years, so I don't quite see how it causes a problem. I'm not claiming it's perfect, but I don't see how. Can you provide some helpful information for me to debug? |
Also note that Which distribution is being affected? |
Here are some debug logs i put in libva and got this after revert of the patch. Debug code. (I reverted the patch and added manually drmGetNodeTypeFromFd call to check the difference in return of both in this test scenario)
output logs: both the function returns differently with same fd. |
@kumarsac are you the original reporter, or you're another person also seeing the issue? Can you help out with a few questions:
In addition to that can you provide the output of:
Thanks o/ |
Bear in mind the original |
hi @evelikov , it is a chromeOS usage, libdrm version is new one, suppose @kumarsac could provide the details. yes, agree that drmGetDeviceNameFromFd will just return /dev/dri/cardx not render node. it is useless |
libdrm chrome using is 2.4.110. code:
|
When you say chromeOS - which version is that? IIRC there are 3-4 variants available. Mind you I'm not sandbox expert, so take the following with a pinch of salt. Chromium applies different sandbox policy for GPU/Decode/Encode If you follow all the use_XXX_specific_policies references across the codebase - you can deduce where and how, plus there is also per-vendor (AMD/Intel/etc) variance. From a quick look these should be enabled for both AMD and Intel
Overall the various details are split quite drastically across the tree, so you might need more than just the above. As a whole, I think most At the moment Intel is playing catch-up and as you can see it's costing your team. |
the case is chrome out of process decode case,
after this patch 4d4c5f06519fe4c40d6fe1b2ccff812ff3b3b402
it will break the initialization process, suppose it is because the check in drmGetNodeTypeFromFd is strict than
if (fstat(fd, &st) == 0)
return S_ISCHR(st.st_mode) && (st.st_rdev & 0x80);
ps:
int drmGetNodeTypeFromFd(int fd)
{
struct stat sbuf;
int maj, min, type;
}
@evelikov-work
The text was updated successfully, but these errors were encountered: