Hi!
> [ Not need to cc, I joined the list ]
> > > Second, suspend is not a good name for a binary. Because (as other
> > > people have brought up already) suspend is a build in command in
> > > bash.
> >
> > This was rasied a few days ago, it was decided to change name after
> > 0.2.
>
> OK, th
On Tue 2006-06-27 13:17:18, Tim Dijkstra wrote:
> Hi,
>
> I added my machines to the whitelist.c. One is a desktop system, 's2ram
> -n' only identifies it with the bios version. Also the work around is
> likely to be only necessary because of the video card (nvidia riva tnt)
> I use, isn't it? So
Hi!
> I added my machines to the whitelist.c. One is a desktop system, 's2ram
> -n' only identifies it with the bios version. Also the work around is
> likely to be only necessary because of the video card (nvidia riva tnt)
> I use, isn't it? So I don't know if it is wise to add it. Seems like a
>
[ Not need to cc, I joined the list ]
On Tue, 27 Jun 2006 21:22:40 +0200
Luca <[EMAIL PROTECTED]> wrote:
> Il Tue, Jun 27, 2006 at 01:11:23PM +0200, Tim Dijkstra ha scritto:
> > Second, suspend is not a good name for a binary. Because (as other
> > people have brought up already) suspend is a bu
On Tue, 27 Jun 2006 21:08:32 +0200
Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > While packaging suspend I ran in a few design problems, which I
> > solved (IMHO) in an elegant way.
> >
> > First the fact that if you want to both suspend-to-disk and
> > suspend-to-both in a regular basis y
Il Tue, Jun 27, 2006 at 01:11:23PM +0200, Tim Dijkstra ha scritto:
> Second, suspend is not a good name for a binary. Because (as other
> people have brought up already) suspend is a build in command in bash.
This was rasied a few days ago, it was decided to change name after 0.2.
> Also it is a
Hi!
> While packaging suspend I ran in a few design problems, which I solved
> (IMHO) in an elegant way.
>
> First the fact that if you want to both suspend-to-disk and
> suspend-to-both in a regular basis you need to config files which
> are identical except for a line 'suspend to both ='.
Why?
Hi!
> > > Right now, there is no problem in co-existing, the pm-utils scripts
> > > just need
> >
> > Well, maintaining two whitelists is going to be ugly. But HAL parsing
> > whitelist from s2ram would be okay... as would be teaching s2ram to
> > use HAL whitelist.
>
> I think the latter is mos
Hi!
> > It uses different criteria (PCI vendor [sub]IDs). Are they better?
>
> Seems to work just the same as we are matching both the card and the
> subvendor (i.e. the system builder) and seems to work in a more general
> way to raw dmi matching.
Okay, good.
> > It does not seem to be able to
Hi,
I added my machines to the whitelist.c. One is a desktop system, 's2ram
-n' only identifies it with the bios version. Also the work around is
likely to be only necessary because of the video card (nvidia riva tnt)
I use, isn't it? So I don't know if it is wise to add it. Seems like a
deficienc
Hi all,
While packaging suspend I ran in a few design problems, which I solved
(IMHO) in an elegant way.
First the fact that if you want to both suspend-to-disk and
suspend-to-both in a regular basis you need to config files which
are identical except for a line 'suspend to both ='.
This is not n
On Tue, 2006-06-27 at 00:53 +0200, Pavel Machek wrote:
> Hi!
>
> > > You can easily use the fdi whitelist (and using HAL) doing this:
> > >
> > > # Suspend all video devices using the HAL dbus methods
> > > devices=`hal-find-by-capability --capability video_adapter_pm`
> > > for device in $device
On Tue, 2006-06-27 at 01:04 +0200, Pavel Machek wrote:
> Hi!
>
> > > If somebody really wants to implement the complex matching in s2ram, there
> > > should be no problem to either implement an fdi parser or just write a
> > > small
> > > converter that "compiles" the HAL fdi files to include the
13 matches
Mail list logo
