~Toughbooktalk~

It's so important to include the links. Thanks mate. Call me when you have time.

Sadlmkr wrote:Welcome to the soiree. Did my new avatar attract you?

You get what you ask for at best. A bat shaped light to the sky may bear other results than a picture of fluffy sheep on a green meadow. You gotta play with the cards you receive, so fleecy powers to the rescue!

Though for the screen resolution problem, I can't come up with any more help than to suggest to have a closer look at the log files and then use a search engine to investigate further into peculiar lines.

As I have just had an utmost annoying time to get a bluetooth GPS receiver going with my CF-31 this weekend, I have a growing suspicion on the cause of your GPS troubles. The Receiver was up and running in about 10 minutes, but not reliably so, especially after suspend/hibernate. It then took me a whole effin' day to work out the quirks, although the bluetooth related stuff was a big part of the equation.
The GPS-daemon would only serve GPS data if it was started or restarted after some grace period ranging from several tens of seconds to a few minutes, depending on the state the receiver was in (turned on/restarted from stand-by or from off state with battery taken out and running on external power). If gpsd was too early started manually, it would never begin to deliver GPS data, although the bluetooth-fed serial device was already present. I ended up writing a short script including rfcomm (bluetooth - not your department), gpsd and xgps for starting, stopping and restarting GPS functionality and also including pkill lines for gpsd and xgps in a suspend/hibernate preparation script in /etc/pm/sleep.d for convenience, because failing to stop gpsd manually before going into suspend/hibernate did result in moderate ("rfcomm connect 0" used when starting) - bluetooth mouse not working and GPS data not beeing served - to catastrophic - total system freeze - ("rfcomm bind 0" when starting and "rfcomm release 0" before sus./hib.) problems after resume.

If I recall correctly the internal GPS, if present, is constantly powered by the battery (which has its pros and cons) so you should get GPS data pretty quickly while the battery is inserted.
Nevertheless the serial device in your machine may as well need some time to work properly so my best bet is for you to also use a script for gpsd (and xgps) just like I do.

Yes I've spent several hours in xorg.0.log dmesg etc. Nothing stands out to me. (to me)

Several timing things going on in gpsd/xgps. I don't have a bluetooth gps at this time.

One quote I remember is bluetooth may be set to a high com port and suggested changing the com port.. FWIW

Sadlmkr wrote:Yes I've spent several hours in xorg.0.log dmesg etc. Nothing stands out to me. (to me)
Several timing things going on in gpsd/xgps. I don't have a bluetooth gps at this time.
One quote I remember is bluetooth may be set to a high com port and suggested changing the com port.. FWIW

From the Navigatrix site, here's some lite reading:
http://navigatrix.net/viewtopic.php?f=4&t=481
http://navigatrix.net/viewtopic.php?f=4&t=640

UNCNDL1 wrote: From the Navigatrix site, here's some lite reading:
http://navigatrix.net/viewtopic.php?f=4&t=481
http://navigatrix.net/viewtopic.php?f=4&t=640

Thanks for the input
I did read through these threads but couldn't find any new tweaks. In fact I had the receiver up and running after 10 minutes using another howto. Making it work reliably was the tricky part.

Right now I'm quite happy with the way the GPS works after further refining upon my script.
Turning on the receiver from stand-by, typing "gps 1" (script location entered into ~/.bash_aliases) into konsole and waiting a little more than 10 seconds until getting location data inside buildings is good enough for me.
If the receiver was cut off from power, it takes several minutes, but thats also ok with me since I still only have to turn it on and type "gps 1".
I don't want to derail this thread, so I'll just mention the important points I found out to make things work:
* the rfcomm bind option is a BIG NO NO to me as it freezes my system after suspend/resume (I think sometimes even during normal bind-release cycles), so I only use rfcomm connect instead
* after the bluetooth connection is terminated the receiver goes into stand-by after a short time, so I have to turn it back on manually whenever I want to use it again
* my script first kills any left over xgps, gpsd and rfcomm processes and then utilizes a loop with the command (started as background process in order to not interfere with the execution of the script) until the corresponding character device /dev/rfcommX is present and then calls Writing udev rules to automate this is possible, but I don't need nor want that.

TL; DR
If you're having trouble with your internal non bluetooth GPS, you might as well try a script

I dont know if this will help, but...

I just loaded Fedora 18/KDE on a CF-29 MK1. Updates (852) were killing my bandwidth so I went
to the library, I set the power settings to ignore the lid closing, I downloaded the updates and shut
the lid as I walked over to get food, the screen went black even though it was supposed to ignore
the lid closing. I opened it back up and the screen lit up and its still downloading, finished the
download and shut the lid as I drove home. It did what it was supposed to and kept running to
finish installing the updates. (about 900MB of updates, it ran for a while)

I dont know the difference between a 29 and 30's innards but the screen was not supposed to black
out but it did and it lit up at the same angle when opening. System never stopped but the display was
affected. I dont know if it was a direct hardware/switch cutoff of the signal or if X as stopped.

Am I the only one to read this thread title as sung by Tina Turner?

Just found this on the Mint Forums:
http://forums.linuxmint.com/viewtopic.php?f=90&t=168383