KWin does not generate window shadows for VLC
Duncan
1i5t5.duncan at cox.net
Sun Aug 1 14:50:18 BST 2010
Nikos Chantziaras posted on Fri, 30 Jul 2010 23:49:36 +0300 as excerpted:
> On 07/30/2010 01:05 AM, Duncan wrote:
>> Nikos Chantziaras posted on Wed, 28 Jul 2010 21:57:18 +0300 as
>> excerpted:
>>
>>> When using VLC with a skin, KWin doesn't drop a shadow under the
>>> window. VLC bypasses the window manager it seems, so even though it's
>>> actually a (frameless) window, it's not handled as such. Is there a
>>> way around that?
>>[...]
>
>> Meanwhile, what sort of video playback display are you using, and on
>> what hardware?
>
> Xv on a Radeon HD4870 using xf86-video-ati with kernel 2.6.35_rc6, UMS.
> The driver supports Xv very well. Everything seems to work OK,
> including VSync.
Xv is X-video (thus the Xv) overlay mode. So everything I said about
overlay applies. Note that with the r6xx/7xx (including both your hd4870
and my hd4650), I believe that the video-overlay *is* implemented via
OpenGL textures. See the radeon manpage. (If you have xvattr merged,
it's a quick merge of maybe a minute, you can see what it says. Here, I
get "Radeon Textured Video".)
Which is really interesting. See below.
>> Finally, what other players have you tried? Just putting a word in for
>> smplayer, with its many features found lacking in kde's default
>> dragonplayer, or the built-in player kparts in
>> dolphin/gwenview/konqueror.
>
> I'm using SMPlayer mainly, but I've come across some missing features
> (like the inability of mplayer to bring silent and loud parts of DTS and
> AC3 audio closer together, like PowerDVD on Windows is able to do) and
> so I thought I'll try VLC and see if it does better.
>
> I'm on Gentoo too btw, so I know mplayer isn't crippled.
FWIW, I run the Linux mainline git tree, tho I make it a point not to
build from head during the merge window, and preferably not until rc2 or
so. I run the git tree as I often do find and report bugs (via the kernel
bugzilla, I haven't tried drinking directly from the firehose of LKML),
and git-bisect to pin it to the commit, so I often do end up actually
building merge-window kernels, but some days after the fact, and I
generally ask if there's anything I should be aware of first, as I recall
one series where, for instance, reiserfs (which I run) had some screwups
if the wrong point was sampled in the merge window.
Anyway, 2.6.35-rc6-19-g86c65a7, ATM, so 19 commits after the rc6 you
mentioned you reported. xf86-video-ati-6.13.1, xorg-server-1.8.2,
libdrm-2.4.21-r1, mesa-7.8.2 (some of those are x11 overlay).
One difference: You mentioned that you run UMS. I run KMS and there's no
looking back, for me. =:^)
Of interest, gcc-4.5, with an emerge --emptytree @world afterward, so
everything's built with it. Always --newuse updates, revdep-rebuild and
emerge --depclean afterward. --as-needed in LDFLAGs, and lafilefixer run
as a post-install hook as flameyes recommended on his blog.
The reason I'm getting so detailed is that I've discovered a bug,
apparently xorg, that I'd like you to check as well, given that you're
system is quite similar to mine.
I've not tried with other video players yet, but with smplayer (0.6.9,
mplayer-1.0_rc4_p20100612), if I have video output set to any of the gl
choices, I can play exactly one video. When I try playing the second, or
replay the first (including auto-repeat), xorg immediately crashes and I
end up back at a text terminal prompt! It's entirely reproduceable,
happening ONLY if the video output is set to one of the gl options (so NOT
if it's set to Xv, x11, or "matrixview", the three that otherwise seem to
work).
This is why the bit above is so interesting. The Xv overlay is textured
OpenGL implemented, yet doesn't suffer the same bug. Also of interest,
the GL works fine for the first video... so it's gotta be a bug in
reinitialization, to play the second.
I had installed the xorg-server 1.8.2 rcs, (1.8.1.901 and .902), but
didn't notice the bug immediately, as I don't play multiple videos in a
row too often, or at least I apparently didn't during the rc2 period. But
I caught the bug right about time 1.8.2 release was available, installed
it, and still had the problem. I then retested earlier versions from
binpkg. The bug appears in .902 (which was identical source to 1.8.2 full
release, there was no change after the second rc, beyond the version bump
itself), but not in .901, so it was apparently added AFTER the first rc.
An additional complication is that I installed gcc 4.5 about the same
time, but I've now verified that with the rest of the system held stable
as built with gcc-4.5.0, the bug appears with xorg-server-1.8.2 regardless
of whether it was built with gcc-4.5.0 or 4.4.4-r1, as well as with
1.8.1.902 (from binpkg, IDR which gcc it was built with), but NOT with
1.8.1.901 (from binpkg, built with 4.4.4 before -r1).
So either the bug is in xorg-server itself, introduced between 1.8.2-rc1
(.901) and rc2 (.902), or it's in something else, but is only /triggered/
with rc2 and the full release.
So you have a very similar 2.6.35-rc6 kernel, also run smplayer on kde4 on
Gentoo, also have a Radeon r7xx series card, and are also running the
freedomware xf86-video-ati driver. IIRC you're also on ~amd64. But you
run UMS while I run KMS, and your graphics hardware is a bit higher end.
What I don't know is whether you're running the x11 overlay and are thus
up with me on the packages there, or perhaps even running the -9999 live
versions. It's also possible you're running DRI project drm instead of in-
mainline-kernel. There's also the question of what gcc you're running, as
well as the versions of mplayer and smplayer. Oh, BTW, I run keyword **
(accept anything) binutils, too, so am currently running 2.20.51.0.10,
used to rebuild the system when I did so after gcc 4.5.0, and you're
probably not running beyond 2.20.1-r1, keyworded amd64 (stable), as
nothing is keyworded at all, beyond that.
So the question is, does setting smplayer output to any of the gl choices,
and trying to play two videos, crash X for you, or not? And what are your
comparable versions for the packages listed, that I don't know yet?
Meanwhile, I guess this gives me a good excuse to see what VLC is all
about. That'll give me a non-mplayer based player to test with. And I
can try newer kaffeine, too. But that'll have to wait, as I have an hour
to sleep now before I get up for church. At least they have breakfast and
coffee, as I expect I'll need it, today...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list