May 2014 - openSUSE KDE - openSUSE Mailing Lists

[opensuse-kde] !(qt)*mobil*
by Felix Miata 02 May '14

02 May '14

Fedora and Rawhide had a required-by-kde[-workspace|libs|-runtime|-&] package qt-mobility that Rawhide just split into 15 sub-packages in order that components only laptops ever use would be dependencies of KDE generally. Factory has no package by that/those names. What provides what in Fedora it/they do in openSUSE, libimobiledevice4? If only one package by whatever name, is there a similar divorce of of non-essential features (bloat reduction) contemplated for KDE4 in openSUSE? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

2 1

[opensuse-kde] KDE update, some observations
by stakanov＠freenet.de 02 May '14

02 May '14

New search machine: is there any way to see it's settings or is it thought to be all automagical. After an update from 4.12.4 to 4.13.1 I have noticed the following regressions and bugs: Kmail: does not honour the settings for "events" and "special dates" any more. This seems a regression that comes in now every second release. A pity because I use it a lot to not forget the dates. So in the summary even if selected, there are no birthdays shown. But events of the calendar i.e. Eastern are shown correctly. Import function of notes: looses all the notes and imported nothing. Not a big issue for me as they where "loosable" but still, who uses it and does not find his notes afterwards..... Filters in Kmail did not work correctly before and after the update. But who needs filtering when s(he) has a search function, right? Still it would be nice to have this fixed before "Plasma next". What is positive however, is, that with 12.4 there was a regression of the "filter amnesia bug" that now has vanished again as it seems. So at least filter rules are just "not applied instead of vanishing or of putting mail randomly in some locker. Good. What is good: the network-management and the functionality of it are finally usable, nice and easy even for non Linux users. The choices of being able to show or unshow Mac address etc. and other features are IMO useful. VPN presence and connection status are now shown throughout all personalities which is safe. Thank you for that. All the other things seem to run well for now. If anybody shares the problem with the calendar dates I will file a bug-report. If there is an easy solution (like a setting "hidden under sub-menu 233") then thank you for sharing. Cheers. PS: if you have a certain "media-plasmoid" installed, this one holds nepomuk packages. So it has to be eliminated as apparently it has a nepomuk requirement. --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

16 85

[opensuse-kde]
by Sam M 02 May '14

02 May '14

>You are making a false assumption. In response to your senseless diatribe, no, I am not making a false assumption. Are you familiar with the word extrapolate? So what, if only a limited amount of people have added the Current repo. It's obvious that you heed feedback from the limited user base that is using the software, and make changes to it as necessary. Your start going off about your presumption of how many people you think are using KDE with openSUSE, and that is completely irrelevant to the topic. Do the search for bugs on kde.org, not Novell's Bugzilla, and you'll find user gripes. Look on the Baloo developer's blog, and there are complaints. Look on the openSUSE forum, and there are complaints. Look on the Arch forum, and there are multiple threads of complaints. Many users know to file reports with KDE, not with Novell. And of that estimation that you pulled out your rear end, not everybody speaks English, has the time to write about Baloo, knows it even exists, or gives a rat's ass about it. Your silly childless over the assuredness which you exhibit that only a few people on the mailing list means nothing just shows how pointless it is to continue to have any future dilogue with KDE or openSUSE developers. It's not a community project; it's a project where developers see things fit a specific way, and you're going to stonewall anybody else that is pointing out a serious design problem. Do you think i am going to worry about it? No, I'm not. I'll go to a different desktop environment, and everybody else gets to see all of your childish and elitist attitudes. >Perhaps in the overall ecosystem of all distributions, there is a higher >number of folks complaining about baloo, but I'm only concerned about >openSUSE, as this is the openSUSE-KDE mailing list. Ding ding ding!!! We have a winner! >So please,check your egos at the door. It's not that we don't care, it's >because you don't matter, and frankly, I'm getting pretty bloody tired of this >thread. Take a look in the mirror, and if you're getting tired of it, don't read it. And if you are going to reply, you may as well attempt to try to help the situation, not act like a 9 year old little girl. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

5 5

[opensuse-kde] Issues with Baloo and all that
by Jos Poortvliet 02 May '14

