<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Monospace'; font-size:10pt; font-weight:400; font-style:normal;"> Hi, On Thursday, 1 September 2016 10:44:08 CEST Adam Jackson wrote: > On Thu, 2016-09-01 at 15:36 +0100, Emil Velikov wrote: > > > Did you have the chance to respin the EGL device patches for mesa or > > shall I ? > > I have a work-in-progress branch to port it to the drmDevice API here: > > https://cgit.freedesktop.org/~ajax/mesa/log/?h=egl-ext-device > > I don't remember how well that worked as of last time I touched it, but > I'll send it on to mesa-dev once I think it's reasonable, should be in > the next week or so. Great! One question that I cannot forsee from your branch: The EGL_EXT_device_enumeration spec says [...] All implementations must support at least one device. [...] Which means to me that once an application sucsessfully asked for EGL_EXT_device_query, this calling application can rely on recieving at least one usable(?) EGL device. As a last resort, that single guaranteed device can be a software renderer, but the application gets at least something that lets it render pictures in some way. Sure, the intent of the extension is to privide access to hw backed implementations. For us it means that we need to provide a software rendering context for the case that there is either no drm capable graphics driver. Or an even more nasty case, when the device node is just not accessible by the user. I have seen distros that restrict the permissions of the render node devices to the user loged in the running X server. So, even if there is hardware that you could potentially use, you may not be able to access it. ... remember, the major intent of this set of extensions is to provide applications with an off screen rendering context for the case where you do not have a local X/wayland/whatnotdisplayserver running. Alternatively to providing a cpu rasterizer as a fallback, we could supress announcing the EXT_device_enumeration extension if there is no hw backed driver available. And in turn EGL_EXT_device_base which depends on EGL_EXT_device_query. That would at least require some infrastructure to dynamically enable client extensions. It would still be unclear what to do then when the render nodes seem accessible when initializing/enumerating but the permissions change until the application wants to create the display using eglGetPlatformDisplayEXT later. What are your plans? Anyhow, thanks for taking care! best Mathias</body></html>