I have a testing account I use often. That account gets used in my real machines and virtual machines. For many years I have used a left-handed mouse (mouse buttons reversed). Because the virtual machine passes the mouse buttons transparently, I wrote a snippet for that user's .bashrc file to test the mouse button configuration and swap the mouse buttons in kcminputrc as necessary. That way I can use a left-handed mouse regardless of which environment the account gets used.
To test my mouse buttons I run the following in that user's .bashrc:
kreadconfig --file $PROFILE_HOME/share/config/kcminputrc --group Mouse --key MouseButtonMapping
Simple enough.
Today I booted my PII machine that has a partition for Trinity 3.5.13. I login from the command line, which means X is not yet running. When I logged in with that testing account I received the following message:
NVIDIA OpenGL Driver requires CPUs with SSE to run. The current CPU does not support SSE.
Superficially, I saw this message because originally I had cloned a testing partition from another hard drive and that partition had the proprietary Nvidia drivers installed. The PII machine does not support those drivers. Hence the messages.
The real mystery is what is kreadconfig and kwriteconfig doing that indirectly causes those messages? I suspect a linking problem, which ldconfig resolved after I removed the Nvidia packages. Nonetheless, why are those two commands querying X libraries when X is not running? Is this a feature or a bug? :)
Darrell
On Mon, 19 Dec 2011 20:23:51 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
I have a testing account I use often. That account gets used in my real machines and virtual machines. For many years I have used a left-handed mouse (mouse buttons reversed). Because the virtual machine passes the mouse buttons transparently, I wrote a snippet for that user's .bashrc file to test the mouse button configuration and swap the mouse buttons in kcminputrc as necessary. That way I can use a left-handed mouse regardless of which environment the account gets used.
To test my mouse buttons I run the following in that user's .bashrc:
kreadconfig --file $PROFILE_HOME/share/config/kcminputrc --group Mouse --key MouseButtonMapping
Simple enough.
Today I booted my PII machine that has a partition for Trinity 3.5.13. I login from the command line, which means X is not yet running. When I logged in with that testing account I received the following message:
NVIDIA OpenGL Driver requires CPUs with SSE to run. The current CPU does not support SSE.
Superficially, I saw this message because originally I had cloned a testing partition from another hard drive and that partition had the proprietary Nvidia drivers installed. The PII machine does not support those drivers. Hence the messages.
The real mystery is what is kreadconfig and kwriteconfig doing that indirectly causes those messages? I suspect a linking problem, which ldconfig resolved after I removed the Nvidia packages. Nonetheless, why are those two commands querying X libraries when X is not running? Is this a feature or a bug? :)
dd@darkstar:~$ ldd `which kwriteconfig` linux-gate.so.1 => (0xffffe000) libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0xf7489000) libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0xf744c000) libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0xf741b000) libtqt.so.4 => /opt/kde3/lib/libtqt.so.4 (0xf7419000) libqt-mt.so.3 => /opt/kde3/lib/libqt-mt.so.3 (0xf6d52000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf6d2f000) libX11.so.6 => /usr/lib/libX11.so.6 (0xf6c14000) libz.so.1 => /usr/lib/libz.so.1 (0xf6c00000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xf6bfd000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf6bf8000) libICE.so.6 => /usr/lib/libICE.so.6 (0xf6be0000) libSM.so.6 => /usr/lib/libSM.so.6 (0xf6bd8000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6ae8000) libm.so.6 => /lib/libm.so.6 (0xf6ac2000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6aa5000) libc.so.6 => /lib/libc.so.6 (0xf6942000) libdl.so.2 => /lib/libdl.so.2 (0xf693d000) libmng.so.1 => /usr/lib/libmng.so.1 (0xf68da000) libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xf68a5000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0xf687f000) libGL.so.1 => /usr/lib/libGL.so.1 (0xf6814000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xf67fd000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf67f6000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf67ed000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf67ea000) libXft.so.2 => /usr/lib/libXft.so.2 (0xf67d7000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf6761000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf6732000) libXext.so.6 => /usr/lib/libXext.so.6 (0xf6724000) libpthread.so.0 => /lib/libpthread.so.0 (0xf670b000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf66f3000) libuuid.so.1 => /lib/libuuid.so.1 (0xf66ef000) /lib/ld-linux.so.2 (0xf774f000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0xf66bb000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf66b6000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xf66b3000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xf66b1000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xf66a1000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf6697000) libXt.so.6 => /usr/lib/libXt.so.6 (0xf6646000) libXau.so.6 => /usr/lib/libXau.so.6 (0xf6643000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf663e000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf6618000) librt.so.1 => /lib/librt.so.1 (0xf660e000) dd@darkstar:~$ ldd /opt/kde3/lib/libkdecore.so.4.2.0 linux-gate.so.1 => (0xffffe000) libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0xf7451000) libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0xf7420000) libz.so.1 => /usr/lib/libz.so.1 (0xf73f2000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xf73ef000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf73e9000) libICE.so.6 => /usr/lib/libICE.so.6 (0xf73d2000) libSM.so.6 => /usr/lib/libSM.so.6 (0xf73ca000) libdl.so.2 => /lib/libdl.so.2 (0xf73c6000) libtqt.so.4 => /opt/kde3/lib/libtqt.so.4 (0xf73c4000) libqt-mt.so.3 => /opt/kde3/lib/libqt-mt.so.3 (0xf6cfe000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf6cf4000) libX11.so.6 => /usr/lib/libX11.so.6 (0xf6bd9000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6ae9000) libm.so.6 => /lib/libm.so.6 (0xf6ac3000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6aa6000) libc.so.6 => /lib/libc.so.6 (0xf6943000) libXext.so.6 => /usr/lib/libXext.so.6 (0xf6934000) libuuid.so.1 => /lib/libuuid.so.1 (0xf6930000) /lib/ld-linux.so.2 (0xf7754000) libmng.so.1 => /usr/lib/libmng.so.1 (0xf68cd000) libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xf6898000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0xf6872000) libGL.so.1 => /usr/lib/libGL.so.1 (0xf6806000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xf67f0000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf67e9000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf67e0000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf67dd000) libXft.so.2 => /usr/lib/libXft.so.2 (0xf67ca000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf6753000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf6725000) libpthread.so.0 => /lib/libpthread.so.0 (0xf670c000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf66f4000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0xf66c1000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf66bb000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xf66b8000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xf66b6000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xf66a6000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf669d000) libXt.so.6 => /usr/lib/libXt.so.6 (0xf664b000) libXau.so.6 => /usr/lib/libXau.so.6 (0xf6648000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf6643000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf661d000) librt.so.1 => /lib/librt.so.1 (0xf6614000) I don't think we should go much farther in the investigation: the dependency of kwriteconfig on kdelibs brings automatic dependency on X libraries even if it is a console program.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
/dev/ammo42 wrote:
I don't think we should go much farther in the investigation: the dependency of kwriteconfig on kdelibs brings automatic dependency on X libraries even if it is a console program.
Good point. That is one reason I like Qt4 much beter than Qt3. For applications that don't need X, you don't pull that stuff in. Qt3 is a single monolithic library with everything, while Qt4 is a collection of 21 libraries. For something like kwriteconfig, it would probably only need libQtCore.
-- Bruce
I don't think we should go much farther in the
investigation: the
dependency of kwriteconfig on kdelibs brings automatic
dependency on X
libraries even if it is a console program.
Good point. That is one reason I like Qt4 much beter than Qt3. For applications that don't need X, you don't pull that stuff in. Qt3 is a single monolithic library with everything, while Qt4 is a collection of 21 libraries. For something like kwriteconfig, it would probably only need libQtCore.
Thanks to both.
For you folks more experienced with coding TDE and Qt3, are there any clever ways to eliminate the overhead with the non X commands? Seems that would be more efficient and shave a few micro/millisecond response times here and there, especially for older hardware. :)
Darrell
Darrell Anderson wrote:
I don't think we should go much farther in the
investigation: the
dependency of kwriteconfig on kdelibs brings automatic
dependency on X
libraries even if it is a console program.
Good point. That is one reason I like Qt4 much beter than Qt3. For applications that don't need X, you don't pull that stuff in. Qt3 is a single monolithic library with everything, while Qt4 is a collection of 21 libraries. For something like kwriteconfig, it would probably only need libQtCore.
Thanks to both.
For you folks more experienced with coding TDE and Qt3, are there any clever ways to eliminate the overhead with the non X commands? Seems that would be more efficient and shave a few micro/millisecond response times here and there, especially for older hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial, but the amount of work depends on the program. There's no way to eliminate X as long as Qt3 is used.
-- Bruce
For you folks more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial, but the amount of work depends on the program. There's no way to eliminate X as long as Qt3 is used.
I was not implying any porting to Qt4. :) Is there a decent technical reason why the X overhead can't be eliminated from the non X TDE commands?
Darrell
For you folks more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial, but the amount of work depends on the program. There's no way to eliminate X as long as Qt3 is used.
I was not implying any porting to Qt4. :) Is there a decent technical reason why the X overhead can't be eliminated from the non X TDE commands?
Darrell
In theory it might be possible to modify the Qt3 source and add an X-less application constructor. I have no idea how complex that would be.
Tim
On 20 Dec 2011, Timothy Pearson spake thusly:
For you folks more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial, but the amount of work depends on the program. There's no way to eliminate X as long as Qt3 is used.
I was not implying any porting to Qt4. :) Is there a decent technical reason why the X overhead can't be eliminated from the non X TDE commands?
In theory it might be possible to modify the Qt3 source and add an X-less application constructor. I have no idea how complex that would be.
Of course this would still pull in the X shared libraries, incurring most of the startup costs nonetheless. Fixing *that* would be a lot more work. (Also, who knows how many places inside Qt3 assume the existence of a live X display connection? After all, they've always had one they can rely on.)
Nix wrote:
Of course this would still pull in the X shared libraries, incurring most of the startup costs nonetheless. Fixing *that* would be a lot more work. (Also, who knows how many places inside Qt3 assume the existence of a live X display connection? After all, they've always had one they can rely on.)
Trolltech did the separation in Qt4. Their major libraries are libQtCore, libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value. If someone is building a new application, they would probably just build it with Qt4.
-- Bruce
On 20 December 2011 12:21, Bruce Dubbs bruce.dubbs@gmail.com wrote:
Nix wrote:
Of course this would still pull in the X shared libraries, incurring
most of the startup costs nonetheless. Fixing *that* would be a lot more work. (Also, who knows how many places inside Qt3 assume the existence of a live X display connection? After all, they've always had one they can rely on.)
Trolltech did the separation in Qt4. Their major libraries are libQtCore, libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value. If someone is building a new application, they would probably just build it with Qt4.
-- Bruce
some applications would load faster and/or use less memory because they aren't linking a giant so file and instead fewer smaller ones that they actually need
Calvin Morrison wrote:
On 20 December 2011 12:21, Bruce Dubbs bruce.dubbs@gmail.com wrote:
Trolltech did the separation in Qt4. Their major libraries are libQtCore, libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value. If someone is building a new application, they would probably just build it with Qt4.
some applications would load faster and/or use less memory because they aren't linking a giant so file and instead fewer smaller ones that they actually need
LOL. The libraries you refer to are already in memory. They don't have to be loaded again. That's what a shared library does. Even if they weren't in memory, the system would have to be instrumented to measure the change. It would be imperceptible to the user.
-- Bruce
On 20 Dec 2011, Bruce Dubbs said:
Calvin Morrison wrote:
On 20 December 2011 12:21, Bruce Dubbs bruce.dubbs@gmail.com wrote:
Trolltech did the separation in Qt4. Their major libraries are libQtCore, libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value. If someone is building a new application, they would probably just build it with Qt4.
some applications would load faster and/or use less memory because they aren't linking a giant so file and instead fewer smaller ones that they actually need
LOL. The libraries you refer to are already in memory. They don't have to be loaded again. That's what a shared library does. Even if they weren't in memory, the system would have to be instrumented to measure the change. It would be imperceptible to the user.
It would use a bit less memory, and speed up startup a bit, because fewer relocations are required, and relocations necessarily require making the page containing the relocations private to that process, and writable. Even on a prelinked system, some memory would be saved, because two relocations are required per C++ class even when prelink is in use, and a split Qt would contain many fewer classes in the non-X-using part than exist in all of Qt now.
(But despite that, you are surely right that the cost/benefit tradeoff is surely not worth it for Qt3.)
On 21 December 2011 15:54, Nix nix@esperi.org.uk wrote:
On 20 Dec 2011, Bruce Dubbs said:
Calvin Morrison wrote:
On 20 December 2011 12:21, Bruce Dubbs bruce.dubbs@gmail.com wrote:
Trolltech did the separation in Qt4. Their major libraries are
libQtCore,
libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the
value.
If someone is building a new application, they would probably just
build
it with Qt4.
some applications would load faster and/or use less memory because they aren't linking a giant so file and instead fewer smaller ones that they actually need
LOL. The libraries you refer to are already in memory. They don't have to be loaded again. That's what a shared library does. Even if they weren't in memory, the system would have to be instrumented to measure the change. It would be imperceptible to the user.
It would use a bit less memory, and speed up startup a bit, because fewer relocations are required, and relocations necessarily require making the page containing the relocations private to that process, and writable. Even on a prelinked system, some memory would be saved, because two relocations are required per C++ class even when prelink is in use, and a split Qt would contain many fewer classes in the non-X-using part than exist in all of Qt now.
(But despite that, you are surely right that the cost/benefit tradeoff is surely not worth it for Qt3.)
-- NULL && (void)
It would not be a giant benefit to users who already have loaded the libraries into memory, but it would for people who are looking to use Trinity applications as stand alone.
It would not be a giant benefit to users who already have loaded the libraries into memory, but it would for people who are looking to use Trinity applications as stand alone.
Okay, computer science majors. Quit trying to see who can crow the loudest. :)
All I want to know is whether the non gui commands of TDE such as kwriteconfig and kreadconfig can (easily) be built without the X overhead.
Darrell
On Wed, 21 Dec 2011 18:49:01 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
It would not be a giant benefit to users who already have loaded the libraries into memory, but it would for people who are looking to use Trinity applications as stand alone.
Okay, computer science majors. Quit trying to see who can crow the loudest. :)
All I want to know is whether the non gui commands of TDE such as kwriteconfig and kreadconfig can (easily) be built without the X overhead.
You would either have to: -separate non-X-dependent parts of Qt like for Qt4 -not do that separation but instead use the X functions as weak symbols and add a dlopen() of X libraries to every X-using Qt3 application
I really don't see a really easy option; there is a third option which would be to compile both with-X and without-X versions of kdelibs and Qt3 but without significant linker magic it is likely to load both versions of kdelibs and Qt3 within a Trinity session.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
All I want to know is whether the non gui commands of
TDE such as
kwriteconfig and kreadconfig can (easily) be built
without the X
overhead.
You would either have to: -separate non-X-dependent parts of Qt like for Qt4 -not do that separation but instead use the X functions as weak symbols and add a dlopen() of X libraries to every X-using Qt3 application
I really don't see a really easy option; there is a third option which would be to compile both with-X and without-X versions of kdelibs and Qt3 but without significant linker magic it is likely to load both versions of kdelibs and Qt3 within a Trinity session.
Fair enough. Too bad. :(
Darrell
Darrell Anderson wrote:
All I want to know is whether the non gui commands of TDE such as kwriteconfig and kreadconfig can (easily) be built without the X overhead.
You would either have to: -separate non-X-dependent parts of Qt like for Qt4 -not do that separation but instead use the X functions as weak symbols and add a dlopen() of X libraries to every X-using Qt3 application
I really don't see a really easy option; there is a third option which would be to compile both with-X and without-X versions of kdelibs and Qt3 but without significant linker magic it is likely to load both versions of kdelibs and Qt3 within a Trinity session.
Fair enough. Too bad. :(
Here's an easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \ "x`grep LeftHanded ~/.kde/share/config/kcminputrc`" != "x" ]; then echo left else echo right fi
-- Bruce
I really don't see a really easy option; there is
a third option
which would be to compile both with-X and
without-X versions of kdelibs and Qt3 but without significant linker magic it is likely
to load both versions of kdelibs and Qt3 within a
Trinity session.
Fair enough. Too bad. :(
Here's an easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \ "x`grep LeftHanded ~/.kde/share/config/kcminputrc`" != "x" ]; then echo left else echo right fi
Thanks much, but you must have missed my original post --- I'm already doing that. :)
In my original message I asked why I saw specific Nvidia error messages when using an allegedly non-gui command in a console outside of X. I solved that mystery and was shown that the commands were built with X dependencies.
The discussion since then is why those non-gui commands can't build without the X dependency. My "too bad" comment was in reference to building those commands otherwise. :)
Darrell
Darrell Anderson wrote:
I really don't see a really easy option; there is
a third option
which would be to compile both with-X and
without-X versions of kdelibs and Qt3 but without significant linker magic it is likely
to load both versions of kdelibs and Qt3 within a
Trinity session.
Fair enough. Too bad. :(
Here's an easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \ "x`grep LeftHanded ~/.kde/share/config/kcminputrc`" != "x" ]; then echo left else echo right fi
Thanks much, but you must have missed my original post --- I'm already doing that. :)
Yes, I missed that.
In my original message I asked why I saw specific Nvidia error messages when using an allegedly non-gui command in a console outside of X. I solved that mystery and was shown that the commands were built with X dependencies.
Yes.
The discussion since then is why those non-gui commands can't build without the X dependency. My "too bad" comment was in reference to building those commands otherwise. :)
That's one reason Qt4 has multiple libraries. Doing that for Qt3 seems to be reinventing the wheel. BTW, I tried to build Qt4 without the X libraries, even though there is a configure option --without-x. It didn't work. However, I could write a program that did not link to any X libraries. Also, programs written to Qt4 (not KDE4) work fine in KDE3, graphical or otherwise.
-- Bruce
-
/dev/ammo42 -
Bruce Dubbs -
Calvin Morrison -
Darrell Anderson -
Nix -
Timothy Pearson