https://bugzilla.redhat.com/show_bug.cgi?id=1031342 --- Comment #22 from Rob Clark <rclark@xxxxxxxxxx> --- (In reply to Nicolas Chauvet (kwizart) from comment #21) > I can confirm that the usabily test has passed for this ddx driver with > current fedora userspace. But the test device (ifc6410) still miss device > tree hence fedora kernel support. just fwiw, the strategy I am taking is to just try to get all the userspace stuff in place upstream for now, and maintain non-fedora kernels. It is much easier for end users with (for example) an ifc6410 board to take a vanilla fedora userspace and only a custom kernel / boot.img, vs if we ask them to also recompile mesa, ddx, etc. But I'm hopeful that the upstream situation is improving for snapdragon.. the pace of patches upstream has picked up, and qcom now a linaro member, etc. > I still wonder if the driver could be auto-selected for a given soc. > Like what is hardcoded from the kernel in pci cases: > http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86pciBus.c fwiw, Thierry Reding had a recent patchset to support autoloading for non-pci devices, which looks like the right way to go long term. http://lists.freedesktop.org/archives/xorg-devel/2014-February/040671.html We could either cherry pick those back into fedora xserver, or take the lazy way for the short term and ask users to manually copy over an xorg .conf file. > I'm going to test the latest patch (xa) with mesa 10.2 backported to f20. btw, I found out about COPR the other day.. I'm sorta thinking it would be useful to have COPR that is something equivalent to xorg-edgers which could pick up latest mesa, ddx, etc. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review