Bug 282882

Please define malformed

Created attachment 64015 [details]
Xrender for compositing works as intended

This is a snapshot when Xrender is selected as the rendering backend for Desktop Effects (not the graphics sunsystem).

kwin does not appear malformed.

Created attachment 64016 [details]
OpenGL Desktop effects and kwin appearance

This is what happens when I select OpenGL as the rendering backend for desktop effects.

Created attachment 64017 [details]
Oxygen window decorations

Oxygen window decorations appear even worse, than keramik.

thanks, what's your GPU, driver, version?

GPU: M9+ 5C61 [Radeon Mobility 9200 (AGP)]
Renderer: Mesa DRI R200 (RV280 5C61)

X -version:

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.0-ARCH i686 
Current Operating System: Linux Pollux 3.0-ck #1 SMP PREEMPT Thu Sep 22 00:10:20 EDT 2011 i686
Kernel command line: root=/dev/sda6 ro 5 radeon.modeset=1 video=1400x1050 elevator=bfq logo.nologo resume=/dev/sda7 quiet splash initrd=../initramfs-linux-ck.img BOOT_IMAGE=../vmlinuz-linux-ck 
Build Date: 17 September 2011  07:40:13AM
 
Current version of pixman: 0.22.2

-----

Using latest OSS drivers:

pacman -Qi xf86-video-ati:

Name           : xf86-video-ati
Version        : 6.14.2-1
URL            : http://xorg.freedesktop.org/
Licenses       : custom
Groups         : xorg-drivers  xorg
Provides       : None
Depends On     : libpciaccess  libdrm  udev  pixman  ati-dri
Optional Deps  : None
Required By    : None
Conflicts With : xorg-server<1.10.0
Replaces       : None
Installed Size : 1153.00 K
Packager       : Andreas Radke <andyrtr@archlinux.org>
Architecture   : i686
Build Date     : Thu 26 May 2011 10:45:52 PM EEST
Install Date   : Thu 04 Aug 2011 11:18:51 PM EEST
Install Reason : Explicitly installed
Install Script : No
Description    : X.org ati video driver

I can only recommend to not use KWin with raster and your hardware. It is extremely old and it is unlikely that we can ever reproduce issues on r200. E.g. such a card I would not be able to even install in my system.

I will soon receive an r300 to try to fix some r300 related issues which might also improve the situation on r200. If that won't help, we won't be able to support your card. I'm sorry.

Xrender is pretty slow for KDE, unfortunatelly and thats the reason I use raster. Lets hope that issues will be resolved. I still wonder though why this was not happening with KDE 4.6.

