09:29 karolherbst: today's fun: when b->shader->info.spec is an empty string, nir_serialize generates a different blob, contrary to when it's NULL, then it does :'(
09:29 karolherbst: *does't
09:29 karolherbst: like different every time
09:58 karolherbst: yeah... a "blob_write_string(blob, "");" seems to cause the generated blake3 to be different every time.. this is kinda weird...
09:58 karolherbst: ohhhhhhh....
09:58 karolherbst: nvm I found it
10:03 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/44262 :')
18:37 bjorn3_gh: Is there a reason display hotplug events are only reported over udev and not (also) as drm_event on the respective drm node?
18:39 bjorn3_gh: This makes it impossible to support hotplugging on OSes other than Linux without udev support without adding an OS specific extension to the DRM interface, which I did rather avoid, and patching every user of the drm interface to use this extension instead of udev.
18:40 bjorn3_gh: If the reason is nobody thought of it before, I wouldn't mind submitting a patch to Linux to add a DRM_EVENT_HOTPLUG event type.
20:57 emersion: bjorn3_gh: how do you plan to support DRM device hotplug/unplug events?
21:23 airlied: bjorn3_gh: I don't remember, but likely drm event didn't exist when we designed hotplug but also all current events are responses to things
21:23 airlied: I'm not sure any of them are async
21:26 bjorn3_gh: emersion: You mean adding/removing an entire gpu? Currently the seat manager only supports presenting a single drm node to the compositor when the respective driver registers itself with the seat manager. In the future the seat manager could present all drm nodes.
21:27 bjorn3_gh: After registering the drm node with the seat manager, the only communication between the seat manager and the gpu driver is the seat manager telling the gpu driver to switch VT over a side channel (and the gpu driver must not call into the seat manager to avoid a deadlock, at best the seat manager could epoll and then read).
21:27 bjorn3_gh: The way it currently works isn't going to work in the long term though. Unlike on Linux currently every client thinks it is the drm master simultaneously, with only the active VT actually making changes to the actual hardware and the rest updating a private copy of the state. Modesetting is going to be an issue with this for example.
21:27 bjorn3_gh: I'm assuming you are suggesting to use the same mechanism for display hotplug as for gpu hotplug? I guess it would be possible for the seat manager to read hotplug events from the gpu, but it feels a bit wrong for the seat manager to do anything other than mediating access to opaque device nodes attached to a seat.
21:28 bjorn3_gh: airlied: Guess that makes sense. Is the current drm implementation preventing async events, or just there was no need to add any?
21:29 bjorn3_gh: Do drm clients ignore unexpected events? Or would it need a client capability if DRM_EVENT_HOTPLUG was accepted?
22:58 airlied: I suspect we'd have to add a client request to enable them, but I've no idea if the current code is designed for async events at all, but it's probably worth raising on dri-devel list