2010/8/16 Jung-uk Kim <j...@freebsd.org>: > On Monday 16 August 2010 06:34 am, David DEMELIER wrote: >> I enabled device dpms, and vesa stuff in the -CURRENT GENERIC >> kernel config but for the moment it resumes well (even the screen!) >> but take a look at the graphic output : >> >> http://files.malikania.fr/Photo0176.jpg >> >> This is X after resuming. Maybe the graphic card `cache|buffer' >> should be cleaned. >> >> Suspend and resuming works on my laptop now ! > > I am glad to hear it helped. :-) > > X.org framebuffer corruption is a totally different issue. For > example, xf86-video-ati saves/restores everything when VT is > switching (not only 2D frame buffer but also 3D texture buffer and > some critical GPU registers, etc), which is the behaviour we are > heavily relying on. In other words, if X.org driver "owns" the video > card, we force switching to the first VT (just as we pressed > CTRL-ALT-F1) so that X.org driver "releases" the video card before we > suspend console, assuming the current video card state is completely > saved by X.org driver. That way, we can just save the console state > and we don't need to worry about X.org or whatever. Conversely, when > we resume, we just restore the console state and switch VT (just as > we pressed ALT-F9) assuming X.org driver will restore the previous > state. If any X.org video drivers don't do it properly, we lose. I > guess you may be experiencing this problem. We may save/restore > "some" video memory contents but it is not a good idea because we can > easily clobber X.org driver's idea of current state. > > Unfortunately, it is even possible some video drivers may not do it > any more as Linux people started moving this type of stuff out of > X.org drivers into Linux kernel and "old school" stuff (e.g., VT > switching from user land) is no longer maintained well or not > supported. :-( > > Jung-uk Kim >
By the way, we can suspend with drm now, but resume make Xorg so slow... Sad. -- Demelier David _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"