similar to: [PATCH 26/26] drm/<drivers>: Don't set FBINFO_(FLAG_)DEFAULT

On Thu, 24 Jan 2019 at 17:00, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > > It's 0. > I'd add a bit more information here. Feel free to reuse as much/little of the following: Both macros evaluate to 0. At the same time flag is already set to zero since the struct is kzalloc'd in framebuffer_alloc(). As called by drm_fb_helper_alloc_fbi() in the DRM drivers.

This was only added for the drm's fbdev emulation support, so that it would try harder to show the Oops. Unfortunately this never really worked reliably, and in practice ended up pushing the real Oops off the screen due to plentyfull locking, sleep-while-atomic and other issues. So we removed all that support from the fbdev emulation a while back. Aside: We've also removed the kgdb

Am Dienstag, 27. November 2018, 18:34:24 CET schrieb Daniel Vetter: > KMS drivers really should all be able to restore their display state > on resume without fbcon helping out. So make this the default. > > Since I'm not entirely foolish, make it only a default, which drivers > can still override. That way when the inevitable regression report > happens I can fix things up

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1

It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1

This patch changes DRM clients to not map the buffer by default. The buffer, like any buffer object, should be mapped and unmapped when needed. An unmapped buffer object can be evicted to system memory and does not consume video ram until displayed. This allows to use generic fbdev emulation with drivers for low-memory devices, such as ast and mgag200. This change affects the generic framebuffer

noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 8 +++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 10 ++++++--

Generic framebuffer emulation uses a shadow buffer for framebuffers with dirty() function. If drivers want to use the shadow FB without such a function, they can now set prefer_shadow or prefer_shadow_fbdev in their mode_config structures. The former flag is exported to userspace, the latter flag is fbdev-only. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Hi Am 07.07.19 um 16:37 schrieb Noralf Tr?nnes: > > > Den 05.07.2019 11.26, skrev Thomas Zimmermann: >> Generic framebuffer emulation uses a shadow buffer for framebuffers with >> dirty() function. If drivers want to use the shadow FB without such a >> function, they can now set prefer_shadow or prefer_shadow_fbdev in their >> mode_config structures. The former

Not needed any more, bochs uses the generic emulation now. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs.h | 9 --- drivers/gpu/drm/bochs/bochs_drv.c | 6 -- drivers/gpu/drm/bochs/bochs_fbdev.c | 137 ------------------------------------ 3 files changed, 152 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. v6: * don't call page_to_phys() on framebuffers in

I verified this is from SANS, and there is a FBI advisory --dave ------------- Begin Forwarded Message ------------- From: The SANS Institute <sans@sans.org> Subject: Virus Alert: FBI Finds 911 Virus Wiping Out Hard Drives Today To: David Collier-Brown (SD143961) <davecb@canada.sun.com> To: David Collier-Brown (SD143961) From: The SANS Institute Research Office Subj: Malicious 911

let vga16fb claim 0xA0000+0x10000 region as its aperture; drm drivers don't use it, so we have to detect it and kick vga16fb manually - but only if drm is driving the primary card Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: James Simmons <jsimmons at infradead.org> Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> --- no

Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures. The former flag is exported to userspace, the latter > flag is fbdev-only. > >

Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures. The former flag is exported to userspace, the latter > flag is fbdev-only. > >

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel

Lovely diffstat, thanks to the new generic fbdev emulation. drm/qxl/Makefile | 2 drm/qxl/qxl_draw.c | 232 ---------------------------------------- drm/qxl/qxl_drv.h | 21 --- drm/qxl/qxl_fb.c | 300 ----------------------------------------------------- Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 21 ---

A couple of new warnings and build errors appeared through the DRM tree in linux-next after the merge window opened. The first patch here is for scripts/headers_check.pl, but as the bug is only present in drm-next at the moment, it would be good to add all five patches to that tree before they make it into mainline. It's likely that some of these have already been fixed since this