02 May '14

Heya, I see quite a bit if misconceptions around the new search infrastructure in KDE. I would strongly suggest you read this article: http://dot.kde.org/2014/02/24/kdes-next-generation-semantic-search And this where we asked for help in testing: http://dot.kde.org/2014/03/12/applications-413-coming-soon-help-us-test I put in a lot of time to write both articles, create liveCD's so you could help test, ask people for testing etcetera. Now it seems some issues were not caught by testing. If you did test and filed a grave bug but it did not get fixed, you can complain about release management and you have every right to be taken very serious. You put in work, after all. If you did not help test but you found a problem, well, I understand. You might not have had time to help. Then, file a bug now, we will fix it asap. But don't waste your and our time complaining about how OTHER PEOPLE did not do enough testing: if YOU want to make sure YOUR features work, then TEST YOURSELF. If you had no time, then accept that we can't test everything. And we can't delay a release forever, waiting for others (you?) to finally decide they have time to test it. If it works for us and everybody who has tested it, we release it. Simple as that. Sorry, that is reality with volunteer work that you are NOT paying for. Then. Some of you complain this should not have been turned of by default, or it should be more plugin-based and easier to install. First about the turned-on-by-default: Search is on by default in Windows, Mac OS X, Android, iOS and even GNOME. With the improvements to search (see article above) we felt confident we solved the issues for 95% of our users and were able to follow into the 21st century. I tested baloo extensively and all the issues I had were fixed by Vishesh (its main developer) before the release. There is only so much we can do, especially without help from all of you. Meanwhile, it works for most users, so sorry that you're part of the small group it does NOT work for: if you had time to test, that could have been avoided. Now you didn't, that is fair, but realize that we can't do anything about you not having time to help us test. So don't blame us. About the 'I want to uninstall it; it should be a plugin; etc'. Funny thing is: Baloo and Akonadi are exactly what you want: modular and because of that, very complex. That is why they have been so problematic for so long: it is very hard to get such a flexible, plugin based technology stable and performant. Actually, Baloo is a lot less flexible than nepomuk was, that is why the new KDE Semantic Search is so much faster and more stable: we took away flexibility. Making everything runtime/plugin based increases complexity. If you want it simple, fast and stable (but not flexible and everything hard coded) use GNOME. Or accept that it takes a bit longer and that it takes more testing (did you help test?) to get it right the way KDE is doing it. About the KNotes issue: the developers rewrote that part because they could no longer maintain the old version. The choice was between rewriting it to make use of common infrastructure, or just removing it. The rewrite looses some functionality, and it clearly has a bug: not always importing all notes properly. This WAS tested and it worked for the developers and at least the people who tested, so I guess some here are just unlucky. Or did not help test. Again, the same: if you would have helped test, the importing would have been more robust. You had no time, that is fair, but then accept that we don't get paid to test or can't pay people to test, so this is all we could do. We would love to get 10 extra, paid developers and 100 paid testers. This would probably then not happen... Of course, if you think we made the wrong choice and should simply have dropped KNotes, you can always simply remove it and accept that we did not have enough volunteers to maintain the old version. That, too, sucks and you can blame a random person (just pick a colleague next to you in the office for example) for not stepping up and maintaining KNotes. Or be happy that somebody at least did the work they did to keep it around and will hopefully add the functionality you are missing... Again, I'm sorry for the issues. So are other KDE developers. But we can't change the world as it is and yelling at us doesn't help. On the contrary, it does the opposite: there is little reason to put in your free time when people just yell at you for doing something for them for free. If you have questions, ask. If you think I'm crazy, fair enough. But if you comment, at least be reasonable and realistic. We can't bend reality so don't expect us to. And be fair and put in some effort to understand what we do and why before you start complaining. As a wise man once said: a fool can ask more questions than the wisest man on earth can answer. Don't be a fool. The world has enough of those. Cheers, Jos -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

13 38

Re: [opensuse-kde]
by Shawn W Dunn 02 May '14

02 May '14