(In reply to comment #8)
> I still wonder though why this was not happening with KDE 4.6.

very simple: support for raster is a new feature in KWin 4.7. Before KWin was enforcing native.

(In reply to comment #8)
> Xrender is pretty slow for KDE,

*cough* ... "on that chip/driver"
Eg. the nvidia driver incredibly sucked (past - it's better now) at pixmap allocation but can do XRender matrix transformations or alpha blending nearly as fast as on OpenGL - *way* faster than the cpu.
The issue is likely that xrender isn't implemented by that driver at all and the generic sw implementation of XRender is... "suboptimal" ;-)

> Lets hope that issues will be resolved.

sudo su
mv /usr/bin/kwin /usr/bin/kwin.bin
echo -e '#!/bin/sh\n/usr/bin/kwin.bin --graphicssystem native &' > /usr/bin/kwin
chmod ugo+rx /usr/bin/kwin
exit

/security note in case someone else reads that - Arch users likely are aware anyway ;-)

!!! This will be overridden by the next kde-workspace package upgrade and you'll have an outdated kwin.bin while kwin will be the elf binary.
Ie., you'll have to repeat the entire procedure. !!!

Thanks Thomas for all the comments and tips.

root:/home/twilight$ echo -e '#!/bin/sh\n/usr/bin/kwin.bin --graphicssystem native &' >
zsh: parse error near `\n

I get this error when typing the command, are you sure you wrote it correctly?

I dont know if Arch users are aware of this, but when I asked them why KDE looks so slow they suggested me to use raster and I did, which it looks faster that time with KDE 4.6, I dont really understand whats the difference now, except of the new kwin's support for raster.

*sigh* - ihatebugzillawhatkindofunbelievableshitisthissupposedtobe...

remove the newline between ">" and "/usr/bin/kwin" (ie. do not copy the ">" from here, type it yourself and paste the line after behind. then press enter)

Sorry :-(

I think I have reported the same bug on Launchpad: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/862964

My hardware specs are described there in detail.

If I could be of help to help solve this bug, please let me know.

I cannot reproduce this issue with an R300 card. Could you please upload a dump of glxinfo.

But I must say clearly that most likely we will not be able to support such old GPUs with all modern code pathes.

*** Bug 283367 has been marked as a duplicate of this bug. ***

I ve created a pastebin for the glxinfo:

http://pastebin.com/9wWFJkfd

(In reply to comment #16)
> I ve created a pastebin for the glxinfo:
thanks, that was fast :-)

Relevant information: 
* GL_ARB_texture_non_power_of_two not supported
* GL_TEXTURE_RECTANGLE_ARB supported

Based on that I'm confident that the fix I'm working on might fix this issue, too.

Thank you Martin. Is this still UNCONFIRMED?

Here is another glxinfo output (Radeon 9200 (dekstop) card), just in case.

http://pastebin.com/mTj9ayiy

Using „native“ graphicssystem actually produces other visual problems
– I will report those as well, if this is not fixed soon.

Donatas

2011/10/15 Martin Gräßlin <mgraesslin@kde.org>:
> https://bugs.kde.org/show_bug.cgi?id=282882
>
>
>
>
>
> --- Comment #14 from Martin Gräßlin <mgraesslin kde org>  2011-10-15 11:51:05 ---
> I cannot reproduce this issue with an R300 card. Could you please upload a dump
> of glxinfo.
>
> But I must say clearly that most likely we will not be able to support such old
> GPUs with all modern code pathes.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

Git commit b22f64f95509c0b9f343c64e60bfcbe2b08d0a0a by Martin Gräßlin.
Committed on 15/10/2011 at 14:14.
Pushed by graesslin into branch 'KDE/4.7'.

Generate texture coordinates for limited NPOT support

Fixes rendering issues with R300 and similar GPUs. If the texture
uses GL_TEXTURE_RECTANGLE_ARB as target the tex coordinates need
to be adjusted. This at least fixes missing text on EffectFrames
with graphicssystem native on R300. Hopefully more issues are
resolved by the change.

BUG: 269576
CCBUG: 282882
FIXED-IN: 4.7.3

M  +11   -4    kwin/libkwineffects/kwinglutils.cpp

http://commits.kde.org/kde-workspace/b22f64f95509c0b9f343c64e60bfcbe2b08d0a0a

Git commit 230d5aee9bdc46c3a796a10b884685b4224ba732 by Martin Gräßlin.
Committed on 15/10/2011 at 14:14.
Pushed by graesslin into branch 'master'.

Generate texture coordinates for limited NPOT support

Fixes rendering issues with R300 and similar GPUs. If the texture
uses GL_TEXTURE_RECTANGLE_ARB as target the tex coordinates need
to be adjusted. This at least fixes missing text on EffectFrames
with graphicssystem native on R300. Hopefully more issues are
resolved by the change.

BUG: 269576
CCBUG: 282882
FIXED-IN: 4.7.3

M  +11   -4    kwin/libkwineffects/kwingltexture.cpp

http://commits.kde.org/kde-workspace/230d5aee9bdc46c3a796a10b884685b4224ba732

I hope the above commit fixes the issue. If anyone is able to compile and test the latest version with the commit this would be appreciated.

So is it only one file in the sources that changed? I would gladly test it if it were possible using kde 4.7.1 sources (of ubuntu) plus this one file.

Do that tomorrow morning – now I have to go.

We applied the patch in comment #20 to the 4.7.2 source in Fedora 16.  No help for my distorted title bars on my Radeon Mobility M6 LY.

Well, unfortunately, I can confirm that the patch proposed does not solve the problem with my video card either (Radeon 9200). I have tested it both by patching the kde 4.7.1 version of kwin and (when that failed to appear as solved) by installing the unstable future 4.8 version (using Kubuntu Project Neon).

damn it. I have one more idea and will try to write the patch and will attach 
it to the bug report

Thank you Martin.

2011/10/20 Martin Gräßlin <mgraesslin@kde.org>:
> https://bugs.kde.org/show_bug.cgi?id=282882
>
> --- Comment #26 from Martin Gräßlin <mgraesslin kde org>  2011-10-20 04:25:47 ---
> damn it. I have one more idea and will try to write the patch and will attach
> it to the bug report

Hi, I hope this will get fixed someday. In the meantime I think we might have some more light here, the devs have finally brought attention to R100/R200 hardware:

http://www.phoronix.com/scan.php?page=news_item&px=MTAyMzU

*** Bug 288464 has been marked as a duplicate of this bug. ***

My GPU is NVIDIA NV11 [GeForce2 MX/MX 400] (rev b2)

Xorg defaults to the NOUVEAU driver.

So I replaced my video card with a ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) and got the same problem.
what would be a fix/workaround?

see comments 10,11,12

I found another workaround, add the following line to /etc/profile:

export QT_GRAPHICSSYSTEM=xrender

"export QT_GRAPHICSSYSTEM=native"
                         ^^^^^^^^ (xrender probably works because it's invalid and "unsets" the variable)

yes - or course you can omit the raster graphicssystem altogether and use the video memory instead of the system RAM - no idea who would compile/set raster as default anyway ...

what distro do you use?

I use Debian unstable updated this past week and my KDE source is from the git repository updated every day this week.

The setting is -if- encoded in Qt or set by a global environment variable.
While it actually can be a significant performance boost, this heavily relies on the GPU/driver/CPU combination and the application code (the more QPainter::drawImage() calls you find, the better are you done with the raster engine).

In return applications & widgets being rather tied to an X11 environment can even segfault on this graphicsssystem (the Qt event translator widget & it's usage seems prone to this)

The setting in kwin's advanced compositing setup is btw. not affected by this - XRender means XRender and OpenGL means OpenGL. Only the decoraion and plasma element (buttons, boxes) painting does really align to the graphicssystem.

anybody please look here.
https://bugs.kde.org/show_bug.cgi?id=293325#c10

whoever can try a patch please raise his hands.

will see what it looks like once it is in the project neon... is it gonna
be there? Sorry, I have no possibility to compile it now.

Donatas

2012/2/7 Donatas Glodenis <dg@lapas.info>

> I will see what it looks like once it is in the project neon... is it
> gonna be there?
>
> Donatas
>
>
> 2012/2/7 Thomas Lübking <thomas.luebking@gmail.com>
>
>> https://bugs.kde.org/show_bug.cgi?id=282882
>>
>>
>>
>>
>>
>> --- Comment #37 from Thomas Lübking <thomas luebking gmail com>
>>  2012-02-07 00:57:10 ---
>> anybody please look here.
>> https://bugs.kde.org/show_bug.cgi?id=293325#c10
>>
>> whoever can try a patch please raise his hands.
>>
>> --
>> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You are on the CC list for the bug.
>>
>
>

there's nothing comitted yet and i'd prefer confirmation before pushing experiments to fix things i don't encounter :-\

ps. please don't quote when mailing to the bugtracker. thanks.

Yeh, sorry about the quotes. I could try it if you sent me a patch to fit
current Kubuntu sources (4.7.4).. I am sorry I am so picky, but it would
take a long time to explain...

Created attachment 68592 [details]
patch against 4.8, should still apply on 4.7 though (with some hunks)

patch against 4.8, should still apply on 4.7 though (with some hunks)

Notice: that this only deals with the major issue on NEW shadows (ie. all for bespin, popups but NOT decorations for oxygen)
Also Notice: that remaining minor glitches are expectable due to the layout of the texture and resulting interpolation errors.

I got the sources of kubuntu kwin package, and it does not build :(  With patch as well as without it :(

if anyone is willing to look at it, here is the session command log: http://paste.ubuntu.com/833658

The particular error is here:

$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
CMake Error at CMakeLists.txt:34 (macro_log_feature):
  Unknown CMake command "macro_log_feature".
-- Configuring incomplete, errors occurred!

I have tried a solution proposed here http://forum.kde.org/viewtopic.php?f=44&t=91782 , and a it did not work. I have also tried to compile the unpatched version (I mean, without the Kubuntu patches, that are automatically applied at apt-get source ...), but it ends with the same error. 

I know this might be distro-specific, sorry if that is the case.

Ooops, sorry, I was wrong, I ignored the last line of the suggestion that I said „did not work“ : "Also, the cmake error I got is irrelevant - you should build the sources from a top directory (in this case, kdelibs)."

So it seems to build now...

By the way, the patch applied with these messages: 
dg@pieva:~/tmp/kde-workspace-4.7.4$ patch -p1 < fix_NPOT_shadows.diff
patching file kwin/scene_opengl.cpp
Hunk #1 succeeded at 1574 (offset -21 lines).
Hunk #2 succeeded at 1702 (offset -21 lines).

Hey, after hours of compiling (I had to recompile the whole kde-workspace, did not work otherwise) it worked! Shadows before the patch: http://wstaw.org/m/2012/02/08/shadows-before-patch.png Shadows after the patch: http://wstaw.org/m/2012/02/08/shadows-after-patch.png

And here is the kubuntu 11.10 package patched with the current patch, should anyone be interested to try on their version of the hardware: http://dg.lapas.info/share/kde-window-manager_4.7.4-0ubuntu0.1_i386.deb

Thank you a lot Thomas!

here's a better patch but currently i need to figure out why
a) the shadow texture is packed this way in the first place
b) the texture format isn't set to GL_TEXTURE_RECTANGLE_ARB (in case NPOT isn't supported but that format is)

Also see updates on bug 293325

And thanks everyone for testing! =)

Hey Thomas,

you usually only get the complaints.
Let's change that: Good work.
Thanks for putting up with this work. Really appreciated.

Cheers,
Ingo

Git commit 7355a9ad14e24ca1eb4088430950bc88f03fb4de by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'KDE/4.8'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 293325, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/7355a9ad14e24ca1eb4088430950bc88f03fb4de

Git commit 4281fd09be344bfa99b0450eae384b49b55db152 by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'master'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 293325, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152

That should have been a ccbug ... raster + decoration possibly still an outstanding issue. Might be resolved when the oxygen deco changes to the new shadow system (supposingly 4.9)

If the fix in comment #48 is the same patch in another thread that I tried (as described in https://bugs.kde.org/show_bug.cgi?id=293325#c25) then yes, raster+decoration is still an isue.

The patch
  https://bugs.kde.org/attachment.cgi?id=68592
fixes oxygen-theme related video artifacts nicely, without regressions.

The patch
http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152
also fixes oxygen-theme related video artifacts, but results in new video glitches (at least in the firefox), and frequent random system hangs (requiring a reboot) when child popups are started. So this patch is not usable.

Neither of these patches fixes the graphicssystem=raster artifacts.

(In reply to comment #51)

> http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152
> but results in new video glitches (at least in the firefox)
of what kind?

> and frequent random system hangs (requiring
> a reboot) when child popups are started.
Since the difference is only where in the texture what pixmap is deposited:
- How do you determine this?
- sure it requires a *reboot*? Suspending the compositor isn't sufficient? (shift+alt+f12)
Can you still switch to VT1 (ctrl+alt+f1, first ensure that this works in general and wasn't deactivated by your distro)
If you can move to VT1 during such "hang", please log in there, gdb attach to the kwin process and fetch a backtrace. You can pipe gdb through tee to dump the output. Please attach that.

in kwin/libkwineffects/kwinglutils.cpp:184
please try adding

Q_ASSERT((n>1 && last > 4) || last > 5);

could be that the different texture layout creates textures < 64x64 and your GPU/driver doesn't like that.

In case that happens you'll get a crash. To avoid that and try a fix instead

if (n > 1)
    return 1 << (qMax(last,5) + 1);
return 1 << qMax(last,6);

(In reply to comment #52)
> (In reply to comment #51)
> 
> > http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152
> > but results in new video glitches (at least in the firefox)
> of what kind?
>

I'll post some screenshots as soon as I can, as its hard to describe.
  
> > and frequent random system hangs (requiring
> > a reboot) when child popups are started.
> Since the difference is only where in the texture what pixmap is deposited:
> - How do you determine this?
> - sure it requires a *reboot*? Suspending the compositor isn't sufficient?
> (shift+alt+f12)
> Can you still switch to VT1 (ctrl+alt+f1, first ensure that this works in
> general and wasn't deactivated by your distro)
> If you can move to VT1 during such "hang", please log in there, gdb attach to
> the kwin process and fetch a backtrace. You can pipe gdb through tee to dump
> the output. Please attach that.

Its pretty much a 'hard hang': cannot switch vts, cannot logout, can't even remotely log in, no response to keynboard, etc; simply have to powerdown..

(In reply to comment #53)
> in kwin/libkwineffects/kwinglutils.cpp:184
> please try adding
> 
> Q_ASSERT((n>1 && last > 4) || last > 5);
> 
and try this after trying the mod below

> could be that the different texture layout creates textures < 64x64 and your
> GPU/driver doesn't like that.
> 
> In case that happens you'll get a crash. To avoid that and try a fix instead
> 
> if (n > 1)
>     return 1 << (qMax(last,5) + 1);
> return 1 << qMax(last,6);

I'll try this first

Created attachment 68664 [details]
attempt to fix NPOT of the decoration

probably the exact same issue, only that the deco textures are created out of the pixmap in the native case (and the scaling only hits otherwise)

please try attached patch, and still pending: use GL_TEXTURE_RECTANGLE_ARB if supported but not NPOT

(In reply to comment #56)
> Created an attachment (id=68664) [details]
> attempt to fix NPOT of the decoration
> 
I'll also try this patch

> probably the exact same issue, only that the deco textures are created out of
> the pixmap in the native case (and the scaling only hits otherwise)
> 
> please try attached patch, and still pending: use GL_TEXTURE_RECTANGLE_ARB if
> supported but not NPOT

Forgive me, but not sure what you mean here w/GL_TEXTURE_RECTANGLE_ARB .. is this and env var ?

(In reply to comment #55)

> > if (n > 1)
> >     return 1 << (qMax(last,5) + 1);
> > return 1 << qMax(last,6);
> 
> I'll try this first

Fair enough, btw. what GPU are we talking about and does it actually have
glxinfo | grep GL_ARB_texture_rectangle

(In reply to comment #57)
> Forgive me, but not sure what you mean here w/GL_TEXTURE_RECTANGLE_ARB .. is
> this and env var ?
No, a texture format that doesn't require textures to be POT (power of two dimensions) but predates and is rather inferior to the "legal" NPOT textures.
If supported and used when loading the texture, this would skip the prescaling to POT dimensions (thus those offset issues) but also break eg. clamping.

Since it's however also used by the GL_texture_from_pixmap conversion, that's actually no argument (as least as that the format is probably slower than POT textures)

If you've support i'll pass you another patch attempt.

(In reply to comment #58)
> (In reply to comment #55)
> 
> > > if (n > 1)
> > >     return 1 << (qMax(last,5) + 1);
> > > return 1 << qMax(last,6);
> > 
> > I'll try this first
> 
> Fair enough, btw. what GPU are we talking about and does it actually have
> glxinfo | grep GL_ARB_texture_rectangle
>

SW: linux-3.2.5, kde-4.8, Qt-4.8, xorg-server.1.11.4, mesa-8.0, libdrm-3.4.31

GPU: Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

$ glxinfo | grep GL_ARB_texture_rectangle
    GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle,

The issue also happens on pc with GPU:
VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA controller])

> (In reply to comment #57)
> > Forgive me, but not sure what you mean here w/GL_TEXTURE_RECTANGLE_ARB .. is
> > this and env var ?
> No, a texture format that doesn't require textures to be POT (power of two
> dimensions) but predates and is rather inferior to the "legal" NPOT textures.
> If supported and used when loading the texture, this would skip the prescaling
> to POT dimensions (thus those offset issues) but also break eg. clamping.
> 
> Since it's however also used by the GL_texture_from_pixmap conversion, that's
> actually no argument (as least as that the format is probably slower than POT
> textures)
> 
> If you've support i'll pass you another patch attempt.

-----------------
Yea! Great work. This is the fix:
  https://bugs.kde.org/attachment.cgi?id=68664

So, the patch
  http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152
plus
  https://bugs.kde.org/attachment.cgi?id=68664

appears to fix everything. I also tried with and without both changes in Comment #53, and they have no obvious effect.

At this point, I think I'll do a clean build with the two patches above and only post back here if any issues occur later

Thanks very very much for this work.

So -sorry, but- is there a remaining kernel halt issue or wasn't that reproducable anymore? (that could be slight important ;-)

(In reply to comment #60)
> So -sorry, but- is there a remaining kernel halt issue or wasn't that
> reproducable anymore? (that could be slight important ;-)

I guess you mean the hangs I mentioned.. nope, with the above two patches I haven't been able to reproduce them. Looks really good; have done a clean build and tested on the following GPUs which had the problems:
 
VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]

VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)

VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

and all look really good now. So, at least for me (and hopefully everyone) it appears to be fully fixed.

If you have any updated/improved versions of the patch(es), or additional patches for similar/other issues feel free to send 'em my way, and, time permitting, I can pretty quickly test them as I build all sw on my systems and keep trees around to save time.

Git commit 40b06e71fa6f770c373395dc8a43c039fdda3301 by Thomas Lübking.
Committed on 10/02/2012 at 16:49.
Pushed by luebking into branch 'KDE/4.8'.

fix NPOT + raster decoration

M  +2    -2    kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/40b06e71fa6f770c373395dc8a43c039fdda3301

*** Bug 294189 has been marked as a duplicate of this bug. ***

GREAT ! thanks very much !

somebody knows, when will the patch be included in the binary packages? (i.e. Release repository of openSUSE 12.1 ?) or is there a known repository which includes the patch ?

The patch will be in 4.8.1 unless your distro does a backport before.
You best ask there, nobody knows better than your distro packagers ;-)

Does someone like to explain to me, how i can apply this patch and/or fix from above? i guess, i have to download the sourcepackage, unpack, and do something like this: "patch -p1 < {/path/to/patch/file}" and at last pack and rebuild the source-rpm, right?

> --- Comment #67 from  <flstcboy hotmail com>
> i guess, i have to download the sourcepackage, unpack, and do something
> like this: "patch -p1 < {/path/to/patch/file}" and at last pack and
rebuild the
> source-rpm, right?

Basically - you described the procedure right. I do not know the
particulars of rpm building, though.

*** Bug 298376 has been marked as a duplicate of this bug. ***

*** Bug 283956 has been marked as a duplicate of this bug. ***