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

[Ilyes Gouta]

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
>