Hi all On 30 September 2016 at 04:09, Laszlo Ersek <lersek@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
