When I'm not responding to a new chat (Google jabber) message X raises to
nearly 100% cpu time. This seems to be caused by the notification. When Kopete
is idle everything is fine. I'm running F14 (fully updated, no kde-redhat).
Anyone else experience this?
"KDE PIM 4.6 is due to be released on June 7th alongside the 4.6.4
versions of the rest of the KDE application suite.
In terms of features, we think it is user ready and there have been
many positive reports already from users of development versions. It
is definitely not bug-free however. There are still some problematic
communications with Exchange servers, and some resource usage spikes,
but we are confident that this is overall a step forward. Users will
be able to (mostly) downgrade to KDE PIM 4.4 if the 4.6 version does
not meet expectations, but that is not a long-term solution so good
bug reports will be required for a smoother experience going forward."
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
= Weekly KDE Summary =
Time: 2011-05-03 15:00 UTC
Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-05-03
Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2011-05-03/kde-
Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2011-05-03/kde-
= Participants =
* Kevin Kofler
* Jaroslav Reznik
* Lukas Tinkl
* Than Ngo
* Radek Novacek
= Agenda =
topics to discuss:
* Fedora 15 status
* 4.6.3 status
* bluedevil drags in pulseaudio
= Summary =
Fedora 15 status (jreznik, 15:06:49)
* F15 deadline is very soon (jreznik, 15:13:38)
* kde-plasma-nm is in a relatively good shape except VPN support  (jreznik,
* nm-compat issues - not everything is implemented there, we have to hide some
features in current snapshots (or use older ones + backport) (jreznik, 15:16:09)
* we are going to use knm in F15 with documented known bugs and guide how to use
nm-applet (jreznik, 15:24:16)
* ACTION: jreznik to document VPN issues as known bug (jreznik, 15:26:41)
4.6.3 (jreznik, 15:27:26)
* AGREED: not to push 4.6.3 to F15, release it as 0-day update (jreznik,
* reasons are: kdeedu is still not yet ready, few days for testing and fixing
possible regressions (jreznik, 15:40:49)
* regarding  Kevin_Kofler is going to go with upstream's menu structure as
than suggested (jreznik, 15:47:15)
bluedevil drags in pulseaudio (jreznik, 15:48:18)
* Bluedevils needs pulseaudio-module-bluetooth to support audio features
correctly (jreznik, 16:03:27)
* we consider creating -core subpackage with real functionality and bluedevil
metapackage that pulls required packages (jreznik, 16:05:17)
= Next Meeting =
= Links =
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
Martin Gräßlin wrote:
> This is now a little bit surprising for me as it was a Fedora developer
> who urged me into raising the requirements. In fact I was even asked to
> raise it for the next minor release as a bugfix.
Uh, I never asked you to up the Mesa requirement to 7.10. The minimal change
to check for "Intel" instead of "GEM" in kwinglcheck (which is the patch I
applied in the Fedora 15 kdebase-workspace package) only raises the
requirement to something much lower. I don't know the exact version (we'd have
to check the history), but the Intel driver has been DRI2 for years! And Adam
Jackson (also a Fedora developer) suggested cleaner ways to check whether
direct rendering will work, which (as far as I know) will also work fine on 7.9
and probably several older releases. There's a middle ground between
supporting everything ancient and requiring the very latest.
And by the way, your new check (which assumes that Mesa == DRI2) is also
incorrect for Mesa 7.10 because DRI1 drivers still exist (e.g. i810/i830
legacy). E.g. Fedora 15 still ships them (and it has a Mesa 7.11 snapshot),
only Fedora 16 will drop them. Some distros might keep them for even longer.
That said, we will probably not upgrade Fedora 14 to 4.7 anyway. We have been
doing only one KDE SC upgrade per Fedora release (i.e. offering the latest KDE
SC only on the latest Fedora) since Fedora 12. We may (or may not) be doing
unofficial packages though, and we may end up having to patch your OpenGL
checking code to make them work. :-(
On Sat 30 April 2011 14:36:02 Martin Gräßlin wrote:
> ----- Ursprüngliche Mitteilung -----
> > On Sat, Apr 30, 2011 at 10:23 PM, Martin Gräßlin <mgraesslin(a)kde.org>
> > wrote:
> > > On Saturday 30 April 2011 22:04:12 Ben Cooksley wrote:
> > > > OpenSUSE 11.3 (which KWin claims is insufficient
> > > > in terms of it's Mesa version) isn't even 9 months old.
> > > >
> > > > Please take steps to improve the user experience.
> > >
> > > And here we have a conflict of possibilities. Mesa developers want
> > > us
> > > to drop support for older drivers so that we can have a more secure
> > > way of checking the capabilities without getting broken by the
> > > drivers
> > > if they do changes. Now you ask us to improve the user experience by
> > > again relying on possibly broken checks. We cannot support old and
> > > modern drivers at the same time - at least it looks like that.
> > Note that I didn't ask for support for Mesa 7.9 or earlier. What I
> > asked for is that your configuration ui makes it explicit that
> > Compositing is unavailable due to Mesa being too old.
> KWin has never provided information like that for cases like software
> rasterizer being used or crashers when activating KWin. In fact compositing
> is in all such cases possible through XRender. Some issues like e.g.
> Software Rasterizer being used or Mesa being outdated can only be
> discovered when actually using the driver and is by that not available to
> the config module.
> Kwin could show a notification which does not help as the user would never
> be able to see it. And as explained in my previous mail users will not hit
> the problem: all modern distributions ship mesa 7.10 and we will
> communicate in the release note and also to the distributions that KWin
> requires Mesa 7.10.
Hmmm, that's unfortunate. Fedora 14 won't get kde-workspace 4.7 then, it looks
like, since it's stuck on mesa 7.9 for the forseeable future. :( Six months !=
modern, I suppose...?
> > The only reason
> > I knew is because I grepped ~/.xsession-errors.
> Which is totally fine as you are an experienced user.
> > I know people do in-place upgrades of their KDE installations - they
> > will run right into this.
> They won't. Either they are experienced and compile by themselves or use
> distro packages which will know about the increased requirement.
> > > No current distribution is shipping less than Mesa 7.10 and the
> > > change
> > > is for KWin 4.7 which will be only used by either current
> > > distributions or the next distribution releases, e.g. OpenSUSE 12.0.
> > >
> > > I am sorry to say that we are not able to fullfill your wish. It is
> > > unlikely that a "user" will face such an issue. We will clearly
> > > communicate in our release notes that KWin 4.7 will require Mesa
> > > 7.10.
> > > A developer has no problem with lack of notification as we print out
> > > a
> > > debug statement.
> > >
> > > Cheers
> > > Martin
> > Regards,
> > Ben
> Plasma-devel mailing list
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
I have the same problem as previously described, with extras...
I use a laptop with a dock. Under the previous edition of Fedora (11)
I could put the laptop in the dock with the lid shut, turn it on, and
the display attached to the dock would be detected and show as a clone
of the laptop screen with the laptop screen's resolution. I could
then set the screen res via an xrandr command and all was well.
Now the non-X detects the screen but it's gone as soon as X fires up,
which is clearly the same problem as discussed here. I have to have
the laptop lid open, set everything manually and then close the lid,
with a 1 in 3 chance of both screens going black and me having to
powercycle the box.
I've looked at the posts and bug reports but can't work out how to fix
my problem from them.
There are no StartupCommand lines anywhere in my config dir I can
find. Should I make some, and if so what? I want the dock screen to
be enabled, but the choice as to whether to set resolution as I may
use the laptop without the dock. I prefer the dock screen to be a
clone of the laptop one, not off to one side.
The krandrrc says this, even when VGA1 is disabled in the system
So I want the VGA1 screen to be enabled on X start, but to have the
resolution the same until I manually set it with /usr/bin/xrandr
--output VGA1 --mode 1680x1050_60.00
For some months (if not years) some action of mine -
maybe moving the cursor near an edge of the screen -
causes the window to be minimized,
and I have to press the Restore button in the top right corner
to get things back where they were.
This is particularly annoying when playing KPatience,
when the card one is clicking suddenly moves to the other end
of the screen.
Is there any way of avoiding this misbehaviour?