All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pavel Machek <pavel@suse.cz>
Cc: James Simmons <jsimmons@infradead.org>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH] Framebuffer: 2nd try: client notification mecanism & PM
Date: 07 Aug 2003 16:37:11 +0200	[thread overview]
Message-ID: <1060267031.722.3.camel@gaston> (raw)
In-Reply-To: <20030807100309.GB166@elf.ucw.cz>


> I believe solution to this is simple: always switch to kernel-owned
> console during suspend. (swsusp does it, there's patch for S3 to do
> the same). That way, Xfree (or qtopia or whoever) should clean up
> after themselves and leave the console to the kernel. (See
> kernel/power/console.c)

I tried using it on pmac, but it causes hell with XFree. I'm not sure
what's up yet, I suspect it may be XFree still doing things after
calling the RELDISP ioctl but I'm not completely sure yet.

The setup XFree + DRI is working without switching to suspend console
(with only the apm_bios emulation for XFree to suspend/restore itself)
but not when switching to suspend console right before doing the apm
emulation callbacks (which should be ignored by X since it's no longer
the frontmost process at this point).

For some reason, it seems that after we have switched to the suspend
console, we race with the X server on accel engine, and on resume, the X
server just crashes.

Ben.
 


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pavel Machek <pavel@suse.cz>
Cc: James Simmons <jsimmons@infradead.org>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	Linux Fbdev development list 
	<linux-fbdev-devel@lists.sourceforge.net>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM
Date: 07 Aug 2003 16:37:11 +0200	[thread overview]
Message-ID: <1060267031.722.3.camel@gaston> (raw)
In-Reply-To: <20030807100309.GB166@elf.ucw.cz>


> I believe solution to this is simple: always switch to kernel-owned
> console during suspend. (swsusp does it, there's patch for S3 to do
> the same). That way, Xfree (or qtopia or whoever) should clean up
> after themselves and leave the console to the kernel. (See
> kernel/power/console.c)

I tried using it on pmac, but it causes hell with XFree. I'm not sure
what's up yet, I suspect it may be XFree still doing things after
calling the RELDISP ioctl but I'm not completely sure yet.

The setup XFree + DRI is working without switching to suspend console
(with only the apm_bios emulation for XFree to suspend/restore itself)
but not when switching to suspend console right before doing the apm
emulation callbacks (which should be ignored by X since it's no longer
the frontmost process at this point).

For some reason, it seems that after we have switched to the suspend
console, we race with the X server on accel engine, and on resume, the X
server just crashes.

Ben.
 

  parent reply	other threads:[~2003-08-07 14:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-29 13:13 [PATCH] Framebuffer: client notification mecanism & PM Benjamin Herrenschmidt
2003-07-29 17:49 ` Pavel Machek
2003-07-30 12:14   ` Benjamin Herrenschmidt
2003-07-30 13:10     ` [PATCH] Framebuffer: 2nd try: " Benjamin Herrenschmidt
2003-07-30 13:14     ` Benjamin Herrenschmidt
2003-07-30 13:14       ` Benjamin Herrenschmidt
2003-08-01 10:04       ` Benjamin Herrenschmidt
2003-08-01 10:04         ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-08-06 23:52         ` James Simmons
2003-08-06 23:52           ` [Linux-fbdev-devel] " James Simmons
2003-08-07  9:38           ` Benjamin Herrenschmidt
2003-08-07  9:38             ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-08-07 10:03             ` Pavel Machek
2003-08-07 10:03               ` [Linux-fbdev-devel] " Pavel Machek
2003-08-07 13:32               ` Benjamin Herrenschmidt
2003-08-07 13:32                 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-08-07 17:26                 ` James Simmons
2003-08-07 21:38                 ` Nigel Cunningham
2003-08-07 21:38                   ` [Linux-fbdev-devel] " Nigel Cunningham
2003-08-07 21:51                   ` Pavel Machek
2003-08-07 21:51                     ` [Linux-fbdev-devel] " Pavel Machek
2003-08-07 14:37               ` Benjamin Herrenschmidt [this message]
2003-08-07 14:37                 ` Benjamin Herrenschmidt
2003-08-07 17:28                 ` James Simmons
2003-08-07 17:28                   ` [Linux-fbdev-devel] " James Simmons
2003-08-07 20:29                 ` Pavel Machek
2003-08-07 17:23               ` James Simmons
2003-08-07 20:29                 ` Pavel Machek
2003-08-07 20:29                   ` [Linux-fbdev-devel] " Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1060267031.722.3.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.