On Mon, Nov 26, 2012 at 1:59 PM, Eren <erenogrul(a)gmail.com> wrote: Hi, I did install TDE on 12.2 - following the instructions found on the trinity site - but not on a minimal install. So I'd guess you are missing something. Maybe you could try to install KDE 3 first, then TDE? Thierry

Le 26/11/2012 22:04, Felix Miata a écrit : Hello, I've just tried a virtual machine installed with "minimal X"; Then I installed "trinity-tdebase" (to have a minimal TDE environment). Then configure DISPLAYMANAGER with full path to kdm. DISPLAYMANAGER="/opt/trinity/bin/kdm" it works as expected. Francois

On 2012-11-26 22:44 (GMT+0100) François ANDRIOT composed: I had already minimal installed to Intel/Radeon hardware and added KDE3 on a test machine. Did this. Did this. Not here, though I don't recall if I ever got KDM login manager to work. No login manager appears on runlevel 5 boot. Startx does work, but NAICT, I'm seeing KDE3, not TDE. xorg/x11 installed package list: http://fm.no-ip.com/Tmp/SUSE/122/xpkg-big31-os112.txt kde/trinity installed package list: http://fm.no-ip.com/Tmp/SUSE/122/tdepkg-big31-os122.txt Xorg.0.log: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-big31-os122.txt .xsession-errors: http://fm.no-ip.com/Tmp/Linux/Xorg/xsession-errors-big31-os122.txt -- "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/

