Follow CRTC, not framebuffer id
w23 opened this issue · comments
is this why I only see my first display in the framebuffer selector?
@edrex I doubt that, but I may be enumerating framebuffers in a not very correct way (can't say that I'm that familiar with libdrm, this was basically my first encounter with it).
Can you create a separate issue for that and post a log there?
I'm trying to implement this by switching the fb enumeration for crtc enumeration and checking all crtcs every second to see if the settings (fb id, width, height etc) have changed, but the fb id seems to change all the time for some reason, and idk if it's a good idea to be creating new EGL images every second. I was expecting the fb to only change when doing stuff like tabbing into a fullscreen game. Do you know of a better way to track a crtc?
Unfortunately, no. I'm not really familiar with libdrm, this capture method was a result of nontrivial amount of experimentation.
I wanted to investigate all of this further at some point, but haven't got to it so far.
I've also experienced this framebuffer "hopping" behaviour on a intel graphics card on linux. On raspberry pi the framebuffer ids are stable. This seems to happen every few seconds. Once the device is opened the id seems to remain stable - as long as the resolution stays the same of course. I haven't come across a better idea than "polling" for changes for my project. I've been searching the api up and down for some sort of "event mechanism" but havent found anything.
Probably to find a second display (if it is using the same card) you'd have to enumerate all "connectors", then find the respective "crtc" and then the primary plane of that crtc. This api unfortunately is dead cumbersome... There is a tool called "drm_info" (https://github.com/ascent12/drm_info) on github which does very detailed enumeration of every aspect of this resource tree.
Found out these things by experimentation too - Hope this helps.