Obviously i915.modeset == 0 all the time (including when I reported the issue). -Ilyes On Fri, Oct 9, 2009 at 9:21 AM, Ilyes Gouta <ilyes.gouta@xxxxxxxxx> wrote: > 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
