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 :
>> 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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"