Re: changing label text in boot0
On 01/15/2011 05:10, Aryeh Friedman wrote: > I have 2 different versions of FB running on the same drive (-STABLE > and -CURRENT) and want to know a) is it possible and b) how to change > the boot0 "F?" labels so that "F1" (slice 1) is "FreeBSD-STABLE" and > "F2" (slice 2) is "FreeBSD-CURRENT" GRUB might solve your needs. sysutils/grub -- Regards, Eric signature.asc Description: OpenPGP digital signature
Re: ATI drivers for FreeBSD - anything? [Slightly OT]
Maxime Henrion wrote: Albert Vest wrote: On Sat, 19 Nov 2005 01:58:25 +0200 (EET) Vladimir Kushnir <[EMAIL PROTECTED]> wrote: Hi all, Is there any project on FreeBSD wrapper for ATI Linux drivers (like nVidia's used to be)? If so - I'd be more than happy to test (sorry I can hardly write it myself). Regards, Vladimir I too would welcome this, mainly for ATI sound but also for video. I see the x11/nvidia-driver port can still be built with LINUX compatibility turned on; maybe if we "make extract" with LINUX=yes, the source code will contain some hints to how it can be done? The Linux compatibility in the nvidia-driver has nothing to do with a wrapper to run Linux drivers; nVidia releases a build of this driver for FreeBSD. The Linux compatibility option is here to install nVidia's Linux OpenGL libraries so that Linux binaries can run with FreeBSD's driver. This is possible because nVidia's OpenGL libraries communicate with the driver by using /dev/nvidia and the FreeBSD driver offers the same interface. With the above said... I have a ATI Radeon m7500 card, and Linux game (nwn) which requires OpenGL (I think). the game is unusably slow. When the game play begins, my frame rate drops to 2fps. I suspect some misconfiguration with my linux-compat openGL setup. Does the ATI driver have a similar 'Linux Compatibility' knob? In short, there is no easy way to use the ATI drivers for Linux under FreeBSD. Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
repeatedly opening the same .so(s) is slow?
Hello,
Sorry if the subject is misleading, not sure how to label this one.
I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz
machine. It used to take 15-20 seconds till all of the libtool changes.
I have no idea if the symptom is related to libtool or not. Others have
said it is not... but that's when the problems began, just for
reference. FWIW, when I had trouble due to libtool, I simply formatted
my machine, reinstalled OS and all ports. So this issue is occurring on
a 'clean' machine.
But here is what I have found, and it looks odd to me.
Using truss, I can see that gnucash/guile is trying to open a dozen or
two files, repeatedly. It fails attempting to open it the first few
times everytime it tries to access it, because it is traversing the
LD_LIBRARY_PATH:
open("/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("/usr/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("/usr/local/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/usr/X11R6/lib/gnucash/libglib-12.la",0x0,0666) ERR#2 'No such
file or directory'
open("/usr/X11R6/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/usr/X11R6/lib/gnucash/libglib-12.la",0x0,0666) ERR#2 'No such
file or directory'
open("/usr/local/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("/usr/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("/usr/local/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/usr/X11R6/lib/gnucash/libglib-12.la",0x0,0666) ERR#2 'No such
file or directory'
open("/usr/X11R6/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/usr/X11R6/lib/gnucash/libglib-12.la",0x0,0666) ERR#2 'No such
file or directory'
open("/usr/local/lib/libglib-12.la",0x0,0666)ERR#2 'No such file or
directory'
open("/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("/usr/lib/libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
open("libglib-12.la",0x0,0666) ERR#2 'No such file or
directory'
access("/lib/libglib-12.so",4) ERR#2 'No such file or
directory'
access("/usr/lib/libglib-12.so",4) ERR#2 'No such file or
directory'
access("/usr/local/lib/libglib-12.so",4) = 0 (0x0)
Now I said a dozen or two files repeatedly. It is 12-20 files maybe...
but it is attempting to open them *hundreds of thousands of times*! It
goes on and on and on...
I am assuming this is what is causing the long startup time. So I have
been working towards helping it find the right files the first time
around. I have manipulated the gnucash environments LD_LIBRARY_PATH a
bit and helped some... but it is only a drop in the bucket. I have
thought of placing symlinks in the folder(s) where it first looks for
any given file, to make sure it finds the file... but this does not seem
quite right either.
What I'm wondering is what is the lists opinion on how to best fix
this type of a problem. Is this even the cause of my long startup?
I have spoken with one or two of the gnucash devs, they seem to think
this is unique to FreeBSD, meaning they have not seen this problem on
any other platform. They said it might have to do with how FreeBSD
handles how files are opened up many times recursively!?
If there is a more appropriate list, please let me know.
Thanks in advance.
--
Regards,
Eric
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: repeatedly opening the same .so(s) is slow?
Peter Jeremy wrote: On Mon, 2006-Mar-20 10:49:57 -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. It takes 15 minutes on a -current Athlon XP-1800 and about 2 minutes on a 2.2GHz AMD64 running -stable. I have no idea if the symptom is related to libtool or not. I initially thought it was libtool related but now I'm uncertain. I didn't just upgrade libtool, I upgraded quite a few other ports at the same time. On the not-libtool side, ade@ says that he hasn't seen this behaviour with other libtool/libltdl ports and I've found that guile include it's own libltdl code (based on libtool). I'm not sure if this is gnucash specific or affects other guile applications. FWIW... I have removed my symlink to libguile-ltdl.so and recreated it to point at libltdl.so.1. So that guile is using my stock libltdl.so. I get the same results. And gnucash seems to run fine. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: Worse than that, it's expanding LD_LIBRARY_PATH using additional paths embedded in the .la files that it's opening. Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I took a complete ktrace of the startup and there are 24e6 NAMI events with the top files tested 2,000,000 times. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. It's definitely a hack. I tried something like this and it didn't help much. The code still wants to open libraries multiple times. I've been looking at adding caching to lt_dlopenext() and my first attempt went much faster but blew up because I wasn't correctly handling open/close/open sequences (libm is opened and then closed 42,000 times). I think this is the way forward but need to find the time to understand ltdl.[ch] (~4800 lines). What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? Any system calls involving opening pathnames are expensive, even with the namei cache. Having 4 orders of magnitude too many is a destinct problem. I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? Possibly Linux can more efficiently handle opening a non-existent file but the underlying problem is that there are far too many system calls being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. hmm... I have a Gentoo system somewhere. It was just an experiment. No idea what shape its in. But maybe I can try installing gnucash on it. If there is a more appropriate list, please let me know. -ports may be better. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: repeatedly opening the same .so(s) is slow?
Peter Jeremy wrote: On Mon, 2006-Mar-20 10:49:57 -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. It takes 15 minutes on a -current Athlon XP-1800 and about 2 minutes on a 2.2GHz AMD64 running -stable. I have no idea if the symptom is related to libtool or not. I initially thought it was libtool related but now I'm uncertain. I didn't just upgrade libtool, I upgraded quite a few other ports at the same time. On the not-libtool side, ade@ says that he hasn't seen this behaviour with other libtool/libltdl ports and I've found that guile include it's own libltdl code (based on libtool). I'm not sure if this is gnucash specific or affects other guile applications. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: Worse than that, it's expanding LD_LIBRARY_PATH using additional paths embedded in the .la files that it's opening. Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I took a complete ktrace of the startup and there are 24e6 NAMI events with the top files tested 2,000,000 times. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. It's definitely a hack. I tried something like this and it didn't help much. The code still wants to open libraries multiple times. I've been looking at adding caching to lt_dlopenext() and my first attempt went much faster but blew up because I wasn't correctly handling open/close/open sequences (libm is opened and then closed 42,000 times). I think this is the way forward but need to find the time to understand ltdl.[ch] (~4800 lines). What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? Any system calls involving opening pathnames are expensive, even with the namei cache. Having 4 orders of magnitude too many is a destinct problem. I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? Possibly Linux can more efficiently handle opening a non-existent file but the underlying problem is that there are far too many system calls being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. FWIW: I spoke with some folks on a gnucash channel. They ran a trace for me on gnucash, and it only attempted to load files 17 times or so. Each time it loaded a file it hung onto it. Sounds like the 'close' is not releasing the library like it does on fbsd. Which is how it 'should' work. If there is a more appropriate list, please let me know. -ports may be better. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: repeatedly opening the same .so(s) is slow?
[EMAIL PROTECTED] wrote: On Mon, Mar 20, 2006 at 10:49:57AM -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. This sounds exactly like the problems I initially had with KDE on DragonFly. You say 'initially'. Did you find a fix? Check whether it is using libtool's dlopen wrapper, since it It has its own libguile-ltdl.so. I'm not sure of its function though as it can happily be replaced with the ligltdl.so, with no immediate bad side effects. seems to believe that the system dlopen either can't support hard-coded search paths (known bug in the last 1.5 version of libtool) or can't trace dependency libs. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: repeatedly opening the same .so(s) is slow?
Peter Jeremy wrote: On Tue, 2006-Mar-21 14:31:24 +0100, [EMAIL PROTECTED] wrote: Set libltdl_cv_sys_dlopen_deplibs=yes in the environment before running configure and try again. And yes, this is *exactly* the same idiosyncraty as KDE. This is needed for both guile and libltdl. After replacing libltdl and libguile-ltdl, So would I need to uninstall guile, libguile-ltdl, and libltdl... and then set the environment variable... then 'make configure' and 'make install' guile? Thanks for all the help. gnucash startup has dropped from 15 minutes to 10 seconds. Thanks for the pointer. The correct fix would be to patch the configure script so it recognizes FreeBSD. I'll file a PR this evening (if no-one has fixed it by then). -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: repeatedly opening the same .so(s) is slow?
Eric Schuele wrote: Peter Jeremy wrote: On Tue, 2006-Mar-21 14:31:24 +0100, [EMAIL PROTECTED] wrote: Set libltdl_cv_sys_dlopen_deplibs=yes in the environment before running configure and try again. And yes, this is *exactly* the same idiosyncraty as KDE. This is needed for both guile and libltdl. After replacing libltdl and libguile-ltdl, So would I need to uninstall guile, libguile-ltdl, and libltdl... and then set the environment variable... then 'make configure' and 'make install' guile? Disregard. Got it. Thank you *very much* for the help! Thanks for all the help. gnucash startup has dropped from 15 minutes to 10 seconds. Thanks for the pointer. The correct fix would be to patch the configure script so it recognizes FreeBSD. I'll file a PR this evening (if no-one has fixed it by then). -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: automatic checking of source code
Divacky Roman wrote: hi I just found http://mygcc.free.fr/ which is a project for automatic checking of source code for bugs (memory leaks, unreleased locks, null pointer dereferences). I recall there was some SoC project to achieve something similar but this is complete and ready to run... it might be of some interest for someone See thread "FreeBSD Kernel Quality?" posted 04/05/06. roman -- www.liberalnistrana.cz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: weird problems with porupgrade
Hannes Hauswedell wrote: hi everybody! since some time now i am developing kports an advanced kde frontend for the freebsd-ports and in future also pkgsrc and openbsd ports. since the last release last summer i have gone through a complete rewrite and right now am at the point where i monitor portupgrades output and am having severe problems with portupgrade's behaviour. the problem is: depending on certain conditions portupgrade doesnt show a big part of the output. these conditions are: the application is started as a subprocess of another application, e.g. kdevelop and/or i use kprocess/qprocess to run the portupgrade command. Could it be you are seeing the differences between stdout and stderr? if i run the applicaiton on its own and use popen() and pipes to access the output it works. this might make it appear to be a problem of the kprocess implementation, however i am pretty sure it is not. i have run the command with "| tee logfile" and the logfile also only has part of the output. this whole problem has been discussed @ http://www.bsdforen.de/showthread.php?p=119650 (in german), so if you speak german you could check that out. an example of the problem: i run the command "portupgrade -v -y -N -PP games/angband" without root previliges (this way the process is over pretty quickly). if run from inside a unix system pipe (file descriptor opened with popen and read with fgets) the output looks like this: -> Session started at: Thu, 06 Apr 2006 10:46:10 + ---> Fresh installation of games/angband started at: Thu, 06 Apr 2006 10:46:17 + ---> Checking for the latest package of 'games/angband' ---> Fetching the package(s) for 'angband-3.0.6' (games/angband) ---> Fetching angband-3.0.6 ++ Will try the following sites in the order named: ftp://ftp.de.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/ ---> Invoking a command: curl ftp://ftp.de.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/angband-3.0.6.tbz -o /var/tmp/portupgradeURBFUqpc/angband-3.0.6.tbz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 579k0 14040 0 1423 0 0:06:57 --:--:-- 0:06:57 1423 20 579k 20 120k0 0 75560 0 0:00:07 0:00:01 0:00:06 183k 59 579k 59 344k0 0 130k 0 0:00:04 0:00:02 0:00:02 207k 96 579k 96 559k0 0 153k 0 0:00:03 0:00:03 --:--:-- 210k 100 579k 100 579k0 0 151k 0 0:00:03 0:00:03 --:--:-- 204k ---> Downloaded as angband-3.0.6.tbz ---> Identifying the package /var/tmp/portupgradeURBFUqpc/angband-3.0.6.tbz ** Failed to save the dowloaded tarball as /usr/ports/packages/All/angband-3.0.6.tbz ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) ! angband-3.0.6 (Permission denied - /usr/ports/packages/All/angband-3.0.6.tbz) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed ** Could not clean up temporary directory: Directory not empty - /var/tmp/portupgradeURBFUqpc ---> Fetching the latest package(s) for 'angband' (games/angband) ---> Fetching angband ++ Will try the following sites in the order named: ftp://ftp.de.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/ ---> Invoking a command: curl ftp://ftp.de.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/angband.tbz -o /var/tmp/portupgrade7LnEZ0Si/angband.tbz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 579k0 14040 0 1451 0 0:06:49 --:--:-- 0:06:49 1451 9 579k9 561600 0 39568 0 0:00:15 0:00:01 0:00:14 118k 25 579k 25 147k0 0 62424 0 0:00:09 0:00:02 0:00:07 100k 55 579k 55 322k0 0 95434 0 0:00:06 0:00:03 0:00:03 128k 80 579k 80 464k0 0 105k 0 0:00:05 0:00:04 0:00:01 134k 100 579k 100 579k0 0 110k 0 0:00:05 0:00:05 --:--:-- 135k ---> Downloaded as angband.tbz ---> Identifying the package /var/tmp/portupgrade7LnEZ0Si/angband.tbz ** Failed to save the dowloaded tarball as /usr/ports/packages/All/angband-3.0.6.tbz ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) ! angband@ (Permission denied - /usr/ports/packages/All/angband-3.0.6.tbz) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed ** Could not clean up temporary directory: Directory not empty - /var/tmp/portupgrade7LnEZ0Si ---> Fresh installation of games/angband ended at: Thu, 06 Apr 2006 10:46:31 + (consumed 00:00:13) ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) ! games/angband (package not found) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed ---> Session ended at: Thu, 06 Apr 2006 10:46:31 + (consum
Re: Strange keyboard (viral?) behaviour
On 06/12/06 14:17, Philip Lykke Carlsen wrote: mandag 12 juni 2006 20:48 skrev du: Philip Lykke Carlsen wrote: Hm. A little more research seems to have narrowed it down a bit. Apparently the text come from my sisters windows pc and is transmitted realtime to my freebsd machine, peculiar as it may sound. but at least now I have the means to look at the problem more carefully. But I am still at a loss as to explain how it continued typing even after I unplugged the network card (it's a laptop..), and how it was able to continue even in singleuser mode before the network had been properly set up (let alone plugged in at all). Wireless keyboard on your sister's machine and your laptop just happens to have a compatible receiver built-in? David Hm. now that you mention it, that does seem probable. And sure enough.. looking closer, the typing stops when I unplug the usb wireless mouse/keyboard reciever.. it's just.. it has never happened before now.. and we've been using this setup for ages.. and I never had quite this success in keyboard transmitting range.. 10 meters at least and through at least four solid brick and steel walls.. hm.. i guess disabling usb-keyboards via devfs.rules or by removing the support from the kernel would solve the problem. But thanks very much. very much indeed :-D hm.. I wonder why I didn't at least consider the possibility of it being the wireless keyboard.. I'm curious Originally you said it was playing back YOUR previous GAIM conversation. Then above you mention "real time text" from your sister's pc. If it is the former... your sister's pc may have a keylogger on it, no? And may require some investigation. Either way, now (with wireless keyboard)... the keylogger only needs to be near your machine, not installed on it. :S ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
On 07/21/2006 08:32, Robert Watson wrote: On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote: I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. I've occasionally also had weird focus problems with KDE. Among other things, it looks like occasionally the mouse release event is lost somewhere in the system (or something along these lines) -- I don't know if it's a driver problem, a moused problem, an X11 probem, or a KDE problem. If I press and release each of the buttons, especially the third button, things will often recover. As long as the button is "held down", KDE doesn't switch the focus and other events are largely ignored. Odd, eh? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I think I'm seeing something similar (not sure) so I thought I'd mention it. I can repeat the effect on demand. If I open my opera browser it launches a weather widget. If I then open a terminal (aterm in this case) and give it focus, everything is good. If I bring my mouse over the widget, it appears to capture the keybaord input. My terminal cursor goes to an empty square. (My window manager is not setup to have the focus follow the mouse. I focus on clicks.) My terminal window is still highlighted as if it actually has focus. If I then click on the terminal window, or within the window in an attempt to give it focus... I still can not type in it (the cursor is still hollow). Keypresses affect the widget only at this point. The only way is to either pick a third window, or actually click in the widget, and then back to the terminal. In fact I've done the same thing with the composing of this e-mail. The focus can be stolen from this "compose" window in a similar fashion. I've only just started using this widget today, so this is the first time I've come across this effect. If you think this is a similar problem... and there is anything I could do to help examine it, let me know. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
