How about releasing an update of xorg-x11-drv-intel for Fedora 11

[Ilyes Gouta]

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 at gmail.com> 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 at gmail.com> 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>