I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.
Cheers.
In article D8Xtf.20426$AP5.3278@redacted.invalid, johnny bobby bee useraddshine_eh@redacted.invalid wrote:
I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.
Probably not, as sleep depends on code external to the UNIX kernel.
In article D8Xtf.20426$AP5.3278@redacted.invalid, johnny bobby bee useraddshine_eh@redacted.invalid wrote:
I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.
AppleScript is your friend:
osascript -e 'tell application "Finder" to sleep'
This make not work if the user you're logged in as isn't logged into the GUI.
- johnny bobby bee (2006-01-01):
I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.
Darwinports has got a sleepnow package.
-Andre
ZnU wrote:
AppleScript is your friend:
osascript -e 'tell application "Finder" to sleep'
Wacky applescript, it works; cheers.
Hans Aberg wrote:
Probably not, as sleep depends on code external to the UNIX kernel.
OS X doesn't really use a traditional UNIX kernel, does it? Panther has replaced init (and others?) with launchd. So, you'd think there could be a built-in apple command to initiate sleep. I'm no apple scripter, but as we see below it can be done with an apple script from terminal. Just thought there would be something like apm or acpid.
In article 3S4uf.28618$6K2.4137@redacted.invalid, johnny bobby bee useraddshine_eh@redacted.invalid wrote:
Hans Aberg wrote:
Probably not, as sleep depends on code external to the UNIX kernel.
OS X doesn't really use a traditional UNIX kernel, does it?
Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel. Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).
In article 3S4uf.28618$6K2.4137@redacted.invalid, johnny bobby bee useraddshine_eh@redacted.invalid wrote:
OS X doesn't really use a traditional UNIX kernel, does it? Panther has replaced init (and others?) with launchd. So, you'd think there could be a built-in apple command to initiate sleep.
Looking at 'man launchd' and 'man init', launchd is used as the root process with PID = 1, and at the end of the boot process, it launches init, which would be the normal root process under BSD. The UNIX kernel (Mach under Mac OS X), does however itself not launch any programs or processes: only a process can launch another process. The kernel just keeps track of these processes, scheduling them, making sure they do not do anything illegal. So all processes end up on a parent-child tree, depending how processes (parents) launch other processes (children).
Then the UNIX kernel cannot go to sleep by itself. So Apple must have installed some other code, first called at boot. Probably launchd links the UNIX kernel to this other code at boot, though I do not see exactly how. But the result is not only the ability to go to sleep, but the inability to handle certain code, kernel panics.
johnny bobby bee useraddshine_eh@redacted.invalid wrote:
ZnU wrote:
AppleScript is your friend:
osascript -e 'tell application "Finder" to sleep'
Wacky applescript, it works; cheers.
Not really wacky. the 'tell ...' is just a straighforward AppleScript,
osacript is a way of running AppleScripts in the shell,
and the flag -e says that the script to run is the bit in quotes. If you had saved a script, as scriptname then
osascript fullpathtoscriptname
would run the script.
Daniel Cohen wrote:
Not really wacky. the 'tell ...' is just a straighforward AppleScript,
and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.
johnny bobby bee useraddshine_eh@redacted.invalid wrote in news:q5iuf.20206 $km.15496@redacted.invalid:
Daniel Cohen wrote:
Not really wacky. the 'tell ...' is just a straighforward AppleScript,
and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.
That's Applescript's syntax:
Tell application.app do this, that, and everything end tell
In article haberg-0201061055260001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article 3S4uf.28618$6K2.4137@redacted.invalid, johnny bobby bee useraddshine_eh@redacted.invalid wrote:
Hans Aberg wrote:
Probably not, as sleep depends on code external to the UNIX kernel.
OS X doesn't really use a traditional UNIX kernel, does it?
Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel.
Well, sort of. The OS X kernel is actually an odd combination of Mach code and kernel code borrowed from various BSD systems.
Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.
In article znu-F6B1F2.20180502012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX kernel extensions, as it affects reliability, for example.
The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.
For Mac OS X, it seems that one has added a mini-OS, by which the FreeBSD and its Mach kernel run within.
But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.
The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself. Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.
In article znu-F6B1F2.20180502012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.
johnny bobby bee useraddshine_eh@redacted.invalid wrote:
Daniel Cohen wrote:
Not really wacky. the 'tell ...' is just a straighforward AppleScript,
and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.
Come to think of it, my version of the instructions was
tell "System Events" to sleep
That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.
The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.
On Tue, 3 Jan 2006 13:09:01 +0000, Daniel Cohen wrote:
johnny bobby bee useraddshine_eh@redacted.invalid wrote:
Daniel Cohen wrote:
Not really wacky. the 'tell ...' is just a straighforward AppleScript,
and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.
Come to think of it, my version of the instructions was
tell "System Events" to sleep
That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.
The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.
No, 'sleep' is a menu item in the Apple Menu, which is shared by all applications.
In article haberg-0301061106310001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-F6B1F2.20180502012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.
Huh? No code executes while the computer is sleeping. The CPU isn't even powered. And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.
In article haberg-0301061058340001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-F6B1F2.20180502012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX kernel extensions, as it affects reliability, for example.
The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.
For Mac OS X, it seems that one has added a mini-OS, by which the FreeBSD and its Mach kernel run within.
There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs on top of this kernel.
But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.
The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself.
There is nothing in OS X which occurs outside of the *nix environment.
Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.
Once again, there is no separate UNIX environment in OS X. OS X is a *nix operating system. All the Mac-like stuff runs within this environment.
In article znu-66453B.15232003012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.
Huh? No code executes while the computer is sleeping. The CPU isn't even powered.
It sounds logical. But there has something that brings it back to life. An interrupt of some kind.
And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.
It can take minutes before the kernel is loading, though.
In article znu-7E587F.15384403012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs on top of this kernel.
So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads). So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.
In article haberg-0401060133200001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-66453B.15232003012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.
Huh? No code executes while the computer is sleeping. The CPU isn't even powered.
It sounds logical. But there has something that brings it back to life. An interrupt of some kind.
Sure, but it's not part of the operating system, or any other software. It's a hardware feature.
And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.
It can take minutes before the kernel is loading, though.
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
momentum:/ znu$ ls -l mach_kernel -rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel
In article haberg-0401060137500001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-7E587F.15384403012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs on top of this kernel.
So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).
That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.
So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.
Mach is a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.
The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.
There's a decent high-level overview at:
http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html
In article znu-662F3B.20352903012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
momentum:/ znu$ ls -l mach_kernel -rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel
Yeah, this confused me for a while, too. I think he is thinking of some of the maintenance tasks early in startup.
In article haberg-0301061106310001@redacted.invalid, Hans Aberg haberg@redacted.invalid wrote:
In article znu-F6B1F2.20180502012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run.
The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.
Matthew Russotto wrote:
The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.
I am hoping at this point, one of the readers of the "sleep from..." thread can give a hint as to why a mouse would not work after sleep?
iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking. The only two things I have found that work, are a reboot or unplugging the USB connection for the mouse receiver. I also tried using the "number keys as mouse option" to force-quit finder but that didn't help. Anything I can type in Terminal to reload something? (driver, extension, kernel, something else?) I have installed the latest Logitech driver, but this seems USB related, not internal (right?) GW
In article znu-662F3B.20352903012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
It can take minutes before the kernel is loading, though.
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.
In article znu-C11FA8.20435803012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).
That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.
This is just the standard description of UNIX and BSD UNIX, as in books: Bach, "The Design of the UNIX operating system" Leffler et al., "The Design and Omplementaion of the BSD UNIX OS"
So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.
Mach is a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.
The original Mach required a lot of information being passed thorugh it, making it slow, but later versions, I am told, have been more monolithic, whatever that means.
The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.
The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.
There's a decent high-level overview at:
http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html
Thanks for the link. But does not seem to address the kernel structure issue.
In article 77KdneD9MvnRySbeRVn-oQ@redacted.invalid, russotto@redacted.invalid (Matthew Russotto) wrote:
One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run.
The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.
Thank you. So it is the PMU one should get rid of. :-)
In article haberg-0401061030430001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-662F3B.20352903012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
It can take minutes before the kernel is loading, though.
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.
When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.
In article haberg-0401061042300001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-C11FA8.20435803012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).
That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.
This is just the standard description of UNIX and BSD UNIX, as in books: Bach, "The Design of the UNIX operating system" Leffler et al., "The Design and Omplementaion of the BSD UNIX OS"
So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.
Mach is a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.
The original Mach required a lot of information being passed thorugh it, making it slow, but later versions, I am told, have been more monolithic, whatever that means.
The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.
The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.
There's a decent high-level overview at:
http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html
Try: http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102
In article znu-34B7A2.10100004012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
It can take minutes before the kernel is loading, though.
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.
When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.
Right, but they should load early on.
In article znu-364084.10133804012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102
That is better. As for kernel vs. microkernel, there is probably a considerable flux as how to term what is what; see: http://en.wikipedia.org/wiki/Kernel_%28computer_science%29 http://en.wikipedia.org/wiki/Microkernel
In article haberg-0401061802430001@redacted.invalid, haberg@redacted.invalid (Hans Aberg) wrote:
In article znu-34B7A2.10100004012006@redacted.invalid, ZnU znu@redacted.invalid wrote:
It can take minutes before the kernel is loading, though.
Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:
If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.
When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.
Right, but they should load early on.
Sure, daemons will typically load during the bit of the boot sequence where the progress bar is displayed. You can hold down command-v (which switches to verbose boot mode) to see some of this.
In article sgMuf.9540$ka.4844@redacted.invalid, Geoff Welsh geoffdubya@redacted.invalid wrote:
I am hoping at this point, one of the readers of the "sleep from..." thread can give a hint as to why a mouse would not work after sleep?
iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.
If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.
Matthew Russotto wrote:
In article sgMuf.9540$ka.4844@redacted.invalid, Geoff Welsh geoffdubya@redacted.invalid wrote:
iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.
If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.
Thanks. IIRC, without the Logitech driver, the mouse response was unbearable. (Adjust in AppleSysPrefs all the way fast but would still take a foot to drag across screen.) I got this machine in July and the problem started in October or November. That's why I suspect an OS glitch from an update. GW
On 2006-01-05 01:15:00 -0500, Geoff Welsh geoffdubya@redacted.invalid said:
Matthew Russotto wrote:
In article sgMuf.9540$ka.4844@redacted.invalid, Geoff Welsh geoffdubya@redacted.invalid wrote:
iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.
If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.
Thanks. IIRC, without the Logitech driver, the mouse response was unbearable. (Adjust in AppleSysPrefs all the way fast but would still take a foot to drag across screen.) I got this machine in July and the problem started in October or November. That's why I suspect an OS glitch from an update. GW
You could try removing the Logitech drivers and installing USB Overdrive. http://www.usboverdrive.com
Malcolm wrote:
On 2006-01-05 01:15:00 -0500, Geoff Welsh geoffdubya@redacted.invalid said:
Matthew Russotto wrote:
In article sgMuf.9540$ka.4844@redacted.invalid, Geoff Welsh geoffdubya@redacted.invalid wrote:
iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.
If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.
Thanks. IIRC, without the Logitech driver, the mouse response was unbearable.
That's why I suspect an OS glitch from an update. GWYou could try removing the Logitech drivers and installing USB Overdrive. http://www.usboverdrive.com
Good tip, thanks. I started reading about that Overdrive the other day, but haven't finished. Anyone know how to remove a driver? It shows in the "Other" section of System Prefs as "Logitech Control Center" GW