Le 27/11/2012 00:36, Patrick Serru a écrit : Hello, the resolution problem is not related to Trinity (or any other desktop environment). At startup, the Xorg server queries the monitor to get all supported resolutions. Then, it sets the display to the maximum supported resolution. Then, you can only switch between maximum and lower resolution from inside Trinity. (you can never use an higner resolution) If 1280x1024 is not available, it means that, for some reason, the autodetection fails. You should inspect your /var/log/Xorg.0.log file to check where it happens. I remember I had an old Hyundai Q17 monitor (17" LCD) which had a firmware bug, it reported 1024x768 as maximum supported resolution, whereas it supported 1280x1024. To get 1280x1024, I had to force 1280x1024 resolution in /etc/X11/xorg.conf file. Check if your distribution has a configuration utility that allows to force the resolution, then use it. E.g, In Mageia control center, I must choose "Generic 1280x1024 Flat panel" (instead of auto-detect), then set resolution to "1280x1024" (instead of auto-detect). Francois

On Mon, Nov 26, 2012 at 10:04 PM, Felix Miata <mrmazda(a)earthlink.net> wrote: Here are the instructions I found (and used) to install via zypper (although I did a standard install with KDE 4 as I may wish to run some KDE apps, even if I don't like the desktop): 1. Configure the supplementary PACKMAN repository Instructions: http://packman.links2linux.org/ 2. Configure the ZYPPER repository (as root user) For OpenSUSE? 12.2 (v3.5.13.1) zypper ar -t YUM -G http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity/rpm/opensuse12.2… -i) trinity zypper ar -t YUM -G http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity/rpm/opensuse12.2… trinity-noarch zypper refresh 3. Install the Trinity desktop environment zypper install trinity-desktop After that I logged out, then in changing the session to TDE, that's all Thierry

Le mardi 27 novembre 2012, Felix Miata a écrit : --------------------------------------------------------------------- Hi all, Sorry about that: first, I disturbed the thread, and second I wrote 1380 instead of 1280! I know that my problem is not related to TDE. I just wanted to point out that testing on virtual system is not necesseraly complete testing. Anyway, I stopped trying distributions. Even if I would be able to fix my display problem by my-self, whichever distribution, that was not the case in a relatively short time, I prefer things that install as for a "lambda" user. Thanks for all, Patrick

On 2012-11-27 13:39 (GMT-0500) Patrick Serru composed: I think everybody has that preference. It's just that developers don't have *your* particular hardware combination to test on, and when the required hardware data is missing or broken, as apparently must be the case for your display's EDID, there's little that can be done unless you participate in the development process and report the problems you encounter before the product is released. -- "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/

Le 27/11/2012 23:16, Felix Miata a écrit : Look at /var/log/kdm.log if it exists. Alas it does not contain many information on my test virtual machine ... You can try /opt/trinity/bin/kdm --help to see options. There is a --nodaemon and a --debug which could help you find out what is happening. Francois

On 2012-11-27 18:08 (GMT-0500) Felix Miata composed: I did some fiddling that produced various other error messages. All today's logs are at: http://fm.no-ip.com/Tmp/SUSE/122/ -- "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/

On 2012-11-27 20:46 (GMT-0500) Patrick Serru composed: It's probably the most common native resolution currently. But, was the Scaleoview T17-2 you're looking at perfect when it left the factory? Is it still perfect? But will they today? That something worked is not proof that it works. IIRC, automatic X configuration was rather young at the time of, and likely not implemented in, openSUSE 11.1. The 11.1 I just booted even has a /etc/X11/XF86Config as a soft link from xorg.conf! The in place backup of its original xorg.conf is timestamped April 2007. What happens when you restart X in 11.1 after removing xorg.conf? When I try X in 11.1 with xorg.conf removed, Xorg.0.log ends with fatal server error \ cannot run in framebuffer mode, even after having correctly identified the gfxchip as Radeon. After restoring xorg.conf, X starts in 1600x1200 according to specification in the xorg.conf file. Most modern distros have automagic X configuration that works in most cases, but not all. Until one tries manual configuration or other hardware, there's no practical way to be sure a particular failure is not some previously unobserved hardware fault. I have found in *every* case tried personally, absent known driver or X bugs applicable to the hardware used, that basic automagic X configuration failure can be worked around through manual configuration. Trying a less than 1Kbyte http://fm.no-ip.com/Share/xorg.conf-minimal-EDID-workaround as a shortcut to manual configuration from scratch is a pretty simple thing to try. It doesn't take much in most cases to work around apparent EDID-related automagic failure. -- "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/

On 2012-11-28 07:05 (GMT+0100) Francois Andriot composed: linux-vdso.so.1 (0x00007fff9077c000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f29cd2e0000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f29cd0dc000) libdbus-tqt-1.so.0 => /opt/trinity/lib64/libdbus-tqt-1.so.0 (0x00007f29cceca000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f29ccc84000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f29cca49000) libpam.so.0 => /lib64/libpam.so.0 (0x00007f29cc83b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f29cc637000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f29cc431000) libc.so.6 => /lib64/libc.so.6 (0x00007f29cc08c000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f29cbe6c000) libtqt.so.4 => /opt/trinity/lib64/libtqt.so.4 (0x00007f29cbc69000) libqt-mt.so.3 => /usr/lib64/libqt-mt.so.3 (0x00007f29cb261000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f29caf5a000) libm.so.6 => /lib64/libm.so.6 (0x00007f29cac63000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f29caa4c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f29ca830000) librt.so.1 => /lib64/librt.so.1 (0x00007f29ca628000) libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f29ca410000) /lib64/ld-linux-x86-64.so.2 (0x00007f29cd61c000) libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f29ca1e7000) libz.so.1 => /lib64/libz.so.1 (0x00007f29c9fd1000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f29c9dc1000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f29c9bb7000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f29c99ae000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f29c97a2000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f29c959f000) libXft.so.2 => /usr/lib64/libXft.so.2 (0x00007f29c9389000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f29c90fc000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f29c8ec5000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f29c8cb3000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f29c8aab000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f29c888f000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f29c8689000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f29c845f000) libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f29c825a000) -- "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/

Le 28/11/2012 07:29, Felix Miata a écrit : Hello, I've just retried my own procedure on an x86_64 opensuse virtual machine, and I confirm it works (at first I was using i586) ... KDM starts, I have no missing symbol. Symbol ZN20KSMModalDialogHeaderC1EP7QWidget is defined in /opt/trinity/lib64/libkdeui.so.4.2.0 , which is part of "tdelibs" package. What did you do differently from the procedure ? You said you use sysvinit instead of systemd, have you installed other software at the same time ? I suspect (never really tried) that TDE 3.5.13 cannot co-exist with KDE3, have you installed KDE3 ? Maybe TDE's kdm is trying to use KDE3's libraries, and that cannot work at all... Some hints: - run "/sbin/ldconfig" then try again . - check that you have no LD_LIBRARY_PATH defined in your environment variables - check that there is no KDE3 related stuff in /etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, and /etc/profile.d/*.sh Please give me your "rpm -qa" output ... Francois

Le 28/11/2012 20:58, Felix Miata a écrit : What does the 'kdelibs3.conf' file contain ? I bet it contains "/opt/kde3/lib64" ... From what I see in your packages, everything you installed from KDE3 exist in TDE (except some Suse-specific artwork packages). Before uninstalling KDE3, you can try a last (dirty) trick: mv /opt/kde3 /opt/kde3.old ldconfig then restart kdm again (or reboot). Francois

