Hi all
On 30 September 2016 at 04:09, Laszlo Ersek lersek@redhat.com wrote:
Hello Daniel,
On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
We already have a fallback in place to fill out the unique from dev->unique, which is set to something reasonable in drm_dev_alloc.
Which means we only need to have a special set_busid for pci devices, to be able to care the backwards compat code for drm 1.1 around, which libdrm still needs.
While developing and testing this patch things blew up in really interesting ways, and the code is rather confusing in naming things between the kernel code, ioctl #defines and libdrm. For the next brave dragon slayer, document all this madness properly in the userspace interface section of gpu.tmpl.
v2: Make drm_dev_set_unique static and update kerneldoc.
v3: Entire rewrite, plus document what's going on for posterity in the gpu docbook uapi section.
v4: Drop accidental amdgpu hunk (Emil).
v5: Drop accidental omapdrm vblank counter change (Emil).
This patch (commit a325725633c2) regresses X.org on QEMU's virtio-vga device. Please see
https://bugzilla.redhat.com/show_bug.cgi?id=1366842
complete with a bisection log under
drivers/gpu/drm/virtio/
Having gone through the xserver code as this patch was written, I'm not entrirely sure how this can happen.
Since there is a very nice cleanup series that this patch is build upon, I'd suggest trying to understand the issue, rather than a blind revert.
Here we want to check the xserver/libdrm codepath before/after the kernel patch, in particular the following drmOpen, drmAvailable, drmSetInterfaceVersion and drmGetBusid. If the xserver is using open() with drmSetInterfaceVersion then that is _not_ something it should be doing and I'm against working around it in the kernel (fwiw).
To ease things one can set LIBGL_DEBUG=verbose (yay fun name) and libdrm will print out some debug output to stderr
Regards, Emil