Hi, I actually (think?) that I fixed the issue. It's all related to a check in the intel i915 drm code in the kernel, which is still present in the latest Fedora 2.6.30.8-64 kernel. It's in the form of data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff disabled for my i855GM. I compared with a stock kernel and found that it was enabled by default for all the intel chips and just reverted that change (and kept the other redhat patches, such as the mchbar and the suspend/restore code) and well, it fixed my problem with Xv. I think that the has_gem thing is exported for X11 and Xv user-space through a GEM ioctl property and it doesn't interfere with the rest of the kernel drm code. Anyway, it's working here :) Any confirmation from redhat's engineers? Regards, Ilyes Gouta. On Fri, Oct 9, 2009 at 5:30 AM, Ben Boeckel <MathStuf@xxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > James Antill wrote: >> The problem is that PPAs/KoPeRs are going to get much less > testing than >> stuff in updates-testing, so if you don't think you are > getting enough >> testing in updates-testing I really don't see how KoPeRs will > solve that >> problem. >> >> Personally I'd suggest pushing to updates-testing but wait a > _long_ >> time (maybe even never) before pushing to stable. >> Of course you are kind of screwed in having a package which > might work >> fine on one machine, but fail on many others. >> >>> I think for F12 updates we could really do with some sort of > side repo >>> setup, so we could have a stability period where QA could > happen on >>> packages that may end up in updates a month or two later. >> >> How would this be different from updates-testing? If you > install >> yum-plugin-aliases it even has predefined aliases lsuT and upT > to get >> the list of updates from testing, and update to them. bodhi > has support >> for it etc. > > The problem with forcing two pipelines through u-t for one > package is that if the stable package has something that needs > to go through updates-testing, the new, possibly unstable, > version shadows the new stable build. Side repos (preferably > "themed" per sé; KDE updates separate from GNOME packages that > the same maintainer happens to maintain as well so that users > don't have to update something they use on the side and can't > test as well) is the only way to fit a double pipeline for a > single package through the update system as it stands. > > - --Ben > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L > nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9 > oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU > qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt > iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv// > 4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49 > AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI > u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5 > hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT > 6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0 > H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY > cIK16m8HKZQ0mYZOhgPe > =AIHy > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
