search for: unblanking

Hi, thanks for taking a look at the patches. Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: >> Set the VGA bit for unblanking with macro constants instead of magic >> values. No functional changes. > > blank/unblank should work simliar to bochs (see commit 250e743915d4), > that is maybe a nice thing to add of you modernize the driver anyway. Yeah, it's the VGA PAS field. [1] But is it really called bla...

Set the VGA bit for unblanking with macro constants instead of magic values. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/tiny/cirrus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c...

On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: > Set the VGA bit for unblanking with macro constants instead of magic > values. No functional changes. blank/unblank should work simliar to bochs (see commit 250e743915d4), that is maybe a nice thing to add of you modernize the driver anyway. take care, Gerd

On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote: > Hi, > > thanks for taking a look at the patches. > > Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: > > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: > >> Set the VGA bit for unblanking with macro constants instead of magic > >> values. No functional changes. > > > > blank/unblank should work simliar to bochs (see commit 250e743915d4), > > that is maybe a nice thing to add of you modernize the driver anyway. > Yeah, it's the VGA PAS field. [1] Bu...

...23 at 01:03:02PM +0100, Thomas Zimmermann wrote: >> Hi, >> >> thanks for taking a look at the patches. >> >> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann: >>> On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote: >>>> Set the VGA bit for unblanking with macro constants instead of magic >>>> values. No functional changes. >>> >>> blank/unblank should work simliar to bochs (see commit 250e743915d4), >>> that is maybe a nice thing to add of you modernize the driver anyway. >> Yeah, it's the VGA PA...

https://bugs.freedesktop.org/show_bug.cgi?id=103383 Bug ID: 103383 Summary: "xset dpms force on" does not unblank laptop screen after "xset dpms force off" is run (or system enters sleep mode) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: All

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e causes the screen stay blank. Add a bool to force an update to fix that. Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> ---

On Mon, Aug 24, 2020 at 09:24:40AM +0200, Jiri Slaby wrote: > On 18. 08. 20, 9:25, Gerd Hoffmann wrote: > > When going through a disable/enable cycle without changing the > > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: > > skip set_scanout if framebuffer didn't change") causes the screen stay > > blank. Add a bool to force an

On Fri, Aug 07, 2020 at 12:54:29PM +0200, Gerd Hoffmann wrote: > When going through a disable/enable cycle without changing the > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: > skip set_scanout if framebuffer didn't change") causes the screen stay > blank. Add a bool to force an update to fix that. > > Cc: 1882851 at bugs.launchpad.net

Hi, > > --- a/drivers/gpu/drm/virtio/virtgpu_display.c > > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c > > @@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc, > > struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); > > > > output->enabled = true; > > + output->need_update = true; >

I have an Alienware laptop that has Nvidia GTX 880M hardware driven by this driver. I recently purchased an ASUS_VN289H monitor. When my system gives a blanking command, the monitor returns some sort of lost signal message which causes the monitor to unblank and the time out I requested is cancelled. This is probably more of an HDMI question than specific to this hardware, but I was wondering

On 01/26/2016 02:40 PM, Ilia Mirkin wrote: > What you're asking for isn't particularly clear... when DPMS is > enabled, instead of suspending the monitor says "no signal" as if it > had been unplugged? Or is something else going on? Then you talk about > passing signals "up the chain" and "filtering"? What signals? What > chain? > > Can

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't

On Tue, Jan 26, 2016 at 5:19 PM, don fisher <hdf3 at comcast.net> wrote: > I am running under openSuse, but trying to avoid most of the GUIs. I cannot > get xset to blank the screen, so I added consoleblank=600 in the grub file > to be added to the kernel command line. The system blanks after 10 minutes, > as expected. The monitor then displays "HDMI/MHL-1 NO SIGNAL",

2014-02-09 23:12 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki <zajec5 at gmail.com> wrote: >> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and >> noticed nasty display corruptions when using nouveau. It seems that >> changing parts of the screen are appearing for a fraction of second in

In the past I've found that the console may have blanked (due to time) and when the system locked up/hung it won't unblank. Booting with "consoleblank=0" on the kernel command line will ensure that whatever is printed to the console (oops, panic, etc) will be there for you to see when you connect. I've had intermittent success in that type of situation with the SysRq key(s),

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are

Move final cleanups from cirrus_pci_remove() to the new callback. Add drm_atomic_helper_shutdown() call to cirrus_pci_remove(). Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. v4: add changelog. v3: use drm_dev*. v2: stop touching hardware after pci_remove(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus.c | 43