On Thursday, May 01, 2014 11:24:28 Sam M wrote: > >You are making a false assumption. > > In response to your senseless diatribe, no, I am not making a false > assumption. Are you familiar with the word extrapolate? So what, if > only a limited amount of people have added the Current repo. It's > obvious that you heed feedback from the limited user base that is > using the software, and make changes to it as necessary. Your start > going off about your presumption of how many people you think are > using KDE with openSUSE, and that is completely irrelevant to the > topic. Do the search for bugs on kde.org, not Novell's Bugzilla, and > you'll find user gripes. Look on the Baloo developer's blog, and there > are complaints. Look on the openSUSE forum, and there are complaints. > Look on the Arch forum, and there are multiple threads of complaints. > Many users know to file reports with KDE, not with Novell. > > And of that estimation that you pulled out your rear end, not > everybody speaks English, has the time to write about Baloo, knows it > even exists, or gives a rat's ass about it. Your silly childless over > the assuredness which you exhibit that only a few people on the > mailing list means nothing just shows how pointless it is to continue > to have any future dilogue with KDE or openSUSE developers. It's not a > community project; it's a project where developers see things fit a > specific way, and you're going to stonewall anybody else that is > pointing out a serious design problem. Do you think i am going to > worry about it? No, I'm not. I'll go to a different desktop > environment, and everybody else gets to see all of your childish and > elitist attitudes. Good riddance. Your kind of help, *I* personally, do not need. > > >Perhaps in the overall ecosystem of all distributions, there is a higher > >number of folks complaining about baloo, but I'm only concerned about > >openSUSE, as this is the openSUSE-KDE mailing list. > > Ding ding ding!!! We have a winner! > > >So please,check your egos at the door. It's not that we don't care, it's > >because you don't matter, and frankly, I'm getting pretty bloody tired of > >this thread. > > Take a look in the mirror, and if you're getting tired of it, don't > read it. And if you are going to reply, you may as well attempt to try > to help the situation, not act like a 9 year old little girl. > I read it, because I am a developer, and packager, and want to know what's going on. You, and the others have essentially clogged up this mailing list for the past four or five days with a pointless circular argument, and driven the signal:noise ratio through the roof. I look at the upstream bug reports when neccessary. But the Novell bugzilla is my primary concern. What Arch, or Fedora, or Debian, or whoever else is doing with baloo isn't relevant to what I VOLUNTEER my time to work on, you jackwad. You don't like the way baloo works, or was implemented? Start submitting code, or start paying us to make it operate the way you like it to. We make the best decision for the widest number of users we can possibly plan for. And apparently you're not in that group of folks that we planned for, and as I said, statistically insignificant. > On Thu, May 1, 2014 at 11:05 AM, Shawn W Dunn <sfalken(a)opensuse.org> wrote: > > On Thursday, May 01, 2014 10:17:04 Sam M wrote: > >> >A: File indexing can be disabled by adding the users' home folder to the > >> >System Settings -> Desktop Search -> Do not search in these locations > >> >list. > >> > >> The thing is, not everybody is going to read the documentation or know > >> to do this. How hard is it to have a GUI option to turn indexing off? > >> You sound so positive that this foisted feature is wanted on a wide > >> scale, but I'm coming across quite a few threads where people are > >> talking about not liking it. It sounds like there are also quite a few > >> unhappy users over Baloo when searching bug reports. Extrapolate this > >> situation, and you have a lot more people who wouldn't like Baloo if > >> they knew what it was or what it was doing, or you have people that > >> understand its shortcomings and aren't whatsoever involved in forums > >> or any mailing list. > > > > You are making a false assumption. > > > > As of the last "best guess" there are something like 440,000 users of > > openSUSE. KDE is the default desktop. So just for the sake of > > argument, > > lets say that 2/3rds of those installs are running KDE. 440,000 x .66 > > = > > 290,400 users. > > > > Now, how many of those users are tracking KDE:Current, rather than just > > running with the default 4.11.4 from the 13.1 Repos? > > > > I have no idea, but for the sake of argument, as most users never do > > actually change the defaults (a choice, I MIGHT add, that you made, by > > enabling KDE:Current, or KDE:Distro:Factory, or whatever non-base repo > > you decided to enable), lets say 3/4 of that userbase is still using > > defaults, which are still using nepomuk as the indexer. 290,400 x .25 = > > 72,600 Users, that have KDE repositories, other than the default 13.1 > > repos enabled. > > > > So, just as an intellectual exercise, we have 72,600 users that are using > > openSUSE KDE 4.13.x with the baloo indexer at the moment. > > > > Now, going and looking at the openSUSE bugzilla, and doing a simple search > > for "baloo" I find, wow, look at that! Not a single open bug report > > against Baloo. > > https://bugzilla.novell.com/buglist.cgi?quicksearch=baloo. So, we > > have, for the sake of argument, 72,600 Users of baloo, and ZERO bug > > reports, and near as I can tell, Five of you here on the mailing list, > > complaining about baloo, and the way it is implemented. > > > > Five Users is what percentage of 72,600? Well, according to > > percentagecalculator.net, it is 0.0068870523415977955% > > > > Statistically insignificant. > > > > Perhaps in the overall ecosystem of all distributions, there is a higher > > number of folks complaining about baloo, but I'm only concerned about > > openSUSE, as this is the openSUSE-KDE mailing list. > > > > > > So please,check your egos at the door. It's not that we don't care, it's > > because you don't matter, and frankly, I'm getting pretty bloody tired of > > this thread.

