~Toughbooktalk~

mklym wrote:
I ran the code and this is what I got:

Code: Select all

morgan@CF-30MK3Mint17 ~ $ xset dpms force off; xset dpms force on
morgan@CF-30MK3Mint17 ~ $ sudo echo -n mem > /sys/power/state
bash: /sys/power/state: Permission denied

When I ran xset command, the screen went black and immediately came back on.

The screen was meant to go black then back on. Each command was meant as a test to try individually to see if it somehow affects gpsd. The second command didn't work because your system lacks a /sys/power/state file and is using an alternate method for suspending.

It's all moot since Jeff seems to have figured out a workaround.

There's still something wrong with the kernel or?????????????????????

Is there a way to roll the Intel Video back just for my own edification and amusement.

This close the lid magic has been going on for quite a while...I remember people talking about putting units on stand-by and coming back to a working GPS.

This seems to work with most of the flickering screen distros....I'll confirm it if I don't forget.

Thanks for the help mklym and kode.

J'd from 74J-W7-SSD

Kali doesn't flicker on my CF-30. Maybe we should compare?

kode-niner wrote:

mklym wrote:
I ran the code and this is what I got:

Code: Select all

morgan@CF-30MK3Mint17 ~ $ xset dpms force off; xset dpms force on
morgan@CF-30MK3Mint17 ~ $ sudo echo -n mem > /sys/power/state
bash: /sys/power/state: Permission denied

When I ran xset command, the screen went black and immediately came back on.

The screen was meant to go black then back on. Each command was meant as a test to try individually to see if it somehow affects gpsd. The second command didn't work because your system lacks a /sys/power/state file and is using an alternate method for suspending.

It's all moot since Jeff seems to have figured out a workaround.

Silly me! Here I thought you wanted feedback. My mistake.
Merry Christmas Nick.

mklym wrote:
Silly me! Here I thought you wanted feedback. My mistake.
Merry Christmas Nick.

Haha, I work better in the dark. Seriously, though, I appreciate your feedback. Since I am not running an OS with GPS problems at the moment, I can only lob in a few suggestions for things to try.

Cheers and merry Christmas!

Code: Select all

morgan@CF-30MK3Mint17 ~ $ xset dpms force off; xset dpms force on
morgan@CF-30MK3Mint17 ~ $ sudo echo -n mem > /sys/power/state
bash: /sys/power/state: Permission denied

When I ran xset command, the screen went black and immediately came back on.

In order to avoid the "Permission denied" error, you either have to sudo into a root shell (i.e. sudo -s or other options with different implications; see "man sudo"), or use "tee" instead of ">" for the writing part, as the root priviledges for the "echo" command are no longer valid for the following ">" command and /sys/power/state only has write permissions set for root: I am not familiar with Mint, but since it's Ubuntu/Debian based, I might give some advice to encircle the problem.
Find out if your desktop environment settings do initiate some power savings procedure (suspend/hibernation) on closing the lid.
I suppose a suspend to RAM is kicked off. Then check for discrepancies between /var/log/syslog and /var/log/pm-* concerning gpsd. You may also look into /etc/init.d/gpsd (start script for boot up) and /etc/default/gpsd (default config file; this probably is where you have to change settings) and use to look for differences in the deamon process options.

Or maybe gpsd gets started too soon in the boot process, so some dependencies are not met. In order to test this restart gpsd again at the end of the boot process by inserting into "/etc/rc.local" or restart it manually.

Finally a general tip for comparing/editing differences betwenn files if you're not just using a shell: install "meld" if it's in the Mint Repositry (best diff program I could find).

Best wishes to everyone for the holiday season

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

fleecy sheep,

We have two things weirdly affected by lid closure. One is the flickering screen syndrome where the OS does not use the laptop screen numbers for LVDS1 1024x768....cured by shutting the lid, changing to any other numbers like 800x600 and return and a couple other things.
This can be avoided by setting bios to internal monitor only.

Then by accident we found that xgps was cured by shutting the lid (stand-by). Most of the contributors to this thread have been talking about this for quite a while. Figuring out if they are related makes my head hurt.

Me: Mint 16 works fine. Mint 17 and 17.1 have issues. Common denominator (this is me) xorg video driver 15.0. Again because it makes my head hurt I am blaming this.

Summation I hope: I like 17 and 17.1 for Mark 1 and 3 CF-30. (Mark 2 doesn't flicker) Crutches or special settings in bios are repellent to me. Why? I want to tell new users that the OS works. My special group is interested in keeping "old" Toughbooks alive with new operating systems, so any new user can use them and love 'em like we do. Also repellent to me is to throw a $5200 machine in the dump. (Check pricing on CF-28's when they were new)

Slightly off topic with the 28 but we have a division of TDR working on mini-Linux. That is any Linux boot disk that is non-PAE and that will fit on a CD-Rom.

Anyhoo...appreciate the information half of which I need to go back and study. And again welcome. Don't be a stranger.

Jeff....TDR-HQ...

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

Nice! Thanks!

Jeff, for operating systems that will fit on a CD, check this link:
http://www.livecdlist.com/?order=field_minsize&sort=asc
I'm currently running WattOS (microwatt) R8 found here: http://www.planetwatt.com/pages/downloads
on the M-34, CF-28, and CF-18. One quirky thing is that after updating the system from the menu, if you want to add anything in Synaptic Package Manager, you need to go into Terminal and change permission-
gksu-properties
This link explains what I am trying to say:
http://planetwatt.com/newforum/index.ph ... sg18#msg18