Le 28/11/2012 21:59, Felix Miata a écrit : OK this is what I thought. KDE3 conflicts with TDE. Until we find a trick, we cannot use both on the same computer. You can remove "kdeartwork3" and install "trinity-tdeartwork". You can remove "kde3-gtk-qt-engine" and install "trinity-qt-engine". About the 2 other packages, I don't know if they are specific to Suse, specific to KDE3, or both. But they are not needed (and not even used) by Trinity, so they are useless to you. You'd better remove them to avoid other strange side-effects. If you have the "kde3-gtk-qt-engine" installed but not "trinity-gtk-qt-engine", it cannot work correctly. Nice find. It could be a Trinity enhancement, you should fill a bug report for it. Finally I've just installed KDE3 in my virtual machine which already had TDE, and I confirm that I have the exact same missing symbol as you have. FYI, the file /etc/ld.so.conf.d/kdelibs3.conf contains /opt/kde3/lib64 and /opt/kde3/lib . Since "kdelibs3.conf" comes before "trinity.conf" in alphabetical order, the kde3 libraries take precedence over Trinity libraries. I'm glad it finally works for you :-) I hope you will enjoy Trinity. Francois

Le 29/11/2012 02:06, Felix Miata a écrit : The TDE packaging is more "fine grained" than KDE3 packaging. The single "kdeartwork3" package is equivalent to the 11 Trinity packages. So you can selectively uninstall any program you don't want, without uninstalling everything from a package family. Of course I mispelled it :) The package is trinity-gtk-qt-engine, as you found . Ok, I've found that openSUSE use specific configuration files to find which DM to use. Save the attached file as /usr/lib/X11/displaymanagers/tdm . Then set "DISPLAYMANAGER=tdm" in /etc/sysconfig/displaymanager Then, edit file /opt/trinity/share/config/kdm/kdmrc Activate and set variable: PidFile=/var/run/tdm.pid Now starting and shutting down TDM with openSUSE scripts should work. I will make these changes to the next package release. Alas, when stopping TDM, it looks like other processes forked by TDM (tsak ...) are not stopped... It looks like the comments are hardcoded in a template in an openSUSE package: /var/adm/fillup-templates/sysconfig.windowmanager You should fill a bug report on openSUSE bugtracker asking to add 'tde' to the list. (they are likely to refuse, since we are not upstream, and kde3 is absent too) Mmm I have no clue about this. Maybe it's because the Trinity repository is in YUM format ... Good luck with that, it's nice to see people (willing to) use TDE in a larger scale than a single home computer :-) Francois

Le 29/11/2012 22:45, Felix Miata a écrit : Hello, in case you are still looking for it: The script is: /opt/trinity/bin/startkde It is provided by package: trinity-ksmserver Francois

On 2012-11-29 21:54 (GMT-0500) Patrick Serru composed: I lost track of what precipitated your inability to run openSUSE on your display's native 1280x1024, but if you're after getting a Fedora or *buntu release from a similar point in time as when the openSUSE release you tried was released, prepare yourself for the likelihood that you'll encounter the same trouble. What openSUSE, Fedora and *buntu are mostly are packagers, not developers. Releases of different distros at similar points in time are unlikely to have very different Xorg versions packaged in them, along with the same bugs. If you get lucky and don't get the same failure, fine for you, but be careful what you expect. You may well wind up needing the exact same workaround in others as I suggested for openSUSE: using config file(s) to override failing automagic. Your unfortunate experience is not uncommon, regardless of distro. Inexplicable failure is the nature of automagic. Developers are human. Hardware is fallible. -- "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/

On 2012-11-29 23:10 (GMT-0500) Patrick Serru composed: I doubt anyone could predict viability of any particular DE over another. If you can get any DE to work in X, then TDE should be no problem if there is a version published for that release. If you want to know if you should expect 12.10 to work, boot its live media and see what happens. If it works, then a 12.10 installation should work too. As for getting from 10.10 to 12.10, be sure to follow the published instructions. Normally an upgrade to each intermediate version is the only way to expect to avoid a mess, and X certainly might break along the way. A clean install might be easier, especially if you already have /home on a separate filesystem. The Trinity list is short of ideal for discussing generic X trouble like yours. Instead, try either http://lists.x.org/mailman/listinfo/xorg or whatever list may be dedicated to X on your distro of choice. -- "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/