https://bugzilla.novell.com/show_bug.cgi?id=771392
https://bugzilla.novell.com/show_bug.cgi?id=771392#c72
Johannes Obermayr
(In reply to comment #68)
(In reply to comment #67) Do you have the time to bisect the necessary patch(es) upstream for a bug reported on bnc (esp. if you do not have the hardware and summary does not really point to it)?
If it's needed, we must do. Or better to say: as an online-update "fix", you must understand what you fixed and how it's fixed. By upgrading the whole stack, a bug might be fixed coincidentally, but you don't know always why it's fixed. And more badly, you don't know always whether any new regression might be introduced, too.
How would you know it has been fixed if you do not have "me" who maintains drm-all and point people to test it (as pointed out sndirsch just points to use nomodeset)? Will you buy the hardware and bisect it then? Will you apply the bisected commit within a few hours, days, weeks, months, years or never? Also often a drm patch does not work without a bunch of other patches because it is a fast living branch (500 commits or more will be pulled in merge window for linux 3.7). AFAIK openSUSE's kernels have not often experienced drm fixes because pointing to use nomodeset and so they are not recognized by kernel developers. Also I cannot see much communication with upstream developers on dri-devel or nouveau. I assume a lot of bugs reported on openSUSE 12.1 or earlier have been fixed upstream already.
So it is easier to provide a official drm package which people can easily revert if it breaks things and have a highly motivated maintainer who also reads specific mailing lists.
Sorry, the "easiness" alone is no good justification. For example, did you think how to handle security fixes once when the codes are split to KMP and kernel?
Requires: kernel-%1 = %2 (in preamble) On kernel update the drm-all package automatically depends on new kernel. Yes, if you have security fixes in drivers/gpu/ also drm-all package must eventually become patched (or better the patch be upstreamed to dri-devel and pulled by me). Wait, you must be fast because if an unpatched drm-all package was build against the patched Kernel it is also possible to use an unpatched drm-all package again. So first the drm-all package should be fixed and then the kernel package. But that shouldn't be too much effort ... On the contrary it is possible to download a small package and use "secure" drm modules without updating the complete kernel.
Again, I'm not against having drm-kmp. It's good for a rolling update model like Tumbleweed. But this cannot be a "fix", thus cannot be provided as a maintenance update.
Using out-of-tree drm modules for ~ 3 years without many regressions (which were mostly fixed fast upstream) on nVidia and ATI/AMD hardware I vote for inclusion in Update. Do you have any download statistics for Update and Tumbleweed? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.