2 1

[opensuse-kde]
by Sam M 02 May '14

02 May '14

>A: File indexing can be disabled by adding the users' home folder to the >System Settings -> Desktop Search -> Do not search in these locations list. The thing is, not everybody is going to read the documentation or know to do this. How hard is it to have a GUI option to turn indexing off? You sound so positive that this foisted feature is wanted on a wide scale, but I'm coming across quite a few threads where people are talking about not liking it. It sounds like there are also quite a few unhappy users over Baloo when searching bug reports. Extrapolate this situation, and you have a lot more people who wouldn't like Baloo if they knew what it was or what it was doing, or you have people that understand its shortcomings and aren't whatsoever involved in forums or any mailing list. It sounds like there's a great deal defensiveness going around over not only the functionality of Baloo, but the decision to hold steadfast with it being unremovable, its default options and behavior (opt-out and not opt-in), and not asking the user permission to start indexing upon initial login. This whole situation with adding the $HOME folder to turn indexing sounds to me like putting a key in a lock, turning it, and the deadbolt goes the opposite way. It makes no sense to me. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

6 5

[opensuse-kde] Surviving kit for baloofile
by Bruno Friedmann 01 May '14

01 May '14

Just to help those who want to understand ( didn't see what Jos have renewed on kde doc pages yet) For those who want to adjust what baloofile index or not. We just don't have any more a nice gui to setup what we want to index or not but all functionality are there. check your ~/.kde4/share/config/baloofilerc file Mine look like this one ( I'm adding comments too starting by ==> ) [Basic Settings] Indexing-Enabled=true ==> Mean you don't want file index put false [General] exclude filters=autom4te,*.rcore,CTestTestfile.cmake,*.o,*.omf,.hg,*.m4,*.orig,.obj,moc_*.cpp,conftest,.pch,.xsession-errors*,CMakeTmpQmake,*.tmp,qrc_*.cpp,po,.svn,.histfile.*,lzo,.bzr,.git,litmain.sh,cmake_install.cmake,CMakeFiles,*.pc,*.nvram,*.elc,*.la,.moc,CMakeCache.txt,confdefs.h,*.gmo,*.csproj,*.rej,config.status,lost+found,confstat,*.pyc,_darcs,CVS,.uic,*.part,libtool,*.aux,*.po,CMakeTmp,Makefile.am,*.lo,ui_*.h,*.loT,*~,*.moc,*.vm*,*.class,core-dumps,core,*.tar.bz2,*.7z,*.tar.xz ==> you could put whatever is sensible to you exclude filters version=2 exclude folders[$e]=/media/src/,/var/,/tmp/,/ioda.nfs/,/proc/,/run/,/sys/,/sigeom/cw3dev/,/media/storage/,/media/multimedia/,/media/backup1t/,$HOME/logs/ ==> want to exclude certain directories, here you go simple as that. exclude mimetypes= ==> Don't want to index video mimetypes etc this is for you first run=false ==> Don't touch this one, or only when you clean up everything and want to restart from scratch folders[$e]=/media/lvmultimedia/,/sigeom/,$HOME/ ==> What to index list ... in my case /sigeom is a shared folder like multimedia ... All of that has been determined during the beta/rc testing Any volunteers to create a nice qml configuration tools? ps0: to Jos, thanks man, I'll appreciate the hard work done, managing the thread(s). ps1: to opensuse-kde maintainers, thanks again for your excellent packaging, I've just finished upgrading 3 computers for 5 users and was really simple. Mine was using kdf and then need the traditional zypper hunt to downgrade packaged due to build number being < -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

2 2

Re: [opensuse-kde] KDE update, some observations
by Vojtěch Zeisek 01 May '14

01 May '14

Hello, thank You for all the information and patience. :-) Dne Čt 1. května 2014 16:38:27 jste napsal(a): > On Thursday 01 May 2014 12:26:12 Vojtěch Zeisek wrote: > > Dne Čt 1. května 2014 12:07:51, Jos Poortvliet napsal(a): > > > On Monday 28 April 2014 05:22:25 Sam M wrote: > > > The vast majority of computer users uses search. Sorry if that hasn't > > > landed for some, but you ARE the exception. Win, Mac, Linux (yes, GNOME > > > has it, too) all use that. 99% of computers can handle it just fine. > > > Baloo indexes ~1000 times faster than Nepomuk and uses ~20 times less > > > memory, putting it on par with the Mac, Windows and other Linux > > > solutions. No reason to not enable it by default, thus. And those few > > > who don't want it can disable it. > > > > From my experience, its performance is much worst than of Nepomuk... And > > it > > seems I'm not the only one. There are some bug reports about that. > > If you've read > http://dot.kde.org/2014/02/24/kdes-next-generation-semantic-search > you see that Baloo is much faster for everybody who ever gave feedback to > the developers - by a factor 1000 and more. It can index gigabytes of data > in a few minutes, emails go by the hundreds per seconds (Nepomuk could > index 5 emails/second after YEARS of optimizations). I still wonder, why destroy one system when it is already matured and working, but I can understand architectonial advances of Baloo and other arguments. It just looks for me as sort of wasting of energy... > Now it is so fast that it sometimes overwhelms the Linux kernel with I/O > requests. This is something that heavily depends on your storage setup - > SSD's, drives, how many, how they are partitioned, filesystem. Also on the > kernel versions. We've introduced a few patches to slow Baloo down a little > bit so that should help a lot. OK, we'll see. > A related problem could be that there are files which are difficult or > impossible to index. These are automatically identified by Search and then > put in a 'ignore' list but the detection process is unfortunately slow. The > initial version took at most 30 minutes per file, usually more like 15. A > recent patch (should now be in the openSUSE packages) should shorten that to > about 10 max, usually 5 minutes and it should stop trying when you take the > powerplug out on a laptop. > > You can find this and more information on > http://userbase.kde.org/Nepomuk > > > > Yes, baloo generates quite a bit of I/O, they've added a patch to > > > throttle > > > that now, I believe. It is actually a kernel issue (anything before 3.14 > > > can not deal well with high I/O). This I/O problem shouldn't take long > > > as Search indexes very fast - thousands of files per second. > > > > This „bit“ means the computer is unusable. It lasted for several days, no > > change to better, so I disabled it. The bug is reported and I'm not the > > only one. I want use desktop search, but for me, latest Nepomuk worked > > fine. > > Again, this is a problem in other parts of the system that we have to work > around. Patches should be in the latest openSUSE packages but we're still > working on more... OK, I hope it will work with also with kernel 3.11... > > > In case it bumps into files which can't be indexed, it will try to > > > determine what file is un-indexable and then disable indexing for that > > > file for the future. Unfortunately, determining what file is hard to > > > index takes a while - about 30 minutes of full cpu and IO at most, per > > > broken file. This has been decreased for 3.14.1 to about 5 minutes at > > > most and will stop/not happen on battery power. > > > > openSUSE 13.1 has kernel 3.11, will it work there? Or do I have to add an > > extra repository for newer kernel? > > > > > Yes, Nepomuk never had this issue because it simply as so slow that it > > > wouldn't eat the entire I/O of a system and I guess the devs use newer > > > kernels that deal with it better so they didn't notice. > > > > > > It's fixed and I think these patches are now in openSUSE Current. > > > > OK, I'll give it one more try... > > > > > > I looked around the internet some, and I found a funny post on the > > > > Kubuntu forum: > > > > > > > > "After a few days baloo settled down on my system but on my wife's > > > > laptop baloo kept going and going for days making it really difficult > > > > to do anything. I found a message that > > > > ~/.kde/share/config/ > > > > baloofilerc has a line in it under [Basic > > > > Settings] Indexing-Enabled=true I changed that to > > > > Indexing-Enabled=false and the laptop was useable again, but lost a > > > > few search items. It's nice when it works but hell when it hogs the > > > > system." > > > > > > > > I love the beginning where he says: "After a few days", and keep in > > > > mind that the 2.5" hard drive on his wife's laptop isn't exactly an > > > > icon for longevity. I can only imagine the wear and tear the first > > > > iteration of Baloo is doing to SSD's. Baloo shouldn't start > > > > automatically the first time a user logs into KDE, but I hate when > > > > OS's ask you questions through a dialogue box when you just want to > > > > get stuff done. I don't have an answer to how this should be done > > > > correctly, but I want to reaffirm that Baloo should _not_ start > > > > indexing anything without the user's permission. They're already > > > > talking about allowing it to be uninstalled by having the Baloo > > > > package be split. I want this, because I want to uninstall it. And if > > > > my supposition is correct, I don't think I'll ever be installing it > > > > again -- not that I don't think it can become better. I just don't > > > > need it. > > > > > > It is easy to disable (add your home folder to the 'do not index' list > > > in > > > the GUI and it disables itself automatically) and as I said before, the > > > vast majority of the computer users on this planet is already used to > > > using search, both on the internet and on their home computers. The fact > > > that you KNOW what it is in the first place makes you an exception (like > > > me, yes). > > > > One problem is performance. Second is total lack of configurability. Of > > course, it is good to optimize it for most of users. But it is not > > possible to meet everyone's needs. So that I (and not only I) consider > > lack of possibility of finer configuration as big problem. > > What kind of configurability are you missing? You can disable indexing your > files or exclude certain folders, at the moment. What else should be > possible? To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist way, but also whitelist way). Again, Nepomuk had it. Also (not)following symlinks and mounted FS. I understand not everyone need such tunning, but I hope those thinks are not so strange... And it is OK to have good defaults, but KDE was always giving a lot of possibilities to configure... All the best, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/

4 4

[opensuse-kde] dual monitor issue after upgrade
by John Quentin Heywood 01 May '14

01 May '14

Hey folks, I am running openSUSE 12.3 and KDE 4.13.0 Since the upgrade to KDE 4.13 from 4.9, I've had issues with my dual monitor setup. I have an ATI Radeon HD 6450, and I am using the latest fglrx64_xpic_SUSE131 driver (14.10.1006-1). When I boot up, the machine is in proper dual monitor format, with the KDM login on one of the monitors. When I login, the splashscreen shows on just that monitor, as it should, until it gets to the point between the first two icons on the splashscreen. That is, after the hard drive icon but before the crossed tools icon (sorry, I know these stages in the login process probably have better names, but I don't know them).. At this point both monitors go blank, and come back, but when they do, they are clones of each other. After login is complete, I start up the AMD Catalyst Control Center using root privileges. The Display Manager shows "Cloned display from displays (1)". When I change that to "Multi-display desktop with displays (1)" and apply it, I have my dual monitors back the way I like them. This lasts until I log out, when it all reverts. This happens with any user, including root and a test user I made new for testing this. I am at a loss. I have looked at my xorg.conf file, and it hasn't changed. The only change I made was upgrading KDE. What have I missed? Is there a setting or a config file I'm overlooking? Any help would be greatly appreciated. John -- John Quentin Heywood heywood(a)american.edu -- To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kde+owner(a)opensuse.org

2 2